1. 20 May, 2018 1 commit
  2. 18 May, 2018 1 commit
    • Eli Schwartz's avatar
      git-update: accept any arch in arch-dependent metadata · 16795eaf
      Eli Schwartz authored and Lukas Fleischer's avatar Lukas Fleischer committed
      
      
      Currently we hardcode the architectures the official repos historically
      supported, which seems both inefficient because of hardcoding, and
      simply wrong, because many packages support various ARM platforms too.
      
      If we were to say "only officially supported arches will be supported in
      the AUR" we'd have to disable i686, which seems silly and arbitrarily
      restrictive. Also there's better places to implement such a blacklist
      (via die_commit in the main loop, via a config option to list supported
      arches, would make much more sense in terms of logic).
      
      As for the metadata extraction itself, there's no reason to hardcode the
      arches to check for at all. We can get this information too, from the
      .SRCINFO itself. Detecting this dynamically is not incompatible with a
      blacklist, should we ever decide to implement such a thing.
      Signed-off-by: Eli Schwartz's avatarEli Schwartz <eschwartz@archlinux.org>
      Signed-off-by: Lukas Fleischer's avatarLukas Fleischer <lfleischer@archlinux.org>
      16795eaf
  3. 17 May, 2018 5 commits
  4. 16 May, 2018 1 commit
  5. 12 May, 2018 4 commits
  6. 11 May, 2018 1 commit
    • Eli Schwartz's avatar
      Use a link to accept orphan requests · 0ffa0679
      Eli Schwartz authored and Lukas Fleischer's avatar Lukas Fleischer committed
      
      
      Currently, a form is used instead of a link. This forwards to a
      confirmation page, and currently drops the "via" parameter in the
      process.
      
      As a result, accepted orphan requests usually show:
      
          Request #XXXXXX has been accepted automatically by the Arch User
          Repository package request system:
      
          The user YYYYYYY disowned the package.
      
      This is wrong, and should show (will show, if you manually add it or use
      the close button instead of the accept button):
      
          Request #XXXXXX has been rejected by YYYYYYY [1]:
      
      Fixes FS#56606.
      Signed-off-by: Eli Schwartz's avatarEli Schwartz <eschwartz@archlinux.org>
      Signed-off-by: Lukas Fleischer's avatarLukas Fleischer <lfleischer@archlinux.org>
      0ffa0679
  7. 10 May, 2018 2 commits
  8. 22 Apr, 2018 1 commit
    • Eli Schwartz's avatar
      config: allow reading both the defaults file and the modified config · 97c5bcec
      Eli Schwartz authored and Lukas Fleischer's avatar Lukas Fleischer committed
      
      
      In the process, rename config.proto to config.defaults (because that is
      what it is now).
      
      Also use dict.get('key', default_value) when querying os.environ, rather
      than an if block, as it is more pythonic/readable/concise, and reduces
      the number of dict lookups.
      
      This change allows aurweb configuration to be done via either:
      - copying config.defaults to config and modifying values
      - creating a new config only containing modified values, next to a
        config.defaults containing unmodified values
      
      The motivation for this change is to enable ansible configuration in our
      flagship deployment by storing only changed values, and deferring to
      config.defaults otherwise.
      
      A side benefit is, it is easier to see what has changed by inspecting
      only the site configuration file.
      
      If a config.defaults file does not exist next to $AUR_CONFIG or in
      $AUR_CONFIG_DEFAULTS, it is ignored and *all* values are expected to
      live in the modified config file.
      Signed-off-by: Eli Schwartz's avatarEli Schwartz <eschwartz@archlinux.org>
      Signed-off-by: Lukas Fleischer's avatarLukas Fleischer <lfleischer@archlinux.org>
      97c5bcec
  9. 08 Apr, 2018 1 commit
  10. 21 Mar, 2018 1 commit
  11. 20 Mar, 2018 1 commit
  12. 14 Mar, 2018 2 commits
  13. 13 Mar, 2018 1 commit
  14. 10 Mar, 2018 2 commits
  15. 24 Feb, 2018 4 commits
  16. 26 Jan, 2018 1 commit
  17. 21 Jan, 2018 1 commit
  18. 23 Dec, 2017 1 commit
  19. 03 Dec, 2017 3 commits
  20. 02 Dec, 2017 1 commit
  21. 28 Nov, 2017 2 commits
  22. 08 Nov, 2017 1 commit
  23. 07 Nov, 2017 1 commit
  24. 06 Nov, 2017 1 commit