9 Aug
2019
9 Aug
'19
6:02 p.m.
Hi,
What is the status of development regarding Wine Gecko? The last general release was
June 2016. As the maintainer in Fedora I have a few concerns that I would like to
address.
1. The build scripts require Python 2. Fedora is dropping Python 2 in Fedora 31/32.
31 is only a few months away from GA.
2. I have been unable to build from source with the latest MinGW toolset since
November 2016. I've last reported this directly to Jacek in 2018, but I have never
heard from him.
3. If no support arrives, I don't have the time to patch wine-gecko. It will be
dropped from Fedora and users will be downloading the binaries from winehq.org. This
provides a reduced user experience and I would like to prevent it.
Thanks,
Michael
9 Aug
9 Aug
6:59 p.m.
Hi Michael,
On 8/9/19 8:02 PM, Michael Cronenworth wrote:
Hi,
What is the status of development regarding Wine Gecko? The last
general release was June 2016. As the maintainer in Fedora I have a
few concerns that I would like to address.
1. The build scripts require Python 2. Fedora is dropping Python 2 in
Fedora 31/32. 31 is only a few months away from GA.
2. I have been unable to build from source with the latest MinGW
toolset since November 2016. I've last reported this directly to Jacek
in 2018, but I have never heard from him.
3. If no support arrives, I don't have the time to patch wine-gecko.
It will be dropped from Fedora and users will be downloading the
binaries from winehq.org. This provides a reduced user experience and
I would like to prevent it.
I do plan to do a new release as soon as I will be able to work on it
and it's high on my TODO list. Earlier this year I was waiting for new
Wine Mono out-of-prefix installation to settle so I can do the same for
Gecko. I believe that it's proven right already, so it's just ETA is
limited only by my time at this point.
Historically, I was doing regular releases every few Firefox releases.
Sadly, at some point, it became impossible for us to use newer Gecko.
That's why releases are no longer as regular as they were in the past.
The next release will be still based on Gecko 47. And I agree it's been
way too long, I'm definitely not happy about that. I have quite a few
changes I'd like to do for the release and that includes fixing building
with newer mingw-w64. I can't promise Python 3 support through. Gecko
build scripts are very complex and I'm not a Python expert. I will look
at it, but if it happens to require too much effort, I may decide to
postpone that for future releases.
BTW, I just checked that I replied to your private email in May last
year. I didn't have anything concrete to say, but you should have heard
from me ;)
Thanks,
Jacek
7:07 p.m.
On 8/9/19 1:59 PM, Jacek Caban wrote:
I do plan to do a new release as soon as I will be
able to work on it and it's
high on my TODO list. Earlier this year I was waiting for new Wine Mono
out-of-prefix installation to settle so I can do the same for Gecko. I believe
that it's proven right already, so it's just ETA is limited only by my time at
this point.
Glad to hear it.
Historically, I was doing regular releases every few Firefox releases. Sadly, at
some point, it became impossible for us to use newer Gecko. That's why releases
are no longer as regular as they were in the past. The next release will be still
based on Gecko 47. And I agree it's been way too long, I'm definitely not happy
about that. I have quite a few changes I'd like to do for the release and that
includes fixing building with newer mingw-w64. I can't promise Python 3 support
through. Gecko build scripts are very complex and I'm not a Python expert. I will
look at it, but if it happens to require too much effort, I may decide to postpone
that for future releases.
I can look into Python 3 support when the time comes. The larger MinGW issues are
time prohibitive for me.
BTW, I just checked that I replied to your private email in May last year. I
didn't have anything concrete to say, but you should have heard from me ;)
Sorry. I may have missed the reply. :)
Regards,
Michael
12 Aug
12 Aug
7:53 p.m.
Hi Michael,
I just pushed build fixes to wine-gecko-2.47 branch:
https://sourceforge.net/p/wine/wine-gecko/ci/master/tree/
I have more plans for the release and it still needs more testing, but I
was able to build with Git mingw-w64 and GCC 9.2 (still with python 2)
from that branch. Please let me know if it works for you. Ideally, no
additional tweaks should be needed. If you still need to patch Wine
Gecko, I'd be interested to hear about it and hopefully have it fixed in
Wine Gecko git.
Jacek
15 Aug
15 Aug
3:07 a.m.
On 8/12/19 2:53 PM, Jacek Caban wrote:
I just pushed build fixes to wine-gecko-2.47 branch:
https://sourceforge.net/p/wine/wine-gecko/ci/master/tree/
I have more plans for the release and it still needs more testing, but I was able
to build with Git mingw-w64 and GCC 9.2 (still with python 2) from that branch.
Please let me know if it works for you. Ideally, no additional tweaks should be
needed. If you still need to patch Wine Gecko, I'd be interested to hear about it
and hopefully have it fixed in Wine Gecko git.
Thanks. Fedora Rawhide (31/32) MinGW is using GCC 9.1.1. Unfortunately the build
fails with a compiler failure when compiling Unified_cpp_dom_presentation0.cpp.
Snippet:
cc1plus: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
make[3]: ***
[/builddir/build/BUILD/wine-mozilla-2.47/wine-mozilla-2.47/config/rules.mk:967:
Unified_cpp_dom_presentation0.o] Error 1
make[2]: ***
[/builddir/build/BUILD/wine-mozilla-2.47/wine-mozilla-2.47/config/recurse.mk:71:
dom/presentation/target] Error 2
make[1]: ***
[/builddir/build/BUILD/wine-mozilla-2.47/wine-mozilla-2.47/config/recurse.mk:33:
compile] Error 2
make: ***
[/builddir/build/BUILD/wine-mozilla-2.47/wine-mozilla-2.47/config/rules.mk:557:
default] Error 2
I don't believe my build host is the problem. It occurred twice. Do you want any
additional logs or preprocessed source to look at?
Thanks,
Michael
22 Aug
22 Aug
8:25 p.m.
I've been working on the Python 3 aspect of this, and it finally
created a .msi package for x86 at least. My github import of
wine-gecko failed so I have no good way to share my work at the
moment. The diff is very large because I ran 2to3 on much of the
codebase.
I still need to test a clean build, try a win64 build, see if they
actually work, and probably do some comparisons of generated code.
23 Aug
23 Aug
12:10 p.m.
Hi Vincent,
On 8/22/19 10:25 PM, Vincent Povirk (they/them) wrote:
I've been working on the Python 3 aspect of this,
and it finally
created a .msi package for x86 at least.
That's great, thanks!
My github import of
wine-gecko failed so I have no good way to share my work at the
moment. The diff is very large because I ran 2to3 on much of the
codebase.
I still need to test a clean build, try a win64 build, see if they
actually work, and probably do some comparisons of generated code.
Yeah, I tried to move it to github as well. It looks like they dropped
my push when it reached 1GB. They claim to not have a hard limit, so
maybe splitting it into multiple pushes would work, but that doesn't
seem appropriate.
Wine Gecko git currently lives on SF, which is less than optimal so I
would like to move it out of there anyway. I'm open for ideas for a
better place.
Thanks,
Jacek
8:43 p.m.
Clean builds and win64 work.
A lot of things have been re-ordered in the generated code, so I don't
have a good way to compare it. I guess what's left is to clean out my
unrelated changes and ask Jacek to review it.
I also made a Vagrantfile for a build vm. Any reason not to leave that in?
25 Aug
25 Aug
4:57 p.m.
Hi Vincent,
On 8/23/19 10:43 PM, Vincent Povirk (they/them) wrote:
Clean builds and win64 work.
A lot of things have been re-ordered in the generated code, so I don't
have a good way to compare it. I guess what's left is to clean out my
unrelated changes and ask Jacek to review it.
That's great.
I also made a Vagrantfile for a build vm. Any reason
not to leave that in?
I'm fine with having it in the tree.
Thanks,
Jacek
13 Sep
13 Sep
5:47 p.m.
On Fri, Aug 23, 2019 at 6:08 AM Jacek Caban <jacek(a)codeweavers.com> wrote:
Wine Gecko git currently lives on SF, which is less than optimal so I
would like to move it out of there anyway. I'm open for ideas for a
better place.
Shouldn't it be on <https://source.winehq.org/git/>? I'm sure
CodeWeavers has more than enough server space for you.
-Alex
20 Sep
20 Sep
3:45 p.m.
On 9/13/19 7:47 PM, Alex Henrie wrote:
On Fri, Aug 23, 2019 at 6:08 AM Jacek
Caban<jacek(a)codeweavers.com> wrote:
I don't think server space was ever an issue. In the past, when I did a
lot of maintenance, importing, merging, etc. It was practical for me to
have direct access to the repo and winehq wasn't setup for that. It's
not the case any more, so I guess we could move Wine Gecko git to winehq.
Thanks,
Jacek
Wine Gecko git currently lives on SF, which is
less than optimal so I
would like to move it out of there anyway. I'm open for ideas for a
better place.
Shouldn't it be on<https://source.winehq.org/git/>?
I'm sure
CodeWeavers has more than enough server space for you.
26 Aug
26 Aug
7:23 p.m.
On 8/15/19 5:07 AM, Michael Cronenworth wrote:
On 8/12/19 2:53 PM, Jacek Caban wrote:
A bit more logs could be useful. Internal compiler error is by
definition a serious GCC bug, not our fault. If it happens with recent
GCC, it deserves reporting to GCC. If it's easy to work around, I can
put it in, but in this case GCC is not even giving a hint about
suspicious area (unless it's earlier in logs, but I think it would
usually be in the same line as "Segmentation fault").
To investigate it further, a preprocessed file would be useful. Gecko
has makefile rules that make it easy. You can get that with:
make PresentationCallbacks.i -C path/to/wine_gecko/build/dom/presentation/
It should be enough to experiment further without doing whole Gecko
builds. Please send PresentationCallbacks.i together with the command
that will be executed. I will see if I can somehow reproduce the problem
with it.
Thanks,
Jacek
I just pushed build fixes to wine-gecko-2.47 branch:
https://sourceforge.net/p/wine/wine-gecko/ci/master/tree/
I have more plans for the release and it still needs more testing,
but I was able to build with Git mingw-w64 and GCC 9.2 (still with
python 2) from that branch. Please let me know if it works for you.
Ideally, no additional tweaks should be needed. If you still need to
patch Wine Gecko, I'd be interested to hear about it and hopefully
have it fixed in Wine Gecko git.
Thanks. Fedora Rawhide (31/32) MinGW is using GCC 9.1.1. Unfortunately
the build fails with a compiler failure when compiling
Unified_cpp_dom_presentation0.cpp.
Snippet:
cc1plus: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
make[3]: ***
[/builddir/build/BUILD/wine-mozilla-2.47/wine-mozilla-2.47/config/rules.mk:967:
Unified_cpp_dom_presentation0.o] Error 1
make[2]: ***
[/builddir/build/BUILD/wine-mozilla-2.47/wine-mozilla-2.47/config/recurse.mk:71:
dom/presentation/target] Error 2
make[1]: ***
[/builddir/build/BUILD/wine-mozilla-2.47/wine-mozilla-2.47/config/recurse.mk:33:
compile] Error 2
make: ***
[/builddir/build/BUILD/wine-mozilla-2.47/wine-mozilla-2.47/config/rules.mk:557:
default] Error 2
I don't believe my build host is the problem. It occurred twice. Do
you want any additional logs or preprocessed source to look at?
13 Sep
13 Sep
5:30 p.m.
On 8/26/19 2:23 PM, Jacek Caban wrote:
A bit more logs could be useful. Internal compiler error is by definition a
serious GCC bug, not our fault. If it happens with recent GCC, it deserves
reporting to GCC. If it's easy to work around, I can put it in, but in this case
GCC is not even giving a hint about suspicious area (unless it's earlier in logs,
but I think it would usually be in the same line as "Segmentation fault").
To investigate it further, a preprocessed file would be useful. Gecko has makefile
rules that make it easy. You can get that with:
make PresentationCallbacks.i -C path/to/wine_gecko/build/dom/presentation/
It should be enough to experiment further without doing whole Gecko builds. Please
send PresentationCallbacks.i together with the command that will be executed. I
will see if I can somehow reproduce the problem with it.
By the time I had time to look into this the issue has been resolved. We updated GCC
to 9.2.1 and it now compiles successfully.
Thanks,
Michael
5:43 p.m.
On 9/13/19 7:30 PM, Michael Cronenworth wrote:
On 8/26/19 2:23 PM, Jacek Caban wrote:
That's good to hear. Meantime, I pushed puthon 3 support from Vincent to
master branch of Wine Gecko git. Please let me know if it works for you.
Thanks,
Jacek
A bit more logs could be useful. Internal compiler error is by
definition a serious GCC bug, not our fault. If it happens with
recent GCC, it deserves reporting to GCC. If it's easy to work
around, I can put it in, but in this case GCC is not even giving a
hint about suspicious area (unless it's earlier in logs, but I think
it would usually be in the same line as "Segmentation fault").
To investigate it further, a preprocessed file would be useful. Gecko
has makefile rules that make it easy. You can get that with:
make PresentationCallbacks.i -C
path/to/wine_gecko/build/dom/presentation/
It should be enough to experiment further without doing whole Gecko
builds. Please send PresentationCallbacks.i together with the command
that will be executed. I will see if I can somehow reproduce the
problem with it.
By the time I had time to look into this the issue has been resolved.
We updated GCC to 9.2.1 and it now compiles successfully.
7 Nov
7 Nov
6:05 p.m.
On 9/13/19 12:43 PM, Jacek Caban wrote:
That's good to hear. Meantime, I pushed puthon 3
support from Vincent to master
branch of Wine Gecko git. Please let me know if it works for you.
I haven't tried that yet, but I have found that while Wine Gecko now builds the code
the MSI creation process has a bug. I didn't notice the RPMs were in the 100k size
instead of 100MB size.
The 'wine cabarc.exe -r -m mszip N winegecko.cab msi/files' command fails to
create
a valid cab file. It's empty.
-rw-r--r--. 1 mockbuild mock 36 Nov 7 11:35 winegecko.cab
-rw-r--r--. 1 mockbuild mock 10240 Nov 7 11:30 wine_gecko-2.47-x86_64.msi
Using 'gcab' to create a valid cabinet the msibuilder commands still create a
valid
MSI and installs successfully.
-rw-rw-r--. 1 mockbuild mock 107818934 Nov 7 11:35 winegecko.cab
-rw-r--r--. 1 mockbuild mock 108684800 Nov 7 11:39 wine_gecko-2.47-x86_64.msi
6:32 p.m.
On 11/7/19 12:05 PM, Michael Cronenworth wrote:
The 'wine cabarc.exe -r -m mszip N winegecko.cab msi/files' command fails to
create a valid cab file. It's empty.
Looks like the file list must be supplied instead of a directory. This fixes it:
- wine cabarc.exe -r -m mszip N winegecko.cab msi/files
+ wine cabarc.exe -r -m mszip N winegecko.cab msi/files/*
1633
days inactive
1723
days old
15 comments
4 participants
participants (4)
-
Alex Henrie -
Jacek Caban -
Michael Cronenworth -
Vincent Povirk (they/them)