Re: Update Windows binaries

[Vasily Galkin]

Hi!

> Pacman does allow you to pin versions just like you can in other package 
> management systems (like apt). You do that like pacman -S bash==3.2. But 
> obviously the pinned version must be available in the repos used.

After trying this locally I'm not sure that installing non-last package version 
is officially supported for msys2.
While *one* of the msys2 mirrors indeed contains older packages like
http://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-gtksourceview3-3.24.6-1-any.pkg.tar.xz

Such packages can't be installed after database updating with pacman -Sy

As of today this command works (current version):
pacman -S mingw64/mingw-w64-x86_64-gtksourceview3=3.24.6-2
And this  doesn't(for previous version):
pacman -S mingw64/mingw-w64-x86_64-gtksourceview3=3.24.6-1

> Vasily, You didn't need to change the path of TK_LIBRARY and TCL_LIBRARY 
> between 32 and 64 bit? 

The only usage of (tcl & tk) in meld is displaying message box about gtk/glib 
absence via tkinter for a case gtk/glib is not installed. It is useful for 
running meld 3.18 from checkout, but doesn't look useful for installer.
So I just add tkinter module to excludes in setup_msys2.py, so tcl & tk is not 
included in installer at all. My latest changes are here 
https://gitlab.gnome.org/galkinvv/meld/tree/meld-installer-build
(installer mostly works but code still a bit hard-to-mantain and history is bit 
hard-to-read)

>And you're saying Msys2 has leftovers between runs? I thought it started with 
>a fresh VM each time?

The entire VM is fresh, but there is a parameter in appveyor-msys2.yml
cache:
  - C:\meld-build-cache

It allows caching network data on appveyour instead of redownloading it every 
time.
The need to download is checked manually from meld/ci_helpers.py

In addition to "manual pinning" of msys packages this allows making *re*builds 
depending only on availability only of 2 servers (meld git, appveor ci) instead 
of 3 (meld git, appveor ci and msys2 repo).


> 
> -Keegan
> 

> On Sat, May 26, 2018 at 6:49 PM Kai Willadsen  wrote:
> 
>> On 19 May 2018 at 05:46, Vasily Galkin  wrote:
>>
>>> Hello again!
>>
>>> Due to recent pangocairo changes in mingw-msys2 meld 3-18 become 
>>> incompatible with it (even running from checkout).
>>
>> Honestly, I think it's unlikely that moving 3.18 to msys2 is worth it.
>>
>> The current Windows builds work (even if the pipeline doesn't _really_
>>
>> work for publishing them) and that's better than new issues from an
>>
>> msys2 change.
>>
>>> So I cherrypicked last changes Keegan Witt made for 3-18 (thanks!) changes 
>>> to new branch created from current master, fix pangocairo and make some 
>>> more adjustments:
>>
>>> - fixed paths to glib data installation
>>
>>> - XDG_DATA_DIR separator
>>
>>> - added caching of msys packages in appveyour data to achieve build 
>>> stability on rolling-release msys2
>>
>> I don't know much about msys2... does it not have a way of pinning
>>
>> package versions?
>>
>>> - remove libwebp (it looks unused?)
>>
>> It will just be there as a gdkpixbuf loader. We don't load webp
>>
>> images, but if in the future we e.g., added image diff or something,
>>
>> then we'd probably want to put it back.
>>
>>> - unified. renamed mingw64+32 scripts in single msys2 script
>>
>>>
>>
>>> The repo with scripts is here - 
>>> https://gitlab.gnome.org/galkinvv/meld/commits/65f5c2fe1d4564a40fb47247a996eff6417ff74d
>>
>>> (meld-installer-build branch)
>>
>>> The resulting installer is here:
>>
>>> https://ci.appveyor.com/project/galkinvv/meld-ljlj2/build/job/jja76xhc0qxdq461/artifacts
>>
>> Awesome! thanks. This looks like a huge step forward to me, and I'd be
>>
>> keen to merge it whenever you think it's ready. In fact, given that
>>
>> right now 3.19 doesn't work at all, I think we can be pretty generous
>>
>> with what "ready" means.
>>
>> It's also worth noting that it's *possible* that we might be able to
>>
>> do this building on the GNOME Gitlab instance in the future (instead
>>
>> of Appveyor). I don't think this changes anything about what you've
>>
>> written, since the steps will be 90% the same, and I would rather get
>>
>> something working now.
>>
>>> This installer installs meld master (3.19-based) and the resulting 
>>> installation behaviour is identical to meld executed from checkout on msys2:
>>
>>> - It mostly works if executed from cmd line with files arguments (works 80% 
>>> of time, but may crash or hang)
>>
>>> - for up-to-date msys2 version meld master has huge problems with 
>>> selection files via new tab page, at least on windows 7.
>>
>> Is the issue to do with Meld, or is it the file selector itself?
>>
>>> So it looks that installation build scripts themselves are mostly correct 
>>> and this version achieves basic windows compatibility for current master 
>>> with msys2.
>>
>>> The commit history of achieving this compatibility mostly contains 
>>> trial commits.
>>
>>> Should the commit history be included in merge request or 

Re: Update Windows binaries

[Kai Willadsen]

On 19 May 2018 at 05:46, Vasily Galkin  wrote:
> Hello again!
> Due to recent pangocairo changes in mingw-msys2 meld 3-18 become incompatible 
> with it (even running from checkout).

Honestly, I think it's unlikely that moving 3.18 to msys2 is worth it.
The current Windows builds work (even if the pipeline doesn't _really_
work for publishing them) and that's better than new issues from an
msys2 change.

> So I cherrypicked last changes Keegan Witt made for 3-18 (thanks!) changes to 
> new branch created from current master, fix pangocairo and make some more 
> adjustments:
>  - fixed paths to glib data installation
>  - XDG_DATA_DIR separator
>  - added caching of msys packages in appveyour data to achieve build 
> stability on rolling-release msys2

I don't know much about msys2... does it not have a way of pinning
package versions?

>  - remove libwebp (it looks unused?)

It will just be there as a gdkpixbuf loader. We don't load webp
images, but if in the future we e.g., added image diff or something,
then we'd probably want to put it back.

>  - unified. renamed mingw64+32 scripts in single msys2 script
>
> The repo with scripts is here - 
> https://gitlab.gnome.org/galkinvv/meld/commits/65f5c2fe1d4564a40fb47247a996eff6417ff74d
> (meld-installer-build branch)
> The resulting installer is here:
> https://ci.appveyor.com/project/galkinvv/meld-ljlj2/build/job/jja76xhc0qxdq461/artifacts

Awesome! thanks. This looks like a huge step forward to me, and I'd be
keen to merge it whenever you think it's ready. In fact, given that
right now 3.19 doesn't work at all, I think we can be pretty generous
with what "ready" means.

It's also worth noting that it's *possible* that we might be able to
do this building on the GNOME Gitlab instance in the future (instead
of Appveyor). I don't think this changes anything about what you've
written, since the steps will be 90% the same, and I would rather get
something working now.

> This installer installs meld master (3.19-based) and the resulting 
> installation behaviour is identical to meld executed from checkout on msys2:
>  - It mostly works if executed from cmd line with files arguments (works 80% 
> of time, but may crash or hang)
>  - for up-to-date msys2 version meld master has huge problems with 
> selection files via new tab page, at least on windows 7.

Is the issue to do with Meld, or is it the file selector itself?

> So it looks that installation build scripts themselves are mostly correct and 
> this version achieves basic windows compatibility for current master with 
> msys2.
> The commit history of achieving this compatibility mostly contains 
> trial commits.
> Should the commit history be included in merge request or squashed to single 
> commit describing ideas of most important changes?

I had a read through that branch, and while I think the commit history
+ messages could be cleaned up a bit (if you're comfortable with
interactive rebase) there's nothing wrong with having the full history
there. I'd probably prefer that to having a single squashed commit.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Update Windows binaries

[Vasily Galkin]

Hello again!
Due to recent pangocairo changes in mingw-msys2 meld 3-18 become incompatible 
with it (even running from checkout).
So I cherrypicked last changes Keegan Witt made for 3-18 (thanks!) changes to 
new branch created from current master, fix pangocairo and make some more 
adjustments:
 - fixed paths to glib data installation
 - XDG_DATA_DIR separator
 - added caching of msys packages in appveyour data to achieve build stability 
on rolling-release msys2
 - remove libwebp (it looks unused?)
 - unified. renamed mingw64+32 scripts in single msys2 script

The repo with scripts is here - 
https://gitlab.gnome.org/galkinvv/meld/commits/65f5c2fe1d4564a40fb47247a996eff6417ff74d
(meld-installer-build branch)
The resulting installer is here:
https://ci.appveyor.com/project/galkinvv/meld-ljlj2/build/job/jja76xhc0qxdq461/artifacts

This installer installs meld master (3.19-based) and the resulting installation 
behaviour is identical to meld executed from checkout on msys2:
 - It mostly works if executed from cmd line with files arguments (works 80% of 
time, but may crash or hang)
 - for up-to-date msys2 version meld master has huge problems with 
selection files via new tab page, at least on windows 7.

So it looks that installation build scripts themselves are mostly correct and 
this version achieves basic windows compatibility for current master with msys2.
The commit history of achieving this compatibility mostly contains trial 
commits.
Should the commit history be included in merge request or squashed to single 
commit describing ideas of most important changes?

Note for those reading this message in search of recent meld windows binaries: 
the installer linked above installs the very unstable combination of meld with 
recent msys2 (with known interoperability bugs).
There exists much more stable 3.18-based installer linked in 
https://mail.gnome.org/archives/meld-list/2018-April/msg00019.html

> Ah. Thanks Vasily! I pushed some more changes, both builds are producing an 
> msi now. Unfortunately, both are also still producing the error
>
> Microsoft Visual C++ Runtime Library
> Runtime Error!
> Program: C:Program Files (x86)MeldMeld.exe
> This application has requested the Runtime to terminate it in
> an unusual way
> Please contact the application's support team for more
> information.
>
> I'm wondering why I'm getting a Visual C++ error, if these are mingw. I think 
> I've still got some wires crossed somewhere.
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Update Windows binaries

[Keegan Witt]

Ah.  Thanks Vasily!  I pushed some more changes, both builds are producing
an msi now.  Unfortunately, both are also still producing the error

Microsoft Visual C++ Runtime Library
Runtime Error!
Program: C:Program Files (x86)MeldMeld.exe
This application has requested the Runtime to terminate it in
an unusual way
Please contact the application's support team for more
information.

I'm wondering why I'm getting a Visual C++ error, if these are mingw.  I
think I've still got some wires crossed somewhere.

On Mon, Apr 30, 2018 at 7:20 PM, Vasily Galkin  wrote:

> > I wasn't actually running the YAML. I exported the YAML then edited it
> to match what I was experimenting with in the UI (it seemed to ignore my
> YAML anyway -- even when I set the YAML name).
> I think that for building from gitlab it should be set not to file name
> but to full url: like https://gitlab.gnome.org/
> keeganwitt/meld/raw/meld-3-18-mingw/appveyor-mingw.yml
>
>
> > The error window says
> >
> > cx_Freeze: Python error in main script
> > Traceback (most recent call last):
> > File
> > C:Python34Wiblsite-packages ox Freeze initscriptsstartup
> > py", line 14, in run
> > File
> > C:Python34Viblsite-packages ax Freezeinitscripts Console.p
> > y, line 26, in run
> > File bin/meld, line 29, in 
> > File "C:Python34libimultiprocessingicontext.py, line 148, in
> > freezesupport
> > File 'C:\Python34\lib\multiprocessingspawn.ру", line 74, in
> > freeze support
> > File .C:\Python34\lib\multiprocessing\spawn.ру", line 106, in
> > spawnmain
> > File .C:\Python34\lib\multiprocessing\spawn.ру", line 119, in
> > main
> > File .C:\Python34\lib\multiprocessingprocess.ру", line 273, in
> > bootstrap
> > AttributeError: "NoneType object has no attribute 'flush
> > OK
> >
> > On Mon, Apr 30, 2018 at 6:00 PM, Vasily Galkin 
> wrote:
> >
> >>> I realize that, I just wasn't sure what components were associated
> with those DLLs as of when the setup script was created. I got it to build
> locally (though Meld exits with "application requested runtime to terminate
> in an unusual way" after it's installed. On Appveyor it still fails with
> "error: invalid command 'bdist_msi'" for some reason. I tossed what I have
> so far into https://gitlab.gnome.org/keeganwitt/meld/tree/meld-3-18-mingw.
> >>
> >> It looks that problem was in multiline & escaping syntax for yml
> >>
> >> (I haven't experience with publishing patch sets, so I created merge
> request as a representation of a patchset; sorry if it is inconvenient)
> >>
> >> https://gitlab.gnome.org/keeganwitt/meld/merge_requests/1
> >>
> >> After those modifications the bdist_msi command started (and failed for
> lacking some dlls, different for 32 and 64 bit case)
> >>
> >> https://ci.appveyor.com/project/galkinvv/meld-ljlj2/
> build/job/ocd53kml05yobxym
> >>
> >> https://ci.appveyor.com/project/galkinvv/meld-ljlj2/
> build/job/tqo4ht1m1ms4k569
> >>
> >>> On another topic: anybody else seeing this error when closing Meld
> built with the AIO setup (it only happens when the prompt asking whether
> you want to save the changes occurs)?
> >>
> >> Unfortunately I can't see the image - both in my mail client (web) and
> in meld list archives.
>
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Update Windows binaries

[Vasily Galkin]

> I wasn't actually running the YAML. I exported the YAML then edited it to 
> match what I was experimenting with in the UI (it seemed to ignore my YAML 
> anyway -- even when I set the YAML name).
I think that for building from gitlab it should be set not to file name but to 
full url: like 
https://gitlab.gnome.org/keeganwitt/meld/raw/meld-3-18-mingw/appveyor-mingw.yml


> The error window says
> 
> cx_Freeze: Python error in main script
> Traceback (most recent call last):
> File
> C:Python34Wiblsite-packages ox Freeze initscriptsstartup
> py", line 14, in run
> File
> C:Python34Viblsite-packages ax Freezeinitscripts Console.p
> y, line 26, in run
> File bin/meld, line 29, in 
> File "C:Python34libimultiprocessingicontext.py, line 148, in
> freezesupport
> File 'C:\Python34\lib\multiprocessingspawn.ру", line 74, in
> freeze support
> File .C:\Python34\lib\multiprocessing\spawn.ру", line 106, in
> spawnmain
> File .C:\Python34\lib\multiprocessing\spawn.ру", line 119, in
> main
> File .C:\Python34\lib\multiprocessingprocess.ру", line 273, in
> bootstrap
> AttributeError: "NoneType object has no attribute 'flush
> OK
> 
> On Mon, Apr 30, 2018 at 6:00 PM, Vasily Galkin  wrote:
> 
>>> I realize that, I just wasn't sure what components were associated with 
>>> those DLLs as of when the setup script was created. I got it to build 
>>> locally (though Meld exits with "application requested runtime to terminate 
>>> in an unusual way" after it's installed. On Appveyor it still fails with 
>>> "error: invalid command 'bdist_msi'" for some reason. I tossed what I have 
>>> so far into https://gitlab.gnome.org/keeganwitt/meld/tree/meld-3-18-mingw.
>>
>> It looks that problem was in multiline & escaping syntax for yml
>>
>> (I haven't experience with publishing patch sets, so I created merge request 
>> as a representation of a patchset; sorry if it is inconvenient)
>>
>> https://gitlab.gnome.org/keeganwitt/meld/merge_requests/1
>>
>> After those modifications the bdist_msi command started (and failed for 
>> lacking some dlls, different for 32 and 64 bit case)
>>
>> https://ci.appveyor.com/project/galkinvv/meld-ljlj2/build/job/ocd53kml05yobxym
>>
>> https://ci.appveyor.com/project/galkinvv/meld-ljlj2/build/job/tqo4ht1m1ms4k569
>>
>>> On another topic: anybody else seeing this error when closing Meld built 
>>> with the AIO setup (it only happens when the prompt asking whether you want 
>>> to save the changes occurs)?
>>
>> Unfortunately I can't see the image - both in my mail client (web) and in 
>> meld list archives.
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Update Windows binaries

[Keegan Witt]

I wasn't actually running the YAML.  I exported the YAML then edited it to
match what I was experimenting with in the UI (it seemed to ignore my YAML
anyway -- even when I set the YAML name).

The error window says
cx_Freeze: Python error in main script
Traceback (most recent call last):
File
C:Python34Wiblsite-packages ox Freeze initscriptsstartup
py", line 14, in run
File
C:Python34Viblsite-packages ax Freezeinitscripts Console.p
y, line 26, in run
File bin/meld, line 29, in 
File "C:Python34libimultiprocessingicontext.py
, line 148, in
freezesupport
File 'C:\Python34\lib\multiprocessingspawn.ру", line 74, in
freeze support
File .C:\Python34\lib\multiprocessing\spawn.ру", line 106, in
spawnmain
File .C:\Python34\lib\multiprocessing\spawn.ру", line 119, in
main
File .C:\Python34\lib\multiprocessingprocess.ру", line 273, in
bootstrap
AttributeError: "NoneType object has no attribute 'flush
OK

On Mon, Apr 30, 2018 at 6:00 PM, Vasily Galkin  wrote:

> > I realize that, I just wasn't sure what components were associated with
> those DLLs as of when the setup script was created. I got it to build
> locally (though Meld exits with "application requested runtime to terminate
> in an unusual way" after it's installed. On Appveyor it still fails with
> "error: invalid command 'bdist_msi'" for some reason. I tossed what I have
> so far into https://gitlab.gnome.org/keeganwitt/meld/tree/meld-3-18-mingw.
>
> It looks that problem was in multiline & escaping syntax for yml
> (I haven't experience with publishing patch sets, so I created merge
> request as a representation of a patchset; sorry if it is inconvenient)
> https://gitlab.gnome.org/keeganwitt/meld/merge_requests/1
>
>
> After those modifications the bdist_msi command started (and failed for
> lacking some dlls, different for 32 and 64 bit case)
> https://ci.appveyor.com/project/galkinvv/meld-ljlj2/
> build/job/ocd53kml05yobxym
> https://ci.appveyor.com/project/galkinvv/meld-ljlj2/
> build/job/tqo4ht1m1ms4k569
>
>
> > On another topic: anybody else seeing this error when closing Meld built
> with the AIO setup (it only happens when the prompt asking whether you want
> to save the changes occurs)?
> Unfortunately I can't see the image - both in my mail client (web) and in
> meld list archives.
>
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Update Windows binaries

[Vasily Galkin]

> I realize that, I just wasn't sure what components were associated with those 
> DLLs as of when the setup script was created. I got it to build locally 
> (though Meld exits with "application requested runtime to terminate in an 
> unusual way" after it's installed. On Appveyor it still fails with "error: 
> invalid command 'bdist_msi'" for some reason. I tossed what I have so far 
> into https://gitlab.gnome.org/keeganwitt/meld/tree/meld-3-18-mingw.

It looks that problem was in multiline & escaping syntax for yml
(I haven't experience with publishing patch sets, so I created merge request as 
a representation of a patchset; sorry if it is inconvenient)
https://gitlab.gnome.org/keeganwitt/meld/merge_requests/1


After those modifications the bdist_msi command started (and failed for lacking 
some dlls, different for 32 and 64 bit case)
https://ci.appveyor.com/project/galkinvv/meld-ljlj2/build/job/ocd53kml05yobxym
https://ci.appveyor.com/project/galkinvv/meld-ljlj2/build/job/tqo4ht1m1ms4k569


> On another topic: anybody else seeing this error when closing Meld built with 
> the AIO setup (it only happens when the prompt asking whether you want to 
> save the changes occurs)?
Unfortunately I can't see the image - both in my mail client (web) and in meld 
list archives.
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Update Windows binaries

[Keegan Witt]

I realize that, I just wasn't sure what components were associated with
those DLLs as of when the setup script was created.  I got it to build
locally (though Meld exits with "application requested runtime to terminate
in an unusual way" after it's installed.  On Appveyor it still fails with
"error: invalid command 'bdist_msi'" for some reason.  I tossed what I have
so far into https://gitlab.gnome.org/keeganwitt/meld/tree/meld-3-18-mingw.

On another topic: anybody else seeing this error when closing Meld built
with the AIO setup (it only happens when the prompt asking whether you want
to save the changes occurs)?

On Sun, Apr 29, 2018 at 9:22 PM, Vasily Galkin  wrote:

> As far as a remember the DLL list that is hard-coded into setup_win32.py
> is specific to gtk version/distribution
> since in fact it lists not only DLLs that meld loads via pygobject
> interface but all their dependencies too.
> For example list content changed (both additions and deletions) with last
> switch of gtk version - and chances are that for mingw64 version it'll
> change again.
>
> So from the msys's pacman point of view - if gtk, gtksourceview and
> pygobject packages are installed - all really needed DLLs are already
> inplace.
> And if meld starts locally with libzzz.dll and libxmlxpat.dll absent - it
> looks that they are not dependencies of this gtk version and can be just
> dropped from list.
>
> Instead some other Dlls may become needed.
>
> > I'm working on getting this running locally in MSYS2 now. It looks like
> the DLLs are in /mingw32/bin/ instead of Python's sites-packages directory.
> There's 2 DLLs I'm missing thoughlibzzz.dll
> > libxmlxpat.dll
> >
> > Do you know what these are? I'm having trouble finding the package that
> will install them.
> >
> > On Sat, Apr 28, 2018 at 11:21 PM, Keegan Witt 
> wrote:
> >
> >> Installing mingw-w64-i686-python3-cx_Freeze instead of installing
> through pip gets around the compilation problem, but then I again hit the
> >>
> >> error: invalid command 'bdist_msi'
> >>
> >> problem. I'm also wondering about the glib2-devel package. There's a
> msys2 package, but not a mingw32 or mingw64 packages.
> >>
> >> On Sat, Apr 28, 2018 at 10:43 PM, Keegan Witt 
> wrote:
> >>
> >>> It appears there's actually 3 different installations of Python 3 in
> MSYS2: mingw32 (/mingw32/bin/python3), mingw64 (/mingw64/bin/python3), and
> msys2 (/usr/bin/python3). To make sure we use the right version of Python,
> I set a MSYSTEM environment variable (I also tried with fully-qualified
> path to python3). I also tried with the 64 bit version instead of 32.
> >>>
> >>> version: 3.18.2.{build}
> >>>
> >>> branches:
> >>> only:
> >>> - meld-3-18
> >>> skip_non_tags: true
> >>> clone_depth: 1
> >>>
> >>> environment:
> >>> MSYSTEM: MINGW32
> >>> PATH: C:\msys64\mingw32\bin;C:\msys64\usr\bin;$(PATH)
> >>>
> >>> install:
> >>> - cmd: >-
> >>> bash -lc 'pacman --sync --refresh'
> >>> REM bash -lc 'pacman --noconfirm --sync --sysupgrade'
> >>>
> >>> bash -lc 'pacman --noconfirm --sync mingw-w64-i686-python3
> mingw-w64-i686-python3-pip mingw-w64-i686-gtk3
> mingw-w64-i686-gtksourceview3'
> >>> bash -lc 'pacman --noconfirm --sync glib2-devel'
> >>> bash -lc 'python3 -m pip install --upgrade pip'
> >>> bash -lc 'python3 -m pip install cx_Freeze'
> >>>
> >>> build_script:
> >>> - cmd: >-
> >>> bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && sed --in-place
> --regexp-extended "s/site.getsitepackages\(\)\[
> 1\]/site.getsitepackages()[-1]/" setup_win32.py'
> >>> bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && glib-compile-schemas data &&
> python3 setup_win32.py bdist_msi'
> >>>
> >>> artifacts:
> >>> - path: dist/*.msi
> >>> name: Meld installer
> >>>
> >>> The problem now is, I can't build cx_freeze
> >>>
> >>> C:\msys64\mingw32\bin/i686-w64-mingw32-gcc.exe -s
> build/temp.mingw-3.6/source/bases/Console.o 
> build/temp.mingw-3.6/source/bases/manifest.rc.o
> -LC:/msys64/mingw32/lib/python3.6/config-3.6m -LC:/msys64/mingw32/lib
> -limagehlp -lShlwapi -lpython3.6m -lversion -o
> build/lib.mingw-3.6/cx_Freeze/bases/Console.exe
> >>>
> >>> C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../
> ../../../i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-crt0_c.o):
> In function `main':
> >>>
> >>> C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crt0_c.c:18:
> undefined reference to `WinMain@16'
> >>>
> >>> collect2.exe: error: ld returned 1 exit status
> >>>
> >>> error: command 'C:\\msys64\\mingw32\\bin/i686-w64-mingw32-gcc.exe'
> failed with exit status 1
> >>>
> >>> 
> >>>
> >>> Command "C:/msys64/mingw32/bin/python3.exe -u -c "import setuptools,
> tokenize;__file__='C:/Users/appveyor/AppData/Local/Temp/1/
> pip-install-wytire78/cx-Freeze/setup.py';f=getattr(tokenize, 'open',
> open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install 

Re: Update Windows binaries

[Vasily Galkin]

As far as a remember the DLL list that is hard-coded into setup_win32.py is 
specific to gtk version/distribution
since in fact it lists not only DLLs that meld loads via pygobject interface 
but all their dependencies too.
For example list content changed (both additions and deletions) with last 
switch of gtk version - and chances are that for mingw64 version it'll change 
again.

So from the msys's pacman point of view - if gtk, gtksourceview and pygobject 
packages are installed - all really needed DLLs are already inplace.
And if meld starts locally with libzzz.dll and libxmlxpat.dll absent - it looks 
that they are not dependencies of this gtk version and can be just dropped from 
list.

Instead some other Dlls may become needed.

> I'm working on getting this running locally in MSYS2 now. It looks like the 
> DLLs are in /mingw32/bin/ instead of Python's sites-packages directory. 
> There's 2 DLLs I'm missing thoughlibzzz.dll
> libxmlxpat.dll
> 
> Do you know what these are? I'm having trouble finding the package that will 
> install them.
> 
> On Sat, Apr 28, 2018 at 11:21 PM, Keegan Witt  wrote:
> 
>> Installing mingw-w64-i686-python3-cx_Freeze instead of installing through 
>> pip gets around the compilation problem, but then I again hit the
>>
>> error: invalid command 'bdist_msi'
>>
>> problem. I'm also wondering about the glib2-devel package. There's a msys2 
>> package, but not a mingw32 or mingw64 packages.
>>
>> On Sat, Apr 28, 2018 at 10:43 PM, Keegan Witt  wrote:
>>
>>> It appears there's actually 3 different installations of Python 3 in MSYS2: 
>>> mingw32 (/mingw32/bin/python3), mingw64 (/mingw64/bin/python3), and msys2 
>>> (/usr/bin/python3). To make sure we use the right version of Python, I set 
>>> a MSYSTEM environment variable (I also tried with fully-qualified path to 
>>> python3). I also tried with the 64 bit version instead of 32.
>>>
>>> version: 3.18.2.{build}
>>>
>>> branches:
>>> only:
>>> - meld-3-18
>>> skip_non_tags: true
>>> clone_depth: 1
>>>
>>> environment:
>>> MSYSTEM: MINGW32
>>> PATH: C:\msys64\mingw32\bin;C:\msys64\usr\bin;$(PATH)
>>>
>>> install:
>>> - cmd: >-
>>> bash -lc 'pacman --sync --refresh'
>>> REM bash -lc 'pacman --noconfirm --sync --sysupgrade'
>>>
>>> bash -lc 'pacman --noconfirm --sync mingw-w64-i686-python3 
>>> mingw-w64-i686-python3-pip mingw-w64-i686-gtk3 
>>> mingw-w64-i686-gtksourceview3'
>>> bash -lc 'pacman --noconfirm --sync glib2-devel'
>>> bash -lc 'python3 -m pip install --upgrade pip'
>>> bash -lc 'python3 -m pip install cx_Freeze'
>>>
>>> build_script:
>>> - cmd: >-
>>> bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && sed --in-place --regexp-extended 
>>> "s/site.getsitepackages\(\)\[1\]/site.getsitepackages()[-1]/" 
>>> setup_win32.py'
>>> bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && glib-compile-schemas data && 
>>> python3 setup_win32.py bdist_msi'
>>>
>>> artifacts:
>>> - path: dist/*.msi
>>> name: Meld installer
>>>
>>> The problem now is, I can't build cx_freeze
>>>
>>> C:\msys64\mingw32\bin/i686-w64-mingw32-gcc.exe -s 
>>> build/temp.mingw-3.6/source/bases/Console.o 
>>> build/temp.mingw-3.6/source/bases/manifest.rc.o 
>>> -LC:/msys64/mingw32/lib/python3.6/config-3.6m -LC:/msys64/mingw32/lib 
>>> -limagehlp -lShlwapi -lpython3.6m -lversion -o 
>>> build/lib.mingw-3.6/cx_Freeze/bases/Console.exe
>>>
>>> C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-crt0_c.o):
>>>  In function `main':
>>>
>>> C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crt0_c.c:18: 
>>> undefined reference to `WinMain@16'
>>>
>>> collect2.exe: error: ld returned 1 exit status
>>>
>>> error: command 'C:\\msys64\\mingw32\\bin/i686-w64-mingw32-gcc.exe' failed 
>>> with exit status 1
>>>
>>> 
>>>
>>> Command "C:/msys64/mingw32/bin/python3.exe -u -c "import setuptools, 
>>> tokenize;__file__='C:/Users/appveyor/AppData/Local/Temp/1/pip-install-wytire78/cx-Freeze/setup.py';f=getattr(tokenize,
>>>  'open', open)(__file__);code=f.read().replace('\r\n', 
>>> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record 
>>> C:/Users/appveyor/AppData/Local/Temp/1/pip-record-0y2u7oho/install-record.txt
>>>  --single-version-externally-managed --compile" failed with error code 1 in 
>>> C:/Users/appveyor/AppData/Local/Temp/1/pip-install-wytire78/cx-Freeze/
>>>
>>> Command exited with code 1
>>>
>>> I think the gtk packages I was installing before weren't affecting the 
>>> version of Python I was invoking because it defaults to the msys2 
>>> installation, but the packages I was installing were for mingw (actually a 
>>> mix of both mingw32 and mingw64 the way I originally had it).
>>>
>>> On Sat, Apr 28, 2018 at 9:01 PM, Vasily Galkin  wrote:
>>>
 I tried again building without pywin32 and its definitely not required 
 while building with msvc-built python on 

Re: Update Windows binaries

[Keegan Witt]

I'm working on getting this running locally in MSYS2 now.  It looks like
the DLLs are in /mingw32/bin/ instead of Python's sites-packages
directory.  There's 2 DLLs I'm missing though
libzzz.dll
libxmlxpat.dll

Do you know what these are? I'm having trouble finding the package that
will install them.




On Sat, Apr 28, 2018 at 11:21 PM, Keegan Witt  wrote:

> Installing mingw-w64-i686-python3-cx_Freeze instead of installing through
> pip gets around the compilation problem, but then I again hit the
> error: invalid command 'bdist_msi'
>
> problem.  I'm also wondering about the glib2-devel package.  There's a
> msys2 package, but not a mingw32 or mingw64 packages.
>
> On Sat, Apr 28, 2018 at 10:43 PM, Keegan Witt 
> wrote:
>
>> It appears there's actually 3 different installations of Python 3 in
>> MSYS2: mingw32 (/mingw32/bin/python3), mingw64 (/mingw64/bin/python3), and
>> msys2 (/usr/bin/python3).  To make sure we use the right version of Python,
>> I set a MSYSTEM environment variable (I also tried with fully-qualified
>> path to python3).  I also tried with the 64 bit version instead of 32.
>>
>> version: 3.18.2.{build}
>>
>> branches:
>> only:
>> - meld-3-18
>> skip_non_tags: true
>> clone_depth: 1
>>
>> environment:
>> MSYSTEM: MINGW32
>> PATH: C:\msys64\mingw32\bin;C:\msys64\usr\bin;$(PATH)
>>
>> install:
>> - cmd: >-
>> bash -lc 'pacman --sync --refresh'
>> REM bash -lc 'pacman --noconfirm --sync --sysupgrade'
>> bash -lc 'pacman --noconfirm --sync mingw-w64-i686-python3
>> mingw-w64-i686-python3-pip mingw-w64-i686-gtk3
>> mingw-w64-i686-gtksourceview3'
>> bash -lc 'pacman --noconfirm --sync glib2-devel'
>> bash -lc 'python3 -m pip install --upgrade pip'
>> bash -lc 'python3 -m pip install cx_Freeze'
>>
>> build_script:
>> - cmd: >-
>> bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && sed --in-place
>> --regexp-extended "s/site.getsitepackages\(\)\[1
>> \]/site.getsitepackages()[-1]/" setup_win32.py'
>> bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && glib-compile-schemas data &&
>> python3 setup_win32.py bdist_msi'
>>
>> artifacts:
>> - path: dist/*.msi
>> name: Meld installer
>>
>> The problem now is, I can't build cx_freeze
>> C:\msys64\mingw32\bin/i686-w64-mingw32-gcc.exe -s
>> build/temp.mingw-3.6/source/bases/Console.o
>> build/temp.mingw-3.6/source/bases/manifest.rc.o
>> -LC:/msys64/mingw32/lib/python3.6/config-3.6m -LC:/msys64/mingw32/lib
>> -limagehlp -lShlwapi -lpython3.6m -lversion -o
>> build/lib.mingw-3.6/cx_Freeze/bases/Console.exe
>> C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../.
>> ./../../i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-crt0_c.o):
>> In function `main':
>> C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crt0_c.c:18:
>> undefined reference to `WinMain@16'
>> collect2.exe: error: ld returned 1 exit status
>> error: command 'C:\\msys64\\mingw32\\bin/i686-w64-mingw32-gcc.exe'
>> failed with exit status 1
>> 
>> Command "C:/msys64/mingw32/bin/python3.exe -u -c "import setuptools,
>> tokenize;__file__='C:/Users/appveyor/AppData/Local/Temp/1/pi
>> p-install-wytire78/cx-Freeze/setup.py';f=getattr(tokenize, 'open',
>> open)(__file__);code=f.read().replace('\r\n',
>> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
>> C:/Users/appveyor/AppData/Local/Temp/1/pip-record-0y2u7oho/install-record.txt
>> --single-version-externally-managed --compile" failed with error code 1
>> in C:/Users/appveyor/AppData/Local/Temp/1/pip-install-wytire78/cx-Freeze/
>> Command exited with code 1
>>
>> I think the gtk packages I was installing before weren't affecting the
>> version of Python I was invoking because it defaults to the msys2
>> installation, but the packages I was installing were for mingw (actually a
>> mix of both mingw32 and mingw64 the way I originally had it).
>>
>> On Sat, Apr 28, 2018 at 9:01 PM, Vasily Galkin 
>> wrote:
>>
>>> I tried again building without pywin32 and its definitely not required
>>> while building with msvc-built python on appveyour.
>>>
>>> There is only warning
>>> >running build_exe
>>> >creating directory build\exe.win32-3.4
>>> >copying C:\Python34\lib\site-packages\cx_Freeze\bases\Win32GUI.exe ->
>>> build\exe.win32-3.4\Meld.exe
>>> >copying C:\windows\SYSTEM32\python34.dll ->
>>> build\exe.win32-3.4\python34.dll
>>> >*** WARNING *** unable to create version resource
>>> >install pywin32 extensions first
>>> >writing zip file build\exe.win32-3.4\python34.zip
>>>
>>> The full log is available at (note, it's huge!)
>>> https://ci.appveyor.com/project/galkinvv/meld-ljlj2?fullLog=true
>>> (see below for yml file link).
>>>
>>> By the way, about direct building from gitlab - preclone red errors in
>>> the log above are caused by using "direct branch building" from Gnome gitlab
>>> that was done by setting the "Custom configuration .yml file name" to
>>> direct link
>>> 

Re: Update Windows binaries

[Keegan Witt]

Installing mingw-w64-i686-python3-cx_Freeze instead of installing through
pip gets around the compilation problem, but then I again hit the
error: invalid command 'bdist_msi'

problem.  I'm also wondering about the glib2-devel package.  There's a
msys2 package, but not a mingw32 or mingw64 packages.

On Sat, Apr 28, 2018 at 10:43 PM, Keegan Witt  wrote:

> It appears there's actually 3 different installations of Python 3 in
> MSYS2: mingw32 (/mingw32/bin/python3), mingw64 (/mingw64/bin/python3), and
> msys2 (/usr/bin/python3).  To make sure we use the right version of Python,
> I set a MSYSTEM environment variable (I also tried with fully-qualified
> path to python3).  I also tried with the 64 bit version instead of 32.
>
> version: 3.18.2.{build}
>
> branches:
> only:
> - meld-3-18
> skip_non_tags: true
> clone_depth: 1
>
> environment:
> MSYSTEM: MINGW32
> PATH: C:\msys64\mingw32\bin;C:\msys64\usr\bin;$(PATH)
>
> install:
> - cmd: >-
> bash -lc 'pacman --sync --refresh'
> REM bash -lc 'pacman --noconfirm --sync --sysupgrade'
> bash -lc 'pacman --noconfirm --sync mingw-w64-i686-python3
> mingw-w64-i686-python3-pip mingw-w64-i686-gtk3
> mingw-w64-i686-gtksourceview3'
> bash -lc 'pacman --noconfirm --sync glib2-devel'
> bash -lc 'python3 -m pip install --upgrade pip'
> bash -lc 'python3 -m pip install cx_Freeze'
>
> build_script:
> - cmd: >-
> bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && sed --in-place --regexp-extended
> "s/site.getsitepackages\(\)\[1\]/site.getsitepackages()[-1]/"
> setup_win32.py'
> bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && glib-compile-schemas data &&
> python3 setup_win32.py bdist_msi'
>
> artifacts:
> - path: dist/*.msi
> name: Meld installer
>
> The problem now is, I can't build cx_freeze
> C:\msys64\mingw32\bin/i686-w64-mingw32-gcc.exe -s
> build/temp.mingw-3.6/source/bases/Console.o 
> build/temp.mingw-3.6/source/bases/manifest.rc.o
> -LC:/msys64/mingw32/lib/python3.6/config-3.6m -LC:/msys64/mingw32/lib
> -limagehlp -lShlwapi -lpython3.6m -lversion -o
> build/lib.mingw-3.6/cx_Freeze/bases/Console.exe
> C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../
> ../../../i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-crt0_c.o):
> In function `main':
> C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crt0_c.c:18:
> undefined reference to `WinMain@16'
> collect2.exe: error: ld returned 1 exit status
> error: command 'C:\\msys64\\mingw32\\bin/i686-w64-mingw32-gcc.exe' failed
> with exit status 1
> 
> Command "C:/msys64/mingw32/bin/python3.exe -u -c "import setuptools,
> tokenize;__file__='C:/Users/appveyor/AppData/Local/Temp/1/
> pip-install-wytire78/cx-Freeze/setup.py';f=getattr(tokenize, 'open',
> open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
> C:/Users/appveyor/AppData/Local/Temp/1/pip-record-0y2u7oho/install-record.txt
> --single-version-externally-managed --compile" failed with error code 1
> in C:/Users/appveyor/AppData/Local/Temp/1/pip-install-wytire78/cx-Freeze/
> Command exited with code 1
>
> I think the gtk packages I was installing before weren't affecting the
> version of Python I was invoking because it defaults to the msys2
> installation, but the packages I was installing were for mingw (actually a
> mix of both mingw32 and mingw64 the way I originally had it).
>
> On Sat, Apr 28, 2018 at 9:01 PM, Vasily Galkin 
> wrote:
>
>> I tried again building without pywin32 and its definitely not required
>> while building with msvc-built python on appveyour.
>>
>> There is only warning
>> >running build_exe
>> >creating directory build\exe.win32-3.4
>> >copying C:\Python34\lib\site-packages\cx_Freeze\bases\Win32GUI.exe ->
>> build\exe.win32-3.4\Meld.exe
>> >copying C:\windows\SYSTEM32\python34.dll ->
>> build\exe.win32-3.4\python34.dll
>> >*** WARNING *** unable to create version resource
>> >install pywin32 extensions first
>> >writing zip file build\exe.win32-3.4\python34.zip
>>
>> The full log is available at (note, it's huge!)
>> https://ci.appveyor.com/project/galkinvv/meld-ljlj2?fullLog=true
>> (see below for yml file link).
>>
>> By the way, about direct building from gitlab - preclone red errors in
>> the log above are caused by using "direct branch building" from Gnome gitlab
>> that was done by setting the "Custom configuration .yml file name" to
>> direct link
>> https://gitlab.gnome.org/galkinvv/meld/raw/meld-3-18-appveyo
>> ur-experiments/appveyor.yml
>>
>> So there is at least two minor issues with direct building from Gnome
>> gitlab with current appveyor:
>> -build versioning issue (Preclone red error)
>> -and explicit branch setting in path to appveyour.yml
>>
>> I didn't test automated building on commit.
>>
>> > Are you sure
>> >
>> > pywin32 isn't required? When I edited the site-packages list, it
>> wouldn't let me run the bdist_msi command
>> >
>> > bash -lc 'cd 

Re: Update Windows binaries

[Keegan Witt]

It appears there's actually 3 different installations of Python 3 in MSYS2:
mingw32 (/mingw32/bin/python3), mingw64 (/mingw64/bin/python3), and msys2
(/usr/bin/python3).  To make sure we use the right version of Python, I set
a MSYSTEM environment variable (I also tried with fully-qualified path to
python3).  I also tried with the 64 bit version instead of 32.

version: 3.18.2.{build}

branches:
only:
- meld-3-18
skip_non_tags: true
clone_depth: 1

environment:
MSYSTEM: MINGW32
PATH: C:\msys64\mingw32\bin;C:\msys64\usr\bin;$(PATH)

install:
- cmd: >-
bash -lc 'pacman --sync --refresh'
REM bash -lc 'pacman --noconfirm --sync --sysupgrade'
bash -lc 'pacman --noconfirm --sync mingw-w64-i686-python3
mingw-w64-i686-python3-pip mingw-w64-i686-gtk3
mingw-w64-i686-gtksourceview3'
bash -lc 'pacman --noconfirm --sync glib2-devel'
bash -lc 'python3 -m pip install --upgrade pip'
bash -lc 'python3 -m pip install cx_Freeze'

build_script:
- cmd: >-
bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && sed --in-place --regexp-extended
"s/site.getsitepackages\(\)\[1\]/site.getsitepackages()[-1]/"
setup_win32.py'
bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && glib-compile-schemas data &&
python3 setup_win32.py bdist_msi'

artifacts:
- path: dist/*.msi
name: Meld installer

The problem now is, I can't build cx_freeze
C:\msys64\mingw32\bin/i686-w64-mingw32-gcc.exe -s
build/temp.mingw-3.6/source/bases/Console.o
build/temp.mingw-3.6/source/bases/manifest.rc.o
-LC:/msys64/mingw32/lib/python3.6/config-3.6m -LC:/msys64/mingw32/lib
-limagehlp -lShlwapi -lpython3.6m -lversion -o
build/lib.mingw-3.6/cx_Freeze/bases/Console.exe
C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-crt0_c.o):
In function `main':
C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crt0_c.c:18:
undefined reference to `WinMain@16'
collect2.exe: error: ld returned 1 exit status
error: command 'C:\\msys64\\mingw32\\bin/i686-w64-mingw32-gcc.exe' failed
with exit status 1

Command "C:/msys64/mingw32/bin/python3.exe -u -c "import setuptools,
tokenize;__file__='C:/Users/appveyor/AppData/Local/Temp/1/pip-install-wytire78/cx-Freeze/setup.py';f=getattr(tokenize,
'open', open)(__file__);code=f.read().replace('\r\n',
'\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
C:/Users/appveyor/AppData/Local/Temp/1/pip-record-0y2u7oho/install-record.txt
--single-version-externally-managed --compile" failed with error code 1 in
C:/Users/appveyor/AppData/Local/Temp/1/pip-install-wytire78/cx-Freeze/
Command exited with code 1

I think the gtk packages I was installing before weren't affecting the
version of Python I was invoking because it defaults to the msys2
installation, but the packages I was installing were for mingw (actually a
mix of both mingw32 and mingw64 the way I originally had it).

On Sat, Apr 28, 2018 at 9:01 PM, Vasily Galkin  wrote:

> I tried again building without pywin32 and its definitely not required
> while building with msvc-built python on appveyour.
>
> There is only warning
> >running build_exe
> >creating directory build\exe.win32-3.4
> >copying C:\Python34\lib\site-packages\cx_Freeze\bases\Win32GUI.exe ->
> build\exe.win32-3.4\Meld.exe
> >copying C:\windows\SYSTEM32\python34.dll -> build\exe.win32-3.4\python34.
> dll
> >*** WARNING *** unable to create version resource
> >install pywin32 extensions first
> >writing zip file build\exe.win32-3.4\python34.zip
>
> The full log is available at (note, it's huge!) https://ci.appveyor.com/
> project/galkinvv/meld-ljlj2?fullLog=true
> (see below for yml file link).
>
> By the way, about direct building from gitlab - preclone red errors in the
> log above are caused by using "direct branch building" from Gnome gitlab
> that was done by setting the "Custom configuration .yml file name" to
> direct link
> https://gitlab.gnome.org/galkinvv/meld/raw/meld-3-18-
> appveyour-experiments/appveyor.yml
>
> So there is at least two minor issues with direct building from Gnome
> gitlab with current appveyor:
> -build versioning issue (Preclone red error)
> -and explicit branch setting in path to appveyour.yml
>
> I didn't test automated building on commit.
>
> > Are you sure
> >
> > pywin32 isn't required? When I edited the site-packages list, it
> wouldn't let me run the bdist_msi command
> >
> > bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && sed --in-place
> --regexp-extended "s/site.getsitepackages\(\)\[
> 1\]/site.getsitepackages()[-1]/" setup_win32.py'
> >
> > bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && glib-compile-schemas data &&
> python3 setup_win32.py bdist_msi'
> >
> > usage: setup_win32.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts]
> ...]
> >
> > or: setup_win32.py --help [cmd1 cmd2 ...]
> >
> > or: setup_win32.py --help-commands
> >
> > or: setup_win32.py cmd --help
> >
> > error: invalid command 'bdist_msi'
> >
> > On Sat, Apr 28, 2018 at 4:06 PM, Vasily Galkin 

Re: Update Windows binaries

[Vasily Galkin]

I tried again building without pywin32 and its definitely not required while 
building with msvc-built python on appveyour.

There is only warning
>running build_exe
>creating directory build\exe.win32-3.4
>copying C:\Python34\lib\site-packages\cx_Freeze\bases\Win32GUI.exe -> 
>build\exe.win32-3.4\Meld.exe
>copying C:\windows\SYSTEM32\python34.dll -> build\exe.win32-3.4\python34.dll
>*** WARNING *** unable to create version resource
>install pywin32 extensions first
>writing zip file build\exe.win32-3.4\python34.zip

The full log is available at (note, it's huge!) 
https://ci.appveyor.com/project/galkinvv/meld-ljlj2?fullLog=true
(see below for yml file link).

By the way, about direct building from gitlab - preclone red errors in the log 
above are caused by using "direct branch building" from Gnome gitlab
that was done by setting the "Custom configuration .yml file name" to direct 
link
https://gitlab.gnome.org/galkinvv/meld/raw/meld-3-18-appveyour-experiments/appveyor.yml

So there is at least two minor issues with direct building from Gnome gitlab 
with current appveyor: 
-build versioning issue (Preclone red error)
-and explicit branch setting in path to appveyour.yml

I didn't test automated building on commit.

> Are you sure
> 
> pywin32 isn't required? When I edited the site-packages list, it wouldn't let 
> me run the bdist_msi command
> 
> bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && sed --in-place --regexp-extended 
> "s/site.getsitepackages\(\)\[1\]/site.getsitepackages()[-1]/" setup_win32.py'
> 
> bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && glib-compile-schemas data && 
> python3 setup_win32.py bdist_msi'
> 
> usage: setup_win32.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
> 
> or: setup_win32.py --help [cmd1 cmd2 ...]
> 
> or: setup_win32.py --help-commands
> 
> or: setup_win32.py cmd --help
> 
> error: invalid command 'bdist_msi'
> 
> On Sat, Apr 28, 2018 at 4:06 PM, Vasily Galkin  wrote:
> 
>>> Once I take out pypiwin32, then I run into the same issue as reported in 
>>> the "Building MSI package under MSYS" thread
>>
>>> bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && glib-compile-schemas data && 
>>> python3 setup_win32.py bdist_msi'
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Update Windows binaries

[Kai Willadsen]

On 29 April 2018 at 05:19, Keegan Witt  wrote:
> I'm having trouble getting pywin32 installed in MSYS2.  When I try to
> install with pip, I get errors
> $ python3 -m pip install pypiwin32==219
> Collecting pypiwin32==219
>   Using cached
> https://files.pythonhosted.org/packages/2b/ca/5c086c18de8f70222787b3e824e755b68d99272531522e77bb381d4f60c8/pypiwin32-219.zip
> Complete output from command python setup.py egg_info:
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/tmp/pip-install-d9xe2c9w/pypiwin32/setup.py", line 121
> print "Building pywin32", pywin32_version
>^
> SyntaxError: Missing parentheses in call to 'print'
>
> 
> Command "python setup.py egg_info" failed with error code 1 in
> /tmp/pip-install-d9xe2c9w/pypiwin32/
>
> $ python3 -m pip install pypiwin32==223
> Collecting pypiwin32==223
>   Using cached
> https://files.pythonhosted.org/packages/d0/1b/2f292bbd742e369a100c91faa0483172cd91a1a422a6692055ac920946c5/pypiwin32-223-py3-none-any.whl
> Collecting pywin32>=223 (from pypiwin32==223)
>   Could not find a version that satisfies the requirement pywin32>=223 (from
> pypiwin32==223) (from versions: )
> No matching distribution found for pywin32>=223 (from pypiwin32==223)

I'm not actually sure, but I notice that you're installing pypiwin32,
not pywin32. Both exist, and pypiwin32 seems to be a partial alias of
pywin32? but only pywin32 has actual platform-specific wheels.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Update Windows binaries

[Kai Willadsen]

On 29 April 2018 at 05:51, Keegan Witt  wrote:
> Kai,
> Maybe we could change that line to get the element that has "site-packages"
> in it?

Seems reasonable! I just pushed this to master.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Update Windows binaries

[Keegan Witt]

Are you sure pywin32 isn't required?  When I edited the site-packages list,
it wouldn't let me run the bdist_msi command

bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && sed --in-place --regexp-extended
"s/site.getsitepackages\(\)\[1\]/site.getsitepackages()[-1]/"
setup_win32.py'
bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && glib-compile-schemas data &&
python3 setup_win32.py bdist_msi'
usage: setup_win32.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
or: setup_win32.py --help [cmd1 cmd2 ...]
or: setup_win32.py --help-commands
or: setup_win32.py cmd --help
error: invalid command 'bdist_msi'

On Sat, Apr 28, 2018 at 4:06 PM, Vasily Galkin  wrote:

> > Once I take out pypiwin32, then I run into the same issue as reported in
> the "Building MSI package under MSYS" thread
> > bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && glib-compile-schemas data &&
> python3 setup_win32.py bdist_msi'
> >
> > Traceback (most recent call last):
> >
> > File "setup_win32.py", line 12, in 
> >
> > site_dir = site.getsitepackages()[1]
> >
> > IndexError: list index out of range
> >
> > Command exited with code 1
> >
> > This is because in the MSYS2 environment, there's only 1 thing in the
> list
> >
>  import site
> >
>  site.getsitepackages()
> > ['/usr/lib/python3.6/site-packages']
> > Whereas on Windows, there's 2
> >
>  import site
> >
>  site.getsitepackages()
> > ['C:\\Python36', 'C:\\Python36\\lib\\site-packages']
> >
> > Vasily,
> > Did you edit setup_win32.py to build on MSYS2?
>
> Unfortunately, no - I never completed installer build on MSYS2. All my
> MSYS2 test and usage are running meld from checkout.
>
> Msys2 project itself has some scripts for building meld package -
> https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-meld3
>
> But they use patched setup.py, not setup_win32.py (and of course don't
> package msi installer).
>
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Update Windows binaries

[Vasily Galkin]

> Once I take out pypiwin32, then I run into the same issue as reported in the 
> "Building MSI package under MSYS" thread
> bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && glib-compile-schemas data && 
> python3 setup_win32.py bdist_msi'
> 
> Traceback (most recent call last):
> 
> File "setup_win32.py", line 12, in 
> 
> site_dir = site.getsitepackages()[1]
> 
> IndexError: list index out of range
> 
> Command exited with code 1
> 
> This is because in the MSYS2 environment, there's only 1 thing in the list
> 
 import site
> 
 site.getsitepackages()
> ['/usr/lib/python3.6/site-packages']
> Whereas on Windows, there's 2
> 
 import site
> 
 site.getsitepackages()
> ['C:\\Python36', 'C:\\Python36\\lib\\site-packages']
> 
> Vasily,
> Did you edit setup_win32.py to build on MSYS2?

Unfortunately, no - I never completed installer build on MSYS2. All my MSYS2 
test and usage are running meld from checkout.

Msys2 project itself has some scripts for building meld package - 
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-meld3

But they use patched setup.py, not setup_win32.py (and of course don't package 
msi installer).
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Update Windows binaries

[Keegan Witt]

Kai,
Or I guess even simpler, just get the last element.

On Sat, Apr 28, 2018 at 3:51 PM, Keegan Witt  wrote:

> Once I take out pypiwin32, then I run into the same issue as reported in
> the "Building MSI package under MSYS" thread
> bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && glib-compile-schemas data &&
> python3 setup_win32.py bdist_msi'
> Traceback (most recent call last):
> File "setup_win32.py", line 12, in 
> site_dir = site.getsitepackages()[1]
> IndexError: list index out of range
> Command exited with code 1
>
> This is because in the MSYS2 environment, there's only 1 thing in the list
> >>> import site
> >>> site.getsitepackages()
> ['/usr/lib/python3.6/site-packages']
> Whereas on Windows, there's 2
> >>> import site
> >>> site.getsitepackages()
> ['C:\\Python36', 'C:\\Python36\\lib\\site-packages']
>
> Vasily,
> Did you edit setup_win32.py to build on MSYS2?
>
> Kai,
> Maybe we could change that line to get the element that has
> "site-packages" in it?
>
> On Sat, Apr 28, 2018 at 3:38 PM, Keegan Witt  wrote:
>
>> Thanks Vasily.
>>
>> I did have one more thing I tried
>> $ wget --no-verbose https://files.pythonhosted.org
>> /packages/d0/f7/56e35902d32299020cf9136264ca102ff0b03c055562
>> 1b469c825bc10d08/pypiwin32-220-cp36-none-win_amd64.whl && python3 -m pip
>> install pypiwin32-220-cp36-none-win_amd64.whl
>> pypiwin32-220-cp36-none-win_amd64.whl is not a supported wheel on this
>> platform.
>>
>> I tried the 32 bit version too.  Python version is 3.6.2, so I'm not sure
>> why it won't let me use that wheel.
>>
>> On Sat, Apr 28, 2018 at 3:34 PM, Vasily Galkin 
>> wrote:
>>
>>> I'm very sorry by not mentioning this earlier but pywin32 is NOT hard
>>> dependency for building meld installer, it's an *optional* dependency of
>>> cxFreeze.
>>> In the pygobject-win32 build it is only used for writing version info
>>> into exe file headers, which is useful, but not required at all.
>>>
>>> So building installer without it would be quite fine!
>>>
>>> The bad thing about msys2 - is the random-hangs bug
>>> https://gitlab.gnome.org/GNOME/meld/issues/174
>>>
>>> > Oh, one last thing I forgot to mention is that there's currently no
>>> package for pywin32 in the MSYS2 repos either.
>>> >
>>> > On Sat, Apr 28, 2018 at 3:19 PM, Keegan Witt 
>>> wrote:
>>> >
>>> >> I'm having trouble getting pywin32 installed in MSYS2. When I try to
>>> install with pip, I get errors$ python3 -m pip install pypiwin32==219
>>> >> Collecting pypiwin32==219
>>> >> Using cached https://files.pythonhosted.org
>>> /packages/2b/ca/5c086c18de8f70222787b3e824e755b68d9927253152
>>> 2e77bb381d4f60c8/pypiwin32-219.zip
>>> >> Complete output from command python setup.py egg_info:
>>> >> Traceback (most recent call last):
>>> >> File "", line 1, in 
>>> >> File "/tmp/pip-install-d9xe2c9w/pypiwin32/setup.py", line 121
>>> >> print "Building pywin32", pywin32_version
>>> >> ^
>>> >> SyntaxError: Missing parentheses in call to 'print'
>>> >>
>>> >> 
>>> >> Command "python setup.py egg_info" failed with error code 1 in
>>> /tmp/pip-install-d9xe2c9w/pypiwin32/
>>> >>
>>> >> $ python3 -m pip install pypiwin32==223
>>> >>
>>> >> Collecting pypiwin32==223
>>> >> Using cached https://files.pythonhosted.org
>>> /packages/d0/1b/2f292bbd742e369a100c91faa0483172cd91a1a422a6
>>> 692055ac920946c5/pypiwin32-223-py3-none-any.whl
>>> >> Collecting pywin32>=223 (from pypiwin32==223)
>>> >> Could not find a version that satisfies the requirement pywin32>=223
>>> (from pypiwin32==223) (from versions: )
>>> >> No matching distribution found for pywin32>=223 (from pypiwin32==223)
>>> >>
>>> >> Downloading and installing outside pip isn't an option because
>>> distutils doesn't support silent installs (https://github.com/mhammond/p
>>> ywin32/issues/845). If you run the command locally, you can see it pops
>>> up the GUI installer.
>>> >> $ wget --no-verbose --output-document=pywin32.exe
>>> https://github.com/mhammond/pywin32/releases/download/b223/p
>>> ywin32-223.win-amd64-py3.6.exe && ./pywin32.exe && rm pywin32.exe
>>> >>
>>> >> We could try compiling pywin32 from source, but it looks like it
>>> might be complicated.
>>> >>
>>> >> On Wed, Mar 28, 2018 at 12:54 AM, Keegan Witt 
>>> wrote:
>>> >>
>>> >>> When I do python --version, I get "Python 3.6.2" (and that's the
>>> version I see pacman downloaded). I think maybe the AIO installer is
>>> installing some stuff I don't have in pacman yet.
>>> >>>
>>> >>> On Tue, Mar 27, 2018 at 5:30 PM Kai Willadsen <
>>> kai.willad...@gmail.com> wrote:
>>> >>>
>>>  Probably not super-helpful, but I notice that you're just using
>>> 
>>>  `python` there, which seems to be defaulting to Python 2.7, whereas
>>> we
>>> 
>>>  definitely want 3.x for current Meld.
>>> 
>>>  Either way, I'm really happy for others to be looking at this.
>>> 
>>> 

Re: Update Windows binaries

[Keegan Witt]

Once I take out pypiwin32, then I run into the same issue as reported in
the "Building MSI package under MSYS" thread
bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && glib-compile-schemas data &&
python3 setup_win32.py bdist_msi'
Traceback (most recent call last):
File "setup_win32.py", line 12, in 
site_dir = site.getsitepackages()[1]
IndexError: list index out of range
Command exited with code 1

This is because in the MSYS2 environment, there's only 1 thing in the list
>>> import site
>>> site.getsitepackages()
['/usr/lib/python3.6/site-packages']
Whereas on Windows, there's 2
>>> import site
>>> site.getsitepackages()
['C:\\Python36', 'C:\\Python36\\lib\\site-packages']

Vasily,
Did you edit setup_win32.py to build on MSYS2?

Kai,
Maybe we could change that line to get the element that has "site-packages"
in it?

On Sat, Apr 28, 2018 at 3:38 PM, Keegan Witt  wrote:

> Thanks Vasily.
>
> I did have one more thing I tried
> $ wget --no-verbose https://files.pythonhosted.org/packages/d0/f7/
> 56e35902d32299020cf9136264ca102ff0b03c0555621b469c825bc10d08
> /pypiwin32-220-cp36-none-win_amd64.whl && python3 -m pip install
> pypiwin32-220-cp36-none-win_amd64.whl
> pypiwin32-220-cp36-none-win_amd64.whl is not a supported wheel on this
> platform.
>
> I tried the 32 bit version too.  Python version is 3.6.2, so I'm not sure
> why it won't let me use that wheel.
>
> On Sat, Apr 28, 2018 at 3:34 PM, Vasily Galkin 
> wrote:
>
>> I'm very sorry by not mentioning this earlier but pywin32 is NOT hard
>> dependency for building meld installer, it's an *optional* dependency of
>> cxFreeze.
>> In the pygobject-win32 build it is only used for writing version info
>> into exe file headers, which is useful, but not required at all.
>>
>> So building installer without it would be quite fine!
>>
>> The bad thing about msys2 - is the random-hangs bug
>> https://gitlab.gnome.org/GNOME/meld/issues/174
>>
>> > Oh, one last thing I forgot to mention is that there's currently no
>> package for pywin32 in the MSYS2 repos either.
>> >
>> > On Sat, Apr 28, 2018 at 3:19 PM, Keegan Witt 
>> wrote:
>> >
>> >> I'm having trouble getting pywin32 installed in MSYS2. When I try to
>> install with pip, I get errors$ python3 -m pip install pypiwin32==219
>> >> Collecting pypiwin32==219
>> >> Using cached https://files.pythonhosted.org
>> /packages/2b/ca/5c086c18de8f70222787b3e824e755b68d9927253152
>> 2e77bb381d4f60c8/pypiwin32-219.zip
>> >> Complete output from command python setup.py egg_info:
>> >> Traceback (most recent call last):
>> >> File "", line 1, in 
>> >> File "/tmp/pip-install-d9xe2c9w/pypiwin32/setup.py", line 121
>> >> print "Building pywin32", pywin32_version
>> >> ^
>> >> SyntaxError: Missing parentheses in call to 'print'
>> >>
>> >> 
>> >> Command "python setup.py egg_info" failed with error code 1 in
>> /tmp/pip-install-d9xe2c9w/pypiwin32/
>> >>
>> >> $ python3 -m pip install pypiwin32==223
>> >>
>> >> Collecting pypiwin32==223
>> >> Using cached https://files.pythonhosted.org
>> /packages/d0/1b/2f292bbd742e369a100c91faa0483172cd91a1a422a6
>> 692055ac920946c5/pypiwin32-223-py3-none-any.whl
>> >> Collecting pywin32>=223 (from pypiwin32==223)
>> >> Could not find a version that satisfies the requirement pywin32>=223
>> (from pypiwin32==223) (from versions: )
>> >> No matching distribution found for pywin32>=223 (from pypiwin32==223)
>> >>
>> >> Downloading and installing outside pip isn't an option because
>> distutils doesn't support silent installs (https://github.com/mhammond/p
>> ywin32/issues/845). If you run the command locally, you can see it pops
>> up the GUI installer.
>> >> $ wget --no-verbose --output-document=pywin32.exe
>> https://github.com/mhammond/pywin32/releases/download/b223/
>> pywin32-223.win-amd64-py3.6.exe && ./pywin32.exe && rm pywin32.exe
>> >>
>> >> We could try compiling pywin32 from source, but it looks like it might
>> be complicated.
>> >>
>> >> On Wed, Mar 28, 2018 at 12:54 AM, Keegan Witt 
>> wrote:
>> >>
>> >>> When I do python --version, I get "Python 3.6.2" (and that's the
>> version I see pacman downloaded). I think maybe the AIO installer is
>> installing some stuff I don't have in pacman yet.
>> >>>
>> >>> On Tue, Mar 27, 2018 at 5:30 PM Kai Willadsen <
>> kai.willad...@gmail.com> wrote:
>> >>>
>>  Probably not super-helpful, but I notice that you're just using
>> 
>>  `python` there, which seems to be defaulting to Python 2.7, whereas
>> we
>> 
>>  definitely want 3.x for current Meld.
>> 
>>  Either way, I'm really happy for others to be looking at this.
>> 
>>  On 27 March 2018 at 15:16, Keegan Witt  wrote:
>> 
>> > I've started work on a pipeline for msys2 here (but it's not
>> working yet):
>> 
>> > https://ci.appveyor.com/project/keeganwitt/meld-q7ht3. I dunno if
>> folks are
>> 
>> 

Re: Update Windows binaries (no pywin32 sub-problem)

[Vasily Galkin]

As far as I remember my thoughts about pywin32 on msys after reading 
https://github.com/Alexpux/MINGW-packages/issues/751
shows that "it is not ready for msys".

Root of a problem is in a fact that pywin32 source code contains some 
visual-studio-specific parts and can't be compiled with mingw.
And visual studio build uses malloc/free from library that is used by visual 
studio (ucrtbase.dll i think). The version stored in pip repo is or official 
python for windows binary (which is compiled by VS2015).

But mingws' python is compiled with mingw and uses malloc/free from 
corresponding library (msvcrt.dll i think).

So I'm not sure there is simple way to use pywin32 with mingw64's python 
without changing pywin32 source code.
--
Vasily

> Thanks Vasily.
> 
> I did have one more thing I tried
> $ wget --no-verbose 
> https://files.pythonhosted.org/packages/d0/f7/56e35902d32299020cf9136264ca102ff0b03c0555621b469c825bc10d08/pypiwin32-220-cp36-none-win_amd64.whl
>  && python3 -m pip install pypiwin32-220-cp36-none-win_amd64.whl
> pypiwin32-220-cp36-none-win_amd64.whl is not a supported wheel on this 
> platform.
> 
> I tried the 32 bit version too. Python version is 3.6.2, so I'm not sure why 
> it won't let me use that wheel.
> 
> On Sat, Apr 28, 2018 at 3:34 PM, Vasily Galkin  wrote:
> 
>> I'm very sorry by not mentioning this earlier but pywin32 is NOT hard 
>> dependency for building meld installer, it's an *optional* dependency of 
>> cxFreeze.
>>
>> In the pygobject-win32 build it is only used for writing version info into 
>> exe file headers, which is useful, but not required at all.
>>
>> So building installer without it would be quite fine!
>>
>> The bad thing about msys2 - is the random-hangs bug 
>> https://gitlab.gnome.org/GNOME/meld/issues/174
>>
>>> Oh, one last thing I forgot to mention is that there's currently no package 
>>> for pywin32 in the MSYS2 repos either.
>>
>>>
>>
>>> On Sat, Apr 28, 2018 at 3:19 PM, Keegan Witt  wrote:
>>
>>>
>>
 I'm having trouble getting pywin32 installed in MSYS2. When I try to 
 install with pip, I get errors$ python3 -m pip install pypiwin32==219
>>
 Collecting pypiwin32==219
>>
 Using cached 
 https://files.pythonhosted.org/packages/2b/ca/5c086c18de8f70222787b3e824e755b68d99272531522e77bb381d4f60c8/pypiwin32-219.zip
>>
 Complete output from command python setup.py egg_info:
>>
 Traceback (most recent call last):
>>
 File "", line 1, in 
>>
 File "/tmp/pip-install-d9xe2c9w/pypiwin32/setup.py", line 121
>>
 print "Building pywin32", pywin32_version
>>
 ^
>>
 SyntaxError: Missing parentheses in call to 'print'
>>

>>
 
>>
 Command "python setup.py egg_info" failed with error code 1 in 
 /tmp/pip-install-d9xe2c9w/pypiwin32/
>>

>>
 $ python3 -m pip install pypiwin32==223
>>

>>
 Collecting pypiwin32==223
>>
 Using cached 
 https://files.pythonhosted.org/packages/d0/1b/2f292bbd742e369a100c91faa0483172cd91a1a422a6692055ac920946c5/pypiwin32-223-py3-none-any.whl
>>
 Collecting pywin32>=223 (from pypiwin32==223)
>>
 Could not find a version that satisfies the requirement pywin32>=223 (from 
 pypiwin32==223) (from versions: )
>>
 No matching distribution found for pywin32>=223 (from pypiwin32==223)
>>

>>
 Downloading and installing outside pip isn't an option because distutils 
 doesn't support silent installs 
 (https://github.com/mhammond/pywin32/issues/845). If you run the command 
 locally, you can see it pops up the GUI installer.
>>
 $ wget --no-verbose --output-document=pywin32.exe 
 https://github.com/mhammond/pywin32/releases/download/b223/pywin32-223.win-amd64-py3.6.exe
  && ./pywin32.exe && rm pywin32.exe
>>

>>
 We could try compiling pywin32 from source, but it looks like it might be 
 complicated.
>>

>>
 On Wed, Mar 28, 2018 at 12:54 AM, Keegan Witt  wrote:
>>

>>
> When I do python --version, I get "Python 3.6.2" (and that's the version 
> I see pacman downloaded). I think maybe the AIO installer is installing 
> some stuff I don't have in pacman yet.
>>
>
>>
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Update Windows binaries

[Vasily Galkin]

I'm very sorry by not mentioning this earlier but pywin32 is NOT hard 
dependency for building meld installer, it's an *optional* dependency of 
cxFreeze.
In the pygobject-win32 build it is only used for writing version info into exe 
file headers, which is useful, but not required at all.

So building installer without it would be quite fine!

The bad thing about msys2 - is the random-hangs bug 
https://gitlab.gnome.org/GNOME/meld/issues/174

> Oh, one last thing I forgot to mention is that there's currently no package 
> for pywin32 in the MSYS2 repos either.
> 
> On Sat, Apr 28, 2018 at 3:19 PM, Keegan Witt  wrote:
> 
>> I'm having trouble getting pywin32 installed in MSYS2. When I try to install 
>> with pip, I get errors$ python3 -m pip install pypiwin32==219
>> Collecting pypiwin32==219
>> Using cached 
>> https://files.pythonhosted.org/packages/2b/ca/5c086c18de8f70222787b3e824e755b68d99272531522e77bb381d4f60c8/pypiwin32-219.zip
>> Complete output from command python setup.py egg_info:
>> Traceback (most recent call last):
>> File "", line 1, in 
>> File "/tmp/pip-install-d9xe2c9w/pypiwin32/setup.py", line 121
>> print "Building pywin32", pywin32_version
>> ^
>> SyntaxError: Missing parentheses in call to 'print'
>>
>> 
>> Command "python setup.py egg_info" failed with error code 1 in 
>> /tmp/pip-install-d9xe2c9w/pypiwin32/
>>
>> $ python3 -m pip install pypiwin32==223
>>
>> Collecting pypiwin32==223
>> Using cached 
>> https://files.pythonhosted.org/packages/d0/1b/2f292bbd742e369a100c91faa0483172cd91a1a422a6692055ac920946c5/pypiwin32-223-py3-none-any.whl
>> Collecting pywin32>=223 (from pypiwin32==223)
>> Could not find a version that satisfies the requirement pywin32>=223 (from 
>> pypiwin32==223) (from versions: )
>> No matching distribution found for pywin32>=223 (from pypiwin32==223)
>>
>> Downloading and installing outside pip isn't an option because distutils 
>> doesn't support silent installs 
>> (https://github.com/mhammond/pywin32/issues/845). If you run the command 
>> locally, you can see it pops up the GUI installer.
>> $ wget --no-verbose --output-document=pywin32.exe 
>> https://github.com/mhammond/pywin32/releases/download/b223/pywin32-223.win-amd64-py3.6.exe
>>  && ./pywin32.exe && rm pywin32.exe
>>
>> We could try compiling pywin32 from source, but it looks like it might be 
>> complicated.
>>
>> On Wed, Mar 28, 2018 at 12:54 AM, Keegan Witt  wrote:
>>
>>> When I do python --version, I get "Python 3.6.2" (and that's the version I 
>>> see pacman downloaded). I think maybe the AIO installer is installing some 
>>> stuff I don't have in pacman yet.
>>>
>>> On Tue, Mar 27, 2018 at 5:30 PM Kai Willadsen  
>>> wrote:
>>>
 Probably not super-helpful, but I notice that you're just using

 `python` there, which seems to be defaulting to Python 2.7, whereas we

 definitely want 3.x for current Meld.

 Either way, I'm really happy for others to be looking at this.

 On 27 March 2018 at 15:16, Keegan Witt  wrote:

> I've started work on a pipeline for msys2 here (but it's not working yet):

> https://ci.appveyor.com/project/keeganwitt/meld-q7ht3. I dunno if folks 
> are

> able to see settings I have so far or not, so here they are

>

> version: 3.18.1.{build}

> skip_non_tags: true

> clone_depth: 1

> environment:

> PATH: C:\msys64\usr\bin;$(PATH)

> install:

> - cmd: >-

> bash -lc "pacman --noconfirm --sync --refresh --refresh pacman"

>

> bash -lc "pacman --noconfirm --sync --refresh --sysupgrade"

>

> bash -lc "pacman --noconfirm -S python mingw-w64-i686-gtk3

> mingw-w64-x86_64-gtksourceview3 glib2-devel"

>

> rem bash -lc "pip install --upgrade pip"

>

> bash -lc "pip install pypiwin32==219"

>

> bash -lc "pip install cx_Freeze==5.0.2"

> build_script:

> - cmd: bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && glib-compile-schemas data

> && python setup_win32.py bdist_msi'

>

>

>

> On Mon, Mar 26, 2018 at 10:13 PM Kai Willadsen 

> wrote:

>>

>> On 26 March 2018 at 22:00, Vasily Galkin  wrote:

>> > About using msys2 binaries instead of pygobject-win32: I'm running meld

>> > checkout with mingw64 for several months by now.

>> > It contains newer gtk and so shortcuts problems with non-english

>> > keyboards https://gitlab.gnome.org/GNOME/meld/issues/129 is solved 
>> > (which is

>> > great!)

>> >

>> > But unfortunately it has a huge problem: nearly 1 of 10 invocations

>> > hangs on startup. This is very annoying. I just reported and 

Re: Update Windows binaries

[Keegan Witt]

Thanks Vasily.

I did have one more thing I tried
$ wget --no-verbose
https://files.pythonhosted.org/packages/d0/f7/56e35902d32299020cf9136264ca102ff0b03c0555621b469c825bc10d08/pypiwin32-220-cp36-none-win_amd64.whl
&& python3 -m pip install pypiwin32-220-cp36-none-win_amd64.whl
pypiwin32-220-cp36-none-win_amd64.whl is not a supported wheel on this
platform.

I tried the 32 bit version too.  Python version is 3.6.2, so I'm not sure
why it won't let me use that wheel.

On Sat, Apr 28, 2018 at 3:34 PM, Vasily Galkin  wrote:

> I'm very sorry by not mentioning this earlier but pywin32 is NOT hard
> dependency for building meld installer, it's an *optional* dependency of
> cxFreeze.
> In the pygobject-win32 build it is only used for writing version info into
> exe file headers, which is useful, but not required at all.
>
> So building installer without it would be quite fine!
>
> The bad thing about msys2 - is the random-hangs bug
> https://gitlab.gnome.org/GNOME/meld/issues/174
>
> > Oh, one last thing I forgot to mention is that there's currently no
> package for pywin32 in the MSYS2 repos either.
> >
> > On Sat, Apr 28, 2018 at 3:19 PM, Keegan Witt 
> wrote:
> >
> >> I'm having trouble getting pywin32 installed in MSYS2. When I try to
> install with pip, I get errors$ python3 -m pip install pypiwin32==219
> >> Collecting pypiwin32==219
> >> Using cached https://files.pythonhosted.org/packages/2b/ca/
> 5c086c18de8f70222787b3e824e755b68d99272531522e77bb381d4f60c8
> /pypiwin32-219.zip
> >> Complete output from command python setup.py egg_info:
> >> Traceback (most recent call last):
> >> File "", line 1, in 
> >> File "/tmp/pip-install-d9xe2c9w/pypiwin32/setup.py", line 121
> >> print "Building pywin32", pywin32_version
> >> ^
> >> SyntaxError: Missing parentheses in call to 'print'
> >>
> >> 
> >> Command "python setup.py egg_info" failed with error code 1 in
> /tmp/pip-install-d9xe2c9w/pypiwin32/
> >>
> >> $ python3 -m pip install pypiwin32==223
> >>
> >> Collecting pypiwin32==223
> >> Using cached https://files.pythonhosted.org/packages/d0/1b/
> 2f292bbd742e369a100c91faa0483172cd91a1a422a6692055ac920946c5
> /pypiwin32-223-py3-none-any.whl
> >> Collecting pywin32>=223 (from pypiwin32==223)
> >> Could not find a version that satisfies the requirement pywin32>=223
> (from pypiwin32==223) (from versions: )
> >> No matching distribution found for pywin32>=223 (from pypiwin32==223)
> >>
> >> Downloading and installing outside pip isn't an option because
> distutils doesn't support silent installs (https://github.com/mhammond/
> pywin32/issues/845). If you run the command locally, you can see it pops
> up the GUI installer.
> >> $ wget --no-verbose --output-document=pywin32.exe
> https://github.com/mhammond/pywin32/releases/download/
> b223/pywin32-223.win-amd64-py3.6.exe && ./pywin32.exe && rm pywin32.exe
> >>
> >> We could try compiling pywin32 from source, but it looks like it might
> be complicated.
> >>
> >> On Wed, Mar 28, 2018 at 12:54 AM, Keegan Witt 
> wrote:
> >>
> >>> When I do python --version, I get "Python 3.6.2" (and that's the
> version I see pacman downloaded). I think maybe the AIO installer is
> installing some stuff I don't have in pacman yet.
> >>>
> >>> On Tue, Mar 27, 2018 at 5:30 PM Kai Willadsen 
> wrote:
> >>>
>  Probably not super-helpful, but I notice that you're just using
> 
>  `python` there, which seems to be defaulting to Python 2.7, whereas we
> 
>  definitely want 3.x for current Meld.
> 
>  Either way, I'm really happy for others to be looking at this.
> 
>  On 27 March 2018 at 15:16, Keegan Witt  wrote:
> 
> > I've started work on a pipeline for msys2 here (but it's not working
> yet):
> 
> > https://ci.appveyor.com/project/keeganwitt/meld-q7ht3. I dunno if
> folks are
> 
> > able to see settings I have so far or not, so here they are
> 
> >
> 
> > version: 3.18.1.{build}
> 
> > skip_non_tags: true
> 
> > clone_depth: 1
> 
> > environment:
> 
> > PATH: C:\msys64\usr\bin;$(PATH)
> 
> > install:
> 
> > - cmd: >-
> 
> > bash -lc "pacman --noconfirm --sync --refresh --refresh pacman"
> 
> >
> 
> > bash -lc "pacman --noconfirm --sync --refresh --sysupgrade"
> 
> >
> 
> > bash -lc "pacman --noconfirm -S python mingw-w64-i686-gtk3
> 
> > mingw-w64-x86_64-gtksourceview3 glib2-devel"
> 
> >
> 
> > rem bash -lc "pip install --upgrade pip"
> 
> >
> 
> > bash -lc "pip install pypiwin32==219"
> 
> >
> 
> > bash -lc "pip install cx_Freeze==5.0.2"
> 
> > build_script:
> 
> > - cmd: bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" &&
> glib-compile-schemas data
> 
> > && python setup_win32.py bdist_msi'
> 
> 

Re: Update Windows binaries

[Keegan Witt]

Oh, one last thing I forgot to mention is that there's currently no package
for pywin32 in the MSYS2 repos either.

On Sat, Apr 28, 2018 at 3:19 PM, Keegan Witt  wrote:

> I'm having trouble getting pywin32 installed in MSYS2.  When I try to
> install with pip, I get errors
> $ python3 -m pip install pypiwin32==219
> Collecting pypiwin32==219
>   Using cached https://files.pythonhosted.org/packages/2b/ca/
> 5c086c18de8f70222787b3e824e755b68d99272531522e77bb381d4f60c8
> /pypiwin32-219.zip
> Complete output from command python setup.py egg_info:
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/tmp/pip-install-d9xe2c9w/pypiwin32/setup.py", line 121
> print "Building pywin32", pywin32_version
>^
> SyntaxError: Missing parentheses in call to 'print'
>
> 
> Command "python setup.py egg_info" failed with error code 1 in
> /tmp/pip-install-d9xe2c9w/pypiwin32/
>
> $ python3 -m pip install pypiwin32==223
> Collecting pypiwin32==223
>   Using cached https://files.pythonhosted.org/packages/d0/1b/
> 2f292bbd742e369a100c91faa0483172cd91a1a422a6692055ac920946c5
> /pypiwin32-223-py3-none-any.whl
> Collecting pywin32>=223 (from pypiwin32==223)
>   Could not find a version that satisfies the requirement pywin32>=223
> (from pypiwin32==223) (from versions: )
> No matching distribution found for pywin32>=223 (from pypiwin32==223)
>
> Downloading and installing outside pip isn't an option because distutils
> doesn't support silent installs (https://github.com/mhammond/
> pywin32/issues/845).  If you run the command locally, you can see it pops
> up the GUI installer.
> $ wget --no-verbose --output-document=pywin32.exe
> https://github.com/mhammond/pywin32/releases/download/
> b223/pywin32-223.win-amd64-py3.6.exe && ./pywin32.exe && rm pywin32.exe
>
> We could try compiling pywin32 from source, but it looks like it might be
> complicated.
>
>
> On Wed, Mar 28, 2018 at 12:54 AM, Keegan Witt 
> wrote:
>
>> When I do python --version, I get "Python 3.6.2" (and that's the version
>> I see pacman downloaded).  I think maybe the AIO installer is installing
>> some stuff I don't have in pacman yet.
>>
>> On Tue, Mar 27, 2018 at 5:30 PM Kai Willadsen 
>> wrote:
>>
>>> Probably not super-helpful, but I notice that you're just using
>>> `python` there, which seems to be defaulting to Python 2.7, whereas we
>>> definitely want 3.x for current Meld.
>>>
>>> Either way, I'm really happy for others to be looking at this.
>>>
>>> On 27 March 2018 at 15:16, Keegan Witt  wrote:
>>> > I've started work on a pipeline for msys2 here (but it's not working
>>> yet):
>>> > https://ci.appveyor.com/project/keeganwitt/meld-q7ht3.  I dunno if
>>> folks are
>>> > able to see settings I have so far or not, so here they are
>>> >
>>> > version: 3.18.1.{build}
>>> > skip_non_tags: true
>>> > clone_depth: 1
>>> > environment:
>>> >   PATH: C:\msys64\usr\bin;$(PATH)
>>> > install:
>>> > - cmd: >-
>>> > bash -lc "pacman --noconfirm --sync --refresh --refresh pacman"
>>> >
>>> > bash -lc "pacman --noconfirm --sync --refresh --sysupgrade"
>>> >
>>> > bash -lc "pacman --noconfirm -S python mingw-w64-i686-gtk3
>>> > mingw-w64-x86_64-gtksourceview3 glib2-devel"
>>> >
>>> > rem bash -lc "pip install --upgrade pip"
>>> >
>>> > bash -lc "pip install pypiwin32==219"
>>> >
>>> > bash -lc "pip install cx_Freeze==5.0.2"
>>> > build_script:
>>> > - cmd: bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && glib-compile-schemas
>>> data
>>> > && python setup_win32.py bdist_msi'
>>> >
>>> >
>>> >
>>> > On Mon, Mar 26, 2018 at 10:13 PM Kai Willadsen <
>>> kai.willad...@gmail.com>
>>> > wrote:
>>> >>
>>> >> On 26 March 2018 at 22:00, Vasily Galkin  wrote:
>>> >> > About using msys2 binaries instead of pygobject-win32: I'm running
>>> meld
>>> >> > checkout with mingw64 for several months by now.
>>> >> > It contains newer gtk and so shortcuts problems with non-english
>>> >> > keyboards https://gitlab.gnome.org/GNOME/meld/issues/129 is solved
>>> (which is
>>> >> > great!)
>>> >> >
>>> >> > But unfortunately it has a huge problem: nearly 1 of 10 invocations
>>> >> > hangs on startup. This is very annoying. I just reported and
>>> crosslinked
>>> >> > this as https://github.com/Alexpux/MINGW-packages/issues/3510 and
>>> >> > https://gitlab.gnome.org/GNOME/meld/issues/174
>>> >> >
>>> >> > Apart from this I had several crashes, but they are extremely rare
>>> (1
>>> >> > per month with intensive every-day use, like 1 from 1000 usages
>>> leads to
>>> >> > crash).
>>> >>
>>> >> ...and we've been forced on to msys2 by some changes I made to stop
>>> >> supporting older GTK+. I *can* revert these, but I'd really rather
>>> >> not, since we need to (IMO) move to using msys2 sooner rather than
>>> >> later anyway.
>>> >>
>>> >> Kai
>>>

Re: Update Windows binaries

[Keegan Witt]

I'm having trouble getting pywin32 installed in MSYS2.  When I try to
install with pip, I get errors
$ python3 -m pip install pypiwin32==219
Collecting pypiwin32==219
  Using cached
https://files.pythonhosted.org/packages/2b/ca/5c086c18de8f70222787b3e824e755b68d99272531522e77bb381d4f60c8/pypiwin32-219.zip
Complete output from command python setup.py egg_info:
Traceback (most recent call last):
  File "", line 1, in 
  File "/tmp/pip-install-d9xe2c9w/pypiwin32/setup.py", line 121
print "Building pywin32", pywin32_version
   ^
SyntaxError: Missing parentheses in call to 'print'


Command "python setup.py egg_info" failed with error code 1 in
/tmp/pip-install-d9xe2c9w/pypiwin32/

$ python3 -m pip install pypiwin32==223
Collecting pypiwin32==223
  Using cached
https://files.pythonhosted.org/packages/d0/1b/2f292bbd742e369a100c91faa0483172cd91a1a422a6692055ac920946c5/pypiwin32-223-py3-none-any.whl
Collecting pywin32>=223 (from pypiwin32==223)
  Could not find a version that satisfies the requirement pywin32>=223
(from pypiwin32==223) (from versions: )
No matching distribution found for pywin32>=223 (from pypiwin32==223)

Downloading and installing outside pip isn't an option because distutils
doesn't support silent installs (
https://github.com/mhammond/pywin32/issues/845).  If you run the command
locally, you can see it pops up the GUI installer.
$ wget --no-verbose --output-document=pywin32.exe
https://github.com/mhammond/pywin32/releases/download/b223/pywin32-223.win-amd64-py3.6.exe
&& ./pywin32.exe && rm pywin32.exe

We could try compiling pywin32 from source, but it looks like it might be
complicated.


On Wed, Mar 28, 2018 at 12:54 AM, Keegan Witt  wrote:

> When I do python --version, I get "Python 3.6.2" (and that's the version
> I see pacman downloaded).  I think maybe the AIO installer is installing
> some stuff I don't have in pacman yet.
>
> On Tue, Mar 27, 2018 at 5:30 PM Kai Willadsen 
> wrote:
>
>> Probably not super-helpful, but I notice that you're just using
>> `python` there, which seems to be defaulting to Python 2.7, whereas we
>> definitely want 3.x for current Meld.
>>
>> Either way, I'm really happy for others to be looking at this.
>>
>> On 27 March 2018 at 15:16, Keegan Witt  wrote:
>> > I've started work on a pipeline for msys2 here (but it's not working
>> yet):
>> > https://ci.appveyor.com/project/keeganwitt/meld-q7ht3.  I dunno if
>> folks are
>> > able to see settings I have so far or not, so here they are
>> >
>> > version: 3.18.1.{build}
>> > skip_non_tags: true
>> > clone_depth: 1
>> > environment:
>> >   PATH: C:\msys64\usr\bin;$(PATH)
>> > install:
>> > - cmd: >-
>> > bash -lc "pacman --noconfirm --sync --refresh --refresh pacman"
>> >
>> > bash -lc "pacman --noconfirm --sync --refresh --sysupgrade"
>> >
>> > bash -lc "pacman --noconfirm -S python mingw-w64-i686-gtk3
>> > mingw-w64-x86_64-gtksourceview3 glib2-devel"
>> >
>> > rem bash -lc "pip install --upgrade pip"
>> >
>> > bash -lc "pip install pypiwin32==219"
>> >
>> > bash -lc "pip install cx_Freeze==5.0.2"
>> > build_script:
>> > - cmd: bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && glib-compile-schemas
>> data
>> > && python setup_win32.py bdist_msi'
>> >
>> >
>> >
>> > On Mon, Mar 26, 2018 at 10:13 PM Kai Willadsen > >
>> > wrote:
>> >>
>> >> On 26 March 2018 at 22:00, Vasily Galkin  wrote:
>> >> > About using msys2 binaries instead of pygobject-win32: I'm running
>> meld
>> >> > checkout with mingw64 for several months by now.
>> >> > It contains newer gtk and so shortcuts problems with non-english
>> >> > keyboards https://gitlab.gnome.org/GNOME/meld/issues/129 is solved
>> (which is
>> >> > great!)
>> >> >
>> >> > But unfortunately it has a huge problem: nearly 1 of 10 invocations
>> >> > hangs on startup. This is very annoying. I just reported and
>> crosslinked
>> >> > this as https://github.com/Alexpux/MINGW-packages/issues/3510 and
>> >> > https://gitlab.gnome.org/GNOME/meld/issues/174
>> >> >
>> >> > Apart from this I had several crashes, but they are extremely rare (1
>> >> > per month with intensive every-day use, like 1 from 1000 usages
>> leads to
>> >> > crash).
>> >>
>> >> ...and we've been forced on to msys2 by some changes I made to stop
>> >> supporting older GTK+. I *can* revert these, but I'd really rather
>> >> not, since we need to (IMO) move to using msys2 sooner rather than
>> >> later anyway.
>> >>
>> >> Kai
>>
>
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Update Windows binaries

[Keegan Witt]

When I do python --version, I get "Python 3.6.2" (and that's the version I
see pacman downloaded).  I think maybe the AIO installer is installing some
stuff I don't have in pacman yet.

On Tue, Mar 27, 2018 at 5:30 PM Kai Willadsen 
wrote:

> Probably not super-helpful, but I notice that you're just using
> `python` there, which seems to be defaulting to Python 2.7, whereas we
> definitely want 3.x for current Meld.
>
> Either way, I'm really happy for others to be looking at this.
>
> On 27 March 2018 at 15:16, Keegan Witt  wrote:
> > I've started work on a pipeline for msys2 here (but it's not working
> yet):
> > https://ci.appveyor.com/project/keeganwitt/meld-q7ht3.  I dunno if
> folks are
> > able to see settings I have so far or not, so here they are
> >
> > version: 3.18.1.{build}
> > skip_non_tags: true
> > clone_depth: 1
> > environment:
> >   PATH: C:\msys64\usr\bin;$(PATH)
> > install:
> > - cmd: >-
> > bash -lc "pacman --noconfirm --sync --refresh --refresh pacman"
> >
> > bash -lc "pacman --noconfirm --sync --refresh --sysupgrade"
> >
> > bash -lc "pacman --noconfirm -S python mingw-w64-i686-gtk3
> > mingw-w64-x86_64-gtksourceview3 glib2-devel"
> >
> > rem bash -lc "pip install --upgrade pip"
> >
> > bash -lc "pip install pypiwin32==219"
> >
> > bash -lc "pip install cx_Freeze==5.0.2"
> > build_script:
> > - cmd: bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && glib-compile-schemas
> data
> > && python setup_win32.py bdist_msi'
> >
> >
> >
> > On Mon, Mar 26, 2018 at 10:13 PM Kai Willadsen 
> > wrote:
> >>
> >> On 26 March 2018 at 22:00, Vasily Galkin  wrote:
> >> > About using msys2 binaries instead of pygobject-win32: I'm running
> meld
> >> > checkout with mingw64 for several months by now.
> >> > It contains newer gtk and so shortcuts problems with non-english
> >> > keyboards https://gitlab.gnome.org/GNOME/meld/issues/129 is solved
> (which is
> >> > great!)
> >> >
> >> > But unfortunately it has a huge problem: nearly 1 of 10 invocations
> >> > hangs on startup. This is very annoying. I just reported and
> crosslinked
> >> > this as https://github.com/Alexpux/MINGW-packages/issues/3510 and
> >> > https://gitlab.gnome.org/GNOME/meld/issues/174
> >> >
> >> > Apart from this I had several crashes, but they are extremely rare (1
> >> > per month with intensive every-day use, like 1 from 1000 usages leads
> to
> >> > crash).
> >>
> >> ...and we've been forced on to msys2 by some changes I made to stop
> >> supporting older GTK+. I *can* revert these, but I'd really rather
> >> not, since we need to (IMO) move to using msys2 sooner rather than
> >> later anyway.
> >>
> >> Kai
>
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Update Windows binaries

[Kai Willadsen]

Probably not super-helpful, but I notice that you're just using
`python` there, which seems to be defaulting to Python 2.7, whereas we
definitely want 3.x for current Meld.

Either way, I'm really happy for others to be looking at this.

On 27 March 2018 at 15:16, Keegan Witt  wrote:
> I've started work on a pipeline for msys2 here (but it's not working yet):
> https://ci.appveyor.com/project/keeganwitt/meld-q7ht3.  I dunno if folks are
> able to see settings I have so far or not, so here they are
>
> version: 3.18.1.{build}
> skip_non_tags: true
> clone_depth: 1
> environment:
>   PATH: C:\msys64\usr\bin;$(PATH)
> install:
> - cmd: >-
> bash -lc "pacman --noconfirm --sync --refresh --refresh pacman"
>
> bash -lc "pacman --noconfirm --sync --refresh --sysupgrade"
>
> bash -lc "pacman --noconfirm -S python mingw-w64-i686-gtk3
> mingw-w64-x86_64-gtksourceview3 glib2-devel"
>
> rem bash -lc "pip install --upgrade pip"
>
> bash -lc "pip install pypiwin32==219"
>
> bash -lc "pip install cx_Freeze==5.0.2"
> build_script:
> - cmd: bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && glib-compile-schemas data
> && python setup_win32.py bdist_msi'
>
>
>
> On Mon, Mar 26, 2018 at 10:13 PM Kai Willadsen 
> wrote:
>>
>> On 26 March 2018 at 22:00, Vasily Galkin  wrote:
>> > About using msys2 binaries instead of pygobject-win32: I'm running meld
>> > checkout with mingw64 for several months by now.
>> > It contains newer gtk and so shortcuts problems with non-english
>> > keyboards https://gitlab.gnome.org/GNOME/meld/issues/129 is solved (which 
>> > is
>> > great!)
>> >
>> > But unfortunately it has a huge problem: nearly 1 of 10 invocations
>> > hangs on startup. This is very annoying. I just reported and crosslinked
>> > this as https://github.com/Alexpux/MINGW-packages/issues/3510 and
>> > https://gitlab.gnome.org/GNOME/meld/issues/174
>> >
>> > Apart from this I had several crashes, but they are extremely rare (1
>> > per month with intensive every-day use, like 1 from 1000 usages leads to
>> > crash).
>>
>> ...and we've been forced on to msys2 by some changes I made to stop
>> supporting older GTK+. I *can* revert these, but I'd really rather
>> not, since we need to (IMO) move to using msys2 sooner rather than
>> later anyway.
>>
>> Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Update Windows binaries

[Keegan Witt]

I've started work on a pipeline for msys2 here (but it's not working yet):
https://ci.appveyor.com/project/keeganwitt/meld-q7ht3.  I dunno if folks
are able to see settings I have so far or not, so here they are

version: 3.18.1.{build}
skip_non_tags: true
clone_depth: 1
environment:
  PATH: C:\msys64\usr\bin;$(PATH)
install:
- cmd: >-
bash -lc "pacman --noconfirm --sync --refresh --refresh pacman"

bash -lc "pacman --noconfirm --sync --refresh --sysupgrade"

bash -lc "pacman --noconfirm -S python mingw-w64-i686-gtk3
mingw-w64-x86_64-gtksourceview3 glib2-devel"

rem bash -lc "pip install --upgrade pip"

bash -lc "pip install pypiwin32==219"

bash -lc "pip install cx_Freeze==5.0.2"
build_script:
- cmd: bash -lc 'cd "%APPVEYOR_BUILD_FOLDER%" && glib-compile-schemas
data && python setup_win32.py bdist_msi'



On Mon, Mar 26, 2018 at 10:13 PM Kai Willadsen 
wrote:

> On 26 March 2018 at 22:00, Vasily Galkin  wrote:
> > About using msys2 binaries instead of pygobject-win32: I'm running meld
> checkout with mingw64 for several months by now.
> > It contains newer gtk and so shortcuts problems with non-english
> keyboards https://gitlab.gnome.org/GNOME/meld/issues/129 is solved (which
> is great!)
> >
> > But unfortunately it has a huge problem: nearly 1 of 10 invocations
> hangs on startup. This is very annoying. I just reported and crosslinked
> this as https://github.com/Alexpux/MINGW-packages/issues/3510 and
> https://gitlab.gnome.org/GNOME/meld/issues/174
> >
> > Apart from this I had several crashes, but they are extremely rare (1
> per month with intensive every-day use, like 1 from 1000 usages leads to
> crash).
>
> ...and we've been forced on to msys2 by some changes I made to stop
> supporting older GTK+. I *can* revert these, but I'd really rather
> not, since we need to (IMO) move to using msys2 sooner rather than
> later anyway.
>
> Kai
>
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Update Windows binaries

[Kai Willadsen]

> On Sun, Mar 25, 2018 at 9:00 PM Keegan Witt <keeganw...@gmail.com> wrote:
>>
>> Sorry, I accidentally replied instead of reply all.
>>
>>
>> -- Forwarded message -
>> From: Keegan Witt <keeganw...@gmail.com>
>> Date: Sun, Mar 25, 2018 at 8:13 PM
>> Subject: Re: Update Windows binaries
>> To: <ngos...@hotmail.es>
>>
>>
>> There's a discussion about Windows builds here:
>> https://bugzilla.gnome.org/show_bug.cgi?id=788570.  From what I can tell,
>> the slow startup problem has been fixed with that artifact
>> (https://ci.appveyor.com/project/kaiw/meld/build/artifacts).
>>
>> Kai, do you want to use that pipeline to do an official binary?  Or do you
>> want to move to Mysys2 first?

The idea was that that pipeline would be used for future 3.18.x
releases, and then *hopefully* we can switch to msys2 for 3.19.x.

I just haven't made a 3.18.1 release yet. I will... try to get the
motivation together to do this. It's just been held up a fair bit by
the Gitlab migration among other things.

On 26 March 2018 at 11:27, Keegan Witt <keeganw...@gmail.com> wrote:
> I wasn't able to build 3.18.0 (failed with "error: error in setup script:
> command 'build_exe' has no such option 'compressed'"), but I was able to
> build latest meld-3-18 branch if you'd like something to use in the mean
> time: https://ci.appveyor.com/project/keeganwitt/meld.

Yeah, 3.18.0 isn't buildable for win32; there's at least a problem
with the cx_freeze version and probably other issues.

Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Update Windows binaries

[Keegan Witt]

I wasn't able to build 3.18.0 (failed with "error: error in setup script:
command 'build_exe' has no such option 'compressed'"), but I was able to
build latest meld-3-18 branch if you'd like something to use in the mean
time: https://ci.appveyor.com/project/keeganwitt/meld.

On Sun, Mar 25, 2018 at 9:00 PM Keegan Witt <keeganw...@gmail.com> wrote:

> Sorry, I accidentally replied instead of reply all.
>
>
> -- Forwarded message -
> From: Keegan Witt <keeganw...@gmail.com>
> Date: Sun, Mar 25, 2018 at 8:13 PM
> Subject: Re: Update Windows binaries
> To: <ngos...@hotmail.es>
>
>
> There's a discussion about Windows builds here:
> https://bugzilla.gnome.org/show_bug.cgi?id=788570.  From what I can tell,
> the slow startup problem has been fixed with that artifact (
> https://ci.appveyor.com/project/kaiw/meld/build/artifacts).
>
> Kai, do you want to use that pipeline to do an official binary?  Or do you
> want to move to Mysys2 first?
>
> On Sun, Mar 25, 2018 at 5:02 PM Ngosang Kplan Strirv <ngos...@hotmail.es>
> wrote:
>
>> Hello everyone,
>>
>>
>>
>> I’m really happy using this software in Linux but the Windows versión is
>> a mess.
>>
>>- Current binaries are outdated
>>- Really slow start. About 2 minutes in my laptop
>>- Weird window theme
>>
>>
>>
>> Can I help in any way?
>>
>>
>>
>> Regards
>> ___
>> meld-list mailing list
>> meld-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/meld-list
>
>
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list