Skip to content
Snippets Groups Projects
  1. Mar 17, 2025
  2. Mar 14, 2025
  3. Mar 12, 2025
  4. Mar 06, 2025
  5. Mar 11, 2025
  6. Mar 10, 2025
    • Pierre-Yves David's avatar
      nightly-build: attempt to no longer choke on existing file · 6e1eb7212633
      Pierre-Yves David authored
      When we run the job multiple time, the upload step fails because the file always
      exists. So we pass the `--skip-existing` flag that is supposed to help with
      that… when supported.
      
      This might have no effect outside of upload to PyPI as the doc says:
      
          Continue uploading files if one already exists. (Only valid when uploading
          to PyPI. Other implementations may not support this.)
      6e1eb7212633
  7. Feb 28, 2025
  8. Mar 06, 2025
  9. Mar 05, 2025
  10. Mar 01, 2025
  11. Feb 28, 2025
  12. Feb 25, 2025
  13. Feb 26, 2025
    • Raphaël Gomès's avatar
      rhg-files: use the correct long-form flag for selecting a revision · 65f6f1fe43ef
      Raphaël Gomès authored
      This went unnoticed forever, I guess most users pass in `-r`.
      65f6f1fe43ef
    • Matt Harbison's avatar
      packaging: fetch gettext dependencies from m-s.o instead of sourceforge · 0570351db4e7
      Matt Harbison authored
      The SourceForge packages were working as recently as late last week, and then
      yesterday I suddenly got a failure that the size of the download changed from
      what was expected.  Let's not trust SourceForge for critical things (though
      the MinGW package manager likely uses that too; I'm not sure how to fix that).
      
      We probably don't need this at all, now that `install-windows-dependencies.ps1`
      installs `gettext` 0.22.5 since da74e81ef9af.  But I don't feel like tinkering
      with the packaging code at this point, and running that PowerShell script in CI
      is probably pretty heavy handed.
      0570351db4e7
  14. Feb 24, 2025
    • Mitchell Kember's avatar
      rust-annotate: do not impl Sync for Lines · 3ac28aa1430e
      Mitchell Kember authored
      I failed to notice before that bdiff_diff mutates its inputs by storing
      bookkeeping information in the `n` and `e` fields. This means &Lines can't be
      shared across threads, so Lines cannot be Sync. Fortunately nothing was using
      this. The parallel file reading and line splitting only relies on Send.
      
      The reason I didn't notice this to begin with was that Lines contains a
      *mut ffi::bdiffline, which is accessible from &Lines, so I never wrote or
      thought about &mut Lines. This pattern (using a mutable pointer stored in an
      immutable struct) would be expressed with RefCell if this was pure safe Rust.
      3ac28aa1430e
  15. Feb 25, 2025
  16. Feb 22, 2025
    • Matt Harbison's avatar
      setup: drop the inaccessible `py2exehacked` code around distutils · e2c239dae5a2
      Matt Harbison authored
      The comment heavily implies, and experimenting confirms, that there's no
      `sys.real_prefix` in a venv on Python3.  I have no idea how the problems
      described would manifest, but nobody has complained for the several years of
      py3 releases build from a venv.  The experimenting was done with 6.9.2 and the
      TortoiseHg build script.
      e2c239dae5a2
  17. Feb 24, 2025
    • Matt Harbison's avatar
      docs: update the IRC channel reference in the Windows readme · 80ec613fea43
      Matt Harbison authored
      I noticed this when trying the Inno installer.
      80ec613fea43
    • Matt Harbison's avatar
      packaging: adapt `__version__.py` parsing for `setuptools_scm` output · d333e14477f1
      Matt Harbison authored
      The file is now generated by `setuptools_scm`, which stores values as strings
      with strong quotes.  This avoids the following failure at the end of the Inno
      installer build:
      
              <snip>
              creating installer
              Traceback (most recent call last):
                File "c:\Users\Matt\projects\mercurial\mercurial-devel\contrib\packaging\packaging.py", line 70, in <module>
                  run()
                File "c:\Users\Matt\projects\mercurial\mercurial-devel\contrib\packaging\packaging.py", line 62, in run
                  cli.main()
                File "c:\Users\Matt\projects\mercurial\mercurial-devel\contrib\packaging\hgpackaging\cli.py", line 154, in main
                  args.func(**kwargs)
                File "c:\Users\Matt\projects\mercurial\mercurial-devel\contrib\packaging\hgpackaging\cli.py", line 35, in build_inno
                  inno.build_with_pyoxidizer(
                File "c:\Users\Matt\projects\mercurial\mercurial-devel\contrib\packaging\hgpackaging\inno.py", line 55, in build_with_pyoxidizer
                  build_installer(
                File "c:\Users\Matt\projects\mercurial\mercurial-devel\contrib\packaging\hgpackaging\inno.py", line 146, in build_installer
                  version = read_version_py(source_dir)
                File "c:\Users\Matt\projects\mercurial\mercurial-devel\contrib\packaging\hgpackaging\util.py", line 188, in read_version_py
                  raise Exception('could not parse %s' % p)
              Exception: could not parse c:\Users\Matt\projects\mercurial\mercurial-devel\mercurial\__version__.py
      
      Note that non-tagged builds end up with complex version strings, and include
      characters that WiX rejects.  That's probably fine- we don't do nightly or other
      non-tagged builds for installers.
      
      Also note that while the Inno installer is capable of using this version string
      as part of the installer, the WiX installer is not for some reason.  That
      installer needs to be built with `--version VERSION` to inject the version into
      the installer metadata and the filename.
      d333e14477f1
    • Matt Harbison's avatar
      contrib: add modern `setuptools` and `setuptools_scm` to the packaging venv · 0e2be2abd963
      Matt Harbison authored
      With `py -3.9 contrib/packaging/packaging.py wix --pyoxidizer-target x86_64-pc-windows-msvc`,
      there is an immediate failure after building the venv (3.9.13 has `setuptools`
      58.1.0):
      
          ModuleNotFoundError: No module named 'setuptools.command.build'
      
      With that fixed, the same command then fails immediately with this error:
      
          Couldn't import setuptools_scm (direct call of setup.py?)
      
      Unfortunately, referencing `setuptools` in the requirements file needs
      `--allow-unsafe` to avoid a warning about not pinning `setuptools`.  However,
      the same warning happens if `setuptools` is pinned to a specific revision, so I
      have no idea what it is complaining about.  It's a separate venv that is only
      used for packaging, so we can fix it if it becomes a problem in the future.
      
      Interestingly, the Inno installer build doesn't fail immediately, and I can see
      it installing `setuptools` and `setuptools_scm` in the wall of text it emits.
      Eventually it does fail with the same errors without this change.
      0e2be2abd963
  18. Feb 22, 2025
Loading