I couldn't find any evidence this is covered by tests in core

In D11207#172082, @marmoute wrote:

file is not bytes, so this will crash, will it not ?

In D11025#169424, @marmoute wrote:

In D11025#169418, @mharbison72 wrote:

I assume the various things that I was installing in before_script are now baked into to the docker image/runner host? (That's good, it was my intention. But the TEMP variable hack made me wonder if maybe it wasn't yet.)

Yes they are.

I'm also a bit surprised you haven't hit any issues by leaving out the make local bits.

I don't know what error you were getting without --local, but the latest run are doing without it. I made a bunch of fixes to run-tests.py that might have helped (and there will be more)

I assume the various things that I was installing in before_script are now baked into to the docker image/runner host? (That's good, it was my intention. But the TEMP variable hack made me wonder if maybe it wasn't yet.)

Does the issue happen with 3.7? I'm wondering if this is the normalization they started to do in os.path.realpath(). See 3dfebba99ef6

This landed as dff19fe2973c, but lacked the Differential URL in the commit comment somehow. It may have gotten pulled off of the Windows CI work on heptapod.

This landed as 6e0af81c43b2, but lacked the Differential URL in the commit comment somehow. It may have gotten pulled off of the Windows CI work on heptapod.

It looks like this never landed.

Is there any more context you can/want to supply about the bug, what's better about Windows, the rabbit hole, etc?

In D10893#166757, @martinvonz wrote:

We have talked internally at work about some kind of interactive hg absorb that lets you decide which commit each line should go into. That sounds similar to what you're thinking of.

In D10893#166684, @martinvonz wrote:

In D10893#166678, @mharbison72 wrote:

In D10893#166666, @martinvonz wrote:

In D10893#166662, @Alphare wrote:

This is indeed a very important quality-of-life feature and I'm +1 on adding it to Mercurial.

Can this get grafted to stable? It goes with 5b3513177f2b. I'm not sure why the stable branch wasn't flagged in phab, because that's where the obsolete commit is in my repo.

In D10756#164445, @indygreg wrote:

Oh wow - I never would have thought that the presence of this symbol would affect linking behavior. But I suppose it makes sense. The functions are probably left as unresolved references but the static variable reference forces early binding or something.

@indygreg - you might be interested in the I/O issue. PyOxidizer doesn't seem to be affected (at least when it's building with 3.9.5), but does seem to set Py_LegacyWindowsStdioFlag. Also not sure if there are other issues with the pager code. I remember you looking at it a little over a year ago and saying there were a lot if iffy things, but IDR seeing a patch series after that.

Thanks for grinding through this packaging stuff!

This is interesting because the test-gendoc-* tests mostly fail on my Windows machines with py3 (but work with py2). The executable is /mingw/bin/msgfmt.exe, but it's been there forever and IDR where I got it. That's a strange place for executables, so I assume it's not from the mingw installers and that I just stuffed it there as a convenient way to get it on PATH. Installing various MSYS packages on the new CI system didn't install a msgfmt that hghave accepted. So then I installed https://github.com/vslavik/gettext-tools-windows/releases/download/v0.21-1/gettext-tools-windows-0.21-1.zip, and it failed the tests in a different way. The 0.14.4 version from SF doesn't seem to print a version number, so that's likely why hghave won't use it for tests.