February 2009 - Wine-Devel - list.winehq.org

Re: An idea for the appdb

by Ben Klein

2009/2/12 Sparr <sparr0(a)gmail.com>: > On Wed, Feb 11, 2009 at 7:31 PM, Ben Klein <shacklein(a)gmail.com> wrote: >> 2009/2/12 Gert van den Berg <wine-devel(a)mohag.net>: >>> It should rather be opt-in. Such as "Wine has detected that it is the >>> first time you run this application, do you want to check AppDb for >>> more information (Yes/No/Ask again/Never ask for any application)" >> >> This would get insanely annoying if you wanted ONE app to grab data >> from AppDB but not every other one. > > Why? Say "Yes" to that one app, then "Never ask for any application" > for the next app. Seems like Gert's suggestion perfectly handles your > use case. > What happens when the Wine version or application version changes? Suddenly it's no longer doing what you'd want. Regardless, it's not worth discussing further, because it has too many drawbacks. As Austin says, too much work required for too little benefit.

Feb. 12, 2009

Re: An idea for the appdb

by Sparr

On Wed, Feb 11, 2009 at 7:31 PM, Ben Klein <shacklein(a)gmail.com> wrote: > 2009/2/12 Gert van den Berg <wine-devel(a)mohag.net>: >> It should rather be opt-in. Such as "Wine has detected that it is the >> first time you run this application, do you want to check AppDb for >> more information (Yes/No/Ask again/Never ask for any application)" > > This would get insanely annoying if you wanted ONE app to grab data > from AppDB but not every other one. Why? Say "Yes" to that one app, then "Never ask for any application" for the next app. Seems like Gert's suggestion perfectly handles your use case.

Feb. 12, 2009

Re: Error on CVS server: no space left on device

by Ben Klein

2009/2/12 Paul Chitescu <paulc(a)voip.null.ro>: > Hi! > > The CVS server cvs.winehq.org is out of disk space: > > $ cvs -z3 -q up -APd > can't create temporary directory /tmp/cvs-serv29410 > No space left on device Wine switched to git ages ago. I'm surprised the CVS server is still accepting requests.

Feb. 12, 2009

Re: Is the test.winehq.org front page too pessimistic?

by Ben Klein

2009/2/12 James Hawkins <truiken(a)gmail.com>: > On Wed, Feb 11, 2009 at 3:27 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> James Hawkins <truiken(a)gmail.com> writes: >> >>> We should leave the failing files percentage up (note the name change) >>> and add a failing tests percentage next to it. The failing tests >>> percentage should be total_test_failures / total_tests_run. >> >> That's not a useful number, many files run a lot of tests, of which a >> huge majority always succeeds. Having a single failure among 10,000 >> tests means that the test failed, and it's something bad that should be >> taken care of. Showing that as a 99.99% success would be very misleading. >> > > Ok you're right. I wasn't thinking on that scale. I assumed we had > more than 0.01% failures. > Just goes to show we're not in the advertising/marketing industry! Facts are good, useful data is good, fudging the figures to make ourselves look good is bad :)

Feb. 12, 2009

Re: An idea for the appdb

by Ben Klein

2009/2/12 Gert van den Berg <wine-devel(a)mohag.net>: > On Wed, Feb 11, 2009 at 2:24 PM, Luke Benstead <kazade(a)gmail.com> wrote: >> I can also see what you mean about >> spyware, but other apps retrieve stuff from the web if there is a >> connection (CDDB, and album covers are two examples). >> > Wine transmitting every application I run to someone else would be > rather worrying... > > It should rather be opt-in. Such as "Wine has detected that it is the > first time you run this application, do you want to check AppDb for > more information (Yes/No/Ask again/Never ask for any application)" This would get insanely annoying if you wanted ONE app to grab data from AppDB but not every other one. > It must be easy to disable globally as well... It might have some > other uses as well such as "A newer version of the application > works better", etc. Reliability of AppDB data is the issue here. > I might be handy to allow automatic submission of test data to AppDb > (which IMHO might be more useful than just retrieving...) Automagically ask the user how well their app runs? No thanks. >, which should automatically include the Wine executables' > checksums + version, distro info (if accessible from lsb-release, > parts of the uname output & kernel checksum Kernel checksum? No thanks. Especially as a lot of people compile the kernel themselves (Gentoo being the prime example). > , which might be used to detect the distro), kernel version, > cpu architecture, X server name and version, graphics driver name > and version, DLL overrides, etc. That's a lot of info you're collecting. Even with an opt-in service, it could be easily mistaken for spyware. Tread carefully. > This might help modified wine versions and the level of tweaks > to be detected by AppDb automatically. Um, no. The big problem is patches, not just DLL overrides. > (There should be a very specific opt-in process for > this data's submission though, such as letting the user manually > upload a file with this data and fully disclosing the file's contents) OK, so instead of an automagic system that collects all the data, a manual system that collects false data? Doesn't sound any better than AppDB as is. > This kind of data can be handy for bug reports as well. This kind of data is typically retrieved on-demand in bug reports. The WORKSFORME bug status is evidence of this. 2009/2/12 Tim Schwartz <tim(a)sanityinternet.com>: > What about packaging the latest appdb information with each release? Because it's BIG. It would also be at least one release behind in test data, making it completely useless. 2009/2/12 <alex(a)centroidcafe.com>: > Automatic submission of test data could be a very handy tool. Scenario: > User A tries to run an application, it crashes due to bugs in Wine. User A > elects to submit data. Sometime in the future, User B tries to run the same > application under a similar configuration. It crashes also, but User B > being a sly user figures out what DLL overrides, patches, etc. allow this > app to progress past the original crash point. Wine detects this and > collects the information. Now when User C tries to run this app, Wine > displays a message like: "This application has been known to fail under the > current configuration. However, workarounds have been discovered that may > yield greater success. <link to AppDB>" Microsoft, KDE and a few other systems have this type of automatic crash reporting. It doesn't work. You are suggesting a new system here, which is storing automated crash report data in a database which will be looked up every time an app runs. This would be a massive load on the server, even just on requests for applications that don't have entries. Would you seriously want to maintain a database of every Windows application in existence? Seriously? Because that's effectively what you're suggesting. It's not even just Windows apps either, but DOS apps too. Wine will attempt to load DOS apps, and almost always crash. An automated crash report system wouldn't know the difference between a genuine win32/win64 app and a DOS app without a lot of extra work. I don't have to respond to Austin's comments. It's all been said before. Simple answer is: would not work.

Feb. 12, 2009

Error on CVS server: no space left on device

by Paul Chitescu

Hi! The CVS server cvs.winehq.org is out of disk space: $ cvs -z3 -q up -APd can't create temporary directory /tmp/cvs-serv29410 No space left on device Message is received from remote server. Anyone able to fix it? Regards, Paul Chitescu

Feb. 12, 2009

Re: Wine64 : Trying to load PE image for unsupported architecture (I386)

by Erik de Castro Lopo

Alexandre Julliard wrote: > Not really, you'll of course still need to build a full 32-bit version > of Wine, the 64-bit Wine will never be able to run 32-bit apps. Ok. > What > needs to be improved is that the 64-bit loader should be able to forward > automatically to the 32-bit one when encountering a 32-bit app. So there will need to be two executables wine and wine64 and if either is started with the wrong kind of binary, it will need to run the binary with the other version? Would it not be possible to have a single light weight binary that has just enough code to detect i386 vs amd64 and then execs either wine32 or wine64? Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "To iterate is human, to recurse divine." -- L. Peter Deutsch

Feb. 11, 2009

Re: Is the test.winehq.org front page too pessimistic?

by Scott Ritchie

James Hawkins wrote: > On Wed, Feb 11, 2009 at 3:27 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> James Hawkins <truiken(a)gmail.com> writes: >> >>> We should leave the failing files percentage up (note the name change) >>> and add a failing tests percentage next to it. The failing tests >>> percentage should be total_test_failures / total_tests_run. >> That's not a useful number, many files run a lot of tests, of which a >> huge majority always succeeds. Having a single failure among 10,000 >> tests means that the test failed, and it's something bad that should be >> taken care of. Showing that as a 99.99% success would be very misleading. >> > > Ok you're right. I wasn't thinking on that scale. I assumed we had > more than 0.01% failures. > Why not just print absolute numbers for tests failed and passed? Does a percentage even serve any benefit here? With absolute numbers we could see progress in both tests being fixed and in tests being written. Thanks, Scott Ritchie

Feb. 11, 2009

Re: How to get more info on timed out/crashed tests?

by Ricardo Filipe

2009/2/11 Juan Lang <juan.lang(a)gmail.com> > Hi all, > > there are a number of tests at test.winehq.org that indicate that > they're timed out or crashed. The difficulty is, I have no access to > machines running the version of Windows on which the test is timing > out or failing, and the data about the crash are not helpful in > pinpointing the failing test. > > How can we get more information about these timeouts/crashes? > --Juan > > > i have some of those in my vista pc, in case you can't get to a global solution i'll be glad to run custom tests that help detect the crashes in my pc, as i'm sure other people will. i understand though that a per machine analysis is not feasible, but it's what i can offer right now.

Feb. 11, 2009

Re: Is the test.winehq.org front page too pessimistic?

by Ricardo Filipe

2009/2/11 Alexandre Julliard <julliard(a)winehq.org> > > That's not a useful number, many files run a lot of tests, of which a > huge majority always succeeds. Having a single failure among 10,000 > tests means that the test failed, and it's something bad that should be > taken care of. Showing that as a 99.99% success would be very misleading.<julliard(a)winehq.org> i think what he means is a value for the whole run, not for each file... this way we get the number of failing files and failing tests for one run. i think that could be useful, at least it can show much more difference and give a better response to fixing tests than a file failure statistic. it would be a more changing rate.

Feb. 11, 2009