Re: Wine Gecko 2.24-beta1

[Jacek Caban]

On 08/18/13 04:14, Zhenbo Li wrote:
> I've tested some websites, and found that these pages have problems:
>
> http://mail.163.com (it will make gecko crash)
> http://huaban.com   (nothing can be shown)
> http://douban.com   (no pictures)
> http://html5test.com/   (can't load page, and I'm sure that it's
> not a regression)
>
> I've tested them with Firefox + flashblock, so I think they are not
> caused by flash.
>
> I'm glad to do more tests to contribute Gecko.

Thanks for testing. I confirmed all those bugs while preparing the
release, but they seem to be caused by MSHTML, not Gecko itself, so the
release won't change behaviour here.

Cheers,
Jacek

Re: Wine Gecko 2.24-beta1

[Zhenbo Li]

I've tested some websites, and found that these pages have problems:

http://mail.163.com (it will make gecko crash)
http://huaban.com   (nothing can be shown)
http://douban.com   (no pictures)
http://html5test.com/   (can't load page, and I'm sure that it's
not a regression)

I've tested them with Firefox + flashblock, so I think they are not
caused by flash.

I'm glad to do more tests to contribute Gecko.

Cheers.

2013/8/14 Jacek Caban :
> Hi all,
>
> It's time to do another update of Wine Gecko, so I prepared a new beta
> build. It's already on Sourceforge [1]. Until server-side support for
> auto install of the package is committed [2], its manual installation is
> required [3]. I attached a patch to Wine that is required for the new Gecko.
>
> Anything that uses MSHTML is worth testing. All help with testing is
> appreciated!
>
> Cheers,
> Jacek
>
> [1] https://sourceforge.net/projects/wine/files/Wine%20Gecko/2.24-beta1/
> [2] http://source.winehq.org/patches/data/97881
> [3] http://wiki.winehq.org/Gecko
>
>
>



-- 
Have a nice day!
Zhenbo Li

Re: wine-bugs change?

[Thomas Spear]

Austin, I think you put me on the right track. I had that disabled. I
enabled it and disabled it again, which caused unintended interface
changes. That forced me into the main settings for the priority inbox (not
gmail settings). There, I found a radio button that was enabled by default
apparently about overriding filters for important messages. I disabled
that. Hopefully this will no longer be a problem.

Thank you,

Thomas


On Tue, Aug 13, 2013 at 12:38 PM, Austin English wrote:

> On Tue, Aug 13, 2013 at 8:57 AM, Thomas Spear 
> wrote:
> > Thanks Henri. Sadly, when I tried that, it filtered nothing at all, just
> the
> > same as the issue I originally reported. Probably a gmail problem with
> > filtering on the List-Id, as they don't have proper support for matching
> it
> > in filters, only searches.
> >
> > Thank you,
> >
> > Thomas
> >
> >
> > On Tue, Aug 13, 2013 at 10:54 AM, Henri Verbeet 
> wrote:
> >>
> >> On 13 August 2013 17:23, Bruno Jesus <00cp...@gmail.com> wrote:
> >> > My filters are still working fine, probably they are configured the
> >> > same as yours:
> >> >
> >> > Matches: to:(wine-devel@winehq.org)
> >> > Do this: Skip Inbox, Apply label "WineDevel", Never send it to Spam
> >> >
> >> > Matches: from:(wine-b...@winehq.org)
> >> > Do this: Skip Inbox, Apply label "WineDevel", Never send it to Spam
> >> >
> >> In case anyone finds this useful, you'll generally want to filter
> >> mailing lists based on the List-Id header.
>
> The recent Gmail changes for bulk/social network notifications/etc.
> email may be the cause:
>
> http://gmailblog.blogspot.com/2013/05/a-new-inbox-that-puts-you-back-in.html
>
> --
> -Austin
>

Re: wine-bugs change?

[Austin English]

On Tue, Aug 13, 2013 at 8:57 AM, Thomas Spear  wrote:
> Thanks Henri. Sadly, when I tried that, it filtered nothing at all, just the
> same as the issue I originally reported. Probably a gmail problem with
> filtering on the List-Id, as they don't have proper support for matching it
> in filters, only searches.
>
> Thank you,
>
> Thomas
>
>
> On Tue, Aug 13, 2013 at 10:54 AM, Henri Verbeet  wrote:
>>
>> On 13 August 2013 17:23, Bruno Jesus <00cp...@gmail.com> wrote:
>> > My filters are still working fine, probably they are configured the
>> > same as yours:
>> >
>> > Matches: to:(wine-devel@winehq.org)
>> > Do this: Skip Inbox, Apply label "WineDevel", Never send it to Spam
>> >
>> > Matches: from:(wine-b...@winehq.org)
>> > Do this: Skip Inbox, Apply label "WineDevel", Never send it to Spam
>> >
>> In case anyone finds this useful, you'll generally want to filter
>> mailing lists based on the List-Id header.

The recent Gmail changes for bulk/social network notifications/etc.
email may be the cause:
http://gmailblog.blogspot.com/2013/05/a-new-inbox-that-puts-you-back-in.html

-- 
-Austin

Re: Wine Gecko repo

[Vincent Povirk]

There is dedicated git hosting software (such as gitolite and gitosis
- most people in #git seem to prefer gitolite) that provides
account-based access to Git repositories without providing any general
shell access. Perhaps something like that could be set up on
source.winehq, running on a dedicated, limiter user account?

Apparently you can also set a user's shell to git-shell to limit that
user to the operations needed to push or fetch.

Then again, if shell accounts with limited access weren't good enough
then I don't know if something like this will help.

Re: wine-bugs change?

[Thomas Spear]

Thanks Henri. Sadly, when I tried that, it filtered nothing at all, just
the same as the issue I originally reported. Probably a gmail problem with
filtering on the List-Id, as they don't have proper support for matching it
in filters, only searches.

Thank you,

Thomas


On Tue, Aug 13, 2013 at 10:54 AM, Henri Verbeet  wrote:

> On 13 August 2013 17:23, Bruno Jesus <00cp...@gmail.com> wrote:
> > My filters are still working fine, probably they are configured the
> > same as yours:
> >
> > Matches: to:(wine-devel@winehq.org)
> > Do this: Skip Inbox, Apply label "WineDevel", Never send it to Spam
> >
> > Matches: from:(wine-b...@winehq.org)
> > Do this: Skip Inbox, Apply label "WineDevel", Never send it to Spam
> >
> In case anyone finds this useful, you'll generally want to filter
> mailing lists based on the List-Id header.
>

Re: wine-bugs change?

[Henri Verbeet]

On 13 August 2013 17:23, Bruno Jesus <00cp...@gmail.com> wrote:
> My filters are still working fine, probably they are configured the
> same as yours:
>
> Matches: to:(wine-devel@winehq.org)
> Do this: Skip Inbox, Apply label "WineDevel", Never send it to Spam
>
> Matches: from:(wine-b...@winehq.org)
> Do this: Skip Inbox, Apply label "WineDevel", Never send it to Spam
>
In case anyone finds this useful, you'll generally want to filter
mailing lists based on the List-Id header.

Re: wine-bugs change?

[Thomas Spear]

Mostly the same, yes. I'll try your exact match from setting and update
shortly. Thanks for the info.

Thank you,

Thomas


On Tue, Aug 13, 2013 at 10:23 AM, Bruno Jesus <00cp...@gmail.com> wrote:

> On Tue, Aug 13, 2013 at 12:14 PM, Thomas Spear 
> wrote:
> > Hi all,
> >
> > I've been subscribed to the lists for several years now, archiving all of
> > the conversations in case a situation ever arises where a backup copy is
> > needed. I've had a filter setup in gmail for wine-bugs that has worked
> > perfectly fine for a long time now, but over the last couple of days,
> I've
> > noticed that all emails sent to or from wine-bugs are now being directed
> to
> > my inbox in addition to the folder I have the filter setup for. I'm
> planning
> > on contacting Google as well, but thought I should cover all of the
> bases by
> > asking here if there have been any changes made to that list specifically
> > that might have caused the filter to not work.
> >
> > I've tried editing the filter so that I can see what messages it searches
> > for, and it appears to be working properly, in that it appears to locate
> the
> > emails I have the filter setup for, including those that are currently in
> > both my inbox and the folder I specified to have them moved to, so it
> could
> > be that there is an issue with the "Skip Inbox" setting of the filter,
> > specifically. But again, I thought I would ask (because Google will and
> I'll
> > need to have an answer for them) what changes, if any, have been made
> > recently on the mailman side of things.
>
> My filters are still working fine, probably they are configured the
> same as yours:
>
> Matches: to:(wine-devel@winehq.org)
> Do this: Skip Inbox, Apply label "WineDevel", Never send it to Spam
>
> Matches: from:(wine-b...@winehq.org)
> Do this: Skip Inbox, Apply label "WineDevel", Never send it to Spam
>
> The same for wine-users and testbot.
>
> >
> > Thank you,
> >
> > Thomas
>
> Best wishes,
> Bruno
>

Re: wine-bugs change?

[Bruno Jesus]

On Tue, Aug 13, 2013 at 12:14 PM, Thomas Spear  wrote:
> Hi all,
>
> I've been subscribed to the lists for several years now, archiving all of
> the conversations in case a situation ever arises where a backup copy is
> needed. I've had a filter setup in gmail for wine-bugs that has worked
> perfectly fine for a long time now, but over the last couple of days, I've
> noticed that all emails sent to or from wine-bugs are now being directed to
> my inbox in addition to the folder I have the filter setup for. I'm planning
> on contacting Google as well, but thought I should cover all of the bases by
> asking here if there have been any changes made to that list specifically
> that might have caused the filter to not work.
>
> I've tried editing the filter so that I can see what messages it searches
> for, and it appears to be working properly, in that it appears to locate the
> emails I have the filter setup for, including those that are currently in
> both my inbox and the folder I specified to have them moved to, so it could
> be that there is an issue with the "Skip Inbox" setting of the filter,
> specifically. But again, I thought I would ask (because Google will and I'll
> need to have an answer for them) what changes, if any, have been made
> recently on the mailman side of things.

My filters are still working fine, probably they are configured the
same as yours:

Matches: to:(wine-devel@winehq.org)
Do this: Skip Inbox, Apply label "WineDevel", Never send it to Spam

Matches: from:(wine-b...@winehq.org)
Do this: Skip Inbox, Apply label "WineDevel", Never send it to Spam

The same for wine-users and testbot.

>
> Thank you,
>
> Thomas

Best wishes,
Bruno

Re: Wine Gecko repo

[Henri Verbeet]

On 13 August 2013 12:28, Jacek Caban  wrote:
> The question is, where should it go?
>
> - Github seems to be the choice for most project currently and it's
> already used by Wine Mono.
> - Reconsider source.winehq.org. This was not chosen due to account
> management overhead, but that's the only way to avoid problems similar
> to recent Sourceforge one (Github nor anyone else is going to give us
> any guarantees)
> - Other ideas?
>
> I'd appreciate opinions.
>
I'm not much of a fan of github in general, and I think it's a bit
awkward that Wine Gecko and Wine Mono aren't available from WineHQ, so
I'd be in favour of hosting it at source.winehq.org. If account
management is the issue, perhaps we could have a setup where Alexandre
pulls from from Vincent and you and pushes to those repositories, but
then perhaps that's worse in terms of overhead.

Re: wine mannual is wrong?

[Vincent Povirk]

You can also run console apps without a graphics driver (if they don't
do anything that requires one).

Re: wine mannual is wrong?

[Austin English]

On Mon, Aug 5, 2013 at 7:49 AM, 中川祥  wrote:
> I'm interpretering wine.man.
> I found it says"this requires X11 to run".
> But the newest ver. does not require X11,does it?

Yes. Unless you're on Mac and use the Mac driver instead.

-- 
-Austin

Re: Wine release 1.6-rc4

[Frédéric Delanoy]

On Sat, Jun 29, 2013 at 10:30 AM, Neumann, A. D.
 wrote:
> Hello,
>
> I changed my email address. Please send this information to:
> info.adneum...@t-online.de
>
> Thank you!
> D. Neumann

You have to update your email address on the wine-announce mailing
list (http://www.winehq.org/mailman/listinfo/wine-announce)

This list is for wine development only.

F. Delanoy

cygwin's fork Re: [wine-devel] Re: Bug 24018 which appears to be a ... for running Cygwin on Wine

[Hin-Tak Leung]

--- On Mon, 1/7/13, David Laight  wrote:

> On Mon, Jul 01, 2013 at 06:13:26PM
> +0200, Peter Rosin wrote:
> > 
> > I would like to point out that it seems that the
> current bug does not
> > appear to be *in* setup.exe, but rather occurs when
> setup.exe runs
> > a bash post-install script, where the bash.exe that
> interprets the
> > script depends on cygwin1.dll. If my analysis is
> correct, the bug
> > would occur also when duplicating the actions of
> setup.exe manually.
> 
> If you read into what cygwin does when trying to emulate
> fork() it
> is surprising it works at all!
> 
> Putting some effort into getting the shell (be it bash or an
> ash derivative)
> and gmake to use posix_spawn() instead of fork() and adding
> posix_spawn()
> to cygwin (for which patches are avaiable) would speed up
> cygwin no end
> and probably avoid  some of these bugs (and the random
> fork failed errors).
> 
> One day I'll get annoyed at some issues with cygwin and
> start fixing them!
> (Like getting ^C to work for windows console programs in
> mintty windows.)

Yap. It is fork/exec, the whole thing around process ids, and stat, inode 
emulation, as well.
It is just not setup.exe - post-install scripts are per-package items and some 
packages don't have them.

That has been hinted at a few times by the cygwin developers who answered and 
me. It is "easier" to see what the problem is (or "what the problems are"), by 
manually unpacking the installing packages and running the scripts by hand - as 
the cygwin developers had already suggested. And it is even "easier" by-passing 
it, if one just wants a cygwin installation to play with, by copying from a 
windows box.

Being able to get through installation, or obtaining an installation, does not 
change the fact that there are fundamental technical reasons that some part of 
cygwin does not work well in wine. Not without some serial rewrite in cygwin 
*and* wine.

cygwin did run on win98 . I used cygwin on win98 regularly then. posix_spawn() 
wasn't available on the 95/98/ME family. 

Since cygwin works well enough on genuine windows (..more or less...), that it 
can be improved/rewritten does not say the issues are less of a wine problem.

How not to ask for help Re: [wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a ... for running Cygwin on Wine

[Hin-Tak Leung]

--- On Tue, 2/7/13, Alan W. Irwin  wrote:

> > Going personal and accusing others of being biased is
> not a way of
> getting help. 

...In short, I have
> a
> prejudice against anyone stating anecdotal evidence
> concerning issues
> with _any_ open-source software if they don't back up that
> anecdotal
> evidence with a solid bug report.  For example, you
> stated some
> anecdotal evidence about a bug in Cygwin "cat", but when I
> requested a
> reference for your associated bug report to Cygwin you were
> silent.
> That told me a lot.
...

That tells you only one thing: I don't care about Cygwin enough now to bother 
filing one more bug among those already filed. My time is more valuable than 
that. 13 years ago I used it daily and I made my own contributions, and that 
was then. Half of the time I file bugs on various projects because I have 
patches to attach/send, and this is not the case with cygwin now, and will not 
be. I don't intend to file a bug because I don't intend spend time fixing it. 
You wish.

I am not the one asking for help - you are. Launching personal attacks on 
people trying to help you is just not the way to do it. Nor is exaggeration, 
nor is 20-line of [lack of] life included in every e-mail.

If you want help, ask for it, nicely, and keep it short.

Re: [wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Austin English]

On Mon, Jul 1, 2013 at 7:11 PM, Alan W. Irwin  wrote:
> On 2013-07-01 19:58+0100 Hin-Tak Leung wrote:
>
>> --- On Mon, 1/7/13, Alan W. Irwin  wrote:
>> ... I hope your negative
>>>
>>> attitude
>>> toward the Cygwin toolchain is not typical of such
>>> developers.  After
>>> all, even though the Windows GNU toolchain code bases have
>>> diverged
>>> between the two groups of developers, there is still a
>>> common interest
>>> between MinGW and Cygwin developers regarding getting the
>>> GNU
>>> toolchain to work properly on Windows.
>>
>> ...
>>
>
>> Look. You have been advised a few times, that it is possible and
>
> even easy to bypass installation-related problems and been given brief
> instructions on how to do so.
>
> The problem discussed on this thread is not with the generic part of
> the installation you have referred to but instead the problem is with
> running one of the post install scripts that is invoked by setup.exe.
>
>
>> you have also been told, *many times*,
>
> and *by the cygwin developers*, that you are just encounter one
> problems out of many, and there are more problems to come, in the
> thread you posted to the cygwin mailing list.
>
> Many times by you and once by a Cygwin developer.  I have answered both,
> but I am going to try again now since you brought it up again.
>
> Even if that assertion were true (something we don't know until some
> Wine developer with an interest in Cygwin systematically looks at it
> for the latest Wine to see how many Cygwin bugs are left for that much
> improved version of Wine) it only strengthens my argument. The fact
> remains, Cygwin is open-source software so in theory (i.e., the Wine
> developer pursuing this opportunity will need some knowledge of
> Cygwin) you know exactly what is going on with the calls to Windows
> software, and you can also directly compare results for those calls
> between the Wine version and Microsoft version of Windows. Therefore I
> think it is obvious that Cygwin represents a good opportunity to get
> rid of Wine bugs.  If there are a lot of such bugs like you and the
> Cygwin developer assert, then it represents even a bigger opportunity
> to debug those Wine issues with exact source code in hand that
> demonstrates the issue.  I think we don't really know what
> bugs are still left in recent Wine until a systematic evaluation is
> done of Cygwin on Wine, but my argument stands whether
> there are a lot of such bugs or only a few.

While it's likely that debugging this (and other) Cygwin problems with
Wine would find and eliminate bugs from Wine, it also takes a lot of
effort and know how to do so. That time is often better spent on
issues that require less effort to debug, and help more user visible
applications.

In other words, while fixing Cygwin issues is a valuable effort, it
takes a lot of time and effort that is better spent elsewhere. If you
want to spend that time and effort, feel free to do so. But asking
others to spend their time to debug issues that fix Cygwin isn't
likely to find many volunteers.

--
-Austin

Re: [wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Alan W. Irwin]

On 2013-07-01 19:58+0100 Hin-Tak Leung wrote:


--- On Mon, 1/7/13, Alan W. Irwin  wrote:
... I hope your negative

attitude
toward the Cygwin toolchain is not typical of such
developers.  After
all, even though the Windows GNU toolchain code bases have
diverged
between the two groups of developers, there is still a
common interest
between MinGW and Cygwin developers regarding getting the
GNU
toolchain to work properly on Windows.

...




Look. You have been advised a few times, that it is possible and

even easy to bypass installation-related problems and been given brief
instructions on how to do so.

The problem discussed on this thread is not with the generic part of
the installation you have referred to but instead the problem is with
running one of the post install scripts that is invoked by setup.exe.


you have also been told, *many times*,

and *by the cygwin developers*, that you are just encounter one
problems out of many, and there are more problems to come, in the
thread you posted to the cygwin mailing list.

Many times by you and once by a Cygwin developer.  I have answered both,
but I am going to try again now since you brought it up again.

Even if that assertion were true (something we don't know until some
Wine developer with an interest in Cygwin systematically looks at it
for the latest Wine to see how many Cygwin bugs are left for that much
improved version of Wine) it only strengthens my argument. The fact
remains, Cygwin is open-source software so in theory (i.e., the Wine
developer pursuing this opportunity will need some knowledge of
Cygwin) you know exactly what is going on with the calls to Windows
software, and you can also directly compare results for those calls
between the Wine version and Microsoft version of Windows. Therefore I
think it is obvious that Cygwin represents a good opportunity to get
rid of Wine bugs.  If there are a lot of such bugs like you and the
Cygwin developer assert, then it represents even a bigger opportunity
to debug those Wine issues with exact source code in hand that
demonstrates the issue.  I think we don't really know what
bugs are still left in recent Wine until a systematic evaluation is
done of Cygwin on Wine, but my argument stands whether
there are a lot of such bugs or only a few.


Going personal and accusing others of being biased is not a way of

getting help.  If you have bothered to look it up as you claim to do,
while I have a formal association with mingw, I have made absolutely
no contribution to mingw at all, ever.

Sourceforge lists you as a MinGW developer, but I believe you when you
state that is only a formal association.  I knew of that possibility
of just a formal association so that is why I was careful to put in
phrasing like "apparently", and "if this is true". I am sorry you
missed that phrasing and took that as a personal attack.

Regardless of your association or not with MinGW, I am still concerned
the opinions you have expressed here on the Cygwin tool chain are
biased. That is because I have my own bias. In short, I have a
prejudice against anyone stating anecdotal evidence concerning issues
with _any_ open-source software if they don't back up that anecdotal
evidence with a solid bug report.  For example, you stated some
anecdotal evidence about a bug in Cygwin "cat", but when I requested a
reference for your associated bug report to Cygwin you were silent.
That told me a lot.


The cygwin people would have told you the exact same thing: running

mingw on wine is fair easier and more straight-forward.

That is obvious and strengthens the argument for using Cygwin
as a debugging tool for Wine.


[...]and that cygwin is

not mingw, and there are important difference where wine is concerned.
You seem to assume the difference between cygwin and mingw is small -
they are not, and really a world apart, as far as wine is concerned.

You are completely wrong about what I assume. Try reading what I have
said earlier today.  The two projects are obviously quite different
which is why I have stated earlier today that Cygwin represents a
different opportunity (and a more extensive opportunity because it is
a lot bigger) than MinGW/MSYS to debug Wine.  Of course, that
opportunity is there only if Cygwin _on Microsoft Windows_ mostly
works and is not riddled with bugs.  I think that is a fair assumption
since Cygwin does have a significant userbase that actually uses it on
Microsoft Windows.

Something about this opportunity to use a comparison of Cygwin's
behaviour on Microsoft Windows versus the Wine version to debug Wine
obviously bothers you, and because of that you have clearly stated you
would prefer the Wine developers here ignore this opportunity and work
on something else.  However, I completely disagree with your opinion
about that opportunity.  Any fixes to Wine that make it more like
Microsoft Windows will help _all_ Windows software being run on Wine.
That said, the actual Wine developers here will probably ignor

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[David Laight]

On Mon, Jul 01, 2013 at 06:13:26PM +0200, Peter Rosin wrote:
> 
> I would like to point out that it seems that the current bug does not
> appear to be *in* setup.exe, but rather occurs when setup.exe runs
> a bash post-install script, where the bash.exe that interprets the
> script depends on cygwin1.dll. If my analysis is correct, the bug
> would occur also when duplicating the actions of setup.exe manually.

If you read into what cygwin does when trying to emulate fork() it
is surprising it works at all!

Putting some effort into getting the shell (be it bash or an ash derivative)
and gmake to use posix_spawn() instead of fork() and adding posix_spawn()
to cygwin (for which patches are avaiable) would speed up cygwin no end
and probably avoid  some of these bugs (and the random fork failed errors).

One day I'll get annoyed at some issues with cygwin and start fixing them!
(Like getting ^C to work for windows console programs in mintty windows.)

David

-- 
David Laight: da...@l8s.co.uk

Re: [wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Hin-Tak Leung]

--- On Mon, 1/7/13, Alan W. Irwin  wrote:
... I hope your negative
> attitude
> toward the Cygwin toolchain is not typical of such
> developers.  After
> all, even though the Windows GNU toolchain code bases have
> diverged
> between the two groups of developers, there is still a
> common interest
> between MinGW and Cygwin developers regarding getting the
> GNU
> toolchain to work properly on Windows.
...

Look. You have been advised a few times, that it is possible and even easy to 
bypass installation-related problems and been given brief instructions on how 
to do so; you have also been told, *many times*, and *by the cygwin 
developers*, that you are just encounter one problems out of many, and there 
are more problems to come, in the thread you posted to the cygwin mailing list.

Going personal and accusing others of being biased is not a way of getting 
help. If you have bothered to look it up as you claim to do, while I have a 
formal association with mingw, I have made absolutely no contribution to mingw 
at all, ever; whereas I have made some patches available, etc to cygwin's GNU 
findutils (merged into coreutils eventually), LaTeX, emacs/xemacs, over a 
decade ago. My history with cygwin is about twice as old as my association with 
mingw. That's a matter of public record.

If you bother to look further, the main reason is really that cygwin is a 
commercial entity - part of Redhat now, but was a privately-own company until 
13 years ago when Redhat acquired part of it. Formal membership to cygwin has 
always been different from how formal membership to mingw operates, for that 
very reason; and that I live locally to where that company was, (and the part 
of cygwin that Redhat choose not to buy, still is), and probably know or have 
met some of the cygwin developers in person. I don't have the fortune to 
meet/know many, but they have my respects.

The cygwin people would have told you the exact same thing: running mingw on 
wine is fair easier and more straight-forward, and there are very simple 
technical reasons why that is the case; and that cygwin is not mingw, and there 
are important difference where wine is concerned. You seem to assume the 
difference between cygwin and mingw is small - they are not, and really a world 
apart, as far as wine is concerned.

Going via exaggeration/sensationalist ("showstoppers") or personal attack is 
not going to win you any help. FWIW, on the latter point, few are interested in 
reading a 20-line introduction about your life (or lack of it) every time at 
the bottom of your posts. That's another thing that put people off from helping 
you.

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Alan W. Irwin]

On 2013-07-01 18:13+0200 Peter Rosin wrote:


On 2013-06-29 18:33, Alan W. Irwin wrote:

Those have been mentioned before here, and I have looked at them.
Cygwin is a very large collection of software so the number of bugs
that are reported does not seem excessive to me, and for my personal
needs (building and testing software on the Cygwin platform) I will
only be using a subset of Cygwin so I may avoid encountering
some of these bugs. Furthermore, some of these bugs (e.g.,
problems resizing a GUI) are not showstoppers, and most of them are
quite old. At the same time the latest Wine is far superior to
Wine-1.4 so some of those bugs may have just disappeared.  I hope to
find out about the actual status of Cygwin on Wine
bugs once I can get setup.exe to work on Wine.


I would like to point out that it seems that the current bug does not
appear to be *in* setup.exe, but rather occurs when setup.exe runs
a bash post-install script, where the bash.exe that interprets the
script depends on cygwin1.dll. If my analysis is correct, the bug
would occur also when duplicating the actions of setup.exe manually.
You would have to also duplicate the actions of all post-install
scripts, which is certainly more work and more error-prone than
duplicating the download and unpacking of a few tarballs.


Hi Peter:

That analysis is absolutely correct, and the current hang I am getting
for that post-install script
(/etc/postinstall/000-cygwin-post-install.sh) is a puzzler since that
occurs with or without the fork-fixed cygwin1.dll and the hang is new
behaviour compared to the result I got a month ago (obviously without
the fork-fixed cygwin1.dll) where I got an abort with an explicit
error message in agreement with the 24018 bug report. So I hope others
here with some cygwin experience will investigate further since I
might be doing something inadvertently different than before when I
replicated the behaviour reported in the 24018 bug report exactly.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Re: [wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Alan W. Irwin]

On 2013-07-01 06:13+0100 Hin-Tak Leung wrote:

[...]In terms of "relative" importance, consider that mingw (both native and cross) GNU toolchain works well, 
the toolchain part of cygwin is hardly a priority.


Once again you are implying the MinGW GNU toolchain is better than the
Cygwin GNU toolchain without mention of any bug reports from you to
Cygwin to back up that assertion.  Your constant repetition of this
theme made me curious so I looked you up on the web, and it appears
you are a MinGW developer.

If you really are a MinGW developer, I hope your negative attitude
toward the Cygwin toolchain is not typical of such developers.  After
all, even though the Windows GNU toolchain code bases have diverged
between the two groups of developers, there is still a common interest
between MinGW and Cygwin developers regarding getting the GNU
toolchain to work properly on Windows.

You certainly have the right to express your opinion about the Cygwin
toolchain here, and you _might_ even be correct, but I am concerned
you are biased since you appear to be broadcasting anecdotal evidence
without sending in bug reports to Cygwin concerning what you have
found.

And now to get back on topic again, thanks, André, for that reference
to http://wiki.winehq.org/CygwinSupport.  The two points there are
worth repeating:

For Wine, the upside would be:
  * a very good test suite
  * a much more solid implementation of the fundamental Win32 APIs

These same points can be made about MinGW/MSYS and my work on building
software (whose build is configured by my "build_projects" project) on
Wine with that toolchain.  And that work has already contributed to 3
Wine fixes (two of which were regressions introduced in the 1.5.x
series).

However, it should be emphasized that Cygwin is a very much bigger
free software project than MinGW/MSYS.  So it provides a much more
comprehensive and rigourous test of Wine than MinGW/MSYS, and this
will be the case for the forseeable future.  The number of software
projects whose builds are configured by build_projects is growing, but
that number it is still very much smaller than the list of software
builds that are included in the Cygwin distribution.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Peter Rosin]

On 2013-06-29 18:33, Alan W. Irwin wrote:
> Those have been mentioned before here, and I have looked at them.
> Cygwin is a very large collection of software so the number of bugs
> that are reported does not seem excessive to me, and for my personal
> needs (building and testing software on the Cygwin platform) I will
> only be using a subset of Cygwin so I may avoid encountering
> some of these bugs. Furthermore, some of these bugs (e.g.,
> problems resizing a GUI) are not showstoppers, and most of them are
> quite old. At the same time the latest Wine is far superior to
> Wine-1.4 so some of those bugs may have just disappeared.  I hope to
> find out about the actual status of Cygwin on Wine
> bugs once I can get setup.exe to work on Wine.

I would like to point out that it seems that the current bug does not
appear to be *in* setup.exe, but rather occurs when setup.exe runs
a bash post-install script, where the bash.exe that interprets the
script depends on cygwin1.dll. If my analysis is correct, the bug
would occur also when duplicating the actions of setup.exe manually.
You would have to also duplicate the actions of all post-install
scripts, which is certainly more work and more error-prone than
duplicating the download and unpacking of a few tarballs.

Cheers,
Peter

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Hin-Tak Leung]

--- On Sun, 30/6/13, André Hentschel  wrote:

> On 29.06.2013 23:34, Hin-Tak Leung
> wrote:
> > --- On Sat, 29/6/13, Alan W. Irwin 
> wrote:
> > 
> > ...
> >>> Also, running cygwin on wine, compared to other
> windows
> >> software
> >> which has no unix/linux equivalents, is hardly a
> priority.
> >>
> >> That is obviously personally true for you. 
> And for my
> >> personal needs
> >> Cygwin on Wine is a "would be nice" software build
> and test
> >> platform.
> > ...
> > 
> > No. Just the fact that nobody else bothered to respond
> to this thread should convince you that getting cygwin is
> not a priority to most people who is knowledgeable and
> capable of hacking wine.
> > 
> 
> I've been following this thread. What i would like to point
> you all to is:
> http://wiki.winehq.org/CygwinSupport
> It describes why running cygwin on wine is not that
> senseless low priority thing.
> Further it's mentioned at:
> http://wiki.winehq.org/TodoList and
> http://wiki.winehq.org/UnitTestSuites

Wiki is what it is - anybody with a wish can add an entry. If somebody put 
their name down and say: "*I* will do this!" - and have the knowledge & 
incentive to deliver, that's when it gets interesting. Until then, it is not. 
(Those entries might just have been added by the original poster of this thread 
- doesn't prove anything).

Using words like "showstopper" is off-putting. Especially considering there are 
at least two well-known(?) ways of getting around a mere installation problem 
of a piece of [any] open-source software - (1) unpack manually. It is 
open-source and all the actions of the installer are known; (2) copy from an 
existing installation & clone the relevant registry entries.

and (3) being able to install is not a warranty it will run.

In terms of "relative" importance, consider that mingw (both native and cross) 
GNU toolchain works well, the toolchain part of cygwin is hardly a priority; 
further,  between mingw and MSVC (note the distinction - I mean mingw, not 
cygwin), I would rather spend time improving wine's support for MSVC .

That is an interesting observation - getting microsoft products to work well is 
obviously a priority to the wider community & to Crossover, but that isn't 
mentioned much in those wiki pages.

Re: Wine release 1.6-rc4

[Neumann, A. D.]

Hello,

I changed my email address. Please send this information to: 
info.adneum...@t-online.de


Thank you!
D. Neumann

Am 28.06.2013 22:02, schrieb Alexandre Julliard:

The Wine development release 1.6-rc4 is now available.

What's new in this release (see below for details):
   - Bug fixes only, we are in code freeze.

The source is available from the following locations:

   http://prdownloads.sourceforge.net/wine/wine-1.6-rc4.tar.bz2
   http://mirrors.ibiblio.org/wine/source/1.6/wine-1.6-rc4.tar.bz2

Binary packages for various distributions will be available from:

   http://www.winehq.org/download

You will find documentation on http://www.winehq.org/documentation

You can also get the current source directly from the git
repository. Check http://www.winehq.org/git for details.

Wine is available thanks to the work of many people. See the file
AUTHORS in the distribution for the complete list.



Bugs fixed in 1.6-rc4 (total 38):

7597  No sound with OSS driver in C&C3
   11224  Throw In (Blitz Basic game) has a memory access violation
   11675  Flatout 2 demo, Battlefield 2 demo, many others need native 
d3dx9_36.D3DXCreateEffect*
   12771  Multiple graphic problems in "The Witcher"
   13314  Winevdm displays a window when running Civilization I
   13662  dogfood: xchat-2.6.2 is very slow, while updating the window
   14318  Michisoft Reader Studio v1.5a fails to produce LIT file from HTML
   16325  incorrect font rendering for CJK programs
   16784  Babylon 7: Trial mode expires after installation
   18930  IDA Pro: Failing to allocate an enormous image
   20769  crash when exiting Microsoft Flight Simulator 98
   20771  the menu bar doesn't work in M. Flight Simulator 98
   21103  Presentation 14.2 (Neurobehavioral Systems): crashes when displaying 
video output
   21827  Photoshop 7, Slider disapear
   22291  DC++ hangs on exit
   23504  Subpixel Font rendering wrong for font MS Sans Serif
   23687  err:seh:setup_exception_record stack overflow when start Proteus7 Ares
   23945  Textures are not properly rendered in Deus-Ex:Invisible War
   24230  "Psalmen - Lieder des Lebens" crashes when clicking Next in settings 
pane
   24796  DIY Kyoto's Holmes fails to start
   25125  Can only print to the default CUPS printer from Visio 5 Professional
   25605  The Settlers 3: Save as bitmap crashes world editor
   26646  Worms Reloaded: sound choppy without hardware sound = emulation
   27658  3dvia plugin installer crashes
   28495  Runes of Magic: sometimes mouse cursor freezes
   29897  Lord Of the Rings Online Slow/Freezes
   29959  Zed: 3D Preview window is blank or doesn't open.
   30578  Disassembly not in fixed-width font in IDA Pro 6.2 demo
   30897  Europa Universalis III demo crashes while 'Loading Map-Sprites...' 
without native d3dxof
   31729  cl.exe: stack overflow with certain long command lines
   31772  NtQuerySystemInformation doesn't fill ReturnLength properly with 
SystemProcessInformation
   31812  Silverlight 4.x/5.x windows have repainting problems
   31908  Garena Blackshot does login
   32820  Offline rekening overzicht, orov doesn't work
   33283  Configuration of WM_NAME is delayed for virtual desktop
   33753  Titan Quest : Multiplayer not working
   33865  Regression in a specialized program
   33883  Scirra httpapi.dll error trying to Run a game



Changes since 1.6-rc3:

Alexandre Julliard (22):
   gdi32: Cache the font smoothing parameters.
   kernel32: FormatMessage precision arguments are integers.
   comdlg32: Add support for the CF_NOVERTFONTS flag.
   clock: Don't offer vertical fonts in the font dialog.
   notepad: Don't offer vertical fonts in the font dialog.
   winecfg: Don't offer vertical fonts in the font dialog.
   wineconsole: Don't offer vertical fonts in the font dialog.
   winefile: Don't offer vertical fonts in the font dialog.
   wordpad: Don't offer vertical fonts in the font dialog.
   make_unicode: Move codepage file output code to a common routine and 
make default characters configurable.
   libwine: Add support for codepage 10001 (Mac Japanese).
   libwine: Add support for codepage 10002 (Mac Traditional Chinese).
   libwine: Add support for codepage 10003 (Mac Korean).
   libwine: Add support for codepage 10008 (Mac Simplified Chinese).
   libwine: Add support for codepage 10010 (Mac Romanian).
   libwine: Add support for codepage 10017 (Mac Ukrainian).
   libwine: Add support for codepage 10021 (Mac Thai).
   libwine: Add support for codepage 10082 (Mac Croatian).
   krnl386: Create a new console for DOS binaries.
   winevdm: Make it a GUI application to avoid a spurious console.
   user32: Fetch the window menu again after sending initialization 
messages.
   advapi32: Fix ReportEvent parameter types in the spec file.

Andrew 

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[André Hentschel]

On 29.06.2013 23:34, Hin-Tak Leung wrote:
> --- On Sat, 29/6/13, Alan W. Irwin  wrote:
> 
> ...
>>> Also, running cygwin on wine, compared to other windows
>> software
>> which has no unix/linux equivalents, is hardly a priority.
>>
>> That is obviously personally true for you.  And for my
>> personal needs
>> Cygwin on Wine is a "would be nice" software build and test
>> platform.
> ...
> 
> No. Just the fact that nobody else bothered to respond to this thread should 
> convince you that getting cygwin is not a priority to most people who is 
> knowledgeable and capable of hacking wine.
> 

I've been following this thread. What i would like to point you all to is:
http://wiki.winehq.org/CygwinSupport
It describes why running cygwin on wine is not that senseless low priority 
thing.
Further it's mentioned at:
http://wiki.winehq.org/TodoList and
http://wiki.winehq.org/UnitTestSuites

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Hin-Tak Leung]

--- On Sat, 29/6/13, Alan W. Irwin  wrote:

...
> > Also, running cygwin on wine, compared to other windows
> software
> which has no unix/linux equivalents, is hardly a priority.
> 
> That is obviously personally true for you.  And for my
> personal needs
> Cygwin on Wine is a "would be nice" software build and test
> platform.
...

No. Just the fact that nobody else bothered to respond to this thread should 
convince you that getting cygwin is not a priority to most people who is 
knowledgeable and capable of hacking wine.

As for true for me - well, I have fixed or help fixed a few issue of wine with 
running microsoft products - embedded IE rendering, and Microsoft's development 
tool chain (yes, I am talking about Visual C++, and nmake, [Microsoft's make], 
and microsoft's manifest modification tool whose name I forget - the tool for 
Microsoft's way of modifying executable binaries post-compilation). Obviously 
my interests lies elsewhere. Mingw works alright. Cygwin is just not a priority 
for my time, and I sincerely hope that other people who are capable of 
improving wine would spend their time on more worthwhile causes.

p.s. using words like "showstopper" actually put people off.

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Alan W. Irwin]

On 2013-06-29 11:57+0100 Hin-Tak Leung wrote:


--- On Sat, 29/6/13, Alan W. Irwin  wrote:

...

The Mingw GNU toolchain works wells under wine. The

cygwin GNU toolchain don't, the last time I checked.

That may be true, but the best way to make that point about
the Cygwin
GNU toolchain is with official Cygwin bug reports rather
than
asserting stuff here in an anecdotal way.





Anytime that a piece of windows software (including Cygwin) works on windows 
but not on wine, is a wine problem.


No question.  In fact I stated bug reports to Cygwin would probably
only be taken seriously if they included a demonstration of the
problem on the Microsoft version of Windows.


The fact that the such software developers (cygwin people) are nice enough to 
respond and adjust their software (cygwin) to fit a *flaw in wine* does not 
make the problem less a wine one.


This statement misrepresents what has recently occurred with regard to
bug 24018.  Arjen Markus's bug report demonstrated the Cygwin fork
problem on Microsoft Windows.  Because of that the Cygwin developers
were quickly able to verify and fix the problem.


The various problems of running cygwin in wine are already

well-documented - just do a search on wine's bugzilla (there are over
a dozen of those).

Those have been mentioned before here, and I have looked at them.
Cygwin is a very large collection of software so the number of bugs
that are reported does not seem excessive to me, and for my personal
needs (building and testing software on the Cygwin platform) I will
only be using a subset of Cygwin so I may avoid encountering
some of these bugs. Furthermore, some of these bugs (e.g.,
problems resizing a GUI) are not showstoppers, and most of them are
quite old. At the same time the latest Wine is far superior to
Wine-1.4 so some of those bugs may have just disappeared.  I hope to
find out about the actual status of Cygwin on Wine
bugs once I can get setup.exe to work on Wine.


So the mere fact that the installer does not work correctly, is just

another such problem.

That's been covered already.  We obviously disagree on this issue.


Also, running cygwin on wine, compared to other windows software

which has no unix/linux equivalents, is hardly a priority.

That is obviously personally true for you.  And for my personal needs
Cygwin on Wine is a "would be nice" software build and test platform.
That is, it is actually a medium to low priority for me since I
already have plenty to do extending my builds and tests of free
software on the MinGW/MSYS/Wine platform to additional software packages.

But our personal needs are not what is important here. From the more
general perspective any problems running open-source software on Wine
should be easier to debug (since all the details of the exact Windows
system calls are known) than trying to debug problems with running
proprietary software (e.g., some random game) on Wine where you have
to guess at the details.  As an illustration of that, three times
during the 1.5.x series I have found Wine bugs or regressions as a
result of running open source software on Wine. (Thankfully, all of
those have been fixed by the Wine developers.) Cygwin is the largest
distribution of open-source software that runs on Windows.  It follows
that Cygwin represents a good opportunity to find and fix Wine issues.

In sum you have expressed your opinions on Cygwin and Wine and I have
mostly disagreed with those opinions.  Therefore, I think we have covered
everything, and it is time to call a halt to this side-topic.  So from now
on my contributions to this thread will focus on the original topic
which is problems in running setup.exe on Wine, i.e., bug 24018, and I
urge you to do the same.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Hin-Tak Leung]

--- On Sat, 29/6/13, Alan W. Irwin  wrote:

...
> > The Mingw GNU toolchain works wells under wine. The
> cygwin GNU toolchain don't, the last time I checked.
> 
> That may be true, but the best way to make that point about
> the Cygwin
> GNU toolchain is with official Cygwin bug reports rather
> than
> asserting stuff here in an anecdotal way.

No. Anytime that a piece of windows software (including Cygwin) works on 
windows but not on wine, is a wine problem. The fact that the such software 
developers (cygwin people) are nice enough to respond and adjust their software 
(cygwin) to fit a *flaw in wine* does not make the problem less a wine one. 

The various problems of running cygwin in wine are already well-documented - 
just do a search on wine's bugzilla (there are over a dozen of those). So the 
mere fact that the installer does not work correctly, is just another such 
problem. Also, running cygwin on wine, compared to other windows software which 
has no unix/linux equivalents, is hardly a priority.

One bug among many, and on a piece of software which is interesting but not a 
priority. That's what the issue is.

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Alan W. Irwin]

On 2013-06-28 23:13+0100 Hin-Tak Leung wrote:


--- On Fri, 28/6/13, Alan W. Irwin  wrote:

... But I _know_ the MSYS version of cat works fine on recent

Wine just
like the rest of the GNU toolchain used for building
software so if
the MSYS and Cygwin GNU toolchain code bases have not
diverged too
much it should be straightforward (and probably quite fast,

...

Again, MSYS (i.e. Mingw) is not cygwin. This is probably an FAQ on mingw's web 
site. You really need to do some reading.


Hmm. I think the shoe is on the other foot.  Please read what I said
above which clearly acknowledges the well-known differences between
the MinGW/MSYS GNU toolchain and the Cygwin one.


The Mingw GNU toolchain works wells under wine. The cygwin GNU toolchain don't, 
the last time I checked.


That may be true, but the best way to make that point about the Cygwin
GNU toolchain is with official Cygwin bug reports rather than
asserting stuff here in an anecdotal way.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Hin-Tak Leung]

--- On Fri, 28/6/13, Alan W. Irwin  wrote:

... But I _know_ the MSYS version of cat works fine on recent
> Wine just
> like the rest of the GNU toolchain used for building
> software so if
> the MSYS and Cygwin GNU toolchain code bases have not
> diverged too
> much it should be straightforward (and probably quite fast,
...

Again, MSYS (i.e. Mingw) is not cygwin. This is probably an FAQ on mingw's web 
site. You really need to do some reading.

The Mingw GNU toolchain works wells under wine. The cygwin GNU toolchain don't, 
the last time I checked.

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Alan W. Irwin]

On 2013-06-28 22:07+0100 Hin-Tak Leung wrote:

--- On Thu, 27/6/13, Alan W. Irwin  wrote:



[...]I asked
Arjen Markus, a PLplot colleague of mine with Cygwin
contacts, to try
and get the debugging process started with the Cygwin
developers.  The
response 
to his
post looks quite promising.  [and now has arrived at a solution that

solves the fork bomb test].


I read that thread with interest.

However, I noticed that you have quite a few fundamental misunderstanding or 
lack of experience with cygwin.


Definitely the latter and probably the former.  :-)


[] However, being able to install [by alternative means than

setup.exe] does not equal to being able to run
[...]

I absolutely agree, but I am concerned that those alternative
installation means might be the source of the issue.


You can try very simple things, like e.g. "cat fileA fileB > fileC", if you 
need convincing.


Have you reported this to Cygwin as a bug?  Their response to the
fork issue was extraordinarily fast.

By the way, when you report that possible cat bug to Cygwin, I am sure they will
insist you use standard means (e.g., setup.exe) to install Cygwin to
remove any uncertainty about whether your non-standard installation is
the cause of the issue. And they will also probably insist you
demonstrate the issue for the Microsoft version of Windows since Wine
currently has an uncertain reputation (rightly or wrongly but we
cannot say anything about that until the standard Cygwin method of
installation works) concerning its ability to run Cygwin.

You may have really found a valid Cygwin bug for their version of cat.
But I _know_ the MSYS version of cat works fine on recent Wine just
like the rest of the GNU toolchain used for building software so if
the MSYS and Cygwin GNU toolchain code bases have not diverged too
much it should be straightforward (and probably quite fast, if the
fork bugfix speed is anything to go by) for the Cygwin developers to
fix the issue if you prove it actually exists with a standard Cygwin
installation on Microsoft Windows.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Hin-Tak Leung]

--- On Thu, 27/6/13, Alan W. Irwin  wrote:

> On 2013-06-26 18:14-0700 Alan W.
> Irwin wrote:
> 
> > Note in retrospect I realized that this period leading
> up to the
> > release of Wine-1.6.0 has been a lousy time to ask wine
> developers
> > with Cygwin expertise to take on the additional
> distraction of getting
> > the debugging process for bug 24018 started with the
> Cygwin
> > developers.
> 
> Because of the bad timing from the Wine developer
> perspective, I asked
> Arjen Markus, a PLplot colleague of mine with Cygwin
> contacts, to try
> and get the debugging process started with the Cygwin
> developers.  The
> response 
> to his
> post looks quite promising.  It turned out the "fork
> bomb" test
> programme failed after only 500 iterations, and the Cygwin
> developer,
> Corinna Vinschen thinks she knows what the issue is with
> more to come.
> So stay tuned to that thread if you have an interest in bug
> 24018.

I read that thread with interest.

However, I noticed that you have quite a few fundamental misunderstanding or 
lack of experience with cygwin.

Firstly, cygwin's setup.exe doesn't do much more than unpacking tar balls, 
write a few registry entries, and run some scripts through sh.exe, 
occasionally. (the last one depends on the package, the middle one is one-off, 
the first time ever you run setup.exe - there after it just read those entries 
back; the unpacking obviously happens per package).

So it is entirely possible to *install* cygwin into a wine prefix, without 
using cygwin's setup.exe, if you know how to unpack those files as well as set 
up the registry entries. It is even easier if you have access to a windows box: 
you can simply export those registries and import them into wine, copy the 
entire installed tree across from a windows box to wine. That, in principle, 
gives identical results as if you manage to run the setup.exe . (you can clone 
a cygwin installation across windows boxes in exactly the same way i.e. by 
copying the whole installed directory, plus export/importing a few registry 
entries.).

However, being able to install does not equal to being able to run, or run 
correctly. I thought I wrote that already. Anyway, *some* people bundle bits of 
cygwin in their custom software for little things, and I have come across at 
least one such installer. The installer runs fine with wine, but the installed 
cygwin bits don't work correctly in wine. cat & echo were the two I noticed - 
the latter is fairly awful, since cmd has a built in echo, and wine cmd's works 
alright; said custom software installer also put its binaries in the front of 
the system $PATH (or if you prefer window's style, %PATH%).

The added registry entries - or at least the important ones - are, if I 
remember correctly, the mount table i.e. it tells the installed bits where to 
find /usr/share, etc. Of course some, e.g. again, cat, echo, etc don't really 
have extra bits to look up, unlike say, emacs - which have lisp code files to 
load - and cat, echo, etc are supposed to work without cygwin mount table 
entires. On windows, they do work, and on wine, they don't (*not* because of 
the absence).

You can try very simple things, like e.g. "cat fileA fileB > fileC", if you 
need convincing.

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Alan W. Irwin]

On 2013-06-26 18:14-0700 Alan W. Irwin wrote:


Note in retrospect I realized that this period leading up to the
release of Wine-1.6.0 has been a lousy time to ask wine developers
with Cygwin expertise to take on the additional distraction of getting
the debugging process for bug 24018 started with the Cygwin
developers.


Because of the bad timing from the Wine developer perspective, I asked
Arjen Markus, a PLplot colleague of mine with Cygwin contacts, to try
and get the debugging process started with the Cygwin developers.  The
response  to his
post looks quite promising.  It turned out the "fork bomb" test
programme failed after only 500 iterations, and the Cygwin developer,
Corinna Vinschen thinks she knows what the issue is with more to come.
So stay tuned to that thread if you have an interest in bug 24018.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Re: [Wine] German translation - netstat.exe

[Joerg Schiermeier]

On Tuesday, 18 Jun 2013 at 19:35:02 André Hentschel wrote:

> when you scroll down a bit on that page, you see everything needed to get rid 
> of false positives.
Ah, I didn't scrolled down sooo deep.
:(

> Oh and fgouget is Fran?ois Gouget
Thanks for this hint. I will deal with it in the right manner.

-- 

Kindly regards
Joerg Schiermeier
Bielefeld/Germany

Re: [Wine] German translation - netstat.exe

[André Hentschel]

On 18.06.2013 16:23, Joerg Schiermeier wrote:
> Hi list,
> 
> in wines call for translators is listed one 'spelling error' in the
> German translation which isn't one.
> 
> 
> The translation is correct:
> 
> 
> --
> [Proto] (unchanged) 10453
>  -> Porto, Proton, Photo, Protest, Protzen
> --
> is correct translated to 'Proto'. 'Proto' is used as an abbreviation
> for protocol.
> 
> This appears in 'netstat.exe' (src/wine/programs/netstat).
> I checked this in an 'Windows 7' installation running the original
> command.
> 
> Who is responsible for the list in
> ?
> You may please take this one faulty error away.
> 

Hi,
when you scroll down a bit on that page, you see everything needed to get rid 
of false positives.
Oh and fgouget is François Gouget

Re: [Wine] Call for Translators

[Frédéric Delanoy]

On Sun, Jun 16, 2013 at 2:02 PM, Martin Gregorie  wrote:
> On Sun, 2013-06-16 at 08:52 +0200, Francois Gouget wrote:
>> On Sun, 16 Jun 2013, Yaron Shahrabani wrote:
>>
>> > Hey Francois, sorry for trolling but I guess this is the time to revisit
>> > our stand regarding web translation platform (because I suspect it might be
>> > the cause for the lack of participation).
>> >
>> > What do you guys think?
>>
>> Do you mean the stance on making sure every contribution is properly
>> attributed to its author? I don't think that's negotiable.
>>
> As a native English speaker I'm not really affected by WINE's language
> support.
>
> My main gripe with WINE is the evident lack of regression testing.
>
> Martin

Please don't hijack threads.

Feel free to open a new thread on this subject on wine-devel.

Frédéric

Re: [wine-devel] Re: How to stop gecko and mono popups while git bisecting?

[Alan W. Irwin]

On 2013-06-04 00:12+0200 André Hentschel wrote:


Or you create a wineprefix after you removed it, but without a valid display 
set:
DISPLAY=none wine wineboot


Perfect.  That was just what I needed for my git bisect test script.

Thanks, André!

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Re: [wine-devel] Troubles configuring and building wine-1.5.30 on Debian wheezy

[Alan W. Irwin]

On 2013-05-21 18:27-0700 Austin English wrote:


On Tue, May 21, 2013 at 6:17 PM, Alan W. Irwin
 wrote:

Can somebody advise me about the importance (or not) of the remaining
two missing 32-bit libraries (libdbus and gstreamer)?  For example,
are they worth some extraordinary measures such as downloading the
binary i386 -dev package and extracting the static 32-bit versions
separately from that package?


For your purposes, libdbus/gstreamer probably aren't important.

You should be aware that cygwin doesn't work terribly well under Wine,
however. There are several open bugs:
http://bugs.winehq.org/show_bug.cgi?id=12104
http://bugs.winehq.org/show_bug.cgi?id=19800
http://bugs.winehq.org/show_bug.cgi?id=19801
http://bugs.winehq.org/show_bug.cgi?id=19858
http://bugs.winehq.org/show_bug.cgi?id=19859
http://bugs.winehq.org/show_bug.cgi?id=21424
http://bugs.winehq.org/show_bug.cgi?id=24018


Thanks, Austin, for that additional information.  In light of that
information I will just ignore libdbus/gstreamer and concentrate on
configuring access to 32-bit png.

The above list of cygwin-related issues seems pretty serious. I ran
into the setup.exe problem detailed by 24018 myself for wine-1.5.19
and also my latest 32-bit build attempt (without png) of wine-1.5.30.
I don't know how to work around 24018 (if that is even possible) due
to my lack of Cygwin experience so I couldn't evaluate the other
Cygwin issues detailed above.

This is my first experience with Cygwin (I only wanted to use it to
test software builds like was so successful for me with MinGW/MSYS
under wine-1.5.19).  However, in light of the above issues and my lack
of experience with Cygwin, I have decided to give up on Cygwin for now
and just continue with MinGW/MSYS builds and tests of my software
projects under Wine.  Of course, even for that case the wine-1.5.30
build issues that are the subject of this thread are still relevant so
I will continue with trying to figure out the png 32-bit library issue
and ultimately try to see whether I can obtain similar success for my
MinGW/MSYS software builds and tests under wine-1.5.30 like I
currently experience with wine-1.5.19.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Re: [wine-devel] Troubles configuring and building wine-1.5.30 on Debian wheezy

[Austin English]

On Tue, May 21, 2013 at 6:17 PM, Alan W. Irwin
 wrote:
> On 2013-05-21 21:22+0200 André Hentschel wrote:
>
>> To finally answer this: pure wine64 can't run 32-bit applications, you
>> need wine32 or a wow64 setup for this.
>
>
> Thanks for that important clarification.  That means I always need
> 32-bit as standalone or as part of wow64.  So regardless of that
> choice I have to figure out the 32-bit library configuration
> issues that have been introduced since wine-1.5.19.
>
> To answer another responder (Ričardas Barkauskas), my system is almost
> entirely 64-bit with many 64-bit development packages installed so I
> can build lots of different 64-bit packages on Linux.  But wine is the
> exception since from the above answer to my question, 32-bit wine is
> always going to be needed, and that requires installation of 32-bit
> libraries (which I only do because of my 32-bit wine needs).
>
> Before, I straightforwardly built wine32 (e.g., for wine-1.5.19) with
> minimal issues with linking to a relatively small number of 32-bit
> libraries that were required at that time.  However, somewhere between
> wine-1.5.19 and wine-1.5.30 (which I have patched as instructed for
> the libwine creation issue that came up early in this thread for
> 1.5.30) much more stringent requirements for 32-bit libraries were
> introduced for the 32-bit build, and this is a problem for Debian
> wheezy because many Debian wheezy library -dev packages (which create
> *.so symlinks to the shared libraries and which typically also provide
> static libraries) are not multiarch aware.  The only way to beat this
> that I am aware of is convert to a 32-bit system (which I definitely
> don't want to do) or create the *.so symlinks to the 32-bit libraries
> myself.  I have created a script to do that (in the user's standalone
> build tree to avoid contaminating system areas).  After running that
> script (attached if anybody else reading this thread in the future
> finds it to be useful) I also execute
>
> export LDFLAGS=-L$(pwd)
>
> so those symlinks in the build tree are accessible to the linker.
>
> The 32-bit wine-1.5.30 configure script results are now much better; I
> have reduced the number of missing 32-bit libraries from ~30 to 5.
> The associated configure messages are
>
> configure: OpenCL 32-bit development files not found, OpenCL won't be
> supported.
> configure: libdbus 32-bit development files not found, no dynamic
> device support.
> configure: gstreamer-0.10 base plugins 32-bit development files not
> found, gstreamer support disabled
>
> configure: WARNING: libjpeg 32-bit development files not found, JPEG
> won't be supported.
>
> configure: WARNING: libpng 32-bit development files not found, PNG
> won't be supported.
>
> At least I now have access to the 32-bit version of libfreetype which
> allows fonts to be generated.  I did the normal 32-bit build after
> that configure step, and it looks like the result passes some minimal
> tests such as being able to run winecfg.  However, when I tried
> running the Cygwin setup.exe from wineconsole, there were lots of
> warning messages about no png.  As a result, I plan to work some more
> to get access to the 32-bit version of the png library before
> configuring and building the 32-bit version of wine-1.5.30 again.
>
> If that search for a way to get access to the 32-bit png library is a
> success, the missing libraries will be reduced to 4. In the past for
> 32-bit builds I have gotten by without opencl and jpeg (according to
> my dated notes) so I am not going to worry about them (unless someone
> here advises me they have some importance I am unaware of).
>
> Can somebody advise me about the importance (or not) of the remaining
> two missing 32-bit libraries (libdbus and gstreamer)?  For example,
> are they worth some extraordinary measures such as downloading the
> binary i386 -dev package and extracting the static 32-bit versions
> separately from that package?

For your purposes, libdbus/gstreamer probably aren't important.

You should be aware that cygwin doesn't work terribly well under Wine,
however. There are several open bugs:
http://bugs.winehq.org/show_bug.cgi?id=12104
http://bugs.winehq.org/show_bug.cgi?id=19800
http://bugs.winehq.org/show_bug.cgi?id=19801
http://bugs.winehq.org/show_bug.cgi?id=19858
http://bugs.winehq.org/show_bug.cgi?id=19859
http://bugs.winehq.org/show_bug.cgi?id=21424
http://bugs.winehq.org/show_bug.cgi?id=24018

--
-Austin

Re: [wine-devel] Troubles configuring and building wine-1.5.30 on Debian wheezy

[Alan W. Irwin]

On 2013-05-21 21:22+0200 André Hentschel wrote:


To finally answer this: pure wine64 can't run 32-bit applications, you need 
wine32 or a wow64 setup for this.


Thanks for that important clarification.  That means I always need
32-bit as standalone or as part of wow64.  So regardless of that
choice I have to figure out the 32-bit library configuration
issues that have been introduced since wine-1.5.19.

To answer another responder (Ričardas Barkauskas), my system is almost
entirely 64-bit with many 64-bit development packages installed so I
can build lots of different 64-bit packages on Linux.  But wine is the
exception since from the above answer to my question, 32-bit wine is
always going to be needed, and that requires installation of 32-bit
libraries (which I only do because of my 32-bit wine needs).

Before, I straightforwardly built wine32 (e.g., for wine-1.5.19) with
minimal issues with linking to a relatively small number of 32-bit
libraries that were required at that time.  However, somewhere between
wine-1.5.19 and wine-1.5.30 (which I have patched as instructed for
the libwine creation issue that came up early in this thread for
1.5.30) much more stringent requirements for 32-bit libraries were
introduced for the 32-bit build, and this is a problem for Debian
wheezy because many Debian wheezy library -dev packages (which create
*.so symlinks to the shared libraries and which typically also provide
static libraries) are not multiarch aware.  The only way to beat this
that I am aware of is convert to a 32-bit system (which I definitely
don't want to do) or create the *.so symlinks to the 32-bit libraries
myself.  I have created a script to do that (in the user's standalone
build tree to avoid contaminating system areas).  After running that
script (attached if anybody else reading this thread in the future
finds it to be useful) I also execute

export LDFLAGS=-L$(pwd)

so those symlinks in the build tree are accessible to the linker.

The 32-bit wine-1.5.30 configure script results are now much better; I
have reduced the number of missing 32-bit libraries from ~30 to 5.
The associated configure messages are

configure: OpenCL 32-bit development files not found, OpenCL won't be
supported.
configure: libdbus 32-bit development files not found, no dynamic
device support.
configure: gstreamer-0.10 base plugins 32-bit development files not
found, gstreamer support disabled

configure: WARNING: libjpeg 32-bit development files not found, JPEG
won't be supported.

configure: WARNING: libpng 32-bit development files not found, PNG
won't be supported.

At least I now have access to the 32-bit version of libfreetype which
allows fonts to be generated.  I did the normal 32-bit build after
that configure step, and it looks like the result passes some minimal
tests such as being able to run winecfg.  However, when I tried
running the Cygwin setup.exe from wineconsole, there were lots of
warning messages about no png.  As a result, I plan to work some more
to get access to the 32-bit version of the png library before
configuring and building the 32-bit version of wine-1.5.30 again.

If that search for a way to get access to the 32-bit png library is a
success, the missing libraries will be reduced to 4. In the past for
32-bit builds I have gotten by without opencl and jpeg (according to
my dated notes) so I am not going to worry about them (unless someone
here advises me they have some importance I am unaware of).

Can somebody advise me about the importance (or not) of the remaining
two missing 32-bit libraries (libdbus and gstreamer)?  For example,
are they worth some extraordinary measures such as downloading the
binary i386 -dev package and extracting the static 32-bit versions
separately from that package?

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

create_i386-linux-gnu_so_links.gz
Description: gzip compressed  bash script to create symlinks in the local directory for 32-bit libraries

Re: [wine-devel] Troubles configuring and building wine-1.5.30 on Debian wheezy

[André Hentschel]

Am 21.05.2013 10:10, schrieb Alan W. Irwin:
> On 2013-05-20 20:24-0700 Alan W. Irwin wrote:
>> So here are my questions and further comments:
>>
>> 1. Is there a way to stick with a pure 64-bit Wine system, or is that
>> normally pretty useless because downloaded applications such as the
>> Cygwin installer which apparently is 32-bit, i.e.,
>>
>> wine@raven> file setup.exe
>> setup.exe: PE32 executable (GUI) Intel 80386 (stripped to external
>> PDB), for MS Windows, UPX compressed
>>
>> wont run on it?
> 
> I would appreciate an answer to this question, and if the answer is a
> standalone wine64 build should work, how do you run the above
> setup.exe?

To finally answer this: pure wine64 can't run 32-bit applications, you need 
wine32 or a wow64 setup for this.

Re: [wine-devel] Troubles configuring and building wine-1.5.30 on Debian wheezy

[Ričardas Barkauskas]

> The idea there to install *.so symlinks manually might be a big help.
> For example, Debian wheezy does allow simultaneous install of
> libfreetype6:i386 and libfreetype6:amd64. (In fact, my system has
> those both installed now.) It is the -dev versions of those packages
> which cannot be simultaneously installed on Debian Wheezy. So the
> appropriate symlink may be all I need (for quite a few packages where
> the i386 library is installed, but not the -dev version with the
> symlink).
>
> I will try this symlink idea (which takes me back to my
> first Linux install in 1996) later today after I get some sleep.
>
> Thanks, Frédéric!  I think this might work.
>
> Alan
> __
> Alan W. Irwin

If you don't care about building anything 64 bit installing
pkg-config:i386 while removing pkg-config:amd64 allows for
libfreetype6-dev:i386 and libfontconfig1-dev:i386 to be installed
without playing with symlinks. (Though maybe 64 bit building stuff still
works after this? )

REalm

Re: [wine-devel] Troubles configuring and building wine-1.5.30 on Debian wheezy

[Alan W. Irwin]

On 2013-05-21 11:08+0200 Frédéric Delanoy wrote:


On Tue, May 21, 2013 at 10:10 AM, Alan W. Irwin
wrote:


Hugh McMaster's reply was already a help, but I need more comments
please.



Maybe http://wiki.winehq.org/WineOn64bit could help?


The idea there to install *.so symlinks manually might be a big help.
For example, Debian wheezy does allow simultaneous install of
libfreetype6:i386 and libfreetype6:amd64. (In fact, my system has
those both installed now.) It is the -dev versions of those packages
which cannot be simultaneously installed on Debian Wheezy. So the
appropriate symlink may be all I need (for quite a few packages where
the i386 library is installed, but not the -dev version with the
symlink).

I will try this symlink idea (which takes me back to my
first Linux install in 1996) later today after I get some sleep.

Thanks, Frédéric!  I think this might work.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Re: [wine-devel] Troubles configuring and building wine-1.5.30 on Debian wheezy

[Frédéric Delanoy]

On Tue, May 21, 2013 at 10:10 AM, Alan W. Irwin
wrote:

> Hugh McMaster's reply was already a help, but I need more comments
> please.
>

Maybe http://wiki.winehq.org/WineOn64bit could help?

Frédéric

Re: [wine-devel] Troubles configuring and building wine-1.5.30 on Debian wheezy

[Alan W. Irwin]

On 2013-05-20 20:24-0700 Alan W. Irwin wrote:


[...]For example:

wine@raven> wine64
wine64: error while loading shared libraries: libwine.so.1: cannot
open shared object file: No such file or directory


I fixed this 1.5.30 issue by applying the patch at

http://source.winehq.org/git/wine.git/patch/ce4b6451aabbe83809c7483c748cfa009cc090d6

as suggested by Hugh McMaster

and then redid the WoW64 build recommended by
http://wiki.winehq.org/Wine64

For the 32-bit part of that, I tried the --without-freetype option
to get round the problem that the
two libfreetype6-dev:i386 and libfreetype6-dev:amd64 packages cannot
be installed simultaneously for Debian wheezy.  This allowed the configuration 
to
finish with a long shopping list of missing 32-bit development
packages.  Those appeared not to be fatal 
unlike the missing 32-bit freetype development package

which indeed turned out to be fatal.  Here is
that error message:

wine@raven> wineconsole setup.exe
err:wineconsole:WINECON_Fatal Couldn't find a decent font, aborting


So here are my questions and further comments:

1. Is there a way to stick with a pure 64-bit Wine system, or is that
normally pretty useless because downloaded applications such as the
Cygwin installer which apparently is 32-bit, i.e.,

wine@raven> file setup.exe
setup.exe: PE32 executable (GUI) Intel 80386 (stripped to external
PDB), for MS Windows, UPX compressed

wont run on it?


I would appreciate an answer to this question, and if the answer is a
standalone wine64 build should work, how do you run the above
setup.exe?



2. If the WoW64 configuration is really the best solution, what are
the consequences of dropping libfreetype from the 32-bit configuration
(but obviously including it in the 64-bit configuration).  IOW, if I
just say --without-freetype for the 32-bit configuration (suggested as
a possibility above by that error message) will the fonts be built and
installed by the 64-bit configuration that includes libfreetype?


I believe I have answered this one above.  Apparently it is still fatal
even though the fonts were (presumably) built and installed for the 64-bit part
of the WoW64 build since that had access to the installed 64-bit libfreetype
development package.



3. I would have liked to continue with pure 32-bit wine since that
was what I have been used to all these years, but it appears
wine-1.5.30 32-bit dependencies are really fearsome compared
to the relative modest 32-bit dependencies for wine-1.5.19 so this 
effectively

makes it impossible to build a standalone 32-bit wine system
on Debian Wheezy (because no fonts will be built if
--without-freetype is used) and might also compromise WoW64 builds
(see question 2 above).  It obviously doesn't affect pure 64-bit Wine
builds, but I couldn't get that to work at all at run time (missing
libwine.so.1 (see above)), but if there are workarounds for that
issue, then it still might be useless (see question 1 above).



So it appears a pure 32-bit build or WoW64
build of (patched) wine-1.5.30 is completely blocked because of the fatal lack 
of 32-bit
libfreetype library on Debian wheezy that can coexist with the 64-bit
version of libfreetype.  This was not an issue for my previous 32-bit
build of wine-1.5.19.  There remains a faint hope that a pure
64-bit build and install of wine-1.5.30 will work since there are no
missing dependencies, and the pure 64-bit build and install finishes without
errors.  But I will need some guidance in that case about how to use
such a pure 64-bit wine at run time to execute, say, the 32-bit
setup.exe.

Hugh McMaster's reply was already a help, but I need more comments
please.

For example, is there a patch that I could apply to get rid
of the fairly new constraint for 32-bit builds that there must be a
32-bit libfreetype development package installed?

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Re: wine-patches

[Marcus Meissner]

On Thu, May 02, 2013 at 08:12:53AM +0200, Daniel Jeliński wrote:
> Hello,
> I sent a ~200KB patch to wine-patches last night and it disappeared without
> a trace. I'm wondering if it got lost or just went to moderation.
> Regards,
> Daniel
> 
> PS.I just resent it, still no luck.

If you are subscribed, the list size trigger will probably have happened
and it is waiting for moderation.


What is in the 200KB patch?

If its sourcecode, it is too large even without looking at it. :)

Ciao, Marcus

Re: Wine History

[Scott Ritchie]

On 04/20/2013 05:50 PM, André Hentschel wrote:
> Hi,
> meanwhile everyone should know that Wine turns 20 this year. AJ said in this 
> years Keynote we'll need to find a way to celebrate this in June.
> So i did some research on this and found "Wine History" mails by Dan Kegel 
> from 2002 and much earlier Bob Amstadt talking about late May or early June 
> 1993.
> The date listed on Wikipedia is July the 4th, but i was still curious about 
> that late May.
> I think i finally found this late May (30th) discussion and want to share it:
> https://groups.google.com/d/msg/comp.os.linux/7TFhxP6IUVQ/gVHAeP_ZBVUJ
> 
> It's of course hard to tell when a project was really born, but as far as i 
> understand, this discussion inspired Bob to write an initial loader.
> I was just 5 at this time, so maybe someone can tell some more about it? :)
> 
> 

Reading that thread, it seems that WABI was an important "Wine before
Wine" -- albeit proprietary and made for SunOS (and bundling a CPU
emulator!)  Perhaps we should mention it in our history page.

Re: Wine Gecko 2.20-beta1

[Jacek Caban]

On 03/07/13 12:07, Jacek Caban wrote:
> Hi all,
>
> I've uploaded a new Gecko builds to SourceForge [1]. This one is based on 
> Firefox 20 beta and, other than usual update of Gecko, it should fix some 
> crashes like bug b*ug 32753* . 
> To test them, you need recent Wine Git version with the attached patch. As 
> usually, grab the build from SourceForge, put it in the right place [2] and 
> run patched Wine. All help with testing is appreciated!
>
> Thanks,
> Jacek
>
> [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/2.20-beta1/
> [2] http://wiki.winehq.org/Gecko
>

The release is pretty close, but it needs some more tests. If anyone is
willing to help, I've attached a rebased patch (nsiface.idl changed a
bit in Wine since I uploaded the last beta build).

Thanks,
Jacek
diff --git a/dlls/appwiz.cpl/addons.c b/dlls/appwiz.cpl/addons.c
index 2a47b84..cdaf7e2 100644
--- a/dlls/appwiz.cpl/addons.c
+++ b/dlls/appwiz.cpl/addons.c
@@ -53,7 +53,7 @@
 
 WINE_DEFAULT_DEBUG_CHANNEL(appwizcpl);
 
-#define GECKO_VERSION "1.9"
+#define GECKO_VERSION "2.20-beta1"
 
 #ifdef __i386__
 #define ARCH_STRING "x86"
diff --git a/dlls/mshtml/htmlelem2.c b/dlls/mshtml/htmlelem2.c
index 24aaba5..516a3f5 100644
--- a/dlls/mshtml/htmlelem2.c
+++ b/dlls/mshtml/htmlelem2.c
@@ -1253,22 +1253,22 @@ static HRESULT WINAPI 
HTMLElement2_getElementsByTagName(IHTMLElement2 *iface, BS
IHTMLElementCollection 
**pelColl)
 {
 HTMLElement *This = impl_from_IHTMLElement2(iface);
-nsIDOMNodeList *nslist;
+nsIDOMHTMLCollection *nscol;
 nsAString tag_str;
 nsresult nsres;
 
 TRACE("(%p)->(%s %p)\n", This, debugstr_w(v), pelColl);
 
 nsAString_InitDepend(&tag_str, v);
-nsres = nsIDOMHTMLElement_GetElementsByTagName(This->nselem, &tag_str, 
&nslist);
+nsres = nsIDOMHTMLElement_GetElementsByTagName(This->nselem, &tag_str, 
&nscol);
 nsAString_Finish(&tag_str);
 if(NS_FAILED(nsres)) {
 ERR("GetElementByTagName failed: %08x\n", nsres);
 return E_FAIL;
 }
 
-*pelColl = create_collection_from_nodelist(This->node.doc, nslist);
-nsIDOMNodeList_Release(nslist);
+*pelColl = create_collection_from_htmlcol(This->node.doc, nscol);
+nsIDOMHTMLCollection_Release(nscol);
 return S_OK;
 }
 
diff --git a/dlls/mshtml/nsiface.idl b/dlls/mshtml/nsiface.idl
index 76f8ed0..a7fc344 100644
--- a/dlls/mshtml/nsiface.idl
+++ b/dlls/mshtml/nsiface.idl
@@ -23,7 +23,7 @@
  * compatible with XPCOM, usable in C code.
  */
 
-cpp_quote("#define GECKO_VERSION \"1.9\"")
+cpp_quote("#define GECKO_VERSION \"2.20-beta1\"")
 cpp_quote("#define GECKO_VERSION_STRING \"Wine Gecko \" GECKO_VERSION")
 
 import "wtypes.idl";
@@ -179,10 +179,7 @@ typedef nsISupports nsIDOMHistory;
 typedef nsISupports nsIDOMNavigator;
 typedef nsISupports nsIDOMMediaQueryList;
 typedef nsISupports nsIDOMScreen;
-typedef nsISupports nsIDOMCrypto;
-typedef nsISupports nsIDOMPkcs11;
 typedef nsISupports nsIAnimationFrameListener;
-typedef nsISupports nsIDOMMozURLProperty;
 typedef nsISupports nsIDOMStorageList;
 typedef nsISupports nsILocalFile;
 typedef nsISupports nsIDOMHTMLMenuElement;
@@ -195,6 +192,7 @@ typedef nsISupports nsIDOMBlob;
 typedef nsISupports nsIPrivacyTransitionObserver;
 typedef nsISupports nsIDOMHTMLPropertiesCollection;
 typedef nsISupports mozIDOMApplication;
+typedef nsISupports nsILoadGroupConnectionInfo;
 
 typedef void *JSContext;
 typedef void *JSObject;
@@ -226,7 +224,7 @@ interface nsIFactory : nsISupports
 
 [
 object,
-uuid(59e7e77a-38e4-11d4-8cf5-0060b0fc14a3),
+uuid(6aef11c4-8615-44a6-9711-98f43805693d),
 local
 ]
 interface nsIMemory : nsISupports
@@ -236,6 +234,7 @@ interface nsIMemory : nsISupports
 void Free(void *_ptr);
 nsresult HeapMinimize(bool immediate);
 nsresult IsLowMemory(bool *_retval);
+nsresult IsLowMemoryPlatform(bool *_retval);
 }
 
 [
@@ -521,7 +520,7 @@ interface nsIStreamListener : nsIRequestObserver
 
 [
 object,
-uuid(3de0a31c-feaf-400f-9f1e-4ef71f8b20cc),
+uuid(19501006-46e3-4634-b97d-26eff894b4d3),
 local
 ]
 interface nsILoadGroup : nsIRequest
@@ -536,11 +535,12 @@ interface nsILoadGroup : nsIRequest
 nsresult GetActiveCount(uint32_t *aActiveCount);
 nsresult GetNotificationCallbacks(nsIInterfaceRequestor 
**aNotificationCallbacks);
 nsresult SetNotificationCallbacks(nsIInterfaceRequestor 
*aNotificationCallbacks);
+nsresult GetConnectionInfo(nsILoadGroupConnectionInfo **aConnectionInfo);
 }
 
 [
 object,
-uuid(98f3b51b-bb55-4276-a43c-db636f8d77e3),
+uuid(2a8a7237-c1e2-4de7-b669-2002af29e42d),
 local
 ]
 interface nsIChannel : nsIRequest
@@ -557,8 +557,8 @@ interface nsIChannel : nsIRequest
 nsresult SetContentType(const nsACString *aContentType);
 nsresult GetContentCharset(nsACString *aContentCharset);
 nsresult SetContentCharset(const nsACString *aContentCharset);
-  

Re: Wine release 1.5.24

[GOUJON Alexandre]

On 02/15/2013 09:38 PM, Gennady Telegin wrote:

Hi,

I want to unsubscribe from this list, how to do it?

Best,
Gennady Telegin

It's wine-announce so go to 
http://www.winehq.org/mailman/listinfo/wine-announce and read 
instructions at the bottom of the page

Re: Wine release 1.5.24

[Gennady Telegin]

Hi,

I want to unsubscribe from this list, how to do it?

Best,
Gennady Telegin


On Sat, Feb 16, 2013 at 12:30 AM, Alexandre Julliard wrote:

> The Wine development release 1.5.24 is now available.
>
> What's new in this release (see below for details):
>   - Keyboard and mouse wheel support in the Mac driver.
>   - Regular expression support in VB Script.
>   - Many RichEdit code cleanups.
>   - Various bug fixes.
>
> The source is available from the following locations:
>
>   http://prdownloads.sourceforge.net/wine/wine-1.5.24.tar.bz2
>   http://mirrors.ibiblio.org/wine/source/1.5/wine-1.5.24.tar.bz2
>
> Binary packages for various distributions will be available from:
>
>   http://www.winehq.org/download
>
> You will find documentation on http://www.winehq.org/documentation
>
> You can also get the current source directly from the git
> repository. Check http://www.winehq.org/git for details.
>
> Wine is available thanks to the work of many people. See the file
> AUTHORS in the distribution for the complete list.
>
> 
>
> Bugs fixed in 1.5.24 (total 38):
>
>6512  power-tab-editor freezes at end of a song
>8598  msvcrt file IO functions do not handle unicode properly in text
> mode
>   12908  Battle Zone I does not start.
>   16685  redraw problem in AIM_675
>   17380  CListCtrl: wrong icon spacing
>   17762  Citavi: Application is very slow
>   17763  Citavi: mouse doesn't catch links
>   18079  AutoCorect: does not properly display custom checkboxes made by
> Alcinoe
>   20294  sigma photo pro crashes in X11DRV_DIB_DeleteDIBSection
>   24089  EverQuest: Escape to Norrath: login screen is blank without
> native ie6
>   24315  Verizon Media Manager crashes on exit (VZMediaagent.exe
>   24361  Crashday: game is unusably slow during gameplay
>   24474  Simpsons Hit & Run sound bug
>   24554  Black screen in Everquest 2 (lighting issue?)
>   25576  Microsoft Flight Simulator X: Demo/Deluxe Edition, menu blank
> without native ie7
>   25584  Racedriver:GRID sound hardware acceleration not working
>   25958  DreamStation 1 free music tracker visually freezes under some
> conditions
>   27011  Lucent Heart: patcher window is blank
>   27905  HUNTED The Demon Forge: Sound does not work in the game (in
> movies this works)
>   29718  IE4 setup wants wininet.dll.LoadUrlCacheContent
>   29873  Guild Wars: Water graphic is missing
>   30008  Resource Hacker logo on about window has black background
>   30183  Fchart installation crashes
>   30246  EA Origin:Crashes when using openssl 1.0.1
>   30839  BSTR cache corrupts most of cached BSTR entries
>   31308  Remote Tools for Visual Studio 2012 RC installer for Windows on
> ARM (WoA) crashes because TPIDRURW (user TLS register) needs to be set to
> TEB address
>   31706  Sacred Underworld: Some models glow like a Christmas tree
>   31977  YoudaoDict crash at start
>   32520  EVE Online and other games want d3d11.dll.D3D11CreateDevice
>   32669  Ghost Master: invisible mouse pointer unless 'Enhanced Cursor'
> option selected
>   32808  installer of PPTV: needs unimplemented
> atl100.dll.AtlComModuleRegisterClassObjects
>   32818  Adrenalin Extreme Show: launcher.exe has repainting issues
>   32842  TurboTax 2012 needs shlwapi.dll IsInternetESCEnabled stub
>   32858  Crash dialog Details button Russian text doesn't fit
>   32862  Microsoft Expression Design 4 (Free Version) needs
> WindowsCodecsExt.dll (Microsoft Windows Codecs Extended Library)
>   32882  Grand Theft Auto IV doesn't start, aborts with a GLX error.
>   32909  QQDownload 3.9 needs unimplemented msvcr80.dll._wstat32i64
>   32929  Microsoft Expression Design 4 (Free Version) needs
> windowscodecsext.dll.WICCreateColorTransform_Proxy
>
> 
>
> Changes since 1.5.23:
>
> Akihiro Sagawa (1):
>   gdi32: Ensure a fixed-pitch full-width character has double advance
> of a half-width character.
>
> Alexander Morozov (1):
>   ole32: Avoid a deadlock when a being loaded DLL calls
> CoRegisterClassObject from its DLL_PROCESS_ATTACH handler.
>
> Alexandre Julliard (28):
>   winemac: Don't move off-screen windows to a random position.
>   gdi32: Return the correct module handle for the initial display
> driver load.
>   explorer: Retrieve the graphics driver module from gdi32.
>   explorer: Return a simple boolean instead of a window in the
> wine_create_desktop entry point.
>   wintab32: Retrieve the graphics driver module from gdi32.
>   imm32: Retrieve the graphics driver module from gdi32.
>   winex11: Ignore color key and exposures when using the null surface.
>   user32: Avoid releasing a potentially null pointer.
>   server: Also exclude the top-level client rectangle for windows that
> have a pixel format.
>   server: Return the window paint flags in the get_visible_region
> request.
>   user32: Don't paint to the surfac

Re: Wine Wiki needs your help!

[Kyle Auble]

On Wed, Jan 16, 2013 at 12:19 AM, Juan Lang wrote:
> Could the password hashes be excluded from the regular tarball? E.g. using 
> --exclude in the tar command?

Sorry I didn't reply sooner, been a little busy the past week. I don't have a
copy of the Wine Wiki data in front of me, but if I remember, the passwords
aren't stored separately at the file level. Each user has a data file (and at
least for v1.5, a .trail and possibly a .bookmark file).

The password is stored as a single record in that file. I'm no security
expert, but my gut feeling is that separating the password data by default
might be a good change upstream. Short of that though, I fiddled with reading
off each password, running it through bcrypt, then putting it back into place
before packing up the files.

It probably wouldn't be too hard to sift out the passwords before archiving
the user directory. Ultimately, it seemed just keeping the user directory out
of the open was the best bet though. My logic was that while there are several
reasons someone might want to "fork" or independently archive the content
(which is LGPL), I couldn't think of a legitimate reason someone would want
everyone's account info without cooperating with the current maintainers.

-Kyle

Re: Wine Wiki needs your help!

[Juan Lang]

Hi Kyle,

On Tue, Jan 15, 2013 at 8:10 AM, Kyle Auble  wrote:

> The one thing that would probably help a lot is if there was a regularly
> updated tarball of the wiki content either at WineHQ or Lattica's FTP
> again. I
> haven't messed with cron itself much, but my archive.cron script should
> pack
> up the files correctly. The main complication is that the user dir probably
> should be shared on a need-to-know basis because it contains weakly-hashed
> password info.
>

Could the password hashes be excluded from the regular tarball? E.g. using
--exclude in the tar command?
--Juan

Re: Wine Wiki needs your help!

[Dimi Paun]

Hi folks,

Thanks for all the help and hits -- much appreciated.

I ended up writing a few scripts myself that cleaned up
both the pages and users. It should do for now.

Please let me know if you see any problems with the
wiki, I hope I wasn't over-eager when cleaning up spam :)))

Cheers,
Dimi.

On 01/15/2013 11:10 AM, Kyle Auble wrote:

On Tue, Jan 15, 2013 at 1:06 PM, Dimi Paun wrote:

Thanks everyone for your help!
I'll take down the Pages spreadsheet.
Now, what about the users? Those are files (not directories) so we don't
face
the same low limit (32k), but it would be nice if we could, somehow, cleanup
those files as well.

If I'm remembering right, a full install of Moinmoin (not just running the
service portably in the unpacked tree) puts a moin command into /usr/bin.
The documentation for it isn't great yet, but you can find it at
http://master.moinmo.in/HelpOnMoinCommand.

Unfortunately, it doesn't have a mechanism for cleaning out users beyond
obvious duplicate accounts. One possibility that I was looking at is that
v1.5 of Moinmoin updates ".trail" files for all logged-in users, even if
the page trail display has been disabled.

The idea was to scan the user directory for all .trail files with a mod-time
older than a certain time period (I picked 1 year). If a user has logged in
to do anything more recently than then, it should show up in the mod-time of
the .trail file.

I wanted to test my scripts a little more, but this was one thing my
sweep-once script at https://bitbucket.org/kauble/moin-admin was designed
to do. Besides blanking-out and putting "file.new" instead of "file.tmp" in
line 96 of split-logs.pl, the logic seemed sound on small test batches. I
wanted to try it on a full copy of the Wine Wiki just to be safe though.

On Tue, Jan 15, 2013 at 4:40 AM, André Hentschel wrote:

This should also speed up that old wiki and maybe helps upgrading it (hopefully 
that'll happen soon :D).

I haven't touched a line of code in a couple of months (had a holiday job that
really knocked the wind from my sails at times), but after getting settled into
my classes over the next few days, I plan on working on moving the wiki to
v1.9 of Moinmoin again.

The one thing that would probably help a lot is if there was a regularly
updated tarball of the wiki content either at WineHQ or Lattica's FTP again. I
haven't messed with cron itself much, but my archive.cron script should pack
up the files correctly. The main complication is that the user dir probably
should be shared on a need-to-know basis because it contains weakly-hashed
password info.

Kyle



--
Dimi Paun
Lattica, Inc.

Re: Wine Wiki needs your help!

[Kyle Auble]

On Tue, Jan 15, 2013 at 1:06 PM, Dimi Paun wrote:
> Thanks everyone for your help!

> I'll take down the Pages spreadsheet.

> Now, what about the users? Those are files (not directories) so we don't
> face
> the same low limit (32k), but it would be nice if we could, somehow, cleanup
> those files as well.

If I'm remembering right, a full install of Moinmoin (not just running the
service portably in the unpacked tree) puts a moin command into /usr/bin.
The documentation for it isn't great yet, but you can find it at
http://master.moinmo.in/HelpOnMoinCommand.

Unfortunately, it doesn't have a mechanism for cleaning out users beyond
obvious duplicate accounts. One possibility that I was looking at is that
v1.5 of Moinmoin updates ".trail" files for all logged-in users, even if
the page trail display has been disabled.

The idea was to scan the user directory for all .trail files with a mod-time
older than a certain time period (I picked 1 year). If a user has logged in
to do anything more recently than then, it should show up in the mod-time of
the .trail file.

I wanted to test my scripts a little more, but this was one thing my
sweep-once script at https://bitbucket.org/kauble/moin-admin was designed
to do. Besides blanking-out and putting "file.new" instead of "file.tmp" in
line 96 of split-logs.pl, the logic seemed sound on small test batches. I
wanted to try it on a full copy of the Wine Wiki just to be safe though.

On Tue, Jan 15, 2013 at 4:40 AM, André Hentschel wrote:
> This should also speed up that old wiki and maybe helps upgrading it 
> (hopefully that'll happen soon :D).

I haven't touched a line of code in a couple of months (had a holiday job that
really knocked the wind from my sails at times), but after getting settled into
my classes over the next few days, I plan on working on moving the wiki to
v1.9 of Moinmoin again.

The one thing that would probably help a lot is if there was a regularly
updated tarball of the wiki content either at WineHQ or Lattica's FTP again. I
haven't messed with cron itself much, but my archive.cron script should pack
up the files correctly. The main complication is that the user dir probably
should be shared on a need-to-know basis because it contains weakly-hashed
password info.

Kyle

Re: Wine Wiki needs your help!

[Dimi Paun]

On 13-01-14 11:11 PM, Dmitry Timoshkov wrote:

Hi Dimi,

Dimi Paun  wrote:


I've cleanup the deleted pages, were down to about 740 pages,
mostly good stuff:

https://docs.google.com/a/lattica.com/spreadsheet/ccc?key=0AmY-Kp_Ihu3idFNEOUt0UkVGUko4elhkOHVoaWx2OWc#gid=5

Please check it out, lemme know if any spam is still left standing.

At least the following pages don't exist (and seem to be deleted as spam):

AdamSpang
AntoineX56
BoyceUai
CharlesYJI
CyrilBann

I didn't check futher entries, may be your scrpt can do that?


Thanks -- some of these where skipped by the first pass of the script.
Ran it again, we're down to 729. However, eyeballing the result looks pretty
clean, so I'll say this is good enough for now, as far as pages are 
concerned.


Thanks everyone for your help!

I'll take down the Pages spreadsheet.

Now, what about the users? Those are files (not directories) so we don't 
face

the same low limit (32k), but it would be nice if we could, somehow, cleanup
those files as well.

--
Dimi Paun 
Lattica, Inc.

Re: Wine Wiki needs your help!

[Dmitry Timoshkov]

Hi Dimi,

Dimi Paun  wrote:

> I've cleanup the deleted pages, were down to about 740 pages,
> mostly good stuff:
> 
> https://docs.google.com/a/lattica.com/spreadsheet/ccc?key=0AmY-Kp_Ihu3idFNEOUt0UkVGUko4elhkOHVoaWx2OWc#gid=5
> 
> Please check it out, lemme know if any spam is still left standing.

At least the following pages don't exist (and seem to be deleted as spam):

AdamSpang
AntoineX56
BoyceUai
CharlesYJI
CyrilBann

I didn't check futher entries, may be your scrpt can do that?

-- 
Dmitry.

Re: Wine Wiki needs your help!

[Dimi Paun]

Hi guys,

I've cleanup the deleted pages, were down to about 740 pages,
mostly good stuff:

https://docs.google.com/a/lattica.com/spreadsheet/ccc?key=0AmY-Kp_Ihu3idFNEOUt0UkVGUko4elhkOHVoaWx2OWc#gid=5

Please check it out, lemme know if any spam is still left standing.

Any ideas on how we can attack the spam users?

Dimi.

On 13-01-14 7:16 PM, André Hentschel wrote:

Am 14.01.2013 21:40, schrieb Andrew Eikum:

On Mon, Jan 14, 2013 at 03:32:40PM -0500, Dimi Paun wrote:

OK, we might be onto something. I've wrote a script
to determine the deleted pages: 20162.

Should I just go ahead and nuke those?


Probably, yes.

One common way for spammers to abuse wikis is to intentionally get the
pages deleted, so that they live on permanently in the revision
history.

See this example from today:
It's rightfully deleted as spam:
   http://wiki.winehq.org/SheriOci
But the "Get Info" link leads you to the old revision, with the
linkspam intact:
   http://wiki.winehq.org/SheriOci?action=recall&rev=1

I don't know if there's a way to keep Moinmoin from preserving
revision history on deleted pages, but it might be sufficient to
simply disable that. I doubt there's much useful history on deleted
pages anyway.

seems done, and know what? The wiki seems to be more than 10 times faster. (i 
tried e.g. editing -> preview)
good choice!
Thanks Dimi for working on this!!!





--
Dimi Paun 
Lattica, Inc.

Re: Wine Wiki needs your help!

[Dimi Paun]

Yes it is done. Ill update the spreadsheet bit later...

André Hentschel  wrote:

>Am 14.01.2013 21:40, schrieb Andrew Eikum:
>> On Mon, Jan 14, 2013 at 03:32:40PM -0500, Dimi Paun wrote:
>>> OK, we might be onto something. I've wrote a script
>>> to determine the deleted pages: 20162.
>>>
>>> Should I just go ahead and nuke those?
>>>
>> 
>> Probably, yes.
>> 
>> One common way for spammers to abuse wikis is to intentionally get the
>> pages deleted, so that they live on permanently in the revision
>> history.
>> 
>> See this example from today:
>> It's rightfully deleted as spam:
>>   http://wiki.winehq.org/SheriOci
>> But the "Get Info" link leads you to the old revision, with the
>> linkspam intact:
>>   http://wiki.winehq.org/SheriOci?action=recall&rev=1
>> 
>> I don't know if there's a way to keep Moinmoin from preserving
>> revision history on deleted pages, but it might be sufficient to
>> simply disable that. I doubt there's much useful history on deleted
>> pages anyway.
>
>seems done, and know what? The wiki seems to be more than 10 times faster. (i 
>tried e.g. editing -> preview)
>good choice!
>Thanks Dimi for working on this!!!
>
>
>-- 
>
>Best Regards, André Hentschel

Re: Wine Wiki needs your help!

[André Hentschel]

Am 14.01.2013 21:40, schrieb Andrew Eikum:
> On Mon, Jan 14, 2013 at 03:32:40PM -0500, Dimi Paun wrote:
>> OK, we might be onto something. I've wrote a script
>> to determine the deleted pages: 20162.
>>
>> Should I just go ahead and nuke those?
>>
> 
> Probably, yes.
> 
> One common way for spammers to abuse wikis is to intentionally get the
> pages deleted, so that they live on permanently in the revision
> history.
> 
> See this example from today:
> It's rightfully deleted as spam:
>   http://wiki.winehq.org/SheriOci
> But the "Get Info" link leads you to the old revision, with the
> linkspam intact:
>   http://wiki.winehq.org/SheriOci?action=recall&rev=1
> 
> I don't know if there's a way to keep Moinmoin from preserving
> revision history on deleted pages, but it might be sufficient to
> simply disable that. I doubt there's much useful history on deleted
> pages anyway.

seems done, and know what? The wiki seems to be more than 10 times faster. (i 
tried e.g. editing -> preview)
good choice!
Thanks Dimi for working on this!!!


-- 

Best Regards, André Hentschel

Re: Wine Wiki needs your help!

[Andrew Eikum]

On Mon, Jan 14, 2013 at 03:32:40PM -0500, Dimi Paun wrote:
> OK, we might be onto something. I've wrote a script
> to determine the deleted pages: 20162.
> 
> Should I just go ahead and nuke those?
> 

Probably, yes.

One common way for spammers to abuse wikis is to intentionally get the
pages deleted, so that they live on permanently in the revision
history.

See this example from today:
It's rightfully deleted as spam:
  http://wiki.winehq.org/SheriOci
But the "Get Info" link leads you to the old revision, with the
linkspam intact:
  http://wiki.winehq.org/SheriOci?action=recall&rev=1

I don't know if there's a way to keep Moinmoin from preserving
revision history on deleted pages, but it might be sufficient to
simply disable that. I doubt there's much useful history on deleted
pages anyway.

Andrew

Re: Wine Wiki needs your help!

[André Hentschel]

Am 14.01.2013 20:00, schrieb Dimi Paun:
> Hm, it doesn't seem to be so simple.
> Each page maintains an edit-log file with all the changes.
> 
> grep-ing for -i spam in the edit-log yields less than 400 hits.
> 
> Maybe we should look for deleted pages?
> 

Simple idea:
Make a backup of the current state, just in case.
And yes, remove all deleted. If they are not spam, then there was some other 
good reason, if someone raises a hand, you can still look into the backup.
This should also speed up that old wiki and maybe helps upgrading it (hopefully 
that'll happen soon :D).


-- 

Best Regards, André Hentschel

Re: Wine Wiki needs your help!

[Dimi Paun]

OK, we might be onto something. I've wrote a script
to determine the deleted pages: 20162.

Should I just go ahead and nuke those?

Dimi.

On 01/14/2013 01:35 PM, Francois Gouget wrote:

On Mon, 14 Jan 2013, Dimi Paun wrote:


MoinMoin creates a dir for every page. I simply got the list
by listing these directories. (This is the problem -- there is a
limit of 2^15 subdirectories, and this is what we were hitting
a few days ago).

Does that answer the question?

It feels like your methodology is flawed.
Let's take the "Jaw crusher from joyal jc001j" page as an example.

As far as I can tell that page has already been deleted. MoinMoin knows
that. So you should not need us humans to waste time going through
2+ rows of the spreadsheet to tell you that the directory
corresponds to a deleted page.

So is your problem that you want to preserve non-spam deleted pages?

Can't a script go through these directories, notice that the page has
been deleted, that the delete comment contains the word 'spam' and then
delete the directory?





--
Dimi Paun
Lattica, Inc.

Re: Wine Wiki needs your help!

[Dimi Paun]

Hm, it doesn't seem to be so simple.
Each page maintains an edit-log file with all the changes.

grep-ing for -i spam in the edit-log yields less than 400 hits.

Maybe we should look for deleted pages?

Dimi.

On 01/14/2013 01:35 PM, Francois Gouget wrote:

On Mon, 14 Jan 2013, Dimi Paun wrote:


MoinMoin creates a dir for every page. I simply got the list
by listing these directories. (This is the problem -- there is a
limit of 2^15 subdirectories, and this is what we were hitting
a few days ago).

Does that answer the question?

It feels like your methodology is flawed.
Let's take the "Jaw crusher from joyal jc001j" page as an example.

As far as I can tell that page has already been deleted. MoinMoin knows
that. So you should not need us humans to waste time going through
2+ rows of the spreadsheet to tell you that the directory
corresponds to a deleted page.

So is your problem that you want to preserve non-spam deleted pages?

Can't a script go through these directories, notice that the page has
been deleted, that the delete comment contains the word 'spam' and then
delete the directory?





--
Dimi Paun
Lattica, Inc.

Re: Wine Wiki needs your help!

[Dimi Paun]

OK, that's a fair point. Lemme quickly go through that
and I'll report back.

Dimi.

On 01/14/2013 01:35 PM, Francois Gouget wrote:

On Mon, 14 Jan 2013, Dimi Paun wrote:


MoinMoin creates a dir for every page. I simply got the list
by listing these directories. (This is the problem -- there is a
limit of 2^15 subdirectories, and this is what we were hitting
a few days ago).

Does that answer the question?

It feels like your methodology is flawed.
Let's take the "Jaw crusher from joyal jc001j" page as an example.

As far as I can tell that page has already been deleted. MoinMoin knows
that. So you should not need us humans to waste time going through
2+ rows of the spreadsheet to tell you that the directory
corresponds to a deleted page.

So is your problem that you want to preserve non-spam deleted pages?

Can't a script go through these directories, notice that the page has
been deleted, that the delete comment contains the word 'spam' and then
delete the directory?





--
Dimi Paun
Lattica, Inc.

Re: Wine Wiki needs your help!

[Francois Gouget]

On Mon, 14 Jan 2013, Dimi Paun wrote:

> MoinMoin creates a dir for every page. I simply got the list
> by listing these directories. (This is the problem -- there is a
> limit of 2^15 subdirectories, and this is what we were hitting
> a few days ago).
> 
> Does that answer the question?

It feels like your methodology is flawed.
Let's take the "Jaw crusher from joyal jc001j" page as an example.

As far as I can tell that page has already been deleted. MoinMoin knows 
that. So you should not need us humans to waste time going through 
2+ rows of the spreadsheet to tell you that the directory 
corresponds to a deleted page.

So is your problem that you want to preserve non-spam deleted pages?

Can't a script go through these directories, notice that the page has 
been deleted, that the delete comment contains the word 'spam' and then 
delete the directory?


-- 
Francois Gouget   http://fgouget.free.fr/
  Any sufficiently advanced Operating System is indistinguishable from Linux

Re: Wine Wiki needs your help!

[Dimi Paun]

MoinMoin creates a dir for every page. I simply got the list
by listing these directories. (This is the problem -- there is a
limit of 2^15 subdirectories, and this is what we were hitting
a few days ago).

Does that answer the question?

Dimi.

On 01/14/2013 12:51 PM, Francois Gouget wrote:

On Mon, 14 Jan 2013, Dimi Paun wrote:
[...]

https://docs.google.com/a/lattica.com/spreadsheet/ccc?key=0AmY-Kp_Ihu3idFNEOUt0UkVGUko4elhkOHVoaWx2OWc#gid=5

I'm not clear on how this is supposed to work.
For instance I see a ton of pages containing 'joyal' or 'crusher' in
their Page Name. For instance:

  Jaw crusher from joyal jc001j

However a quick search for 'crusher' shows '0 results out of about 21011
pages' (for both a Title and Full Text search). Either I'm searching
wrong or these pages have already been deleted. If the latter, then why
do we have to manually mark them as Spam again?





--
Dimi Paun
Lattica, Inc.

Re: Wine Wiki needs your help!

[Francois Gouget]

On Mon, 14 Jan 2013, Dimi Paun wrote:
[...]
> https://docs.google.com/a/lattica.com/spreadsheet/ccc?key=0AmY-Kp_Ihu3idFNEOUt0UkVGUko4elhkOHVoaWx2OWc#gid=5

I'm not clear on how this is supposed to work.
For instance I see a ton of pages containing 'joyal' or 'crusher' in 
their Page Name. For instance:

 Jaw crusher from joyal jc001j

However a quick search for 'crusher' shows '0 results out of about 21011 
pages' (for both a Title and Full Text search). Either I'm searching 
wrong or these pages have already been deleted. If the latter, then why 
do we have to manually mark them as Spam again?


-- 
Francois Gouget   http://fgouget.free.fr/
  All generalizations are false, including this one.
 -- Mark Twain

Re: Wine Wiki needs your help!

[Dimi Paun]

On 01/14/2013 11:43 AM, Erich E. Hoover wrote:

On Mon, Jan 14, 2013 at 9:38 AM, Dimi Paun  wrote:

...
Please let me know if we can do this any simpler or if there are
any problems.

Do you want us to move marked items up to the top of the spreadsheet
or will you do that for us?

I don't think we need to move marked items at the top of the
spreadsheet, that's a lot of work/churn.

What we can do instead is that we can move (from time to time)
marked items to a separate sheet if that helps (to have them out
of the way, and avoid having to scroll too much through the sheet).

Actually, all these ideas are OK with me -- feel free to suggest/do
anything that makes sense and makes it easier to sort through
all this stuff, all I really care is the data :)

--
Dimi Paun
Lattica, Inc.

Re: Wine Wiki needs your help!

[Erich E. Hoover]

On Mon, Jan 14, 2013 at 9:38 AM, Dimi Paun  wrote:
> ...
> Please let me know if we can do this any simpler or if there are
> any problems.

Do you want us to move marked items up to the top of the spreadsheet
or will you do that for us?

Erich

Re: [wine-devel] Re: [SOLVED] wine-1.5.20 regression compared to 1.5.19 and previous; MinGW/gcc 4.7.0 segfaults under wineconsole

[Alan W. Irwin]

On 2012-12-28 10:22-0800 Alan W. Irwin wrote:


[...Let's] leave
it like this. Wine-1.5.20 has introduced an obvious regression for an
important Windows app (the MinGW gcc compiler for Windows) that has
been working for years for prior Wine versions.


Grant communicated to me off list that he was able to replicate the
regression for Wine-1.5.20, but he also found (as did Boyd) the
regression had (inadvertently?) been solved for a recent wine-git
version. Grant's results were for MinGW-4.7.2.

I have just now confirmed for MinGW-4.7.0 that Wine-1.5.20 had the
issue, but wine-1.5.20-104-g0004788 (or one of the 103 commits before
that) solves it. So although using the Wine platform to build software
doesn't work for Wine-1.5.20, building and testing software (notably
shapelib, PLplot, ephcom, and te_gen using cmake.exe/MinGW/MSYS) works
well for 1.5.19, and from my simple test of gcc for recent Wine git,
it is certainly looking good for the next Wine release as well!

Grant also told me that gcc had no obvious issues for wine-1.5.20 when
invoked directly with wine.  Instead he had to follow my wineconsole +
bash method for invoking gcc to confirm the issue for wine-1.5.20.

The following is my recipe for that gcc invocation method if anyone
here wants to bisect to find the commit between 1.5.19 and 1.5.20 that
created the issue, and the commit between 1.5.20 and
wine-1.5.20-104-g0004788 that solved it:

(1) Download and install a recent MinGW/MSYS using the automatic
installer, mingw-get-inst-20120426.exe that is accessible at
https://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/mingw-get-inst-20120426/.
Check the GUI box to get the latest versions.  Some time ago I
installed 4.7.0 this way, and Grant's experience is that now installs
4.7.2.  Include MSYS in the install, and install to a unique prefix
(rather than a wine system file location).  (I did that to
make sure I could easily change between wine versions using different
PATH and WINEPREFIX values.)

(2) Make a bash "source" script to set up the PATH so that wine can
find MinGW and MSYS where you installed them in the above step.  Here
is my version of that script:

irwin@raven> cat set_mingw_msys_path.wine_sh
export MINGW_VERSION=4.7.0
MINGW_PREFIX=/z/home/wine/newstart/MinGW_$MINGW_VERSION
PATH=$MINGW_PREFIX/msys/1.0/bin/:$PATH
PATH=$MINGW_PREFIX/bin/:$PATH

(3) Get into a wineconsole environment

wineserver -p
wineconsole --backend=curses MinGW_4.7.0/msys/1.0/bin/bash.exe

(4) Attempt to compile a "hello-world" programme from that environment

bash.exe-3.1$ source set_mingw_msys_path.wine_sh
bash.exe-3.1$ gcc hello_world.c

On wine-1.5.20, this immediately creates an GUI error box.  When you
exit from that error box, a very long error message is displayed in the 
wineconsole
terminal.  In contrast to this bad behaviour of gcc on wine-1.5.20, for
both wine-1.5.19 and wine-1.5.20-104-g0004788 this simple test compilation
succeeds without issues and you can then run the resulting executable
with

bash.exe-3.1$ ./a.exe
Hello World

And now back to getting my forthcoming releases of ephcom and te_gen out
the door this next weekend.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Re: wine-1.5.20 regression compared to 1.5.19 and previous; MinGW/gcc 4.7.0 segfaults under wineconsole

[Alan W. Irwin]

On 2012-12-28 13:45+0100 Frédéric Delanoy wrote:


Other users have issues with wine but they don't generally complain as
loudly as you did.


It is possible I was not cautious enough with my tone, but let's leave
it like this. Wine-1.5.20 has introduced an obvious regression for an
important Windows app (the MinGW gcc compiler for Windows) that has
been working for years for prior Wine versions.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Re: wine-1.5.20 reversion compared to 1.5.19 and previous; MinGW/gcc 4.7.0 segfaults under wineconsole

[Frédéric Delanoy]

On Fri, Dec 28, 2012 at 11:54 AM, Alan W. Irwin
 wrote:
> On 2012-12-28 10:44+0100 Frédéric Delanoy wrote:
>
>> On Mon, Dec 24, 2012 at 8:58 AM, Alan W. Irwin
>>  wrote:
>>>
>>> On 2012-12-23 21:25-0600 Austin English wrote:
>>>
 On Dec 23, 2012 7:22 PM, "Alan W. Irwin" 
 wrote:
>
> The subject line pretty much says it all.  Running MinGW/gcc under
> wineconsole for any simple test programme should demonstrate the issue
> for wine-1.5.20 which is not present in wine-1.5.19 and a fairly large
> selection of 1.5.x and MinGW versions I have tried over the last year
> or so.
>
> I would be happy to supply more details if there is any difficulty
> replicating this reversion.
>
> Alan

 Please run a regression test and file a bug at http://bugs.winehq.org.
>>>
>>> No thank you.
>>
>> Why would anyone help you if you fail to do your homework?
>
> The shoe is on the other foot. I am trying to help Wine developers
> assuming they have an interest in fixing obvious problems in their
> code no matter how informally such problems are pointed out.
>
> This bug should be easy to replicate.  Try to compile any C programme
> (e.g., a "Hello, world" programme) with MinGW-4.7.0 under wine-1.5.20
> and that compiler segfaults.  Do the same under wine-1.5.19, and there
> is no such problem.  That's all that should be required to not only
> replicate the bug but also demonstrate the reversion.  Meanwhile, I am
> happy to stick with 1.5.19 until some Wine developer takes
> responsibility for getting this regression fixed.

I think that creating a bug would have taken less time than writing
your emails, and be more helpful on the long run (this thread will be
archived like others, and be mostly forgotten, unlike bugs in
bugzilla)

> If anybody tries such a test, and doesn't see the issue, then
> as I said before I am willing to supply more details.
>
> By the way, informal bug reports reported on mailing lists have been
> quite helpful to me in the past for my own software projects.  I also
> have seen a number of projects spend an inordinate amount of time with
> bug triage rather than actually fixing the code.

Wine is a big project. What applies to a small/medium project doesn't
necessarily apply here.
If everybody started reporting bugs in emails, that would quickly
become unmanageable.

> So I welcome
> informal bug reports for my own projects especially when an issue is
> easy to replicate. It appears you do not personally welcome such
> informal reports, but hopefully other wine developers are not so
> inflexible for obvious problems like this one is.

It's not so much that I don't welcome informal reports (they can be
helpful of course), but I didn't like the tone of your inital reply.
It sounded to me like: "Have someone fix my bug quickly, but I don't
want to waste time reporting it correcty ["go through a bunch of Wine
 bug-reporting hoops"]...  so do all the work yourself".

That isn't a nice way to ask for support IMHO, especially for other
people volunteering their time on Wine, and who may also have other
projects of their own.
Also, you didn't probably pay a cent for your wine version, so don't
expect people to prioritize the issues you encounter above all others,
which may be equally important.
Other users have issues with wine but they don't generally complain as
loudly as you did.

> Alan

Frédéric

Re: wine-1.5.20 reversion compared to 1.5.19 and previous; MinGW/gcc 4.7.0 segfaults under wineconsole

[Alan W. Irwin]

On 2012-12-28 10:44+0100 Frédéric Delanoy wrote:


On Mon, Dec 24, 2012 at 8:58 AM, Alan W. Irwin
 wrote:

On 2012-12-23 21:25-0600 Austin English wrote:


On Dec 23, 2012 7:22 PM, "Alan W. Irwin" 
wrote:


The subject line pretty much says it all.  Running MinGW/gcc under
wineconsole for any simple test programme should demonstrate the issue
for wine-1.5.20 which is not present in wine-1.5.19 and a fairly large
selection of 1.5.x and MinGW versions I have tried over the last year
or so.

I would be happy to supply more details if there is any difficulty
replicating this reversion.

Alan


Please run a regression test and file a bug at http://bugs.winehq.org.


No thank you.


Why would anyone help you if you fail to do your homework?


The shoe is on the other foot. I am trying to help Wine developers
assuming they have an interest in fixing obvious problems in their
code no matter how informally such problems are pointed out.

This bug should be easy to replicate.  Try to compile any C programme
(e.g., a "Hello, world" programme) with MinGW-4.7.0 under wine-1.5.20
and that compiler segfaults.  Do the same under wine-1.5.19, and there
is no such problem.  That's all that should be required to not only
replicate the bug but also demonstrate the reversion.  Meanwhile, I am
happy to stick with 1.5.19 until some Wine developer takes
responsibility for getting this regression fixed.

If anybody tries such a test, and doesn't see the issue, then
as I said before I am willing to supply more details.

By the way, informal bug reports reported on mailing lists have been
quite helpful to me in the past for my own software projects.  I also
have seen a number of projects spend an inordinate amount of time with
bug triage rather than actually fixing the code.  So I welcome
informal bug reports for my own projects especially when an issue is
easy to replicate. It appears you do not personally welcome such
informal reports, but hopefully other wine developers are not so
inflexible for obvious problems like this one is.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Re: wine-1.5.20 reversion compared to 1.5.19 and previous; MinGW/gcc 4.7.0 segfaults under wineconsole

[Frédéric Delanoy]

On Mon, Dec 24, 2012 at 8:58 AM, Alan W. Irwin
 wrote:
> On 2012-12-23 21:25-0600 Austin English wrote:
>
>> On Dec 23, 2012 7:22 PM, "Alan W. Irwin" 
>> wrote:
>>>
>>> The subject line pretty much says it all.  Running MinGW/gcc under
>>> wineconsole for any simple test programme should demonstrate the issue
>>> for wine-1.5.20 which is not present in wine-1.5.19 and a fairly large
>>> selection of 1.5.x and MinGW versions I have tried over the last year
>>> or so.
>>>
>>> I would be happy to supply more details if there is any difficulty
>>> replicating this reversion.
>>>
>>> Alan
>>
>> Please run a regression test and file a bug at http://bugs.winehq.org.
>
> No thank you.

Why would anyone help you if you fail to do your homework? Your bug
description is rather vague and you can't expect people to start
randomly testing apps until they (supposedly) find the bug you're
talking about. Please provide a minimal  "simple test program"
If you want it fixed, failing to cooperate here won't help you much.
Instead, create your test program, specify download links, and
describe a minimal procedure to reproduce your bug (and add the
appropriate keywords: download, patch, testcase, ...)

http://wiki.winehq.org/BugReports and
http://bugs.winehq.org/describekeywords.cgi can help here.

For regressions, especially a rather recent one like you seem to
suggest, there are more likely to be fixed quickly, especially if you
perform the regression test yourself (reasons: you're in the best
position to do it yourself; it can take some time developpers won't
necessarily have: if they ran regression tests all day, when would
they code???)
See http://wiki.winehq.org/RegressionTesting

> The last time I wrote a wine bug report (with a test case and a patch
> to fix the problem no less),

Which bug?
> wine developers seemed content with the
> fact that that bug had been reported.  They did not actually fix the
> problem until I made a special personal appeal to one of them more
> than a year later. So eventually there was a happy ending there, but
> the impression I got from that experience is that Wine bug reports for
> even the most obvious issues like that one are pretty much a waste of
> everyone's time unless and until a Wine developer takes
> responsibility.  Of course, in that case the bug reporting system is
> worthwhile since it can make a permanent record of all the events
> leading to a solution.

If the bug was trivial to fix, why did you not send it yourself to wine-patches?
There are a lot of bugs, and not many people who can fix those, so you
can't expect *your* bug to be fixed in minutes.
If you want to increase your chance for the bug to be fixed, you could
wait less than a year, and e.g. restest if the bug still persists
every couple of months (or better, after every wine release) and tell
so on the bug report.

No amount of complaining on this list will likely help...

> In this case, I would like a Wine developer to take responsibility as
> well for what I think is an obvious issue with 1.5.20 by verifying the
> issue, and then taking any further development steps they want to take
> concerning this issue.  Or perhaps there will be an even more obvious
> symptom of the problem with 1.5.20 that will lead to a solution
> quicker than if someone follows the MinGW segfault symptom that I have
> found.  In other words, I am willing to help out Wine by reporting the
> issue informally here, and let Wine developers make their best
> judgement of what to do about the issue, but that is about it.

Again, the bugzilla system is there to report bug, not this mailing list.
Do you really expect someone to read your mail and create a bug from it???

> Sorry I have to be ruthless about this, but I do not want to get
> involved in wine development or go through a bunch of Wine
> bug-reporting hoops since I need to reserve my development efforts for
> my own free software projects.

If you don't want to be cooperative, why should we help you???
Creating a good bug report is not really "being involved in wine
development" IMO. Mere users without any programming experience do it
regularly.
>
> Alan

Frédéric

Re: wine-1.5.20 reversion compared to 1.5.19 and previous; MinGW/gcc 4.7.0 segfaults under wineconsole

[Alan W. Irwin]

On 2012-12-23 21:25-0600 Austin English wrote:


On Dec 23, 2012 7:22 PM, "Alan W. Irwin"  wrote:


The subject line pretty much says it all.  Running MinGW/gcc under
wineconsole for any simple test programme should demonstrate the issue
for wine-1.5.20 which is not present in wine-1.5.19 and a fairly large
selection of 1.5.x and MinGW versions I have tried over the last year
or so.

I would be happy to supply more details if there is any difficulty
replicating this reversion.

Alan


Please run a regression test and file a bug at http://bugs.winehq.org.


No thank you.

The last time I wrote a wine bug report (with a test case and a patch
to fix the problem no less), wine developers seemed content with the
fact that that bug had been reported.  They did not actually fix the
problem until I made a special personal appeal to one of them more
than a year later. So eventually there was a happy ending there, but
the impression I got from that experience is that Wine bug reports for
even the most obvious issues like that one are pretty much a waste of
everyone's time unless and until a Wine developer takes
responsibility.  Of course, in that case the bug reporting system is
worthwhile since it can make a permanent record of all the events
leading to a solution.

In this case, I would like a Wine developer to take responsibility as
well for what I think is an obvious issue with 1.5.20 by verifying the
issue, and then taking any further development steps they want to take
concerning this issue.  Or perhaps there will be an even more obvious
symptom of the problem with 1.5.20 that will lead to a solution
quicker than if someone follows the MinGW segfault symptom that I have
found.  In other words, I am willing to help out Wine by reporting the
issue informally here, and let Wine developers make their best
judgement of what to do about the issue, but that is about it.

Sorry I have to be ruthless about this, but I do not want to get
involved in wine development or go through a bunch of Wine
bug-reporting hoops since I need to reserve my development efforts for
my own free software projects.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

Re: wine-1.5.20 reversion compared to 1.5.19 and previous; MinGW/gcc 4.7.0 segfaults under wineconsole

[Austin English]

On Dec 23, 2012 7:22 PM, "Alan W. Irwin"  wrote:
>
> The subject line pretty much says it all.  Running MinGW/gcc under
> wineconsole for any simple test programme should demonstrate the issue
> for wine-1.5.20 which is not present in wine-1.5.19 and a fairly large
> selection of 1.5.x and MinGW versions I have tried over the last year
> or so.
>
> I would be happy to supply more details if there is any difficulty
> replicating this reversion.
>
> Alan

Please run a regression test and file a bug at http://bugs.winehq.org.

Re: Wine Gecko versioning

[Rosanne DiMesio]

On Tue, 27 Nov 2012 18:33:20 +0300
Nikolay Sivov  wrote:

> It's described here http://wiki.winehq.org/Gecko. I guess failure 
> message loading gecko (in load_gecko()) could be improved adding 
> GECKO_VERSION to it so user clearly see what version he needs to have if 
> it's somehow not downloaded already.
> 
I know where the information is; in fact, I had to correct that page myself 
once because the information originally posted was wrong. 

Adding the version needed to the error message would definitely be helpful. 
-- 
Rosanne DiMesio 

Re: Wine Gecko versioning

[Jacek Caban]

On 11/27/12 16:33, Nikolay Sivov wrote:
> On 11/27/2012 17:26, Rosanne DiMesio wrote:
>> On Tue, 27 Nov 2012 13:32:02 +0100
>> Jacek Caban  wrote:
>>
>>> The idea is that Wine Gecko version could be just something based on
>>> other versions, that are more informative.
>>>
>> Users don't care what version of Firefox the latest gecko is based
>> on; most don't even realize it is based on Firefox.  What does often
>> confuse users, and which your suggested scheme doesn't address, is
>> keeping track of which version of Wine uses which version of wine-gecko.

As Nikolay said, we have a Wiki page for that. It's not something we can
improve by different Gecko versioning.

> It's described here http://wiki.winehq.org/Gecko. I guess failure
> message loading gecko (in load_gecko()) could be improved adding
> GECKO_VERSION to it so user clearly see what version he needs to have
> if it's somehow not downloaded already.

Sounds like a good idea, although we'll probably want to fix it by
including version information in Gecko downloader.

Thanks,
Jacek

Re: Wine Gecko versioning

[Jacek Caban]

On 11/27/12 14:53, André Hentschel wrote:
> Am 27.11.2012 13:32, schrieb Jacek Caban:
>> The idea is that Wine Gecko version could be just something based on
>> other versions, that are more informative. It's not really possible to
>> use Wine version, because the first version of Wine that will use new
>> Gecko is not ultimately when Wine Gecko branches. Also multiple Wine
>> versions use the same Wine Gecko. That leaves us with Gecko (Firefox
>> version). We don't release on every Firefox release (every 6 weeks), so
>> if we just used Firefox version, that would look strange (like Wine
>> Gecko 18 followed by Wine Gecko 20). That can be mitigated by using it
>> as a minor version. So the next few release would look like:
>> - 1.9 (that's already in beta and will be the last release using old scheme)
>> - 2.20 (assuming the next update will be 3 months from 1.9, which means
>> Firefox 20)
>> - 2.22 (assuming another 3 moths for the update).
> I like the idea, but why move to 2.x? 1.20, 1.22 and so on would perfectly 
> fit.
> And if the gap between 1.9 and 1.20 is confusing someone, then he really has 
> issues.
> I'm  also fine with 2.x, i just think a new version scheme shouldn't 
> necessarily lead to a version increment.

You're right, 1.20 would fit, but I also don't see anything wrong with
version increment. That said, I don't have strong preference here.

Thanks,
Jacek

Re: Wine Gecko versioning

[Nikolay Sivov]

On 11/27/2012 17:26, Rosanne DiMesio wrote:

On Tue, 27 Nov 2012 13:32:02 +0100
Jacek Caban  wrote:


The idea is that Wine Gecko version could be just something based on
other versions, that are more informative.


Users don't care what version of Firefox the latest gecko is based on; most 
don't even realize it is based on Firefox.  What does often confuse users, and 
which your suggested scheme doesn't address, is keeping track of which version 
of Wine uses which version of wine-gecko.
It's described here http://wiki.winehq.org/Gecko. I guess failure 
message loading gecko (in load_gecko()) could be improved adding 
GECKO_VERSION to it so user clearly see what version he needs to have if 
it's somehow not downloaded already.

Re: Wine Gecko versioning

[Rosanne DiMesio]

On Tue, 27 Nov 2012 13:32:02 +0100
Jacek Caban  wrote:

> The idea is that Wine Gecko version could be just something based on
> other versions, that are more informative. 
> 
Users don't care what version of Firefox the latest gecko is based on; most 
don't even realize it is based on Firefox.  What does often confuse users, and 
which your suggested scheme doesn't address, is keeping track of which version 
of Wine uses which version of wine-gecko. 

-- 
Rosanne DiMesio 

Re: Wine Gecko versioning

[André Hentschel]

Am 27.11.2012 13:32, schrieb Jacek Caban:
> The idea is that Wine Gecko version could be just something based on
> other versions, that are more informative. It's not really possible to
> use Wine version, because the first version of Wine that will use new
> Gecko is not ultimately when Wine Gecko branches. Also multiple Wine
> versions use the same Wine Gecko. That leaves us with Gecko (Firefox
> version). We don't release on every Firefox release (every 6 weeks), so
> if we just used Firefox version, that would look strange (like Wine
> Gecko 18 followed by Wine Gecko 20). That can be mitigated by using it
> as a minor version. So the next few release would look like:
> - 1.9 (that's already in beta and will be the last release using old scheme)
> - 2.20 (assuming the next update will be 3 months from 1.9, which means
> Firefox 20)
> - 2.22 (assuming another 3 moths for the update).

I like the idea, but why move to 2.x? 1.20, 1.22 and so on would perfectly fit.
And if the gap between 1.9 and 1.20 is confusing someone, then he really has 
issues.
I'm  also fine with 2.x, i just think a new version scheme shouldn't 
necessarily lead to a version increment.

-- 

Best Regards, André Hentschel

Re: Wine and multiarch on Debian Testing

[Francois Gouget]

On Mon, 12 Nov 2012, Francois Gouget wrote:
[...]
>libtiff4-dev - #689085

I got bad news on this one: the maintainer has closed it as wontfix.

The rational is that he does not have time to do it and does not want to 
deviate from upstream. So if upstream does not fix it or a patch is not 
provided, he won't fix it either. The header causing trouble is 
tiffconf.h(*) which upstream appears to already be aware of but has not 
taken action with the libtiff4 major release.

For more details:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689085



(*) This is the equivalent to Wine's config.h file!

-- 
Francois Gouget   http://fgouget.free.fr/
Indifference will certainly be the downfall of mankind, but who cares?

Re: Wine and multiarch on Debian Testing

[Francois Gouget]

On Mon, 12 Nov 2012, Nicolas Le Cam wrote:
[...]
> #677885, #678040, #678070, #678895 and #678898 already contains trivial
> patches, I did check packages on every offered architectures to see if file
> differs, I can recheck if necessary.

Yes. It's thanks to your work either checking that there's no issue or 
even providing patches that these are on the trivial list.


> I can also check #677657 to see if things has changed since bug report 
> and provide a patch if needed.

The libfixes-dev in Testing had not improved as of a few days ago.


-- 
Francois Gouget 

Re: Wine and multiarch on Debian Testing

[Nicolas Le Cam]

2012/11/12 Francois Gouget 

> On Wed, 17 Oct 2012, Erich E. Hoover wrote:
>
> > I just upgraded to 12.04, until they fix the "32-bit headers problem"
> > you'll have to manually create the symbolic links for the "-dev"
> > package behavior:
>
> I ran into pretty much the same set of problems with Wine on Debian
> Testing. However some development packages are already
> multiarch-compatible so I installed them and created a bit fewer
> symbolic links than you. In particular I was able to install the
> following i386 development packages:
>
>libasound2-dev:i386
>libcapi20-dev:i386
>libjpeg8-dev:i386
>liblcms1-dev:i386
>libldap2-dev:i386
>libmpg123-dev:i386
>libopenal-dev:i386
>libtinfo-dev:i386 (needed for ncurses)
>libv4l-dev:i386
>libx11-dev:i386
>libxau-dev:i386
>libxcb1-dev:i386
>libxinerama-dev:i386
>libxml2-dev:i386
>libxrender-dev:i386
>zlib1g-dev:i386
>
>
> I also made a list of the packages that need to be fixed in order for
> work on Wine to be possible without so much complication, and made sure
> we have bugs to track the status of each of them. I am sure the
> maintainers would appreciate some help so here are the multiarch fixes
> needed for Wine development:
>
>  * These all seem to be fixable trivially. Double-check and submit a
>patch? The Debian freeze might block your efforts though :-(
>libfontconfig1-dev - #677885
>libgl1-mesa-dev - #678040, #689088
>libglu1-mesa-dev - #678040, #689089
>libgnutls-dev - #678070
>libosmesa6-dev - #678040
>libxcomposite-dev - #689082
>libxfixes-dev - #677657
>libxrandr-dev - #678895
>libxvmc1 - #640499 (well the work seems to have been done in any case)
>libxxf86vm-dev - #678898
>

Hi François,

#677885, #678040, #678070, #678895 and #678898 already contains trivial
patches, I did check packages on every offered architectures to see if file
differs, I can recheck if necessary. I can also check #677657 to see if
things has changed since bug report and provide a patch if needed.

libgl1-nvidia-glx doesn't depend on libxvmc1 so it should be a problem
anymore (at least if you use nvidia packages from unstable).

Unfortunately I didn't have much time to spend on not so trivial packages
and Debian freeze doesn't really help accepting patches, even if multiarch
is a release goal ...

-- 
Nicolas Le Cam

Re: Wine test bot

[Christian Costa]

Le 06/10/2012 06:13, Christian Costa a écrit :

Hi,

Is there a problem with Wine test bost? Jobs seem to be stuck and some 
VMs show problem of memory.


Christian


Wine test bost is still stuck. Any plan to fix that problem?

Re: Wine Mono 0.0.6 Release - Because hey, why not?

[Vincent Povirk]

So, it seems I've screwed up this release. Sorry about that. It won't
be added to Wine, and I'll try again later.

Specifically, I messed up the flags on the mono-registry64 msi
component, and I forgot to commit the guids for the new
System.Web.Http.SelfHost msi components (which means packages built
from the source tarball will have different guids, and weird things
could happen to that component when upgrading from them).

Re: Wine, fullscreen applications, and RandR 1.2

[Andy Ritger]

On Sat, Sep 08, 2012 at 12:08:06AM -0700, Henri Verbeet wrote:
> On 8 September 2012 01:22, Andy Ritger  wrote:
> > In any case, there is an enthusiast community around immersive gaming; e.g.,
> >
> > http://www.nvidia.com/object/3d-vision-surround-technology.html
> >
> > In those cases, the content across the monitors is rendered as one
> > big screen, rather than rendered separately per display with different
> > view frustums.
> >
> > With RandR 1.1 + NVIDIA MetaModes, users could achieve that sort of
> > configuration with Wine.  They can't really do that now with Wine and
> > RandR 1.2.
> >
> How does that work in Windows? In a typical D3D9 application you would
> normally end up with one adapter per display. Unless the application
> is multihead aware, switching to fullscreen mode would just make the
> application fullscreen on the primary display. Does the display driver
> change how the displays are presented to the application?

Yes.  As I understand it: the NVIDIA Windows driver, to support those
sorts of immersive gaming configurations, presents one adapter to the
Windows OS, which in turn presents that one adapter to the application
(e.g., one 7680x1600 adapter, rather than 3 2560x1600 adapters).
This is conceptually similar to NVIDIA Linux driver's MetaMode + RandR
1.1 (or XF86VidMode).

There are definitely cases where you would want the application to
be multihead aware so that they can make more intelligent use of each
monitor.  But in the case of monitors with similar geometry, abstracting
the complexity of multiple monitors away from the application has had
some success.

Somewhat timely, a related article was just posted on phoronix:

http://www.phoronix.com/scan.php?page=news_item&px=MTE3OTQ

That article suggests that there should be some coordination between
fullscreen applications and window managers.  Since that would also
introduce complexity, and would be needed across multiple applications
(and multiple window managers), a suspect one or more helper libraries
to centralize and abstract the complexity might be a good approach.

Thanks for the feedback in this thread.  I'll give some thought to what
these sorts of helper libraries might look like.

Thanks,
- Andy

Re: Wine, fullscreen applications, and RandR 1.2

[Henri Verbeet]

On 8 September 2012 01:22, Andy Ritger  wrote:
> In any case, there is an enthusiast community around immersive gaming; e.g.,
>
> http://www.nvidia.com/object/3d-vision-surround-technology.html
>
> In those cases, the content across the monitors is rendered as one
> big screen, rather than rendered separately per display with different
> view frustums.
>
> With RandR 1.1 + NVIDIA MetaModes, users could achieve that sort of
> configuration with Wine.  They can't really do that now with Wine and
> RandR 1.2.
>
How does that work in Windows? In a typical D3D9 application you would
normally end up with one adapter per display. Unless the application
is multihead aware, switching to fullscreen mode would just make the
application fullscreen on the primary display. Does the display driver
change how the displays are presented to the application?

Re: Wine, fullscreen applications, and RandR 1.2

[Andy Ritger]

On Thu, Sep 06, 2012 at 01:05:42AM -0700, Henri Verbeet wrote:
> On 5 September 2012 22:45, Andy Ritger  wrote:
> > On Wed, Sep 05, 2012 at 11:26:23AM -0700, Henri Verbeet wrote:
> >> From Wine's point of view, we'd just get a bunch of extra code to maintain
> >> because nvidia does things differently from everyone else.
> >
> > Eventually, I hope NVIDIA isn't unique about this approach to viewport
> > configuration.  The drawbacks aren't NVIDIA-specific.
> >
> > The concern about added code maintenance to Wine is fair; is that concern
> > lessened if the details of viewport configuration are abstracted by a new
> > standard library?
> >
> A little, but adding extra dependencies isn't without its costs
> either. You'd also have to wait a fair bit before it ends up in common
> distributions. (And that means things like "Debian stable" or "RHEL",
> not "Ubuntu & Fedora".)

Yes; understood.

> >> Perhaps there's a use case for a "big screen" setup, but that too is
> >> something that's probably best handled on the RandR / X server level
> >> instead of Wine.
> >
> > I don't think we can have it both ways:
> >
> > * RandR 1.1 gives you one "big screen" per X screen; the user can
> >   configure what is within that big screen via NVIDIA's MetaModes.
> >
> > * RandR 1.2 gives applications control of each individual CRTC/output.
> >
> > Are you suggesting we go back to something more like RandR 1.1?
> >
> I imagine you could configure things in e.g. xorg.conf so that the
> displays show up as a single CRTC / output instead of individual
> CRTCs, perhaps depending on how the MetaModes are setup. Or perhaps
> there's some way to make this fit it with some of the new
> functionality in RandR 1.5. The main point though is that there's no
> reasonable way for Wine to decide to do one or the other
> automatically. We could of course add a configuration option for that,
> but at that point it makes more sense to do it globally for all
> applications in RandR or the X server.

RandR 1.2+ intentionally gives control of the individual CRTCs/outputs
to client applications, with the goal of moving display configuration
policy out of the X server.  But I agree it is a burden for every
fullscreen application to have to decide for itself how to configure
the available CRTCs/outputs.

Here again maybe some helper library can help bridge the gap.

> >> I don't think you can actually do "immersive gaming"
> >> properly without support from the application though, you'll get
> >> fairly significant distortion at the edges if you just render to such
> >> a setup as if it was a single very wide display.
> >
> > I'm sorry; I don't understand the distortion concern.  Are you referring
> > to the bezel of the monitor occupying physical space, but not pixel space
> > in the X screen?  I believe people often address that by configuring
> > "dead space" in the X screen between their monitors.
> >
> No, I mean the distortion caused by perspective projection, because
> you're essentially projecting a spherical "world" onto a flat screen.
> An application that is aware of this could e.g. use a separate camera
> for each display to mitigate this, or perhaps adjust the projection
> matrix.

Maybe there is a distortion concern in theory (though it may depend on
whether the monitors are all in the same plane or tilted to "wrap around"
the user), but in practice it seems to normally work out well enough.
I suppose maybe users use side displays for peripheral vision, and then
move their viewport such that the content they care about is in the
center display.

In any case, there is an enthusiast community around immersive gaming; e.g.,

http://www.nvidia.com/object/3d-vision-surround-technology.html

In those cases, the content across the monitors is rendered as one
big screen, rather than rendered separately per display with different
view frustums.

With RandR 1.1 + NVIDIA MetaModes, users could achieve that sort of
configuration with Wine.  They can't really do that now with Wine and
RandR 1.2.

> > Since we have some differing viewpoints that won't be quickly resolved,
> > how about as a compromise we add a way for users to force Wine from
> > RandR 1.2 back to RandR 1.1?  That would at least let users achieve
> > some of the configurations they cannot configure with top of tree.
> > If that seems fair, what is the preferred configuration mechanism to
> > do that?  Just a simple environment variable?
> >
> You could perhaps extend the existing "UseXRandR" registry setting
> (see dlls/winex11.drv/x11drv_main.c) to take a version number. It's
> not something we've heard a lot of users about though.

Sounds good; I'll look into that.

Thanks,
- Andy

Re: Wine, fullscreen applications, and RandR 1.2

[Henri Verbeet]

On 5 September 2012 22:45, Andy Ritger  wrote:
> On Wed, Sep 05, 2012 at 11:26:23AM -0700, Henri Verbeet wrote:
>> From Wine's point of view, we'd just get a bunch of extra code to maintain
>> because nvidia does things differently from everyone else.
>
> Eventually, I hope NVIDIA isn't unique about this approach to viewport
> configuration.  The drawbacks aren't NVIDIA-specific.
>
> The concern about added code maintenance to Wine is fair; is that concern
> lessened if the details of viewport configuration are abstracted by a new
> standard library?
>
A little, but adding extra dependencies isn't without its costs
either. You'd also have to wait a fair bit before it ends up in common
distributions. (And that means things like "Debian stable" or "RHEL",
not "Ubuntu & Fedora".)

>> Perhaps there's a use case for a "big screen" setup, but that too is
>> something that's probably best handled on the RandR / X server level
>> instead of Wine.
>
> I don't think we can have it both ways:
>
> * RandR 1.1 gives you one "big screen" per X screen; the user can
>   configure what is within that big screen via NVIDIA's MetaModes.
>
> * RandR 1.2 gives applications control of each individual CRTC/output.
>
> Are you suggesting we go back to something more like RandR 1.1?
>
I imagine you could configure things in e.g. xorg.conf so that the
displays show up as a single CRTC / output instead of individual
CRTCs, perhaps depending on how the MetaModes are setup. Or perhaps
there's some way to make this fit it with some of the new
functionality in RandR 1.5. The main point though is that there's no
reasonable way for Wine to decide to do one or the other
automatically. We could of course add a configuration option for that,
but at that point it makes more sense to do it globally for all
applications in RandR or the X server.

>> I don't think you can actually do "immersive gaming"
>> properly without support from the application though, you'll get
>> fairly significant distortion at the edges if you just render to such
>> a setup as if it was a single very wide display.
>
> I'm sorry; I don't understand the distortion concern.  Are you referring
> to the bezel of the monitor occupying physical space, but not pixel space
> in the X screen?  I believe people often address that by configuring
> "dead space" in the X screen between their monitors.
>
No, I mean the distortion caused by perspective projection, because
you're essentially projecting a spherical "world" onto a flat screen.
An application that is aware of this could e.g. use a separate camera
for each display to mitigate this, or perhaps adjust the projection
matrix.

> Since we have some differing viewpoints that won't be quickly resolved,
> how about as a compromise we add a way for users to force Wine from
> RandR 1.2 back to RandR 1.1?  That would at least let users achieve
> some of the configurations they cannot configure with top of tree.
> If that seems fair, what is the preferred configuration mechanism to
> do that?  Just a simple environment variable?
>
You could perhaps extend the existing "UseXRandR" registry setting
(see dlls/winex11.drv/x11drv_main.c) to take a version number. It's
not something we've heard a lot of users about though.

Re: Wine, fullscreen applications, and RandR 1.2

[Andy Ritger]

On Wed, Sep 05, 2012 at 11:26:23AM -0700, Henri Verbeet wrote:
> On 5 September 2012 18:52, Andy Ritger  wrote:
> > At first glance, I agree that would be easier for applications, but that
> > approach has some drawbacks:
> >
> > * lies to the user/application about what timings are actually being
> >   driven to the monitor
> > * the above bullet causes confusion: the timings reported in the monitor's
> >   on screen display don't match what is reported by the X server
> > * user/application doesn't get complete control over what actual timings
> >   are being sent to the monitor
> > * does not provide the full flexibility of the hardware to configure,
> >   e.g., arbitrary position of the ViewPortOut within the active raster
> >
> Perhaps, but none of that changes, as far as Win32 applications are
> concerned, if we generate modes in Wine instead of in the kernel.

Agreed.

> From Wine's point of view, we'd just get a bunch of extra code to maintain
> because nvidia does things differently from everyone else.

Eventually, I hope NVIDIA isn't unique about this approach to viewport
configuration.  The drawbacks aren't NVIDIA-specific.

The concern about added code maintenance to Wine is fair; is that concern
lessened if the details of viewport configuration are abstracted by a new
standard library?

> > I imagine counter arguments include:
> >
> > * we already have the "scaling mode" output property in most drivers;
> >   that is good enough
> > * Transformation matrix and Border are too low level for most applications
> >
> > For the first counter argument: I'm trying to make the case that
> > providing the full flexibility, and being truthful about modetimings to
> > users/applications, is valuable enough to merit a change (hopefully even
> > in the drivers that currently expose a "scaling mode" output property).
> >
> I must say that I'm having some trouble imagining what not generating
> standard modes will allow someone to do that they couldn't do before.
> In terms of figuring out the "real" timings, the RandR "preferred"
> mode is probably close enough, but I suppose it should be fairly easy
> to extend RandR to explicitly mark specific modes as "native". I
> imagine that for most applications it's just an implementation detail
> whether the display panel has a scaler itself, or if that's done by
> the GPU though. Either way, that seems like a discussion more
> appropriate for e.g. dri-devel.

Fair enough; I'll discuss with the other drivers, first.

> Perhaps there's a use case for a "big screen" setup, but that too is
> something that's probably best handled on the RandR / X server level
> instead of Wine.

I don't think we can have it both ways:

* RandR 1.1 gives you one "big screen" per X screen; the user can
  configure what is within that big screen via NVIDIA's MetaModes.

* RandR 1.2 gives applications control of each individual CRTC/output.

Are you suggesting we go back to something more like RandR 1.1?

> I don't think you can actually do "immersive gaming"
> properly without support from the application though, you'll get
> fairly significant distortion at the edges if you just render to such
> a setup as if it was a single very wide display.

I'm sorry; I don't understand the distortion concern.  Are you referring
to the bezel of the monitor occupying physical space, but not pixel space
in the X screen?  I believe people often address that by configuring
"dead space" in the X screen between their monitors.

In any case, my impression is that multi-monitor fullscreen gaming is
not an uncommon use case.

> (Also, uneven numbers
> of displays are probably more useful for such a thing than even
> numbers of displays.)

Agreed.


Since we have some differing viewpoints that won't be quickly resolved,
how about as a compromise we add a way for users to force Wine from
RandR 1.2 back to RandR 1.1?  That would at least let users achieve
some of the configurations they cannot configure with top of tree.
If that seems fair, what is the preferred configuration mechanism to
do that?  Just a simple environment variable?

Thanks,
- Andy

Re: Wine, fullscreen applications, and RandR 1.2

[Henri Verbeet]

On 5 September 2012 18:52, Andy Ritger  wrote:
> At first glance, I agree that would be easier for applications, but that
> approach has some drawbacks:
>
> * lies to the user/application about what timings are actually being
>   driven to the monitor
> * the above bullet causes confusion: the timings reported in the monitor's
>   on screen display don't match what is reported by the X server
> * user/application doesn't get complete control over what actual timings
>   are being sent to the monitor
> * does not provide the full flexibility of the hardware to configure,
>   e.g., arbitrary position of the ViewPortOut within the active raster
>
Perhaps, but none of that changes, as far as Win32 applications are
concerned, if we generate modes in Wine instead of in the kernel. From
Wine's point of view, we'd just get a bunch of extra code to maintain
because nvidia does things differently from everyone else.

> I imagine counter arguments include:
>
> * we already have the "scaling mode" output property in most drivers;
>   that is good enough
> * Transformation matrix and Border are too low level for most applications
>
> For the first counter argument: I'm trying to make the case that
> providing the full flexibility, and being truthful about modetimings to
> users/applications, is valuable enough to merit a change (hopefully even
> in the drivers that currently expose a "scaling mode" output property).
>
I must say that I'm having some trouble imagining what not generating
standard modes will allow someone to do that they couldn't do before.
In terms of figuring out the "real" timings, the RandR "preferred"
mode is probably close enough, but I suppose it should be fairly easy
to extend RandR to explicitly mark specific modes as "native". I
imagine that for most applications it's just an implementation detail
whether the display panel has a scaler itself, or if that's done by
the GPU though. Either way, that seems like a discussion more
appropriate for e.g. dri-devel.

> When the RandR primary output (as queried/set by RR[SG]etOutputPrimary)
> is non-None, then its CRTC will be sorted to the front of the CRTCs
> list reported by RRGetScreenResources{,Current}.  However, None is a
> valid value for the primary output, in which case all bets are off wrt
> CRTC/output sorting order in the RRGetScreenResources{,Current} reply.
>
Yes, as I said this is something we'll probably address at some point.

> Further, while RandR primary output seems like a reasonable default,
> the spec spells out a focus on window manager (e.g., "primary" is where
> the menu bar should be placed).  It seems like a valid use case would
> be for the user to have his window manager primary output on one monitor,
> but run his full screen Wine application on another monitor.  Given that,
> would it be reasonable for the user to specify the RandR output he wants
> Wine to use?
>
We can probably add an override if there's a lot of demand. It doesn't
strike me as a very common use case though.

> I can definitely believe that plumbing RandR outputs to multiple objects
> in Win32 is not an important/compelling use case, since not many Win32
> applications would do useful things with that.  What seems more useful,
> though, is driving multiple RandR outputs and presenting that to Win32 as
> a single big screen.  E.g., "immersive gaming" where your Wine application
> spans two, three, or more RandR outputs (NVIDIA Kepler GPUs can have up
> to four heads).
>
Perhaps there's a use case for a "big screen" setup, but that too is
something that's probably best handled on the RandR / X server level
instead of Wine. I don't think you can actually do "immersive gaming"
properly without support from the application though, you'll get
fairly significant distortion at the edges if you just render to such
a setup as if it was a single very wide display. (Also, uneven numbers
of displays are probably more useful for such a thing than even
numbers of displays.)

Re: Wine, fullscreen applications, and RandR 1.2

[Andy Ritger]

Thanks, Henri.

On Wed, Sep 05, 2012 at 01:34:47AM -0700, Henri Verbeet wrote:
> On 5 September 2012 08:07, Andy Ritger  wrote:
> > Questions:
> >
> > * Looking at dlls/winex11.drv/xrandr.c, the first RandR CRTC/output's
> >   modelist is used to populate Wine's list of available modes.  Is the
> >   data flow between Wine and Windows applications always such that you
> >   need to advertise a list of (width, height, refreshRate)s?  Or would
> >   an application ever tell Wine what resolution it wants?
> >
> Windows applications use EnumDisplaySettingsEx() to query supported
> modes, and ChangeDisplaySettingsEx() to set one. Applications can't
> make up modes on their own.

Thanks for clarifying.

> > * Would you be open to patches to make dlls/winex11.drv/xrandr.c generate
> >   a larger set of (width, height, refreshRate)s, and then have
> >   xrandr12_set_current_mode() use RandR transformation matrix and Border
> >   property to satisfy those?  I was envisioning something where we take
> >   the "preferred" mode for the RandR output, and create all of the
> >   following resolutions using ViewPort{In,Out}:
> >
> > 1920 x 1200
> > 1920 x 1080
> > 1600 x 1200
> > 1280 x 1024
> > 1280 x 720
> > 1024 x 768
> > 800 x 600
> > 640 x 480
> >
> It's ultimately not up to me whether such a patch would be accepted,
> but it's not something I would be particularly happy about. I think
> the preferred way to handle this would be to generate the standard DMT
> etc. modes in the kernel, and use the "scaling mode" output property
> to control the scaling mode, pretty much like all the other drivers.

At first glance, I agree that would be easier for applications, but that
approach has some drawbacks:

* lies to the user/application about what timings are actually being
  driven to the monitor
* the above bullet causes confusion: the timings reported in the monitor's
  on screen display don't match what is reported by the X server
* user/application doesn't get complete control over what actual timings
  are being sent to the monitor
* does not provide the full flexibility of the hardware to configure,
  e.g., arbitrary position of the ViewPortOut within the active raster

I imagine counter arguments include:

* we already have the "scaling mode" output property in most drivers;
  that is good enough
* Transformation matrix and Border are too low level for most applications

For the first counter argument: I'm trying to make the case that
providing the full flexibility, and being truthful about modetimings to
users/applications, is valuable enough to merit a change (hopefully even
in the drivers that currently expose a "scaling mode" output property).

For the second counter argument: maybe the viewport configuration
belongs in a library rather than directly in applications like Wine.
In that case, I'd like to build a better understanding of Wine's needs
so that I could properly design the API to such a library.

> > * The current xrandr.c code picks the first CRTC/output, which may not
> >   be currently active.  At the least, it should scan for an active
> >   CRTC+output.  I imagine it would be even better if the user could
> >   configure which RandR output they want.  Would that be reasonable?  What
> >   mechanisms are available in Wine for users to provide runtime 
> > configuration?
> >
> The RandR primary display should be CRTC 0, output 0.

That is true most of the time, but I don't believe it is strictly mandated
by the RandR specification:

http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt

When the RandR primary output (as queried/set by RR[SG]etOutputPrimary)
is non-None, then its CRTC will be sorted to the front of the CRTCs
list reported by RRGetScreenResources{,Current}.  However, None is a
valid value for the primary output, in which case all bets are off wrt
CRTC/output sorting order in the RRGetScreenResources{,Current} reply.

Further, while RandR primary output seems like a reasonable default,
the spec spells out a focus on window manager (e.g., "primary" is where
the menu bar should be placed).  It seems like a valid use case would
be for the user to have his window manager primary output on one monitor,
but run his full screen Wine application on another monitor.  Given that,
would it be reasonable for the user to specify the RandR output he wants
Wine to use?

> Users can
> typically change this through xrandr or xorg.conf. Unfortunately not
> all drivers do something reasonable by default here, so we'll probably
> add code to pick the first connected display as Win32 primary instead
> if no primary is defined through RandR. For the moment we end up
> falling back to the older RandR version though, so at least the
> behaviour isn't any worse than before.
>
> > * From the current code, it does not look like Wine's RandR support tries
> >   to do anything with multiple simultaneous RandR outputs.
> >
> Yes, pr

Re: Wine, fullscreen applications, and RandR 1.2

[Henri Verbeet]

On 5 September 2012 08:07, Andy Ritger  wrote:
> Questions:
>
> * Looking at dlls/winex11.drv/xrandr.c, the first RandR CRTC/output's
>   modelist is used to populate Wine's list of available modes.  Is the
>   data flow between Wine and Windows applications always such that you
>   need to advertise a list of (width, height, refreshRate)s?  Or would
>   an application ever tell Wine what resolution it wants?
>
Windows applications use EnumDisplaySettingsEx() to query supported
modes, and ChangeDisplaySettingsEx() to set one. Applications can't
make up modes on their own.

> * Would you be open to patches to make dlls/winex11.drv/xrandr.c generate
>   a larger set of (width, height, refreshRate)s, and then have
>   xrandr12_set_current_mode() use RandR transformation matrix and Border
>   property to satisfy those?  I was envisioning something where we take
>   the "preferred" mode for the RandR output, and create all of the
>   following resolutions using ViewPort{In,Out}:
>
> 1920 x 1200
> 1920 x 1080
> 1600 x 1200
> 1280 x 1024
> 1280 x 720
> 1024 x 768
> 800 x 600
> 640 x 480
>
It's ultimately not up to me whether such a patch would be accepted,
but it's not something I would be particularly happy about. I think
the preferred way to handle this would be to generate the standard DMT
etc. modes in the kernel, and use the "scaling mode" output property
to control the scaling mode, pretty much like all the other drivers.

> * The current xrandr.c code picks the first CRTC/output, which may not
>   be currently active.  At the least, it should scan for an active
>   CRTC+output.  I imagine it would be even better if the user could
>   configure which RandR output they want.  Would that be reasonable?  What
>   mechanisms are available in Wine for users to provide runtime configuration?
>
The RandR primary display should be CRTC 0, output 0. Users can
typically change this through xrandr or xorg.conf. Unfortunately not
all drivers do something reasonable by default here, so we'll probably
add code to pick the first connected display as Win32 primary instead
if no primary is defined through RandR. For the moment we end up
falling back to the older RandR version though, so at least the
behaviour isn't any worse than before.

> * From the current code, it does not look like Wine's RandR support tries
>   to do anything with multiple simultaneous RandR outputs.
>
Yes, proper multihead support is something we still need to implement.
There aren't a lot of Win32 applications that do something useful with
multiple displays though, so it's not something that has a very high
priority at the moment.

>   Ironically:
>   this actually works better with RandR 1.1 + NVIDIA: users can configure
>   their MetaModes to describe what mode (plus viewport configuration)
>   they want on each monitor, and then RandR 1.1 chooses the MetaMode.
>
No. With RandR 1.1 you get one big screen, and you can choose between
getting fullscreen applications stretched across all your displays, or
turning off all displays except one. What you actually want is for the
application to be fullscreen on a specific display, or multiple
displays if the application supports that, and leave everything else
alone.

As an aside, the fake refresh rates generated by "DynamicTwinView"
aren't very helpful either. Some Win32 applications expect modes like
800x600@60Hz or 1024x768@60Hz to always exist, and just die if they
don't.

Re: Wine Gecko 1.8-beta1

[Dmitry Timoshkov]

Vincent Povirk  wrote:

> > On related note, I seriously consider dropping debug builds and replace
> > them by unstripped release build or even just a separated package
> > containing only debug symbols for the release build.
> 
> No one has complained about the debugging symbols in Wine Mono yet.
> They are included mostly because I don't know how to get rid of them,
> and it seems silly to put effort into that given the debug symbols
> have proven useful so far.

So, I decided to have a look at ~/.wine/drive_c/windows/mono sizes, and
was pretty surprized by the result:

cd ~/.wine/drive_c/windows
du -h ./mono
121M./mono
find ./mono -type f -exec strip {} \;
du -h ./mono
104M./mono

So, it's not the debug symbols that creates all that bloat in mono.

-- 
Dmitry.

Re: Wine Gecko 1.8-beta1

[Jacek Caban]

On 09/02/12 20:52, Vincent Povirk wrote:
>> On related note, I seriously consider dropping debug builds and replace
>> them by unstripped release build or even just a separated package
>> containing only debug symbols for the release build.
> No one has complained about the debugging symbols in Wine Mono yet.
> They are included mostly because I don't know how to get rid of them,
> and it seems silly to put effort into that given the debug symbols
> have proven useful so far.

Are you suggesting shipping unstripped builds as default package
version? That's not an option, xul.dll alone is over 700MB unstripped.

Jacek

Re: Wine Gecko 1.8-beta1

[Vincent Povirk]

> On related note, I seriously consider dropping debug builds and replace
> them by unstripped release build or even just a separated package
> containing only debug symbols for the release build.

No one has complained about the debugging symbols in Wine Mono yet.
They are included mostly because I don't know how to get rid of them,
and it seems silly to put effort into that given the debug symbols
have proven useful so far.

Re: Wine bot results

[Alistair Leslie-Hughes]

Hi Jacek,

--
From: "Jacek Caban" 
Sent: Wednesday, August 29, 2012 1:16 AM
To: "Alistair Leslie-Hughes" 
Cc: 
Subject: Re: Wine bot results



This VariantClear call attempts to free uninitialized VARIANT instance.
You probably meant VariantInit().

Thanks,  it works on all systems now.

Best Regards
Alistair Leslie-Hughes 

Re: Wine bot results

[Saulius Krasuckas]

* On Tue, 28 Aug 2012, Saulius Krasuckas wrote:
> * On Tue, 28 Aug 2012, Alistair Leslie-Hughes wrote:
> > 
> > > Target: i686-w64-mingw32
>   ...
> > Target: i586-mingw32msvc
> 
> There was the same topic brought up two years ago:
> http://www.winehq.org/pipermail/wine-devel/2010-September/086643.html
> 
> IIRC, MSVC and i586-mingw32msvc compilers initialize every declared 
> variable while *-mingw32* one does not.

I mean *-mingw32-gcc (the one not using MSVCRT.DLL) with the latter;)

S.