In D7967#118158, @marmoute wrote:

I can confirm the spec version number are different to the changegroup version number. For the rest. I'll try to have a look soon.

LGTM, thanks for the update.

In D8146#121277, @martinvonz wrote:

In D8146#121271, @mharbison72 wrote:

In D8146#121267, @marmoute wrote:

Since the line does not occurs on linux, this probably got affected by some other change without being noticed.

Makes sense for why it was missed, but I bisected it back to the referenced commit. I know @martinvonz made some other related changes prior to that commit that had similar test fallout on Windows, but it isn't obvious to me why the referenced commit would change the order of when the background thread spins up.

Perhaps the line doesn't actually happen before that commit? You can try removing the (?) in the commit before my commit and see if that line is actually printed. I'm thinking that that commit pushed the number of files to close above some threshold that made it get printed. In that case, it was probably some of my earlier commits that made it no longer get printed and we just didn't notice since (?) means optional (no error if it doesn't get printed).

In D8146#121267, @marmoute wrote:

Since the line does not occurs on linux, this probably got affected by some other change without being noticed.

In D8145#121269, @marmoute wrote:

Could we get a test for this? To make sure the hint looks fine and that the error code does not crash ?

This is meant for stable. The other test fixes I'll submit shortly are for default.

This needs D8126 (which I assume is going to end up on stable) to pass.

Generating test recordings

Generating test recordings

Generating test recodings

Generating test recodings

Generating test recodings

Does this also allow extensions to be bundled in the exe, or are you thinking we need to leave the extensions outside the binary?

In D6846#120513, @indygreg wrote:

macOS supports a @loader_path and related magic tokens in rpath to load libraries relative to the current binary. See e.g. https://blogs.oracle.com/dipol/dynamic-libraries,-rpath,-and-mac-os and https://medium.com/@donblas/fun-with-rpath-otool-and-install-name-tool-e3e41ae86172 for examples.

I forgot to reply to this last week- I was concerned when the subsequent part of the stack went in without suppressing the per file progress bars here, that the displayed progress bar would be bouncing around randomly. But it wasn't- it was ever increasing like only the main bar was being changed. Any ideas why that would be?

In D8099#120114, @pulkit wrote:

This one fails to apply on tip of stable branch. Can you rebase and resend?

The py3 breakage fixed by D8099 convinced me that this is going in the wrong direction.

In D6846#119328, @marmoute wrote:

are we talking about python library or compiled library ? Go you have any "empty" item in the various PATH used for the build ?

In D7960#119446, @marmoute wrote:

This is very unappealling ☹ could we update the total value in case authentication is needed instead ?

Obsoleted by D8058, which stops treating these as resources with py2exe.

I just did Inno 5.0.2 -> current Inno without uninstalling, and I didn't see any errors. In this case, it preserves the existing capitalized names. But since we renamed help -> helptext, hgrc.d -> defaultrc, and since the previous installer cleanup this cycle did some things like rename Docs -> doc, it's probably a good idea to uninstall before upgrading. That said, it seemed like a functional installation (version and debuginstall worked). A subsequent uninstall removed the entire mess, not just the newly dropped files.

This change also means that Inno and WiX are now using very similar code for managing the install layout. This means that on disk both packages are nearly identical. The differences in install layout are as follows:
...