utils: stop using datetime.utcfromtimestamp() deprecated in Python 3.12 Python3.12 made tests fail with warnings: DeprecationWarning: datetime.utcfromtimestamp() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.fromtimestamp(timestamp, datetime.UTC). Computing the diff while in timestamp seconds seems to preserve to the original intent from ae04af1ce78d. It would be nice to have some doctest coverage of this, with the problematic corner cases that has popped up over time...

branching: merge stable into default

Added signature for changeset 3ffc7209bbae

Added tag 6.5 for changeset 3ffc7209bbae

relnotes: add 6.5 final

rust-changelog: removed now useless early conditional for NULL_REVISION Now that the underlying `RevlogEntry` returned for `NULL_REVISION` is viable, it has become pointless to check NULL_REVISION several times, even for performance: the check will be far more frequent than the benefit of bailing earlier in the rare case where the requested revision is `NULL_REVISION`. This case is covered explicitly by the first assertion of `test_data_from_rev_null`.

rust-revlog: fix RevlogEntry.data() for NULL_REVISION Before this change, the pseudo-entry returned by `Revlog.get_entry` for `NULL_REVISION` would trigger errors in application code using it. For example, this fixes a crash spotted with changelog data while implementing RHGitaly: `Changelog.data_for_rev(-1)` was already returning the pseudo content as expected, e.g., for `hg log`, but `Changelog.entry_for_rev(-1).data()` would still crash with "corrupted revlog, hash check failed for revision -1". There is an added test for this scenario.

rust-revlog: using constant in test Always better

rust-revlog: fix incorrect results with NULL_NODE prefixes In case a short hash is a prefix of `NULL_NODE`, the correct revision number lookup is `NULL_REVISION` only if there is no match in the nodemap. Indeed, if there is a single nodemap match, then it is an ambiguity with the always matching `NULL_NODE`. Before this change, using the Mercurial development repository as a testbed (it has public changesets with node ID starting with `0005` and `0009`), this is what `rhg` did (plain `hg` provided for reference) ``` $ rust/target/debug/rhg cat -r 000 README README: no such file in rev 000000000000 $ hg cat -r 000 README abort: ambiguous revision identifier: 000 ``` Here is the expected output for `rhg` on ambiguous prefixes (again, before this change): ``` $ rust/target/debug/rhg cat -r 0001 README abort: ambiguous revision identifier: 0001 ``` The test provided by 8c29af0f6d6e in `test-rhg.t` could become flaky with this change, unless all hashes are fixed. We expect reviewers to be more sure about that than we are.

rust-revlog: split out method for `rev_from_node` without persistent nodemap This will make easier for the bug fix that is about to come.

win32mbcs: unbyteify some strings for py3 support A crash was reported on the TortoiseHg bug tracker for this[1]. [1] https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5905

heptapod-ci: turn off pipelines for merge request events These are always duplicated by the external (from the user) push, or internal (from Heptapod itself) push pipeline, so they're entirely redundant.

heptapod-ci: always make the default run condition explicit This has no effect on behavior, it's just to make everything obvious.

heptapod-ci: remove push exception for named branches The internal workings of Heptapod cause even fast-forward merges to look like pushes to Gitlab. The only way to run a pipeline on topic-less named branches is not through the web interface. I am probably the only person affected by this, so it's not really a problem. This was confirmed with Georges, the maintainer of Heptapod, though the only way to be *actually* sure, is to merge this and see.

heptapod-ci: (hopefully) fix the pipeline savings system There is no easy way for me to test this outside of the actual repo since it would require setting up `heptapod-runner` locally, making a Git repo with the right changes, etc. It's not worth my time at this point. If this fails, I'll try to ask for help from Georges, the maintainer of Heptapod.

heptapod-ci: don't run pipelines for topic-less branches See inline comment for more details.

clonebundles: add warning if auto-generate is enabled without formats

clonebundles: fix display of auto-generate.on-change lines

hgweb: drop references to deprecated cgitb cgitb is going away and gives warnings when importing, and that make tests fail: $TESTTMP/hgweb.cgi:5: DeprecationWarning: 'cgitb' is deprecated and slated for removal in Python 3.13 The lack of a "nice" high level error handler is not a huge problem, neither for users (where it is disabled anyway) or for tests (where we don't use a browser and the plain tracebacks often are more readable). It is inevitable that it is going away, and there is no obvious alternative. Remove it and move on.

setup: fall back to setuptools setup if distutils isn't available The setuptools comments around this seems slightly outdated. Setuptools is improving and distutils is being deprecated, so it should perhaps be the default. But at least, it is a fair fallback.

tests: use simple mock smtp server instead of deprecated asyncore smtpd test-patchbomb-tls.t would fail with: .../hg/tests/dummysmtpd.py:6: DeprecationWarning: The asyncore module is deprecated and will be removed in Python 3.12. The recommended replacement is asyncio import asyncore .../hg/tests/dummysmtpd.py:8: DeprecationWarning: The smtpd module is deprecated and unmaintained and will be removed in Python 3.12. Please see aiosmtpd (https://aiosmtpd.readthedocs.io/) for the recommended replacement. import smtpd The recommended migration path to the standalone asiosmtpd would be overkill. The tests do not need a full smtp server - we can just use a very simple mock hack to preserve the existing test coverage.

tests: fix dummysmtpd argument check

tests: improve test-patchbomb-tls.t by by logging errors and data The actual SSL error might be like: ::1 ssl error: [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:1002) and will probably vary so much that it can't be checked in the test. It is however very useful when debugging failures.

tests: show test-patchbomb-tls.t smtp server log Improve test coverage by exposing what the smtp server actually receives. Make dummystmtpd redirect stderr to a log file.