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

Re: why is Kronenberg's Wine/Mac work blacklisted on winehq?

by Brian Vincent

On Fri, Jun 26, 2009 at 2:42 PM, Mike Kronenberg < mike.kronenberg(a)kronenberg.org> wrote: > OS X > My main concern is to have usable builds. Ie, usable without the need of a > terminal. People on OS X don't care about how stuff works, it just has to > work. > > Vanilla build > I totally agree that by adding certain patches, the builds can't be > considered as vanilla. > I'll recheck the necessity of the patches again on Tiger and Leopard and > they really get less and less. My $.02: we've got two different problems we're trying to solve with the same build. We're trying to give the user a great user experience by including lots of extras; and this is a Noble Goal and a Good Thing. We're also trying to collect good bug reports that aren't tainted by crap; and this is also a Noble Goal and Good Thing. It seems like this could be solved by two different builds. Keep the Darwine stuff the way it is, just put a huge warning label on it that says the code is unsupported. Second, provide another binary build that's as much of a vanilla wine as possible. Because we like our user community and we like to be nice to them, we'll provide links to BOTH of them from the Wine website as well as put the giant UNSUPPORTED stamp on the first one. Then we tell Mac users if they want to submit a bug report they should download and install this other package and try to reproduce their bug. Now, the side effect there is that maybe it will improve the quality of bugs being reported. Folks who take the time to download that extra package, set up their environment properly, etc, etc, well, they probably have the ability to also write a coherent bug report. (You could also argue that rather than provide this second package you could simply make people compile it themselves, but I'd argue that it makes it an order of magnitude harder to submit a bug report and we'd effectively alienate the vast majority of the user community.) Oh, and we have a branding issue where this code magically transforms from Wine into something by another name. I completely understand why we're not a big fan of that. I also understand it could break things if you attempt to change paths. However, the sooner you do that, the sooner it gets done. It's actually doing the user community a disservice by calling it Darwine rather than Wine. If you throw "Darwine" into Google, you don't turn up a single site on the first page that's a Wine web page. As a result, all the great things like our AppDB, Wiki, developer tips, etc aren't a resource for that user community. (Wow! Look at our Page Rank for "Wine". We need to start selling bottles of wine on winehq.org.) -Brian

June 30, 2009

Re: [3/7] [wined3d] add NP2 fixup code to shader_arb_generate_pshader (resend)

by Tobias Jakobi

Won't work since the GL_LIMITS macro is defined in this way: #define GL_LIMITS(ExtName) (GLINFO_LOCATION.max_##ExtName) I don't think changing the variable name is an option, since keeping consistency there should be priority: ps_arb_max_local_constants -> ??? (I don't think it's wise to drop the ps_arb prefix, since it's specific to ARB and specific to PS).

June 30, 2009

Re: [4/7] [wined3d] add NP2 fixup code to shader_hw_sample (ARB) (resend)

by Tobias Jakobi

It's very easy. Only ordinary sampling is supported, because I have no application which I can use to test the others variants (only support the features you can actually test).

June 30, 2009

Re: [2/7] [wined3d] add arb_ps_np2fixup_info structure (resend)

by Tobias Jakobi

*hint* *hint* See the commit message!

June 30, 2009

Re: server/fd.c: Prevent using uninitialized pointers

by Henri Verbeet

2009/6/30 Daniel Santos <javatroubadour(a)yahoo.com>: > Some pointers are getting used prior to initialization. It would appear that the current compilers are initializing them to zero or we've been lucky. > No, the C standard specifies that these are initialized to NULL, since they have static storage duration.

June 30, 2009

Re: server/fd.c: Prevent using uninitialized pointers

by Matteo Bruni

I'm quite sure that C standards guarantee global variables are initialized to 0. 2009/6/30 Daniel Santos <javatroubadour(a)yahoo.com>: > Some pointers are getting used prior to initialization. It would appear that the current compilers are initializing them to zero or we've been lucky. > > > > > >

June 30, 2009

Appdb flight simulation sub category

by Keith Muir

Hi, Any chance of a games> simulation> flight simulation sub category? Regards, Keith

June 30, 2009

Re: Fw: Re: Removing active maintainers

by Austin English

On Tue, Jun 30, 2009 at 10:21 AM, James Mckenzie<jjmckenzie51(a)earthlink.net> wrote: > Sent to Rosanne only, meant to send it to the list as a comment to this thread. > > James McKenzie > > -----Forwarded Message----- >>From: James Mckenzie <jjmckenzie51(a)earthlink.net> >>Sent: Jun 29, 2009 6:36 PM >>To: Rosanne DiMesio <dimesio(a)earthlink.net> >>Subject: Re: Removing active maintainers >> >>Rosanne DiMesio <dimesio(a)earthlink.net> Subject: Re: Removing active maintainers >>> >>>On Mon, 29 Jun 2009 14:56:23 +0200 >>>Remco <remco47(a)gmail.com> wrote: >>> >>>> On Mon, Jun 29, 2009 at 2:22 PM, Rosanne DiMesio<dimesio(a)earthlink.net> wrote: >>>> > That would still leave the test results sitting there unprocessed for weeks, which leaves a pretty bad impression on the users who submitted them. Test results for apps without maintainers get processed by the admins within 24 hours. >>>> >>>> How about mailing admins after 24 hours? Maintainers are useful to >>>> offload tasks of admins. If they are away for a while, admins just get >>>> the mail as if there were no maintainer. If you have to remove a >>>> maintainer every time he can't respond in 24 hours, you won't have >>>> many left after a while. >>>> >>>> Remco >>> >>>Nobody's suggesting a 24 hour time limit for maintainers. >>> >>>As for emailing the admins, I know I turned off emails from the AppDB to avoid having my mailbox overwhelmed with hundreds of useless notices every day, >>>and I doubt I'm the only one who did this. http://bugs.winehq.org/show_bug.cgi?id=14755 needs to be fixed first for any solution that involves emailing >>>admins to be viable. >> >>I see several good ideas here: >> >>1. Maintainers should be able to mark themselves as not available. No reason should be required. >>2. Admins should have the ability to suspend a maintainer for non-response. There are several reasons for not responding and most of them would be considered an emergency. >>3. Any maintainer who fails, after three suspensions, to properly carry out the functions of being a maintainer, should be banned for a specific period of time, increases to a complete ban. >>4. What maintainers have to do to maintain their status should be posted on the Maintainers page when you sign up and a reminder message every 90 days or so should be sent out to keep maintainers honest. >>5. Maintainers should be given the option of gracefully resigning when they no longer can perform the duties of their position. A lot of these suggestions are overly complex and require a lot of modification to the AppDB. There's only one person really working on it (thanks Alexander!), but keep in mind that while it's easy to suggest lots of complex changes to the AppDB, it only matters if someone is willing to take the time to do that work. TL;DR AppDB patches needed. -- -Austin

June 30, 2009

Fw: Re: Removing active maintainers

by James Mckenzie

Sent to Rosanne only, meant to send it to the list as a comment to this thread. James McKenzie -----Forwarded Message----- >From: James Mckenzie <jjmckenzie51(a)earthlink.net> >Sent: Jun 29, 2009 6:36 PM >To: Rosanne DiMesio <dimesio(a)earthlink.net> >Subject: Re: Removing active maintainers > >Rosanne DiMesio <dimesio(a)earthlink.net> Subject: Re: Removing active maintainers >> >>On Mon, 29 Jun 2009 14:56:23 +0200 >>Remco <remco47(a)gmail.com> wrote: >> >>> On Mon, Jun 29, 2009 at 2:22 PM, Rosanne DiMesio<dimesio(a)earthlink.net> wrote: >>> > That would still leave the test results sitting there unprocessed for weeks, which leaves a pretty bad impression on the users who submitted them. Test results for apps without maintainers get processed by the admins within 24 hours. >>> >>> How about mailing admins after 24 hours? Maintainers are useful to >>> offload tasks of admins. If they are away for a while, admins just get >>> the mail as if there were no maintainer. If you have to remove a >>> maintainer every time he can't respond in 24 hours, you won't have >>> many left after a while. >>> >>> Remco >> >>Nobody's suggesting a 24 hour time limit for maintainers. >> >>As for emailing the admins, I know I turned off emails from the AppDB to avoid having my mailbox overwhelmed with hundreds of useless notices every day, >>and I doubt I'm the only one who did this. http://bugs.winehq.org/show_bug.cgi?id=14755 needs to be fixed first for any solution that involves emailing >>admins to be viable. > >I see several good ideas here: > >1. Maintainers should be able to mark themselves as not available. No reason should be required. >2. Admins should have the ability to suspend a maintainer for non-response. There are several reasons for not responding and most of them would be considered an emergency. >3. Any maintainer who fails, after three suspensions, to properly carry out the functions of being a maintainer, should be banned for a specific period of time, increases to a complete ban. >4. What maintainers have to do to maintain their status should be posted on the Maintainers page when you sign up and a reminder message every 90 days or so should be sent out to keep maintainers honest. >5. Maintainers should be given the option of gracefully resigning when they no longer can perform the duties of their position. > >James McKenzie > >> >>-- >>Rosanne DiMesio <dimesio(a)earthlink.net> >> >>

June 30, 2009

Re: configure.ac: make sure we can run cmdlgtst and view from outside wine tree

by Austin English

On Tue, Jun 30, 2009 at 6:17 AM, Michael Stefaniuc<mstefani(a)redhat.com> wrote: > Austin English wrote: >> On Mon, Jun 29, 2009 at 10:37 PM, Detlef Riekenberg<wine.dev(a)web.de> wrote: >>> On Mo, 2009-06-29 at 12:50 -0500, Austin English wrote: >>>> With this patch, they are treated like other programs, e.g., winhlp32, >>>> and installed, so one can use: >>>> $ wine view >>>> and get the same effect. >>> That parts of configure.ac are created by tools/make_makefiles >>> >>> tools/make_makefiles-50-# Programs that we don't want to install at all >>> tools/make_makefiles-51-my %dont_install = >>> tools/make_makefiles-52-( >>> tools/make_makefiles:53: "cmdlgtst" => 1, >>> tools/make_makefiles-54- "view" => 1, >>> tools/make_makefiles-55- "winetest" => 1, >>> tools/make_makefiles-56-); >> >> Good to know, thanks. But AJ told me on IRC he won't accept it, since >> he doesn't think those binaries should be used outside of the tree. > Right, those aren't needed by users. > > I really wonder what purpose cmdlgtest serves this days and if it > shouldn't be just removed. Actually, it's got a bug open that should probably be fixed before that's considered: http://bugs.winehq.org/show_bug.cgi?id=17495 -- -Austin

June 30, 2009