chmorgan@charter.net 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-... 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-... 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
On Wednesday 28 July 2004 04:36 pm, chmorgan@charter.net 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
On Wed, Jul 28, 2004 at 11:51:58PM -0400, Kevin Koltzau wrote:
On Wednesday 28 July 2004 04:36 pm, chmorgan@charter.net 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.
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, chmorgan@charter.net 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
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
Kevin Koltzau kevin@plop.org writes:
On Wednesday 28 July 2004 04:36 pm, chmorgan@charter.net 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?
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
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.
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
chmorgan@charter.net writes:
http://osdn.dl.sourceforge.net/sourceforge/wine/winetest-200407091000-kevin-...
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?
-
chmorgan＠charter.net -
Dimitrie O. Paun -
Ferenc Wagner -
Hans Leidekker -
Kevin Koltzau -
Robert Reif -
Shachar Shemesh