This instance will be upgraded to Heptapod 0.21.0rc2 on 2021-04-16 at 11:00 UTC+2 (a few minutes of down time)

  1. 21 Jul, 2020 1 commit
    • muxator's avatar
      py3: fix drag & drop in the Repository Registry · bff76ec4059e
      muxator authored
      Before this change, dragging & dropping repositories across groups in the
      registry was not working on py3: at drop, the message b'Start tag expected.'
      was printed in the console, but nothing happened.
      
      The reason is that QMimeData::data() returns a QByteArray containing an XML
      document that was passed through str() and directly fed to
      repotreemodel.readXml(), which instead expects either a unicode string or
      bytes.
      
      This change converts the QByteArray to bytes(), and restores the drag & drop
      functionality in the Repo Registry.
      
      --HG--
      branch : stable
      bff76ec4059e
  2. 14 Jul, 2020 5 commits
  3. 11 Jun, 2020 2 commits
  4. 19 Jul, 2020 3 commits
  5. 18 Jul, 2020 1 commit
  6. 10 Jul, 2020 2 commits
  7. 15 Jul, 2020 1 commit
  8. 14 Jul, 2020 1 commit
  9. 04 Jun, 2020 1 commit
    • Manuel Jacob's avatar
      ci: add .gitlab-ci.yml · 10996640148f
      Manuel Jacob authored
      The .gitlab-ci.yml file was generated by the contrib/generate_gitlab_ci_yml.py
      script.
      
      At first, I tried to avoid "code" duplication using GitLab and YAML features.
      However, support for that is very incomplete. After spending too much time
      reading low-quality blog posts and inconclusive discussions on the GitLab issue
      tracker about (not) adding better support for that, I gave up and wrote a
      Python script generating the .gitlab-ci.yml file.
      
      --HG--
      branch : stable
      10996640148f
  10. 10 Jul, 2020 5 commits
  11. 29 Jun, 2020 1 commit
    • Matt Harbison's avatar
      about: migrate to `latest.dat` on mercurial-scm.org for upgrade checks · 20f9aee27152
      Matt Harbison authored
      This represents both a file format and host change.  The file on the server was
      copied from a source used to advertise core Mercurial installers, so we're
      reusing existing conventions.  It has a distinct pattern for WOW64 User-Agents
      vs 64bit ones.  (Currently, both patterns point to the same file.)
      
      Yuya expressed concern about blindly using regex patterns from the server, so
      there's a check to filter out anything that's not trivial.  I toyed with the
      idea of just checking substrings in each pattern, but it got hard to cover all
      of the cases that the pattern matching provides.  For example x86 Windows needs
      to know about x64 Windows in order to actively ignore x64 packages.  With
      pattern matching, x86 Windows only needs to know about itself when emulating the
      User-Agent.  I also toyed with the idea that matching any OS substring was OK
      (e.g. any pattern containing "Windows").  But that won't work because I can
      eventually see x86 Windows being frozen in time at the last version, and it
      would be annoying if the x86 builds reported an update anyway.
      
      Either of those rejected options could mean extra coordination with any changes
      to the file on the server.  Overall, it seems better to have a single, unified
      method of checking for upgrades from web browsers and the application,
      especially because there's enough I forget about doing the package uploads once
      per month already.
      
      There is near-identical code in the bugreporter module, but I don't see an
      obvious, shareable place to store this code.  The existing version modules seem
      minimal by design, and various other util modules seem even less related.
      
      --HG--
      branch : stable
      20f9aee27152
  12. 12 Feb, 2020 1 commit
    • Matt Harbison's avatar
      packaging: distribute OpenSSL 1.0.2t on Windows · 7e572dbf5cb7
      Matt Harbison authored
      This is needed to make version checks work.  These were dropped accidentally(?)
      in thg/winbuild 07c551483c40 when libsvn was removed.  Therefore, this will
      require an updated winbuild repo.
      
      Even though it's now EOL, Qt5.9 only supported 1.0.2.  There is a 1.0.2u build,
      but I'm using this version because that is what is reported by the following,
      even when building 1.0.2u:
      
          >>> from PyQt5 import QtNetwork
          >>> print(QtNetwork.QSslSocket.sslLibraryBuildVersionString())
          OpenSSL 1.0.2t  10 Sep 2019
      
      This does report 1.0.2u, when added to the virtualenv:
      
          >>> print(QtNetwork.QSslSocket.sslLibraryVersionString())
          OpenSSL 1.0.2u  20 Dec 2019
      
      Unlike the other command line configurable items, this just assumes that `perl`
      and `nasm` are on PATH because it seems unlikely that selecting other versions
      is useful.
      
      --HG--
      branch : stable
      7e572dbf5cb7
  13. 07 Jul, 2020 1 commit
    • Matt Harbison's avatar
      packaging: fix specifying an output path on Windows · cc5ac4776d71
      Matt Harbison authored
      Not sure when I broke this, because the virtualenvs being used to build the
      installers were definitely put in a specific location.  It was probably just
      missed in some last minute cleanup.
      
      --HG--
      branch : stable
      cc5ac4776d71
  14. 16 Feb, 2020 1 commit
  15. 27 Jun, 2020 1 commit
  16. 25 Jun, 2020 1 commit
  17. 18 Apr, 2020 2 commits
  18. 07 Jun, 2019 1 commit
    • Matt Harbison's avatar
      wix: add missing template files · 8f35e3e09471
      Matt Harbison authored
      Based on a PR on BitBucket by Micha Wiedenmann <mw-r1@gmx.de>.
      
      This fixes a bug when using `hg serve` and clicking on the "Graph" item. (The
      browser shows "Internal Server Error" for <http://localhost:8000/graph/tip>) and
      the console shows:
      
      ```
      127.0.0.1 - - [07/Jun/2019 10:20:22] Exception happened during processing request '/graph/tip':
      Traceback (most recent call last):
        File "mercurial\hgweb\server.pyo", line 102, in do_POST
        File "mercurial\hgweb\server.pyo", line 95, in do_write
        File "mercurial\hgweb\server.pyo", line 198, in do_hgweb
        File "mercurial\hgweb\hgweb_mod.pyo", line 310, in run_wsgi
        File "mercurial\hgweb\hgweb_mod.pyo", line 430, in _runwsgi
        File "mercurial\hgweb\webcommands.pyo", line 1379, in graph
        File "mercurial\hgweb\hgweb_mod.pyo", line 196, in sendtemplate
        File "mercurial\templater.pyo", line 942, in generate
        File "mercurial\templater.pyo", line 706, in process
        File "mercurial\templater.pyo", line 681, in _load
        File "mercurial\templater.pyo", line 381, in compileexp
        File "mercurial\templater.pyo", line 413, in buildtemplate
        File "mercurial\templater.pyo", line 381, in compileexp
        File "mercurial\templater.pyo", line 430, in buildmap
        File "mercurial\templater.pyo", line 406, in gettemplate
        File "mercurial\templater.pyo", line 677, in _load
        File "mercurial\templater.pyo", line 814, in load
      IOError: [Errno 2] template file C:\Program Files\TortoiseHg\templates\paper\graphentry.tmpl: No such file or directory
      ```
      
      --HG--
      branch : stable
      8f35e3e09471
  19. 27 Jun, 2020 3 commits
    • Matt Harbison's avatar
      py3: fix a str vs bytes issue loading MQ patches (fixes #5541) · a650db5c379a
      Matt Harbison authored
      --HG--
      branch : stable
      a650db5c379a
    • Matt Harbison's avatar
      py3: byteify tortoisehg.util.patchctx · 81e15879e3f9
      Matt Harbison authored
      In testing the next fix, I hit this with an (unapplied) MQ patch that didn't
      have a branch name:
      
          Traceback (most recent call last):
            File "c:\Users\Matt\projects\thg_py3\tortoisehg\hgqt\repomodel.py", line 791, in _getrevlabels
              branchheads = self._branchheads[branch]
          KeyError: ''
      
      The strange thing is that it didn't trigger the exception from the handling
      block, though prints confirm it entered the `except` clause.
      
      At any rate, this class looks like it is trying to be a replacement for the
      `context` class in core, so it should deal in bytes.
      
      --HG--
      branch : stable
      81e15879e3f9
    • Matt Harbison's avatar
      sync: fix an encoding issue when writing out settings · 5226b74d2b75
      Matt Harbison authored
      Found this working on the previous fix.  The type of `val` is `bytes` or `bool`
      according to the type annotation.  That was causing an empty setting to be
      displayed as `b''` after closing the options dialog.  I also somehow managed to
      get a QVariant type written to the config file, which causes issues when
      relaunching.  Not sure if that was related, but I haven't seen it since fixing
      this.
      
      --HG--
      branch : stable
      5226b74d2b75
  20. 18 Jun, 2020 2 commits
  21. 13 Jun, 2020 3 commits
  22. 06 Jun, 2020 1 commit