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 <kai.willad...@gmail.com> wrote: > >> On 19 May 2018 at 05:46, Vasily Galkin <galkin...@yandex.ru> 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&comparing 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&error 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 _______________________________________________ meld-list mailing list meld-list@gnome.org https://mail.gnome.org/mailman/listinfo/meld-list
