Re: [Msys2-users] Proof of concept: MSYS2, pacman and makepkg on Wine

[Qian H. <fra...@gm...>]

Hi Ray,

On Tue, Mar 24, 2015 at 4:23 AM, Ray Donnelly <min...@gm...> wrote:
> Sounds good. I think those packages you mention should be added as
> PKGBUILD recipes to the MINGW-packages repository so that they're
> available as binaries from pacman and also easy to build from source.
>
Good point, if their is any progress from us we will update here any
submit new PKGBUILD recipes to MSYS2.


>
> OK, well it's a good start to have some things working and you can
> start to file bugs (or fix things) with Wine for the things that don't
> work yet.

Agree, we are working on improving our hacks. Once all hacks are
converted to proper fix and accepted by Wine / Wine-Staging, we will
start to use bugzilla from Wine / Wine-Staing. Currently it's not
suitable to submit bugs to Wine / Wine-Staging because a couples of
custom patches are applied so our version of Wine is not "clean"
enough to match upstream's bug submitting guide line.


> I'd like to see ReactOS capable of using MSYS2 and all of that running
> on Wine. That would be really cool I think as it'd be Open Source all
> the way down.

Agree, that's cool. ReactOS would be benefit from the work once most
patches are accepted by Wine upstream since ReactOS sync Wine code
frequently. Once our work is stable enough I can discuss with ReactOS
developers for future advice and plan, I think Amine Khaldi from
ReactOS has some interesting with this idea ;-)


> I keep checking out the latest Wine on ArchLinux every so often - I
> saw that the installer runs mostly quite cleanly two days ago. Would
> it be possible for you to maintain an ArchLinux PKGBUILD that builds
> from your branch? That would make it easy for us MSYS2'ers to test it
> since we're quite used to PKGBUILDs.

That's a very useful idea, thanks. I'd love to maintain a PKGBUILD,
however, unfortunately, recent MSYS2 update triggers new Wine bug in
our branch which makes the proof-of-concept works poor. (Certainly
this is not MSYS2's fault :D)

(Technically, due to recent MSYS2 update, it seems more packages
depends on the version 2.1.x of msys2-runtime. Newer msys2-runtime
works fine, just the upgrading process itself triggers our bug, those
core dlls in used like msys-2.0.dll are lost after exit MSYS2 shell.
It looks like a bug in FileDispositionInformation support of
NtSetInformationFile)

In short, we are not ready yet. Hopefully we'll fix these things and
come back in a couple of weeks. After that, MSYS2 users could simply
use Wine-Staging's PKGBUILD / pre-built pakages to try MSYS2.


> I looked at your README.md, seems some tasks have a good overlap with
> MSYS2, for example I'd really like to see:
> "Setup build bot in Appveyor CI (for Windows, as comparison build) and
> Travis CI (for Linux, with Xvfb). Run regression tests for every
> commit to catch bugs in first minute.", (esp. the Appveyor part)
> happen ASAP.
>
Glad to know about the overlap. If we have any progress we will update here.

>
> I think once some of the major bugs are fixed it will be more pleasant
> to try doing more stuff in Wine. If it ran at e.g. > 50% of the speed
> and mostly everything worked then I'd occasionally develop PKGBUILDs
> in that environment for MSYS2, why not eh? I think once you reach this
> stage, hopefully a lot of GNU/Linux users/developers will consider
> this approach for their Windows port too.
>
Thanks for the thoughts, very useful.

>
> Appveyor :-)
I'd love that too. Once we are free from current busy task we will start that.


> We are the polar opposite to chocolatey who simply repackage binaries;
> their approach is of no interest to us and their description of
> themselves as "like apt-get for Windows" is IMHO, silly, it ignores
> the most important bit; that apt-get installs Open Source packages
> that the user can modify and re-build. I'm guessing npackd is the same
> sort of deal so neither would be of much interest to Windows-based
> Open Source developers. Certainly, the MSYS2 project would never
> recommend its users to install another package manager when we have
> Pacman. Making the MSYS2 build infrastructure work well is the most
> important thing from my perspective, so anything involved in that,
> git, mintty, python (of which we have 4), perl (of which we have 2)
> and the base-devel package group should be prioritised. For me
> personally, I like an IDE when debugging and I use the MSYS2's
> Qt-Creator package for that, so if this can be run as well, then I'd
> be very happy.
>

Ah, thanks a lot, all these are very useful information, I learn something new.
We'll priority our work according to your advice.


> Sure, once we get to the "mostly usable" state I'll be happy to try,
> though I'm not familiar with Wine's codebase.
Many thanks.
Ideally there is no need for MSYS2 developers and users to spend time
on learning deeply about the Wine codebase if they have no time or
interest.
When a MSYS2 program triggers a Wine bug, if MSYS2 people could help
to point out which function inside the MSYS2 program doesn't work, and
exactly which child-function doesn't work, then exactly which
grand-child-function doesn't work, etc, then these kinds of
information are perfect enough for people who are familiar with Wine's
codebase to fix Wine bugs. That would be great appreciated.



> Having the source available and easily build-able should be a great
> help. You can test theories and fixes quickly that way. We'll help
> anyone in #msys2 or on the mailing list provided they are polite,
> patient and willing to take our advice. Not all of our PKGBUILDs work
> correctly with options=('debug' '!strip') but many do. That's the best
> way to investigate problems.
>
Thanks. BTW, if some package has no debugging information even with
"options=('debug' '!strip')", is it worth to report to MSYS2 community
(maybe without a proposal of fix)?


>
> I started doing a little work to get a PKGBUILD for Firefox but I got
> very busy again with my job. I think one for LibreOffice would be good
> too for both of us.
>
Agree, will work on that direction.


> If I think of anything more I'll reply.
Thank you very much ;-)



-- 
Regards,
Qian Hong

-
http://www.winehq.org