Skip to content
Snippets Groups Projects
  1. Mar 02, 2023
    • Robin Steuber's avatar
      Bug 1815019 - Customize 7z to write provenance data r=nalexander · 2f864174
      Robin Steuber authored
      This patch was heavily inspired by the existing 7z customizations that read the download token into the "postSigningData" file. In both cases, the installation self-extractor copies some data into the same temporary directory where the installer is written. It will then be up to the NSIS installer to copy that file into the installation directory (that work will be done later in this stack).
      
      This patch also includes changes to some files that were regenerated based on the code changes made.
       - `mozilla_customizations.diff` was updated so that it still reflects all Mozilla-made code changes to 7z.
       - The `7zSD.ARM64.sfx` and `7zSD.Win32.sfx` executables were re-built from the new code.
       - `SFXSetup.vcxproj` was updated to use newer toolchains.
      
      Differential Revision: https://phabricator.services.mozilla.com/D171109
      2f864174
    • Robin Steuber's avatar
      Bug 1815019 - Document procedure for changing 7zstub r=nalexander · 42042888
      Robin Steuber authored
      I wanted to figure out how to re-generate `mozilla_customizations.diff` in a way that matched the way that it was originally created. This is so that (a) I could ensure that I was starting with a clean slate and that the current `mozilla_customizations.diff` matched the existing changes to `other-licenses/7zstub/src` and (b) when I regenerated `mozilla_customizations.diff` after making further changes to it, the patch of the diff changes would be at least somewhat readable rather than being a huge mess.
      
      Some aspects of regenerating it created changes that I think are appropriate (ex: the full path to the user directory being present in the diff'ed file names). There were also some changes that I just couldn't figure out how to avoid (ex: the length of the function name context line). I'm not sure what diff utility was originally used, but I'm hoping that documenting how I generated it this time will allow it to be generated consistently in the future. And this commit should bring it in line with that consistency.
      
      Differential Revision: https://phabricator.services.mozilla.com/D171108
      42042888
  2. Jan 03, 2023
  3. Nov 15, 2022
  4. Nov 11, 2022
  5. Nov 10, 2022
  6. Jul 12, 2022
  7. Jun 27, 2022
    • Ben Hearsum's avatar
      Bug 1771951: add pin to taskbar support in the installer on Windows 10 & 11 r=mhowell, a=dmeehan · d7243576
      Ben Hearsum authored
      This patch starts pinning Firefox to the Taskbar by default on all supported Windows versions. The main addition here is a port of our existing taskbar pinning code for modern Windows 10 & 11 versions to an NSIS plugin (compiled version also included).
      
      After discussion with a few stakeholders, we also decided that we will never pin during an update on Windows 10 or 11. (Arguably we could stop on Windows 7 & 8 as well - but I don't really see any harm in carrying forward our pre-existing behaviour there.) With this in mind, I dropped all the second pinning attempt code (which was only ever enabled for Windows 10).
      
      Differential Revision: https://phabricator.services.mozilla.com/D148288
      d7243576
    • Ben Hearsum's avatar
      Bug 1771951: add pin to taskbar support in the installer on Windows 10 & 11 r=mhowell · 0210e257
      Ben Hearsum authored
      This patch starts pinning Firefox to the Taskbar by default on all supported Windows versions. The main addition here is a port of our existing taskbar pinning code for modern Windows 10 & 11 versions to an NSIS plugin (compiled version also included).
      
      After discussion with a few stakeholders, we also decided that we will never pin during an update on Windows 10 or 11. (Arguably we could stop on Windows 7 & 8 as well - but I don't really see any harm in carrying forward our pre-existing behaviour there.) With this in mind, I dropped all the second pinning attempt code (which was only ever enabled for Windows 10).
      
      Differential Revision: https://phabricator.services.mozilla.com/D148288
      0210e257
    • Cristian Tuns's avatar
      Backed out 2 changesets (bug 1771951) for causing build bustages on makensis.mk CLOSED TREE · 0ecf2c62
      Cristian Tuns authored
      Backed out changeset d5dc93904754 (bug 1771951)
      Backed out changeset 9651db4a6e3f (bug 1771951)
      0ecf2c62
    • Ben Hearsum's avatar
      Bug 1771951: add pin to taskbar support in the installer on Windows 10 & 11 r=mhowell · 7b7e16ab
      Ben Hearsum authored
      This patch starts pinning Firefox to the Taskbar by default on all supported Windows versions. The main addition here is a port of our existing taskbar pinning code for modern Windows 10 & 11 versions to an NSIS plugin (compiled version also included).
      
      After discussion with a few stakeholders, we also decided that we will never pin during an update on Windows 10 or 11. (Arguably we could stop on Windows 7 & 8 as well - but I don't really see any harm in carrying forward our pre-existing behaviour there.) With this in mind, I dropped all the second pinning attempt code (which was only ever enabled for Windows 10).
      
      Differential Revision: https://phabricator.services.mozilla.com/D148288
      7b7e16ab
  8. Jun 23, 2022
  9. Jun 22, 2022
    • Ben Hearsum's avatar
      Bug 1771951: add pin to taskbar support in the installer on Windows 10 & 11 r=mhowell · fa35a436
      Ben Hearsum authored
      This patch starts pinning Firefox to the Taskbar by default on all supported Windows versions. The main addition here is a port of our existing taskbar pinning code for modern Windows 10 & 11 versions to an NSIS plugin (compiled version also included).
      
      After discussion with a few stakeholders, we also decided that we will never pin during an update on Windows 10 or 11. (Arguably we could stop on Windows 7 & 8 as well - but I don't really see any harm in carrying forward our pre-existing behaviour there.) With this in mind, I dropped all the second pinning attempt code (which was only ever enabled for Windows 10).
      
      Differential Revision: https://phabricator.services.mozilla.com/D148288
      fa35a436
  10. May 25, 2022
  11. Oct 01, 2021
  12. Aug 25, 2021
    • Andi-Bogdan Postelnicu's avatar
      Bug 1725145 - Preparation for the hybrid build env.... · 2fc4f70e
      Andi-Bogdan Postelnicu authored
      Bug 1725145 - Preparation for the hybrid build env. r=necko-reviewers,firefox-build-system-reviewers,valentin,glandium
      
      Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
      when the module governed by the build config file is not buildable outside on the unified environment.
      
      This needs to be done in order to have a hybrid build system that adds the possibility of combing
      unified build components with ones that are built outside of the unified eco system.
      
      Differential Revision: https://phabricator.services.mozilla.com/D122345
      2fc4f70e
  13. May 26, 2021
  14. Feb 16, 2021
  15. Feb 11, 2021
  16. Jan 26, 2021
  17. Oct 20, 2020
  18. Sep 09, 2020
    • Chris Peterson's avatar
      Bug 1663217 - Remove MOZ_MUST_USE comment from NSIS BitsUtils.cpp. r=agashlin · 35d27dc9
      Chris Peterson authored
      The MOZ_MUST_USE macro is defined as clang's and gcc's nonstandard __attribute__((warn_unused_result)). Now that we compile as C++17 by default (bug 1560664), we can replace MOZ_MUST_USE with C++17's standard [[nodiscard]] attribute.
      
      BitsUtils.cpp only references MOZ_MUST_USE in a comment about forking a copy of mozilla::ScopeExit to remove some dependencies on other Mozilla header files (including MOZ_MUST_USE from mfbt/Attributes.h). [[nodiscard]] doesn't require a header file, so we can just remove this comment about MOZ_MUST_USE.
      
      Differential Revision: https://phabricator.services.mozilla.com/D89296
      35d27dc9
  19. Oct 20, 2020
  20. May 05, 2020
    • Ricky Stewart's avatar
      Bug 1634535 - Move ply to third_party/python r=glandium · ab55fb68
      Ricky Stewart authored
      The license used to be LGPL so the code lived in other-licenses, but it was changed to BSD eleven years ago. Let's move it over to third_party/python/ply where it belongs.
      
          ./mach vendor python ply==3.10
      
      `diff -r` between the original `ply` directory and the new one only comes up with the new file `third_party/python/ply/CHANGES` which isn't relevant to the functionality of the code, so this should be a no-op all told.
      
      Differential Revision: https://phabricator.services.mozilla.com/D73341
      ab55fb68
  21. Apr 29, 2020
  22. Apr 24, 2020
  23. Apr 20, 2020
  24. Apr 14, 2020
  25. Mar 17, 2020
  26. Mar 11, 2020
  27. Feb 27, 2020
  28. Jan 07, 2020
Loading