D8473: packaging: support building Inno installer with PyOxidizer

indygreg created this revision. Herald added a reviewer: hg-reviewers. Herald added a subscriber: mercurial-patches. REVISION SUMMARY We want to start distributing Mercurial on Python 3 on Windows. PyOxidizer will be our vehicle for achieving that. This commit implements basic support

D8477: packaging: support building WiX installers with PyOxidizer

indygreg created this revision. Herald added a reviewer: hg-reviewers. Herald added a subscriber: mercurial-patches. REVISION SUMMARY We initially implemented PyOxidizer support for Inno installers. That did most of the heavy work of integrating PyOxidizer into the packaging system.

D8475: packaging: integrate signing into run_wix_packaging()

indygreg created this revision. Herald added a reviewer: hg-reviewers. Herald added a subscriber: mercurial-patches. REVISION SUMMARY Previously, signing was implemented via a separate function which called build_installer() and then called signing functionality. In this model, in

D8476: packaging: move version derivation to run_wix_packaging()

indygreg created this revision. Herald added a reviewer: hg-reviewers. Herald added a subscriber: mercurial-patches. REVISION SUMMARY With the previous commit moving signing inline, we no longer need to compute the version string in build_installer() and can instead move this logic to

D8474: packaging: isolate invocation of WiX to own function

indygreg created this revision. Herald added a reviewer: hg-reviewers. Herald added a subscriber: mercurial-patches. REVISION SUMMARY Like we did for Inno, we want to split out the building of Mercurial from invoking the packaging tool so that we can introduce an alternate build mechanism.

D8469: setup: use sysstr() on process output

indygreg created this revision. Herald added a reviewer: hg-reviewers. Herald added a subscriber: mercurial-patches. REVISION SUMMARY Otherwise we get a str-bytes mismatch on Python 3 if an error occurs. REPOSITORY rHG Mercurial BRANCH stable REVISION DETAIL

D8470: packaging: add docutils as dependency

indygreg created this revision. Herald added a reviewer: hg-reviewers. Herald added a subscriber: mercurial-patches. REVISION SUMMARY The previous commit revealed that attempting to run `python setup.py build_doc` from the packaging virtualenv failed due to missing docutils package. We

D8472: packaging: split Inno installer building from Mercurial building

indygreg created this revision. Herald added a reviewer: hg-reviewers. Herald added a subscriber: mercurial-patches. REVISION SUMMARY We want to make the logic for producing the installer agnostic about how Mercurial is built to allow for alternate build methods (like PyOxidizer).

D8468: contrib: install PyOxidizer in Linux and Windows environments

indygreg created this revision. Herald added a reviewer: hg-reviewers. Herald added a subscriber: mercurial-patches. REVISION SUMMARY For Linux, this was trivial. For Windows, we need to teach the powershell script to install Rust as well. This was also pretty straightforward.

D8471: packaging: remove pyoxidizer.bzl from packaging directory

indygreg created this revision. Herald added a reviewer: hg-reviewers. Herald added a subscriber: mercurial-patches. REVISION SUMMARY We have another version in rust/hgcli that is more modern and is already associated with our Rust CLI project. REPOSITORY rHG Mercurial BRANCH stable

D8466: contrib: update to latest Python 2.7, 3.7, and 3.8

indygreg created this revision. Herald added a reviewer: hg-reviewers. Herald added a subscriber: mercurial-patches. REVISION SUMMARY We would ideally update the 3.5 and 3.6 versions as well. But Python didn't generate exe installers for newer versions for some reason. REPOSITORY rHG

D8467: automation: install latest Python versions in Linux

indygreg created this revision. Herald added a reviewer: hg-reviewers. Herald added a subscriber: mercurial-patches. REVISION SUMMARY Staying up to date. Keeping parity with the Windows environment. REPOSITORY rHG Mercurial BRANCH stable REVISION DETAIL

D8465: automation: always use latest Windows AMI

indygreg created this revision. Herald added a reviewer: hg-reviewers. Herald added a subscriber: mercurial-patches. REVISION SUMMARY The old AMI isn't available any more. We seem to run into this problem every few months. Amazon (or Microsoft) appears to be removing the old AMIs when

Re: Moving patches traffic to a another list?

> On Apr 21, 2020, at 18:49, Augie Fackler wrote: > > In the admin interface for the individual list? Or is there some > mailman-global interface I don't yet know about? Per list. I’m not aware of any global interface either (global changes can be done by editing the mailman config). Jeff.

Re: Moving patches traffic to a another list?

In the admin interface for the individual list? Or is there some mailman-global interface I don't yet know about? On Tue, Apr 21, 2020, 18:36 Josef 'Jeff' Sipek wrote: > On Tue, Apr 21, 2020 at 18:09:37 -0400, Augie Fackler wrote: > > Presumably, but I honestly have no idea where to look.

Re: Moving patches traffic to a another list?

On Tue, Apr 21, 2020 at 18:09:37 -0400, Augie Fackler wrote: > Presumably, but I honestly have no idea where to look. Anyone? I'm guessing you want in the admin interface: "Privacy options..." and then "advertised" = yes Jeff. > > > On Apr 21, 2020, at 13:00, Gregory Szorc wrote: > > > > I

Re: Moving patches traffic to a another list?

Presumably, but I honestly have no idea where to look. Anyone? > On Apr 21, 2020, at 13:00, Gregory Szorc wrote: > > I don't see a new list at https://www.mercurial-scm.org/mailman/listinfo > . Are we missing a setting in > Mailman to make it

D8464: locking: wait for locks in `hg cp` and `hg mv`

spectral created this revision. Herald added a reviewer: hg-reviewers. Herald added a subscriber: mercurial-patches. REVISION SUMMARY I traced this back to revision 1822 (64df422 ), and there's no explanation why we

Re: Moving patches traffic to a another list?

I don't see a new list at https://www.mercurial-scm.org/mailman/listinfo. Are we missing a setting in Mailman to make it public? On Tue, Apr 21, 2020 at 12:39 AM Pierre-Yves David < pierre-yves.da...@ens-lyon.org> wrote: > I think the list is ready to receive visitor now. > > On 4/20/20 5:56 PM,

Re: Moving patches traffic to a another list?

I think the list is ready to receive visitor now. On 4/20/20 5:56 PM, Augie Fackler wrote: I think this is all squared away via IRC, please let me know if something looks amiss. On Apr 20, 2020, at 06:16, Pierre-Yves David wrote: I set the mailing list side up, but I am not sure of how do