Skip to content
Snippets Groups Projects
  1. Feb 02, 2021
  2. Feb 01, 2021
  3. Jan 27, 2021
    • Kyle Lippincott's avatar
      wix: tell ComponentSearch that it is finding a directory (not a file) · 8deab876
      Kyle Lippincott authored
      This is to fix an issue we've noticed where fresh installations start at
      `C:\Program Files\Mercurial`, and then upgrades "walk up" the tree and end up in
      `C:\Program Files` and finally `C:\` (where they stay).
      
      ComponentSearch defaults to finding files, which I think means "it produces a
      string like `C:\Program Files\Mercurial`", whereas with the type being
      explicitly a directory, it would return `C:\Program Files\Mercurial\` (note the
      final trailing backslash). Presumably, a latter step then tries to turn that
      file name into a proper directory, by removing everything after the last `\`.
      
      This could likely also be fixed by actually searching for the component for
      hg.exe itself. That seemed a lot more complicated, as the GUID for hg.exe isn't
      known in this file (it's one of the "auto-derived" ones). We could also consider
      adding a Condition that I think could check the Property and ensure it's either
      empty or ends in a trailing slash, but that would be an installer runtime check
      and I'm not convinced it'd actually be useful.
      
      This will *not* cause existing installations that are in one of the bad
      directories to fix themselves. Doing that would require a fair amount more
      understanding of wix and windows installer than I have, and it *probably*
      wouldn't be possible to be 100% correct about it either (there's nothing
      preventing a user from intentionally installing it in C:\, though I don't know
      why they would do so).
      
      If someone wants to tackle fixing existing installations, I think that the first
      installation is actually the only one that shows up in "Add or Remove Programs",
      and that its registry keys still exist. You might be able to find something
      under HKEY_USERS that lists both the "good" and the "bad" InstallDirs. Mine was
      under `HKEY_USERS\S-1-5-18\Software\Mercurial\InstallDir` (C:\), and
      `HKEY_USERS\S-1-5-21-..numbers..\Software\Mercurial\InstallDir` (C:\Program
      Files\Mercurial). If you find exactly two, with one being the default path, and
      the other being a prefix of it, the user almost certainly hit this bug :D
      
      We had originally thought that this bug might be due to unattended
      installations/upgrades, but I no longer think that's the case. We were able to
      reproduce the issue by uninstalling all copies of Mercurial I could find,
      installing one version (it chose the correct location), and then starting the
      installer for a different version (higher or lower didn't matter). I did not
      need to deal with an unattended or headless installation/upgrade to trigger the
      issue, but it's possible that my system was "primed" for this bug to happen
      because of a previous unattended installation/upgrade.
      
      Differential Revision: https://phab.mercurial-scm.org/D9891
      8deab876
  4. Jan 29, 2021
  5. Jan 27, 2021
  6. Jan 26, 2021
  7. Jan 25, 2021
  8. Dec 01, 2020
  9. Jan 25, 2021
  10. Dec 14, 2020
  11. Jan 08, 2021
  12. Dec 04, 2020
  13. Jan 15, 2021
  14. Dec 02, 2020
  15. Jan 15, 2021
  16. Jan 08, 2021
  17. Jan 13, 2021
  18. Jan 11, 2021
  19. Jan 06, 2021
  20. Dec 19, 2020
  21. Dec 12, 2020
  22. Dec 01, 2020
  23. Dec 05, 2020
  24. Nov 26, 2020
  25. Dec 03, 2020
  26. Nov 28, 2020
  27. Nov 30, 2020
  28. Nov 26, 2020
    • Matt Harbison's avatar
      packaging: add pygit2 to the py3 Windows installers · d2649781
      Matt Harbison authored
      This is needed to be able to use the git extension.
      
      The extension no longer complains about the library being not installed, but
      `hg log -r .` on a repo that works in WSL yielded a TypeError:
      
            ...
            File "mercurial.hg", line 188, in _peerorrepo
            File "mercurial.localrepo", line 3224, in instance
            File "mercurial.localrepo", line 623, in makelocalrepository
            File "hgext.git", line 117, in _makestore
            File "hgext.git", line 48, in __init__
          TypeError: Repository unable to unpack backend.
      
      Differential Revision: https://phab.mercurial-scm.org/D9405
      d2649781
  29. Nov 24, 2020
    • Matt Harbison's avatar
      packaging: drop Disco (19.04) and add Focal (20.04) · 97142451
      Matt Harbison authored
      Disco support ended in January 2020, and Focal does not have an announced EOL.
      
      Something is now installing and configuring `tzdata`, which was throwing up an
      interactive prompt to configure the timezone.  Aside from being hostile to
      automation, the prompt didn't actually accept input and hung the process.  This
      propagates the host's timezone into the image via environment variable in order
      to skip the prompt, and avoid hardcoding a value.
      
      Differential Revision: https://phab.mercurial-scm.org/D9396
      97142451
    • Matt Harbison's avatar
      packaging: add `HG_DOCKER_OWN_USER` to `dockerdeb` like exists in `dockerrpm` · f6a1540d
      Matt Harbison authored
      I was getting build failures when it was trying to write to the working
      directory on CentOS 7 without this.  It is basically the same as was added to
      the RPM builder in 4c0d4bbdc395.
      
      For some reason, this doesn't work with Xenial, and the only solution I found
      was to invoke it with UID 1000 on the host side.  It doesn't EOL until April
      2024, but it also has python 3.5.2, so this build complication is the least of
      the problems with supporting it after py2 is dropped.
      
      Differential Revision: https://phab.mercurial-scm.org/D9394
      f6a1540d
  30. Nov 29, 2020
Loading