September 2015 - Wine-Devel

Re: ntdll: Reduce stack usage of virtual memory functions by storing sigset in static memory.

by Michael Müller

Am 27.09.2015 um 00:07 schrieb Sebastian Lackner: > From: Michael Müller <michael(a)fds-team.de> > > For https://bugs.winehq.org/show_bug.cgi?id=34558 > > Depending on the compiler optimization flags there is still no guarantee that > everything will fit into the available stack space, no matter if its declared > as static or not. As suspected the idea does not work for all optimization levels. At least GCC merges the content of the functions when using -O2 and therefore reintroduces the problem - even __attribute__ ((noinline)) is not sufficient. As most distributions compile Wine with -02, I would suggest to ignore the patch for now. Maybe we can come up with a more general solution.

Sept. 27, 2015

Re: [PATCH v2] comctl32: Fix sizing of edit window for listview icon view

by Nikolay Sivov

On 26.09.2015 22:11, Barrett Karish wrote: > Test Program: https://bugs.winehq.org/attachment.cgi?id=35473 > --- By test I meant a test integrated into wine tests, in this case it should go to comctl32/tests/listview.c. Test should basically create Listview of particular style, enable item text edit control and check its style. I think I tried that long time ago and test didn't confirm what appeared to be obvious fix, but I might be wrong.

Sept. 27, 2015

opengl32: it does not compile well in CYGWIN and MINGW

by carlo.bramix＠libero.it

Hello, I'm writing here for asking a suggestion about a patch that I have sent one month ago. The fix attached in this email: https://www.winehq.org/pipermail/wine-patches/2015-August/141811.html is required because, when compiling opengl32 on Windows (CYGWIN or MINGW), the compiler complains that the exported functions are redeclared without dllimport attribute, while they should be declared with dllexport from beginning. This error can be fixed by adding the definition of _GDI32_ so that WINGDIAPI macro is declared correctly. This fix already exists for example in /dlls/gdi32/Makefile.in as you can see here: http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/gdi32/Makefile.in I hope that it could be committed because perhaps it does not make difference on platforms without dllexport/dllimport attribute support, but it does on real Windows. Thank you. Sincerely, Carlo

Sept. 27, 2015

Re: WineConf 2015 decisions

by Aaryaman Vasishta

That's largely just because Python has become my go-to language over the > past few years, but it also seemed like Django is relatively good at > sitting on top of independent components (or at least Google actually > returned pages with advice on doing that; the docs for frameworks like > Rails or CakePHP were vaguer). That way we shouldn't have to python-ize > everything, but could just start with the views and account management, > then make changes incrementally from there. > > +1 for python. I have basic experience with django. I can try to contribute on the backend of things, if needed. Cheers, Aaryaman

Sept. 27, 2015

Re: WineConf 2015 decisions

by Kyle Auble

On 09/25/2015 03:16 AM, Alexandre Julliard wrote: > Over the last few months there have been a lot of discussions about how > to improve our development process. I've been gathering feedback, and > last week at WineConf I summarized the suggestions in my keynote > presentation.... > > ... > > I'm hoping that this will make the development process more pleasant for > everybody, and enable us to better respond to users' needs. > > Once these changes are in place, I'll also encourage everybody who had > given up in disgust to give us another chance; and if things are still > not satisfactory, please send us feedback. This is a work in progress, > and we will continue to listen and work on making things better. I just wanted to say that beyond all of these ideas sounding good, I think the simple fact that everyone's discussing them is a very encouraging sign. I get the feeling a lot of problems that cropped up recently aren't anyone's personal fault so much as growing pains, natural feedback from the project's advance (and the popularity and heightened expectations that come with that). After all, how long did it take before the first stable release was ready? Then compare that, in the past few years for example, to Pipelight or Andre H. being able to port everything to ARM64 in under a week. So the old approach actually made a lot of progress, until it started hitting new ceilings. At this point, my involvement with Wine mainly consists of technical writing and simple web-design, but before I take another hiatus, I'd like to toss out a couple thoughts based on what I've seen from that POV, digging through old docs and emails scattered across WineHQ. On 09/25/2015 03:16 AM, Alexandre Julliard wrote: > - Wine-staging is now considered an integral part of the Wine > development process, and will be used as a mechanism to enable more > patches to meet the requirements for inclusion in the main tree. We > will all be working together as a team. Regarding wine-staging, I haven't had any direct interaction with the branch, but I think nurturing it and bringing it back into the fold upstream is great. I know there was some concern that it would cause the code quality to start declining, but I could see the opposite happening too. Bugs either pop up for local reasons or subtler, structural ones; usually eyeballs (or maybe tools) can catch the former, but often only testing by a lot of users ultimately teases apart the the latter. And wine-staging seems to have hit on a way to attract more contributors, eyeballs and all. Involving more people in the project would also really help on the support side of things too (documentation, forums, bug triage, etc.) My one concern isn't that wine-staging will harm anything, but that it isn't a panacea for other issues... On 09/25/2015 03:16 AM, Alexandre Julliard wrote: > - We will switch to a time-based stable release, on a yearly > schedule. The code freeze will start every year in the fall. Michael > Stefaniuc will be maintaining the stable branch starting with 1.8. > > - We will start enforcing a Signed-Off-By header on patches, to make it > possible to better distribute reviewing responsibility, and to allow > multiple authors to cooperate on a patch. > > - We will keep a list of maintainer contact information for the various > submodules; developers will be encouraged to go through the respective > maintainer before submitting to wine-patches. ... but in combination with these changes, it could pay extra dividends down the road. I don't know if it's ever been suggested, but on top of just doing releases on a time-line, what if every subsystem's maintainer submitted their queue of signed-off patches at fixed times, in rotating order? If every patch within, say the past few days, is from one subsystem, and a regular tester or prompt bug-reporter finds a regression, we would already know where the bug lives, or at least where it vacations. Also, I was thinking that if every developer knows there are regular submission periods for the components they're interested in, they might feel like working more on things like refactoring, documentation, & bug-hunts during the rest periods. I'm biased because the wiki has partly become my baby in the project, but I think if there's one thing that might nudge more power-users/testers into becoming developers, it would be making the code-base easier to navigate. Refactoring and clear, up-to-date technical documentation (both specs like on WineAPI and implementation details) would be two immediate ways of accomplishing that, but both usually require the active developers' knowledge. On 09/26/2015 12:11 PM, Rosanne DiMesio wrote: > On Sat, 26 Sep 2015 09:07:56 -0700 > Ben Shadwick <benshadwick(a)gmail.com> wrote: >> I know this is the devel list, but what does this mean for AppDB? You >> mentioned being able to report bugs against wine-staging in the bug >> tacker, but nothing about being able to submit compatibility reports >> against it in the AppDB. These are currently rejected, which just >> happened to me. > They should be accepted, but getting the word out to all maintainers about that is going to be a problem. > > I've processed your report that was rejected. Now for all of the user-facing parts of the project, I think if there's one smart investment we could make, it would be migrating WineHQ to a web-framework. With that, it should become much simpler to update static pages, coordinate AppDB, Bugzilla, the source, & the docs, give users a streamlined view of the whole project (and managing their account), and even cooler things hitherto unimagined. I would be happy to try, but I really haven't had the time or energy to focus on that involved a project these past few years. If nobody else jumps on it first though, maybe I'll be available for that a year or two from now. I did do a little preliminary research, and was leaning away from the CMS-es (too restrictive and probably too much cruft) and towards Django actually. That's largely just because Python has become my go-to language over the past few years, but it also seemed like Django is relatively good at sitting on top of independent components (or at least Google actually returned pages with advice on doing that; the docs for frameworks like Rails or CakePHP were vaguer). That way we shouldn't have to python-ize everything, but could just start with the views and account management, then make changes incrementally from there. On 09/25/2015 04:45 PM, Tom Wickline wrote: > Was a overhaul of winehq.org <http://winehq.org> discussed? The site > really needs to be mobile friendly if you want the site to remain > relevant in the future. :) I could be wrong, but I expect this would be much simpler to do coming from a framework (with mobile helper packages) than the separate HTML/CSS for each sub-site we have now. - Kyle

Sept. 27, 2015

Re: WineConf 2015 decisions

by Benjamin Shadwick

That was unexpected, thanks. Maybe putting a banner at the top of the AppDB area of the site for a while would help? On Sat, Sep 26, 2015 at 11:11 AM, Rosanne DiMesio <dimesio(a)earthlink.net> wrote: > On Sat, 26 Sep 2015 09:07:56 -0700 > Ben Shadwick <benshadwick(a)gmail.com> wrote: > > > > > I know this is the devel list, but what does this mean for AppDB? You > > mentioned being able to report bugs against wine-staging in the bug > > tacker, but nothing about being able to submit compatibility reports > > against it in the AppDB. These are currently rejected, which just > > happened to me. > > > > They should be accepted, but getting the word out to all maintainers about > that is going to be a problem. > > I've processed your report that was rejected. > > > -- > Rosanne DiMesio <dimesio(a)earthlink.net> > > >

Sept. 26, 2015

Re: WineConf 2015 decisions

by Rosanne DiMesio

On Sat, 26 Sep 2015 13:11:59 -0500 Rosanne DiMesio <dimesio(a)earthlink.net> wrote: > > They should be accepted, but getting the word out to all maintainers about that is going to be a problem. > I found an "Email all maintainers" link on the Maintainers list, and just sent an email informing maintainers of the change. I don't know how well that will work. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Sept. 26, 2015

Re: WineConf 2015 decisions

by Rosanne DiMesio

On Sat, 26 Sep 2015 09:07:56 -0700 Ben Shadwick <benshadwick(a)gmail.com> wrote: > > I know this is the devel list, but what does this mean for AppDB? You > mentioned being able to report bugs against wine-staging in the bug > tacker, but nothing about being able to submit compatibility reports > against it in the AppDB. These are currently rejected, which just > happened to me. > They should be accepted, but getting the word out to all maintainers about that is going to be a problem. I've processed your report that was rejected. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Sept. 26, 2015

Re: WineConf 2015 decisions

by Ben Shadwick

Alexandre, I know this is the devel list, but what does this mean for AppDB? You mentioned being able to report bugs against wine-staging in the bug tacker, but nothing about being able to submit compatibility reports against it in the AppDB. These are currently rejected, which just happened to me. Thanks, - Ben S.

Sept. 26, 2015

Re: user32/tests: Allow tracing in menu test

by André Hentschel

Am 25.09.2015 um 10:45 schrieb Francois Gouget: > On Thu, 24 Sep 2015, André Hentschel wrote: > [...] >> The sense behind this patch is that I have a task from wineconf to send AJ >> a trace log of what happens before: >> Test failed: id 205: wID should be equal to hSubMenu >> on w2k8 systems. >> Strange enough is that I can't reproduce it by manually testbot runs anymore. > > Sometimes a test does not fail when run on its own but does when > run as part of WineTest because previous tests changed something. > Typically they left a window open or something like it. > > But if you managed to reproduce the issue by running the test on its own > before it may be something else. > It's suddenly gone: https://test.winehq.org/data/tests/user32:menu.html And I was able to reproduce it back in July, see attachment

Sept. 26, 2015