Re: WineHQ:service.cgi: fix winrash option

2004-07-30 Thread Ferenc Wagner
<[EMAIL PROTECTED]> writes:

>>> http://osdn.dl.sourceforge.net/sourceforge/wine/winetest-200407091000-kevin-mingw.zip
>
> I just tried that url and it worked.  Many of the ones
> I've tried in the past haven't and the cause seems to be
> that the mirror chosen doesn't have the file.

Hmm, Sourceforge's actually selling away what we want, see
on http://sourceforge.net/subscription.php:

* Direct Downloads

Download any file released on SourceForge.net in a
hurry. No need to use the website; download files
directly from the command line. Need to add software to
a remote server? This is the easier way to do it.

Does it only mean connecting one to the right(?) mirror
automatically?
-- 
Feri.



Re: WineHQ:service.cgi: fix winrash option

2004-07-30 Thread Hans Leidekker
On Friday 30 July 2004 05:48, Robert Reif wrote:

> Unfortunately someone must have copied my mistake and placed them in the
> mingw dxguid.lib.  So wine's code is now correct for wine and Windows but

Well, not by mistake. I'm maintaining a version of MinGW 
(at http://mirzam.it.vu.nl/mingw) with a number of patches 
thrown in to make cross building Wine tests and dlls work.

Adding missing guids was one of those patches. I could remove
that one but Wine (dxsound) has progressed so much lately that
more patching is needed for MinGW (it's w32api part, to be 
precise).

These problems are bound to occur more often and although the
proper solution seems to be to fix MinGW, reality has it that MinGW
won't accept some of our patches.

Now that we have our own SDK package on sourceforge, wine-w32api,
I am contemplating using that instead of mingw-w32api, along with
mingw-gcc and mingw-binutils.

That would help us with issues like these but at the same time we
would lose testing Wine builds with third-party headers and import
libs, which turns up Wine bugs every once and a while.

 -Hans



Re: WineHQ:service.cgi: fix winrash option

2004-07-29 Thread Robert Reif
Kevin Koltzau wrote:
On Thursday 29 July 2004 05:10 am, Ferenc Wagner wrote:
 

since I included dsound into winetest you don't seem to
publish any more winetest versions on Sourceforge.  Have you
got problems compiling the dsound tests?  Can you cope?
   

multiple definition of `CLSID_DirectSoundPrivate'
multiple definition of `DSPROPSETID_DirectSoundDevice'
I don't think I'll have time to check into this at least until next week
 

These were included in dxguid.lib by me by mistake.  They are not included
in Windows dxguid.lib so I removed them and fixed the code in wine
to define them.  The wine dsound tests will now compile on Windows with
a Microsoft compiler and libraries.
Unfortunately someone must have copied my mistake and placed them in the
mingw dxguid.lib.  So wine's code is now correct for wine and Windows but
mingw's dxguid.lib is causing the problem.  We could revert my patch
or add a mingw check in the code but the proper way is to fix mingw's
dxguid.lib.
I'm sorry the tests are broken.  They have been very helpful to me in 
getting
winmm more compatible and I would really like to see the same thing happen
to dsound.




Re: WineHQ:service.cgi: fix winrash option

2004-07-29 Thread Kevin Koltzau
On Thursday 29 July 2004 05:10 am, Ferenc Wagner wrote:
> since I included dsound into winetest you don't seem to
> publish any more winetest versions on Sourceforge.  Have you
> got problems compiling the dsound tests?  Can you cope?

multiple definition of `CLSID_DirectSoundPrivate'
multiple definition of `DSPROPSETID_DirectSoundDevice'

I don't think I'll have time to check into this at least until next week



Re: WineHQ:service.cgi: fix winrash option

2004-07-29 Thread Kevin Koltzau
On Thursday 29 July 2004 02:26 am, Shachar Shemesh wrote:
> Actually, running a gentoo mirror myself (il1.rsync.gentoo.org), the way 
> gentoo handles the mirrors is to sync the distro several days in advance 
> with permissions preventing anyone (except us :-D ) from getting it, and 
> then rsyncing just the permission change.
> 
> This allows more or less simultaneous release on all mirrors.

That's true for published ebuilds, but for an ebuild not yet in portage,
or before the sync is complete, the method I described is what is used



Re: WineHQ:service.cgi: fix winrash option

2004-07-29 Thread Ferenc Wagner
Kevin Koltzau <[EMAIL PROTECTED]> writes:

> On Wednesday 28 July 2004 04:36 pm, [EMAIL PROTECTED]
> wrote:
>
>> Your help is much appreciated.  This is a tricky issue it
>> seems as SF isn't always reliable for downloads...
>
> Gentoo handles this situation fairly well, [...]

Hi Kevin,

since I included dsound into winetest you don't seem to
publish any more winetest versions on Sourceforge.  Have you
got problems compiling the dsound tests?  Can you cope?
-- 
Thanks,
Feri.



Re: WineHQ:service.cgi: fix winrash option

2004-07-28 Thread Shachar Shemesh
Dimitrie O. Paun wrote:
On Wed, Jul 28, 2004 at 11:51:58PM -0400, Kevin Koltzau wrote:
 

On Wednesday 28 July 2004 04:36 pm, [EMAIL PROTECTED] wrote:
   

Your help is much appreciated.  This is a tricky issue it seems as SF isn't always reliable for downloads...
 

Gentoo handles this situation fairly well, it simply uses a URL format 'mirror://sourceforge/project/file'
and has a small database of sourceforge base urls that are tried in a round robbin until all are attempted
or the file is successfully downloaded. Possibly a solution similar to this may work for us
   

I still don't understand why we need all this complication. All you need to do is 
to have a
*private* list of such mirrors, and to simply poll them after uploading until you can
successfully download the file from one of them. At that point, use that mirror's 
address
to publish the release on WineHQ.
 

Actually, running a gentoo mirror myself (il1.rsync.gentoo.org), the way 
gentoo handles the mirrors is to sync the distro several days in advance 
with permissions preventing anyone (except us :-D ) from getting it, and 
then rsyncing just the permission change.

This allows more or less simultaneous release on all mirrors.
   Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/



Re: WineHQ:service.cgi: fix winrash option

2004-07-28 Thread Dimitrie O. Paun
On Wed, Jul 28, 2004 at 11:51:58PM -0400, Kevin Koltzau wrote:
> On Wednesday 28 July 2004 04:36 pm, [EMAIL PROTECTED] wrote:
> > Your help is much appreciated.  This is a tricky issue it seems as SF isn't always 
> > reliable for downloads...
> 
> Gentoo handles this situation fairly well, it simply uses a URL format 
> 'mirror://sourceforge/project/file'
> and has a small database of sourceforge base urls that are tried in a round robbin 
> until all are attempted
> or the file is successfully downloaded. Possibly a solution similar to this may work 
> for us

I still don't understand why we need all this complication. All you need to do is to 
have a
*private* list of such mirrors, and to simply poll them after uploading until you can
successfully download the file from one of them. At that point, use that mirror's 
address
to publish the release on WineHQ.

-- 
Dimi.



Re: WineHQ:service.cgi: fix winrash option

2004-07-28 Thread Kevin Koltzau
On Wednesday 28 July 2004 04:36 pm, [EMAIL PROTECTED] wrote:
> Your help is much appreciated.  This is a tricky issue it seems as SF isn't always 
> reliable for downloads...

Gentoo handles this situation fairly well, it simply uses a URL format 
'mirror://sourceforge/project/file'
and has a small database of sourceforge base urls that are tried in a round robbin 
until all are attempted
or the file is successfully downloaded. Possibly a solution similar to this may work 
for us



Re: Re: WineHQ:service.cgi: fix winrash option

2004-07-28 Thread chmorgan
> <[EMAIL PROTECTED]> writes:
> 
> > Which errors are you referring to?  The most frequent ones
> > lately are the ones where the winetest package isn't
> > available on the sourceforge osdn mirror.
> 
> For example this:
> 
> > Winrash version: winrash-0008-chris-msvc.exe
> > [...]
> > winetest = winetest-200407091000-kevin-mingw.zip
> > winetest_history = 
> > Script:
> > 8 total commands, current command is 6
> > 0: error_url http://test.winehq.org/error
> > 1: error_sleep 3600
> > 2: download winetest-200407091000-kevin-mingw.zip 
> > http://osdn.dl.sourceforge.net/sourceforge/wine/winetest-200407091000-kevin-mingw.zip
> > 3: cookie winetest winetest-200407091000-kevin-mingw.zip
> > 4: cookie winetest_history 
> > 5: unzip winetest-200407091000-kevin-mingw.zip
> > --> 6: run winetest-200407091000-kevin-mingw.exe -c -t Cogman -u 
> > http://osdn.dl.sourceforge.net/sourceforge/wine/winetest-200407091000-kevin-mingw.zip
> > 7: sleep 300
> > Command in error:
> > 6
> > Last error text: The system cannot find the file specified.
> 
> Does the above mean that the download was unsuccessful?
> Equally for "Last error text: %1 is not a valid Win32
> application."?  Then we don't need these messages (which
> could be improved at least).
> 

Yep.  I just tried that url and it worked.  Many of the ones I've tried in the past 
haven't and the cause seems to be that the mirror chosen doesn't have the file.  I'm 
not sure what a good solution is.  Perhaps we should implement a way of providing a 
list of potential download sites for a file.I'm not sure how to detect that the 
download fails.  Sourceforge provides a page that says that the file can't be found.  
This is what winrash probably downloaded in this case.  Any ideas how to make the 
system more robust without making it much more complex?


> Hmm, some still try to download winrash-0008 from the osdn
> mirror, which has been obsoleted for a long time.  Why?
> 

I have no idea what the issue is here.  The script should be telling the 0007 client 
to download 0009.  I'm not sure if this is a bug or not.

> And service.cgi shouldn't pass the -u option to winetest
> anymore, I patched it out.  At least I think so.
> 
> > We are still asking people to download the tests from this
> > location for particular test releases.  I'd imagine the
> > fix is simply to point the downloads at valid mirror for
> > the file.
> 
> By editing service.cgi's database?  You could ask Jer, his
> is very helpful if you can catch him on IRC.  I wish there
> was some logging feature in service.cgi...  I'll go deeper
> in a couple of days.
> -- 
> Feri.

Your help is much appreciated.  This is a tricky issue it seems as SF isn't always 
reliable for downloads...

Chris





Re: WineHQ:service.cgi: fix winrash option

2004-07-28 Thread Ferenc Wagner
<[EMAIL PROTECTED]> writes:

> Which errors are you referring to?  The most frequent ones
> lately are the ones where the winetest package isn't
> available on the sourceforge osdn mirror.

For example this:

> Winrash version: winrash-0008-chris-msvc.exe
> [...]
> winetest = winetest-200407091000-kevin-mingw.zip
> winetest_history = 
> Script:
>   8 total commands, current command is 6
>   0: error_url http://test.winehq.org/error
>   1: error_sleep 3600
>   2: download winetest-200407091000-kevin-mingw.zip 
> http://osdn.dl.sourceforge.net/sourceforge/wine/winetest-200407091000-kevin-mingw.zip
>   3: cookie winetest winetest-200407091000-kevin-mingw.zip
>   4: cookie winetest_history 
>   5: unzip winetest-200407091000-kevin-mingw.zip
> -->   6: run winetest-200407091000-kevin-mingw.exe -c -t Cogman -u 
> http://osdn.dl.sourceforge.net/sourceforge/wine/winetest-200407091000-kevin-mingw.zip
>   7: sleep 300
> Command in error:
> 6
> Last error text: The system cannot find the file specified.

Does the above mean that the download was unsuccessful?
Equally for "Last error text: %1 is not a valid Win32
application."?  Then we don't need these messages (which
could be improved at least).

Hmm, some still try to download winrash-0008 from the osdn
mirror, which has been obsoleted for a long time.  Why?

And service.cgi shouldn't pass the -u option to winetest
anymore, I patched it out.  At least I think so.

> We are still asking people to download the tests from this
> location for particular test releases.  I'd imagine the
> fix is simply to point the downloads at valid mirror for
> the file.

By editing service.cgi's database?  You could ask Jer, his
is very helpful if you can catch him on IRC.  I wish there
was some logging feature in service.cgi...  I'll go deeper
in a couple of days.
-- 
Feri.



Re: Re: WineHQ:service.cgi: fix winrash option

2004-07-26 Thread chmorgan
Which errors are you referring to?  The most frequent ones lately are the ones where 
the winetest package isn't available on the sourceforge osdn mirror.  We are still 
asking people to download the tests from this location for particular test releases.  
I'd imagine the fix is simply to point the downloads at valid mirror for the file.

Chris

> 
> From: Ferenc Wagner <[EMAIL PROTECTED]>
> Date: 2004/07/26 Mon AM 07:57:51 EDT
> To: [EMAIL PROTECTED]
> CC: <[EMAIL PROTECTED]>,  <[EMAIL PROTECTED]>
> Subject: Re: WineHQ:service.cgi: fix winrash option
> 
> <[EMAIL PROTECTED]> writes:
> 
> > What is the service doing with winrash options btw?  The
> > installer stops, installs and starts the winrash service.
> >
> > The installer uses /S for silent installs, otherwise it
> > will try to popup windows.  Are you sure the service isn't
> > calling the installer with /S?
> 
> You are right, I was wrong.  This patch is rubbish.  I can't
> really understand the errors on wine-test-results.  Have you
> got an idea what may have gone wrong?  Aren't any functional
> winrash instances running?  Is something broken in the
> service script?  The documentation is somewhat scarce so I'm
> doing a slow start...
> -- 
> Feri.
> 
> 




Re: WineHQ:service.cgi: fix winrash option

2004-07-26 Thread Ferenc Wagner
<[EMAIL PROTECTED]> writes:

> What is the service doing with winrash options btw?  The
> installer stops, installs and starts the winrash service.
>
> The installer uses /S for silent installs, otherwise it
> will try to popup windows.  Are you sure the service isn't
> calling the installer with /S?

You are right, I was wrong.  This patch is rubbish.  I can't
really understand the errors on wine-test-results.  Have you
got an idea what may have gone wrong?  Aren't any functional
winrash instances running?  Is something broken in the
service script?  The documentation is somewhat scarce so I'm
doing a slow start...
-- 
Feri.