Opened 4 weeks ago

Closed 4 days ago

#21194 closed enhancement (fixed)

mercurial-7.0

Reported by: Bruce Dubbs Owned by: pierre
Priority: elevated Milestone: 12.4
Component: BOOK Version: git
Severity: normal Keywords:
Cc:

Description

New point version.

IMO this package is a PITA. It only takes 0.3 SBU to build, but it takes 15 SBU to run tests.

It also seems to have a lot of releases. It was updated 4 times in the last six months.

In addition, we only reference it for cmake and setuptools_scm for tests, and it is optional for openjdk.

Lets wait until mid cycle (May).

Change History (14)

comment:1 by Douglas R. Reno, 11 days ago

Milestone: 99-Waiting12.4
Priority: normalelevated
Summary: mercurial-6.9.3 (Wait until May)mercurial-6.9.4

comment:2 by Douglas R. Reno, 8 days ago

Owner: changed from blfs-book to Douglas R. Reno
Status: newassigned

comment:3 by Douglas R. Reno, 7 days ago

Mercurial 6.9.4

* hgweb: fix XSS vulnerability in hgweb (CVE-2025-2361)

Mercurial 6.9.3

/!\ out of schedule release to fix a regression introduced in 6.9.2

    fix processing of superfluous requirements specified for streamclone in clone bundle 
manifest 

comment:4 by Douglas R. Reno, 6 days ago

Summary: mercurial-6.9.4mercurial-7.0

Now 7.0. This will need the addition of the 'build' python module

comment:5 by Douglas R. Reno, 6 days ago

Owner: changed from Douglas R. Reno to pierre
Status: assignednew

comment:6 by pierre, 6 days ago

Status: newassigned

Mercurial 7.0

Packaging Changes

The 7.0 release is the first to be compliant with PEP 517.

This required an overhaul of the Mercurial packaging: packagers should pay extra attention to this release and report any issues they might encounter with the new system.

In practice, this means that Mercurial's setup.py can no longer be called directly. Instead, one should build the Mercurial package using PyPA's build package (https://github.com/pypa/build). In the general case, this will take care of the build dependencies, but packagers might want to explicitly manage them. Currently the build depends on:

-wheel

-setuptools>=64

-setuptools_scm>=8.1.0

-docutils

The Makefile no longer offers a build target. We now use BuildTools 2022 when building Windows packages.

Other Backwards Compatibility Changes

-sslutil: bump the default minimum TLS version of the client to 1.2 (BC) (085cc409847d)

-setup: require TLS 1.2 support from the Python interpreter (BC) (a820a7a1fce0)

New Features

-It is now possible to store inline clone bundle outside of .hg (48572371d478)

-Added a generic storage.all-slow-path option to control the default behavior regarding degraded support for some repository format. (bbbb12632607)

-Added a --to flag to hg graft that allows graft in memory (68dc6cecca32)

-Added a fix.extra-bin-paths configuration for the fix extension (1330278b9029)

New Experimental Features

-add a --ignore-changes-from-ancestors option (688665425496)

-stream-clone: use dedicated threads to write the data on disk (7f848cfc4286, 58baa86c7a02, aee193b1c784)

-the experimental git extension now supports more commands

Bug Fixes

-subrepo: fix calling outgoing with multiple paths (85c095c1f8bc)

-stream clone: fix a race condition around volatile files (46574e588017, 3f0cf7bb3086)

-rhg: set the expected dirstate permissions (0o666 minus umask) (a48c688d3e80)

-rhg: fix matcher issue (136e74c2bf8f)

-rhg files correctly implements --rev (it instead provided --revision)

-clone-bundles: fix background spawning of automatic generation

-bundle-spec: properly format boolean parameter (issue6960)

-bundle2: fix a bug where _forwardchunks doesn't work with empty bundles

Rust

-the Rust code is now exposed to Python though PyO3 instead of rust-cpython (6673cec8605c)

-rhg: support status --change, including --copies (bde718849153)

-Rust implementation for the internal part of revlogs

-Rust implementation for hg annotate (6183949219b2)

-Rust implementation for hg update from a completely empty working copy

[1] Both rust-cpython and PyO3 bridges are present in this release in case users need to switch back (by changing every importrust call) in case something went really wrong in the translation. The rust-cpython code will be removed entirely in Mercurial 7.1.

Miscellaneous

-help: modernize the help text for hostsecurity.minimumprotocol (b65085c6d6ff)

-run-tests: add a 4th HGPORT value (7f8d0c2c3692)

-rust-ignore: make debugignorerhg command show a full regex, with exact files (e2e49069eeb6)

-tests: fix filtertraceback.py to handle contiguous File lines (8431296a93e8)

-typing: moved interface logic from zope interfaces to typing.Protocol (a1c0f19e7cb4)

-format: add pattern filtering to debugformat (8dede0df9de9)

-run-tests: add a --tail-report argument to analyze run parallelism (a814534aaedd)

comment:7 by pierre, 5 days ago

Eventually, it turns out the the "build" module is only needed for making a "wheel" package. make PREFIX=/usr install only uses pip (and probably wheel) AFAICT. In any case, I could run this (with PREFIX=<DESTDIR>/usr) without "build" installed.

But I am not sure: Should we use this all-in-one command or should we do "make wheel" and then install the wheel to the system?

comment:8 by Bruce Dubbs, 5 days ago

I also was able to build/install with only, in my case for testing, 'make PREFIX=/tmp/hg'. Using PREFIX=/usr should be good enough for us.

The problem is that the tests do not work. It's unclear if they are a rust (or rust version) problem or something else. We can always add "Does not come with a working test suite."

comment:9 by pierre, 4 days ago

Here is what I have found so far for tests:

  • make check fails with a lot of rust (cargo-clippy) errors
  • it is possible to bypass rust tests by running cd tests && pytnon3 run-tests.py, but:
    • first, since the command make PREFIX=/usr install is run as root, some files in the build directory are owned by root, and the tests want to remove them. This can be cured by running chown -R $USER:$USER . in the top build directory.
    • second, the tests stop quickly with
      fatal: fetching library from `hg` failed with 1:
      /tmp/hgtests.hu0u07c8/install/lib/python3.13/site-packages/mercurial
      

comment:10 by pierre, 4 days ago

But it seems python3 run-tests.py --with-hg /usr/bin/hg goes farther.

comment:11 by pierre, 4 days ago

cd tests && python3 run-tests.py --with-hg /usr/bin/hg reports:

# Ran 960 tests, 67 skipped, 0 failed

I guess a few less would be skipped if subversion python bindings were installed.

comment:12 by pierre, 4 days ago

Looks like make doc is part of the make install target (it builds the man and html docs), that only the man doc is installed and there is no target for installing html doc... It can be copied though.

comment:13 by Bruce Dubbs, 4 days ago

Nice work,

    sudo make $BFLAGS PREFIX=/usr install &&

    echo "BLFS Start CHECK"       &&
    sudo chown -R bdubbs:bdubbs . &&
    cd tests                      &&
    python3 run-tests.py --with-hg /usr/bin/hg

From the tests

running 1027 tests using 28 parallel processes
...
# Ran 963 tests, 64 skipped, 0 failed.
513.4 Elapsed Time -  mercurial-7.0

md5sum : 2e65ffe3d37b7ca716de63c01d93d4e4  /usr/src/mercurial/mercurial-7.0.tar.gz
8528 /usr/src/mercurial/mercurial-7.0.tar.gz SIZE (8.328 MB)
145184 kilobytes BUILD SIZE (141.781 MB)
SBU=5.901

BFLAGS=-j28

I had run the tests earlier with sudo and got 7 errors.

The builds/install time was about 30 seconds. I really don't like to run tests on packages where the test time is 10x the build time.

Not sure what we should use for the name used by chown in qthe book. Perhaps $LOGNAME:$LOGNAME

comment:14 by pierre, 4 days ago

Resolution: fixed
Status: assignedclosed

Hmm, why isn't there a "reply" button? With the --with-hg ... option, there is no need to change owner in the build directory, so that the question of the user name is not relevant. Fixed at e0cf28a3f9

Note: See TracTickets for help on using tickets.