Re: [freenet-dev] Updating helper executables on Windows
On Tue, Aug 25, 2009 at 6:59 PM, Matthew Toseland wrote: > On Friday 07 August 2009 04:17:34 Juiceman wrote: >> On Thu, Aug 6, 2009 at 6:57 AM, Matthew >> Toseland wrote: >> > On Thursday 06 August 2009 01:30:10 Juiceman wrote: >> >> On Wed, Aug 5, 2009 at 8:02 PM, Zero3 wrote: >> >> > Juiceman skrev: >> >> >>> Sorry, these are uploaded manually at the moment. The sha1's have >> >> >>> been fixed for now. >> >> >> >> >> >> Thanks! >> >> > >> >> > How are you doing on this? And do you need any more info about shutting >> >> > down tray managers or other stuff? Anything? >> >> >> >> I ran into two snags with sha1test.jar >> >> 1. It seems to only look in >> >> http://downloads.freenetproject.org/alpha/ and not the subdirectory >> >> /installer/ >> > >> > Even if you pass in installer/filename ?? >> >> It seems to be a problem with the website actually. >> https://checksums.freenetproject.org/latest/ contains the actual >> files, but not the .sha1 files for the helper executables > > Fixed, and updated the scripts so it should stay fixed. >> >> >> 2. It tries to connect 10 times and then fails because of #1, but >> >> returns an errorlevel code of 0. That is bad. >> >> Nevermind on this part. I needed to do %ERRORLEVEL% NEQ 0 instead of >> NOT ERRORLEVEL 0 > > Fixed? Yes. :-) I just just pushed a patch to enable the new functionality. imho it's ready for go-live. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
On Friday 07 August 2009 04:17:34 Juiceman wrote: > On Thu, Aug 6, 2009 at 6:57 AM, Matthew > Toseland wrote: > > On Thursday 06 August 2009 01:30:10 Juiceman wrote: > >> On Wed, Aug 5, 2009 at 8:02 PM, Zero3 wrote: > >> > Juiceman skrev: > >> >>> Sorry, these are uploaded manually at the moment. The sha1's have been > >> >>> fixed for now. > >> >> > >> >> Thanks! > >> > > >> > How are you doing on this? And do you need any more info about shutting > >> > down tray managers or other stuff? Anything? > >> > >> I ran into two snags with sha1test.jar > >> 1. It seems to only look in > >> http://downloads.freenetproject.org/alpha/ and not the subdirectory > >> /installer/ > > > > Even if you pass in installer/filename ?? > > It seems to be a problem with the website actually. > https://checksums.freenetproject.org/latest/ contains the actual > files, but not the .sha1 files for the helper executables Fixed, and updated the scripts so it should stay fixed. > > >> 2. It tries to connect 10 times and then fails because of #1, but > >> returns an errorlevel code of 0. That is bad. > > Nevermind on this part. I needed to do %ERRORLEVEL% NEQ 0 instead of > NOT ERRORLEVEL 0 Fixed? signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
On Fri, Aug 7, 2009 at 3:24 PM, Matthew Toseland wrote: > On Friday 31 July 2009 01:53:59 Juiceman wrote: >> On Thu, Jul 30, 2009 at 1:04 PM, Matthew >> Toseland 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 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 >> >> > > 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/, 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 Ove
Re: [freenet-dev] Updating helper executables on Windows
On Friday 31 July 2009 01:53:59 Juiceman wrote: > On Thu, Jul 30, 2009 at 1:04 PM, Matthew > Toseland 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 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 > >> > > 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/, 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: Wininst
Re: [freenet-dev] Updating helper executables on Windows
On Thu, Aug 6, 2009 at 6:57 AM, Matthew Toseland wrote: > On Thursday 06 August 2009 01:30:10 Juiceman wrote: >> On Wed, Aug 5, 2009 at 8:02 PM, Zero3 wrote: >> > Juiceman skrev: >> >>> Sorry, these are uploaded manually at the moment. The sha1's have been >> >>> fixed for now. >> >> >> >> Thanks! >> > >> > How are you doing on this? And do you need any more info about shutting >> > down tray managers or other stuff? Anything? >> >> I ran into two snags with sha1test.jar >> 1. It seems to only look in >> http://downloads.freenetproject.org/alpha/ and not the subdirectory >> /installer/ > > Even if you pass in installer/filename ?? It seems to be a problem with the website actually. https://checksums.freenetproject.org/latest/ contains the actual files, but not the .sha1 files for the helper executables >> 2. It tries to connect 10 times and then fails because of #1, but >> returns an errorlevel code of 0. That is bad. Nevermind on this part. I needed to do %ERRORLEVEL% NEQ 0 instead of NOT ERRORLEVEL 0 -- I may disagree with what you have to say, but I shall defend, to the death, your right to say it. - Voltaire Those who would give up Liberty, to purchase temporary Safety, deserve neither Liberty nor Safety. - Ben Franklin ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
On Thursday 06 August 2009 01:30:10 Juiceman wrote: > On Wed, Aug 5, 2009 at 8:02 PM, Zero3 wrote: > > Juiceman skrev: > >>> Sorry, these are uploaded manually at the moment. The sha1's have been > >>> fixed for now. > >> > >> Thanks! > > > > How are you doing on this? And do you need any more info about shutting > > down tray managers or other stuff? Anything? > > I ran into two snags with sha1test.jar > 1. It seems to only look in > http://downloads.freenetproject.org/alpha/ and not the subdirectory > /installer/ Even if you pass in installer/filename ?? > 2. It tries to connect 10 times and then fails because of #1, but > returns an errorlevel code of 0. That is bad. > > I was looking for the source for sha1test.jar so I could verify this > but I am having trouble locating it. In app-new_installer. signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
On Wed, Aug 5, 2009 at 8:02 PM, Zero3 wrote: > Juiceman skrev: >>> Sorry, these are uploaded manually at the moment. The sha1's have been >>> fixed for now. >> >> Thanks! > > How are you doing on this? And do you need any more info about shutting > down tray managers or other stuff? Anything? I ran into two snags with sha1test.jar 1. It seems to only look in http://downloads.freenetproject.org/alpha/ and not the subdirectory /installer/ 2. It tries to connect 10 times and then fails because of #1, but returns an errorlevel code of 0. That is bad. I was looking for the source for sha1test.jar so I could verify this but I am having trouble locating it. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
Juiceman skrev: >> Sorry, these are uploaded manually at the moment. The sha1's have been fixed >> for now. > > Thanks! How are you doing on this? And do you need any more info about shutting down tray managers or other stuff? Anything? - Zero3 ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
On Thu, Jul 30, 2009 at 1:04 PM, Matthew Toseland 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 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 >> > > 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/, 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! ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
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 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 > > > 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/, 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. signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
On Monday 13 July 2009 07:03:53 Juiceman wrote: > On Sat, Jun 13, 2009 at 1:57 PM, Zero3 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 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 > >> ___ > >> Devl mailing list > >> Devl@freenetproject.org > >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > >> > > 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/, 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. signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
Juiceman skrev: > On Tue, Jul 14, 2009 at 5:45 PM, Juiceman wrote: >> On Tue, Jul 14, 2009 at 8:46 AM, Zero3 wrote: >>> Juiceman skrev: On Mon, Jul 13, 2009 at 8:37 PM, Zero3 wrote: > Juiceman skrev: >> On Mon, Jul 13, 2009 at 10:59 AM, Zero3 wrote: >>> Juiceman skrev: 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 ;-) >>> Cool! Remember to update freenettray.exe as well. > > > I think I have finished update.cmd to handle all of the binaries. > I have these sections of the script bypassed until non-blank .sha1's > of the files on the website can be generated and Zero3 can finish the > freenettray.exe utility. Once those are done, I can fully test those > sections of the script and wire them in for final release. > We don't necessarily need to wait for the freenettray. The sha1's > will let me do most of the work that remains... > > Balls in your court gentlemen. =) Sweeet! I'm currently doing *major* update of the translation system in the wininstaller (mostly to simlpify the translation process for translators and reduce the number of strings and their lengths by reusing common ones). The service account reworking and tray manager are already done (but needs testing, if anyone bothers!). - Zero3 ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
On Tue, Jul 14, 2009 at 5:45 PM, Juiceman wrote: > On Tue, Jul 14, 2009 at 8:46 AM, Zero3 wrote: >> Juiceman skrev: >>> On Mon, Jul 13, 2009 at 8:37 PM, Zero3 wrote: Juiceman skrev: > On Mon, Jul 13, 2009 at 10:59 AM, Zero3 wrote: >> Juiceman skrev: >>> 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 ;-) >> Cool! Remember to update freenettray.exe as well. I think I have finished update.cmd to handle all of the binaries. I have these sections of the script bypassed until non-blank .sha1's of the files on the website can be generated and Zero3 can finish the freenettray.exe utility. Once those are done, I can fully test those sections of the script and wire them in for final release. We don't necessarily need to wait for the freenettray. The sha1's will let me do most of the work that remains... Balls in your court gentlemen. =) -- I may disagree with what you have to say, but I shall defend, to the death, your right to say it. - Voltaire Those who would give up Liberty, to purchase temporary Safety, deserve neither Liberty nor Safety. - Ben Franklin ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
On Tue, Jul 14, 2009 at 8:46 AM, Zero3 wrote:
> Juiceman skrev:
>> On Mon, Jul 13, 2009 at 8:37 PM, Zero3 wrote:
>>> Juiceman skrev:
On Mon, Jul 13, 2009 at 10:59 AM, Zero3 wrote:
> Juiceman skrev:
>> 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 ;-)
> Cool! Remember to update freenettray.exe as well.
Is that separate from the freenetlauncher.exe?
>>> Yes. Will be located in the bin folder. The launcher has no user
>>> interface and does nothing but load fproxy in the best available browser
>>> when executed. The tray manager is reponsible for keeping a tray icon
>>> running in the background.
>>
>> Ah, ok. I will need Toad to push it to the website folder where I can get
>> it.
>
> He can't do that before it is released, though (or he could temporarily
> upload the beta version of course)
If he wants to put the beta up so i can test it, great. If so, I will
comment out this section of the script until you give the ok to
release it.
> Did you put any thought into how to handle existing installations
> without the tray manager? The ideal solution (but which requires a bit
> more work from you) would be to offer to install the tray manager for
> installations that do not already have it. It's really just a matter of
> downloading the file and adding it to the "Start" all users program
> group in the start menu.
Honestly, adding the tray manager would be easy enough for
installations that have been done with the new wininstaller you
created, but older installs won't work because they are lacking
installid.dat (although I could probably create it, hmm...)
>>> I don't think we should mess around with installations by the old
>>> installer - no. But adding the tray manager to installations made with
>>> the new wininstaller would be cool. We might want to branch the update
>>> script into one version for old installations and one for wininstaller
>>> installations?
>>
>> I will install the tray with a prompt then. Might there be permissions
>> issues?
>
> Hmm. Most likely not on XP, but Vista might whine if we try to add a
> shortcut to the all users startup folder. We might have to ask the user
> kindly to manually create the shortcut if it fails.
>
>> I can do it easy enough with one script. I think I will test for
>> installid.dat and if found ask to install the tray program.
>
> Sounds like a good plan :).
>
>>> We could also silently install it? But I'd rather ask, to be honest..
>>> The good old DOS "choice" command (probably not included in XP/Vista,
>>> but can be downloaded from various sites) has a timeout setting, after
>>> which it will continue with a default value (no, in our case) anyway.
>>
>> I thought about the choice command (I have used it before) but you are
>> right in that it is not available on XP and I'd rather not bundle any
>> more files than necessary.
>
> Agreed. Maybe there is another way?
>
I see you are now installing via the system account instead of
creating a user called "freenet", how does this affect my work?
>>> Yea. You should give access via cacls/icacls to the LocalService user
>>> instead... Though you shouldn't need to do that at all on wininstaller
>>> installations. The installer fixes the access for the main installation
>>> folder with the "inherit" flag active, meaning that any changed/new
>>> files will get the correct access automatically.
>>
>> What happens if I just change it now? Do I need to do them both in case?
>> Maybe I'll just do (on XP)
>> if %VISTA%==0 echo Y| cacls %LOCATION% /E /T /C /G freenet:F /G
>> LocalService:F
>> I changed the . to %LOCATION% that should affect the Freenet
>> installation folder and cause inheritance, right?
>
> ("." would be equal to the install folder.)
>
> I'm not sure what you mean? I was trying to say that the wininstaller
> already fixes the access levels at install time, so update.cmd doesn't
> need to do it at all.
Ok, so I will just leave the script as is for existing old installations.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
Juiceman skrev:
> On Mon, Jul 13, 2009 at 8:37 PM, Zero3 wrote:
>> Juiceman skrev:
>>> On Mon, Jul 13, 2009 at 10:59 AM, Zero3 wrote:
Juiceman skrev:
> 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 ;-)
Cool! Remember to update freenettray.exe as well.
>>> Is that separate from the freenetlauncher.exe?
>> Yes. Will be located in the bin folder. The launcher has no user
>> interface and does nothing but load fproxy in the best available browser
>> when executed. The tray manager is reponsible for keeping a tray icon
>> running in the background.
>
> Ah, ok. I will need Toad to push it to the website folder where I can get it.
He can't do that before it is released, though (or he could temporarily
upload the beta version of course)
Did you put any thought into how to handle existing installations
without the tray manager? The ideal solution (but which requires a bit
more work from you) would be to offer to install the tray manager for
installations that do not already have it. It's really just a matter of
downloading the file and adding it to the "Start" all users program
group in the start menu.
>>> Honestly, adding the tray manager would be easy enough for
>>> installations that have been done with the new wininstaller you
>>> created, but older installs won't work because they are lacking
>>> installid.dat (although I could probably create it, hmm...)
>> I don't think we should mess around with installations by the old
>> installer - no. But adding the tray manager to installations made with
>> the new wininstaller would be cool. We might want to branch the update
>> script into one version for old installations and one for wininstaller
>> installations?
>
> I will install the tray with a prompt then. Might there be permissions
> issues?
Hmm. Most likely not on XP, but Vista might whine if we try to add a
shortcut to the all users startup folder. We might have to ask the user
kindly to manually create the shortcut if it fails.
> I can do it easy enough with one script. I think I will test for
> installid.dat and if found ask to install the tray program.
Sounds like a good plan :).
>> We could also silently install it? But I'd rather ask, to be honest..
>> The good old DOS "choice" command (probably not included in XP/Vista,
>> but can be downloaded from various sites) has a timeout setting, after
>> which it will continue with a default value (no, in our case) anyway.
>
> I thought about the choice command (I have used it before) but you are
> right in that it is not available on XP and I'd rather not bundle any
> more files than necessary.
Agreed. Maybe there is another way?
>>> I see you are now installing via the system account instead of
>>> creating a user called "freenet", how does this affect my work?
>> Yea. You should give access via cacls/icacls to the LocalService user
>> instead... Though you shouldn't need to do that at all on wininstaller
>> installations. The installer fixes the access for the main installation
>> folder with the "inherit" flag active, meaning that any changed/new
>> files will get the correct access automatically.
>
> What happens if I just change it now? Do I need to do them both in case?
> Maybe I'll just do (on XP)
> if %VISTA%==0 echo Y| cacls %LOCATION% /E /T /C /G freenet:F /G LocalService:F
> I changed the . to %LOCATION% that should affect the Freenet
> installation folder and cause inheritance, right?
("." would be equal to the install folder.)
I'm not sure what you mean? I was trying to say that the wininstaller
already fixes the access levels at install time, so update.cmd doesn't
need to do it at all.
- Zero3
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
On Mon, Jul 13, 2009 at 8:37 PM, Zero3 wrote: > Juiceman skrev: >> On Mon, Jul 13, 2009 at 10:59 AM, Zero3 wrote: >>> Juiceman skrev: 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 ;-) >>> Cool! Remember to update freenettray.exe as well. >> >> Is that separate from the freenetlauncher.exe? > > Yes. Will be located in the bin folder. The launcher has no user > interface and does nothing but load fproxy in the best available browser > when executed. The tray manager is reponsible for keeping a tray icon > running in the background. Ah, ok. I will need Toad to push it to the website folder where I can get it. >>> Did you put any thought into how to handle existing installations >>> without the tray manager? The ideal solution (but which requires a bit >>> more work from you) would be to offer to install the tray manager for >>> installations that do not already have it. It's really just a matter of >>> downloading the file and adding it to the "Start" all users program >>> group in the start menu. >> >> Honestly, adding the tray manager would be easy enough for >> installations that have been done with the new wininstaller you >> created, but older installs won't work because they are lacking >> installid.dat (although I could probably create it, hmm...) > > I don't think we should mess around with installations by the old > installer - no. But adding the tray manager to installations made with > the new wininstaller would be cool. We might want to branch the update > script into one version for old installations and one for wininstaller > installations? I will install the tray with a prompt then. Might there be permissions issues? I can do it easy enough with one script. I think I will test for installid.dat and if found ask to install the tray program. >> The other issue I have is adding a prompt will change the default >> function of the script so if someone has a cron job it will hang >> waiting for input. If people don't think that breaking this is a >> problem I will do it. > > Well. Users should *not* run update.cmd on regular basis at all. It's > only meant for crash recovery , updater-over-freenet failure or updating > of helper executables. Agreed, and even if they did, once installed they would not get a prompt any more. > We could also silently install it? But I'd rather ask, to be honest.. > The good old DOS "choice" command (probably not included in XP/Vista, > but can be downloaded from various sites) has a timeout setting, after > which it will continue with a default value (no, in our case) anyway. I thought about the choice command (I have used it before) but you are right in that it is not available on XP and I'd rather not bundle any more files than necessary. >> I see you are now installing via the system account instead of >> creating a user called "freenet", how does this affect my work? > > Yea. You should give access via cacls/icacls to the LocalService user > instead... Though you shouldn't need to do that at all on wininstaller > installations. The installer fixes the access for the main installation > folder with the "inherit" flag active, meaning that any changed/new > files will get the correct access automatically. What happens if I just change it now? Do I need to do them both in case? Maybe I'll just do (on XP) if %VISTA%==0 echo Y| cacls %LOCATION% /E /T /C /G freenet:F /G LocalService:F I changed the . to %LOCATION% that should affect the Freenet installation folder and cause inheritance, right? > I'm not sure if there are anywhere else the script would be affected? > > - Zero3 > ___ ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
Juiceman skrev: > On Mon, Jul 13, 2009 at 10:59 AM, Zero3 wrote: >> Juiceman skrev: >>> 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 ;-) >> Cool! Remember to update freenettray.exe as well. > > Is that separate from the freenetlauncher.exe? Yes. Will be located in the bin folder. The launcher has no user interface and does nothing but load fproxy in the best available browser when executed. The tray manager is reponsible for keeping a tray icon running in the background. >> Did you put any thought into how to handle existing installations >> without the tray manager? The ideal solution (but which requires a bit >> more work from you) would be to offer to install the tray manager for >> installations that do not already have it. It's really just a matter of >> downloading the file and adding it to the "Start" all users program >> group in the start menu. > > Honestly, adding the tray manager would be easy enough for > installations that have been done with the new wininstaller you > created, but older installs won't work because they are lacking > installid.dat (although I could probably create it, hmm...) I don't think we should mess around with installations by the old installer - no. But adding the tray manager to installations made with the new wininstaller would be cool. We might want to branch the update script into one version for old installations and one for wininstaller installations? > The other issue I have is adding a prompt will change the default > function of the script so if someone has a cron job it will hang > waiting for input. If people don't think that breaking this is a > problem I will do it. Well. Users should *not* run update.cmd on regular basis at all. It's only meant for crash recovery , updater-over-freenet failure or updating of helper executables. We could also silently install it? But I'd rather ask, to be honest.. The good old DOS "choice" command (probably not included in XP/Vista, but can be downloaded from various sites) has a timeout setting, after which it will continue with a default value (no, in our case) anyway. > I see you are now installing via the system account instead of > creating a user called "freenet", how does this affect my work? Yea. You should give access via cacls/icacls to the LocalService user instead... Though you shouldn't need to do that at all on wininstaller installations. The installer fixes the access for the main installation folder with the "inherit" flag active, meaning that any changed/new files will get the correct access automatically. I'm not sure if there are anywhere else the script would be affected? - Zero3 ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
On Mon, Jul 13, 2009 at 10:59 AM, Zero3 wrote: > Juiceman skrev: >> 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 ;-) > > Cool! Remember to update freenettray.exe as well. Is that separate from the freenetlauncher.exe? > Did you put any thought into how to handle existing installations > without the tray manager? The ideal solution (but which requires a bit > more work from you) would be to offer to install the tray manager for > installations that do not already have it. It's really just a matter of > downloading the file and adding it to the "Start" all users program > group in the start menu. Honestly, adding the tray manager would be easy enough for installations that have been done with the new wininstaller you created, but older installs won't work because they are lacking installid.dat (although I could probably create it, hmm...) The other issue I have is adding a prompt will change the default function of the script so if someone has a cron job it will hang waiting for input. If people don't think that breaking this is a problem I will do it. I see you are now installing via the system account instead of creating a user called "freenet", how does this affect my work? > Though... As you mentioned earlier, the script is getting quite complex. > Should we just keep on patching it, rewrite it or eventually upgrade it > to something more advanced (Java / AHK / whatever)? Thoughts? > > - Zero3 The script is not so bad now that I added the update_temp directory and streamlined the logic. The main trouble we are going to have is with installations that were done previously, user account issue, lack of installid.dat, etc... I am going to limit my efforts to updating existing binaries unless there is a consensus on modifying a users installation... -- I may disagree with what you have to say, but I shall defend, to the death, your right to say it. - Voltaire Those who would give up Liberty, to purchase temporary Safety, deserve neither Liberty nor Safety. - Ben Franklin ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
Juiceman skrev: > 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 ;-) Cool! Remember to update freenettray.exe as well. Did you put any thought into how to handle existing installations without the tray manager? The ideal solution (but which requires a bit more work from you) would be to offer to install the tray manager for installations that do not already have it. It's really just a matter of downloading the file and adding it to the "Start" all users program group in the start menu. Though... As you mentioned earlier, the script is getting quite complex. Should we just keep on patching it, rewrite it or eventually upgrade it to something more advanced (Java / AHK / whatever)? Thoughts? - Zero3 ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
On Sat, Jun 13, 2009 at 1:57 PM, Zero3 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 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 >> ___ >> Devl mailing list >> Devl@freenetproject.org >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >> > 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/, 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. >> >> >> >> >> ___ >> Devl mailing list >> Devl@freenetproject.org >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > 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 > ___ > Devl mailing list > Devl@freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > 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 ;-) ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
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 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 > ___ > Devl mailing list > Devl@freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > 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/, 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. > > > > > ___ > Devl mailing list > Devl@freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl 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 ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
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 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 > >>> ___ > >>> Devl mailing list > >>> Devl@freenetproject.org > >>> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > >>> > >> 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/, 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. signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
Matthew Toseland skrev: > On Thursday 21 May 2009 17:32:55 Juiceman wrote: >> On Thu, May 21, 2009 at 6:58 AM, Zero3 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 >>> ___ >>> Devl mailing list >>> Devl@freenetproject.org >>> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >>> >> 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/, 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. - Zero3 ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
On Thursday 21 May 2009 17:32:55 Juiceman wrote: > On Thu, May 21, 2009 at 6:58 AM, Zero3 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 > > ___ > > Devl mailing list > > Devl@freenetproject.org > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > 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/, not from downloads... are the relevant files currently available from checksums? signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
On May 21, 2009, at 11:32 AM, Juiceman wrote: > On Thu, May 21, 2009 at 6:58 AM, Zero3 > 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. If it helps, my understanding is that zip & jar are cross compatible. Or more specifically, that a jar is a zip file with extra flags and a manifest file. -- Robert Hailey ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
On Thu, May 21, 2009 at 6:58 AM, Zero3 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 > ___ > Devl mailing list > Devl@freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > 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. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
