- Nov 04, 2024
-
-
Raphaël Gomès authored
This is more explicit and will not be confused with `len`.
-
- Oct 29, 2024
-
-
Raphaël Gomès authored
`open` being read *and* write is surprising because it differs from the Rust stdlib where `std::fs::File::open` is read-only by default. More importantly, writing is more dangerous than reading, so let's make it more explicit.
-
Raphaël Gomès authored
This was the warning by clippy 1.82.0, which explains the change: ``` warning: this function depends on never type fallback being `()` --> hg-core/src/dirstate_tree/status.rs:397:5 | 397 | / fn traverse_fs_directory_and_dirstate<'ancestor>( 398 | | &self, 399 | | has_ignored_ancestor: &'ancestor HasIgnoredAncestor<'ancestor>, 400 | | dirstate_nodes: ChildNodesRef<'tree, 'on_disk>, ... | 404 | | is_at_repo_root: bool, 405 | | ) -> Result<bool, DirstateV2ParseError> { | |___________________________________________^ | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #123748 <https://github.com/rust-lang/rust/issues/123748> = help: specify the types explicitly note: in edition 2024, the requirement `!: rayon::iter::FromParallelIterator<()>` will fail --> hg-core/src/dirstate_tree/status.rs:453:28 | 453 | .collect::<Result<_, _>>()?; | ^^^^^^^^^^^^ = note: `#[warn(dependency_on_unit_never_type_fallback)]` on by default ```
-
Raphaël Gomès authored
This test wasn't testing anything anymore since the feature has been removed. This was caught by clippy 1.82.0.
-
Raphaël Gomès authored
These were highlighted by the latest version of clippy (1.82.0).
-
Raphaël Gomès authored
This normalizes the naming scheme between the `Revlog`, `Changelog`, etc. which is less suprising, though no real bugs could stem from this because of the type signature mismatch. The very high-level `Repo` object still uses an `UncheckedRevision` parameter for its methods because that's what most callers will want.
-
- Nov 12, 2024
-
-
Pierre-Yves David authored
We have over ten thousands old pipeline that take a huge space and that I suspect to be the source of some slowdown in merge request. However it seems that the only way to clear them is manually and through the API, so lets do it. The script was run today.
-
Matt Harbison authored
TLS v1.0 and v1.1 are deprecated by RFC8996[1]: These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018)... Various browsers have disabled or removed it[2][3][4], as have various internet services, and Windows 11 has it disabled by default[5]. We should move on too. (We should also bump it on the server side, as this config only affects clients not allowing a server to negotiate down. But the only server-side config is a `devel` option to pick exactly one protocol version and is commented as a footgun, so I'm hesitant to touch that. See 7dec5e441bf7 for details, which states that using `hg serve` directly isn't expected for a web service.) I'm not knowledgeable enough in this area to know if we should follow up with disabling certain ciphers too. But this should provide better security on its own. [1] https://datatracker.ietf.org/doc/rfc8996/ [2] https://learn.microsoft.com/en-us/DeployEdge/microsoft-edge-policies#sslversionmin [3] https://hacks.mozilla.org/2020/02/its-the-boot-for-tls-1-0-and-tls-1-1/ [4] https://security.googleblog.com/2018/10/modernizing-transport-security.html [5] https://techcommunity.microsoft.com/blog/windows-itpro-blog/tls-1-0-and-tls-1-1-soon-to-be-disabled-in-windows/3887947
-
- Nov 11, 2024
-
-
Matt Harbison authored
Two issues here: 1) We're well past Pythons that only support TLSv1.0 (py27 supports v1.2) 2) It never occurred to me that this is a client-only setting
-
Matt Harbison authored
This is easier to manage, and avoids one nested conditional. There is one final sweep of killing individual servers near the end, but that's left alone because there's a comment about not killing `tinyproxy.py`, due to potentially emitting additional output.
-
- Dec 22, 2020
-
-
Matt Harbison authored
AFAICT, all of the TLS versions are supported by the server without doing any explicit work, and there's only a `devel` config to specify an exact version on the server side. Clients would also use TLSv1.3 if available, but this prevents the server from negotiating down. This also causes "tls1.3" to be listed in `hg debuginstall`, even though it was previously supported (if the Python intepreter supported it- IDK if there's a good way to proactively test for and show future protocols without requiring manual updates like this). The v1.3 tests are nested inside the v1.2 tests for simplicity. The v1.2 blocks already assume v1.0 and v1.1 support, so this seems reasonable for now. If/when the older protocols start getting dropped, this will have to be reworked anyway.
-
- Dec 21, 2020
-
-
Matt Harbison authored
I want to add tls1.3 support, and test-https.t already uses the existing ports to test tls1.0 through 1.2. It doesn't look to me like it can easily be converted to a bunch of #testcases, because this also tests downgrades to prior versions for the given client version. This partially reverts bc010fcd836b.
-
- Nov 11, 2024
-
-
Matt Harbison authored
The last usage was removed in 94cf83d9a2c9.
-
- Nov 20, 2024
-
-
Matt Harbison authored
-
- Nov 09, 2024
-
-
Matt Harbison authored
There's also a block of code around line 47 related to `ssl.HAS_TLSv1` to determine the supported protocols that references "Python 3.7", but I'm not altering that because the commit referenced there wasn't landed until just prior to the 3.9 release, and I'm not sure what flavors of py38 might not have a backport. Avoid de-indenting for now for a clearer text diff.
-
- Nov 12, 2024
-
-
Raphaël Gomès authored
While writing a very dumb manifest diffing algorithm for a proof-of-concept I saw that `Manifest::find_by_path` was much slower than I was expecting. It turns out that the Rust stdlib uses slow (all is relative) code when searching for byte positions for reasons ranging from portability, SIMD API stability, nobody doing the work, etc. `memch` is much faster for these purposes, so let's use it. I was measuring ~670ms of profile time in `find_by_path`, after this patch it went down to ~230ms.
-
- Oct 31, 2024
-
-
Brian Hulette authored
-
- Nov 20, 2024
-
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
Raphaël Gomès authored
I've folded bugfixes that only exist to fix 6.9-specific things to the best of my attention span for this task.
-
Pierre-Yves David authored
I hope this is not too scary, but as discussed last month, we need to have a better compatibility story before pushing more people toward Rust.
-
Pierre-Yves David authored
As discussed last Friday after publishing the rc wheel, we need to update the rust readme and highlight that change in the release announcement if we want people using Rust to keep being able to use pip.
-
Pierre-Yves David authored
Sight.
-
- Nov 13, 2024
-
-
Pierre-Yves David authored
We don't test them yet, but we build them, as as many other flavors.
-
- Nov 16, 2024
-
-
Matt Harbison authored
This is mostly a translation of `contrib/packaging/build-windows-wheels.bat`, except the default pythons to build can be inferred from `setup.py` and/or `pyproject.toml`, and all use the same configuration. All we need to do is force the building of translation files, tell it to skip pypy wheels, and tell it to build universal2 wheels instead of for the current architecture.
-
- Nov 18, 2024
-
-
Raphaël Gomès authored
Possibly we would have caught the looming bug earlier if this had been named closer to what it actual is used for.
-
Raphaël Gomès authored
This is not currently a problem since the options are the same, but would have become one at some point in the future.
-
- Nov 15, 2024
-
-
Pierre-Yves David authored
The embarrassing details of how this was discovered will be kept under silence.
-
Pierre-Yves David authored
We no longer run the test while building wheels as they are build the very same ways as in the CI (that run tests).
-
- Nov 14, 2024
-
-
Matt Harbison authored
This is duplicated from the current CI config, to be able to build releases consistently outside of CI. I don't like the duplication, but I'm not worried about things changing too often, so I'm not bothering with PowerShell or some form that would allow execution by the CI runner. We should consider putting the config in `pyproject.toml`, where things like what python versions to support can be centrally controlled for all platforms. The output directory is different from CI here, but that's fine because it is intended to run this on a system that is *not* hosting the CI setup, and `dist/` is more standard. I dropped the `win32` part of the output because that implies the 32-bit Intel architecture. Apparently, arm64 builds are supported back to Python 3.9, but support is still experimental (with py3.13)[1]. The CI system starts arm64 support with Python 3.11, because that's the first version that an arm64 Python installer was available on Windows. This doesn't second guess that decision. The required `msgfmt.exe` was installed manually[2], as it isn't currently handled by the dependency installation script. Otherwise, this was successfully used with an activated venv based on Python 3.12.5, and only `cibuildwheel==2.21.3` installed. [1] https://cibuildwheel.pypa.io/en/stable/#what-does-it-do [2] https://github.com/mlocati/gettext-iconv-windows/releases/download/v0.22.5a-v1.17-r3/gettext0.22.5a-iconv1.17-shared-64.exe
-
Matt Harbison authored
This lets us build arm64 wheels on Windows. We should update from VS 2017 to VS 2019, but that can wait until there's a clean Windows system available. There's a little bit of handwaving here because I originally installed some packages on the CI system by checking boxes in the GUI installer to get arm64 support, since I didn't know the name(s) of the things needed. Exporting the configuration from the GUI installer showed the list of things present, and then I was able to run `vs_buildtools.exe` on another system that previously had this dependency script run a few years ago, with just this new arg. That allowed the wheels to be built (the process failed on this second system prior to this). The only difference between the CI system configuration prior to installing arm64 stuff and this second system after, is the second system has the WinXP support component. Surprisingly, the arm64 WDK and arm64 CRT or Universal CRT doesn't seem to be required.
-
- Nov 15, 2024
-
-
Pierre-Yves David authored
People of weird hardware use i686 so testing the building it useful.
-
Pierre-Yves David authored
We now have image to make that work.
-
Pierre-Yves David authored
We add a trigger to not run that all the time.
-
- Nov 14, 2024
-
-
Pierre-Yves David authored
These can be installed on alpine… which is quite useful.
-
- Nov 15, 2024
-
-
Pierre-Yves David authored
This will make introduction of more variant simpler and testing quicker
-
Pierre-Yves David authored
This is useful when using --jobs for example
-
Pierre-Yves David authored
It is currently broken.
-
Pierre-Yves David authored
The image should now have the proper config set globally to access this
-