1. 27 Jan, 2020 1 commit
    • Eli Schwartz's avatar
      makepkg: make per-package files containing '$pkgname' consistently work · d626a17e
      Eli Schwartz authored and Allan McRae's avatar Allan McRae committed
      
      
      Extracting function variables containing arbitrarily scoped variables of
      arbitrary nature is a disaster, but let's at least cover the common case
      of using the actual '$pkgname' in an install/changelog file. It's the
      odd case of actually being basically justified use of disambiguating
      between the same variable used in multiple different split packages...
      and also, --printsrcinfo already uses and overwrites the variable
      'pkgname' in pkgbuild_extract_to_srcinfo, so this "works" in .SRCINFO
      but doesn't work in .src.tar.gz
      
      It doesn't work in lint_pkgbuild either, but in that case the problem is
      being too permissive, not too restrictive -- we might end up checking
      the same file twice, and printing that it is missing twice.
      
      Fixes FS#64932
      
      Signed-off-by: Eli Schwartz's avatarEli Schwartz <eschwartz@archlinux.org>
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      d626a17e
  2. 26 Nov, 2019 1 commit
  3. 06 Nov, 2019 2 commits
  4. 30 Oct, 2019 2 commits
  5. 29 Oct, 2019 1 commit
    • Eli Schwartz's avatar
      makepkg: protect against unexpected whitespace in filenames · a745d97c
      Eli Schwartz authored and Allan McRae's avatar Allan McRae committed
      
      
      zipman:
      
      read -r protects against those evil manpages whose filenames contain
      backslash escapes, (muahahaha?)
      
      IFS= read protects against filenames with:
      
      - leading whitespace (but no one is actually stupid enough to configure
        their MAN_DIRS=() in makepkg.conf with such silly directories, *right*?)
      
      - trailing whitespace (but likewise, no one should be stupid enough to
        write an uncompressed manpage for section '1 ' or something)
      
      Also fix several other cases where we read filenames without protecting
      against surrounding whitespace, or without using null-delimited
      filenames when we could trivially do so.
      
      Signed-off-by: Eli Schwartz's avatarEli Schwartz <eschwartz@archlinux.org>
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      a745d97c
  6. 23 Oct, 2019 1 commit
  7. 09 Oct, 2019 1 commit
    • Eli Schwartz's avatar
      makepkg: do not save fflags when creating packages · a897599f
      Eli Schwartz authored and Allan McRae's avatar Allan McRae committed
      
      
      Saving fflages breaks reproducible builds due to encoding information
      specific to the filesystem that was used to build the package. This
      information is not needed for packaging purposes anyway.
      
      Including fflags also means that attempting to extract a package file as
      root (or fakeroot) might result in angry warnings being printed to the
      console by bsdtar, followed by a non-zero exit code, unless the user
      remembers to use --no-fflags during extraction. This is unpleasant UI, even
      if pacman itself won't care about these.
      
      Signed-off-by: Eli Schwartz's avatarEli Schwartz <eschwartz@archlinux.org>
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      a897599f
  8. 07 Oct, 2019 4 commits
  9. 25 Jun, 2019 1 commit
  10. 28 May, 2019 2 commits
  11. 08 May, 2019 3 commits
  12. 19 Mar, 2019 1 commit
  13. 07 Mar, 2019 1 commit
  14. 21 Feb, 2019 2 commits
  15. 31 Jan, 2019 1 commit
  16. 30 Jan, 2019 1 commit
    • Allan McRae's avatar
      makepkg: use --unneeded for pacman call in remove_deps() · 6cf05481
      Allan McRae authored
      
      
      This patch was inspired by FS#32723 which asks makepkg to install makedepends
      before depends.  The use case is to build a package depending on a virtual
      package that is only provided by other packages (e.g. java-runtime in Arch
      Linux), but wanting to build against a specific version.  Installing makedepends
      first (but not at the same time as depends) would allow specifying the version
      to build against, instead of pacman resolving to the default version when
      installing depends.
      
      It turns out, we can already achieve installing makedepends first by specifying
      dependencies only in the package function (and making sure makedepends includes
      everything needed). The only issue is that if we use makepkg to install the
      built package with the --install flag and along with the --rmdeps flag, we will
      try to remove any installed dependencies that are specified in the depends
      array in the package function.  To counter this, we need to use the --unneeded
      flag for the pacman call.
      
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      6cf05481
  17. 10 Jan, 2019 3 commits
  18. 04 Jan, 2019 3 commits
  19. 27 Nov, 2018 3 commits
  20. 03 Nov, 2018 1 commit
    • Eli Schwartz's avatar
      makepkg: fix .PKGINFO/.BUILDINFO files swallowing status printing · 3dfec574
      Eli Schwartz authored and Allan McRae's avatar Allan McRae committed
      The respective write_* functions are low-level and shouldn't be
      outputting statuses; move these to the logic flow where they are used.
      This ensures the functions can be used in the future wherever, and also
      solves an issue where, as fallout from the message.sh retrofitting in
      commit 882e707e
      
      , the statuses got
      redirected to the actual files.
      
      The resulting package was technically correct, except that it contained
      useless lines which pacman ignored, and repo-add also ignored but at the
      same time generated an error message:
      
      /usr/bin/repo-add: line 335: declare: `=-> Generating .PKGINFO file...': not a valid identifier
      
      Thirdparty package tools with stricter parsers may abort with errors,
      and "repose" is known to do so.
      
      Signed-off-by: Eli Schwartz's avatarEli Schwartz <eschwartz@archlinux.org>
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      3dfec574
  21. 21 Oct, 2018 3 commits
  22. 18 Sep, 2018 2 commits
    • Eli Schwartz's avatar
      scripts: deduplicate localized copyright messages · 58c76daf
      Eli Schwartz authored and Allan McRae's avatar Allan McRae committed
      
      
      We don't need to translate the "Copyright YEAR AUTHOR" part, no part of
      it should probably be translated and it definitely shouldn't turn every
      single license terms notice into a separate translation just because the
      author/year is different.
      
      Fixes FS#58452
      Also consistently add a blank line after the copyright and before the
      license terms.
      
      Signed-off-by: Eli Schwartz's avatarEli Schwartz <eschwartz@archlinux.org>
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      58c76daf
    • Eli Schwartz's avatar
      Revert "makepkg: add whirlpool to the list of hashing algorithms" · d03409cc
      Eli Schwartz authored and Allan McRae's avatar Allan McRae committed
      This reverts commit 9cdfd187.
      
      We've never documented whirlpoolsums support in the manpage and no one
      really seems to have realized we support it, let alone use it -- except
      for a few parabola packages, being the contributor's motivation for
      adding support.
      
      The problem is that for two years the code has been broken. In commit
      57770125
      
       we moved to coreutils to
      provide checksum commands, rather than openssl, but there is no
      whirlpoolsums binary.
      
      Properly fixing this would require re-adding a dependency on openssl,
      independent of the libalpm crypto backend -- which defeats the purpose
      of moving to coreutils in the general case. nettle-hash does not provide
      a whirlpool algorithm any more than it does base64 (the original reason
      for moving to coreutils).
      
      Therefore, we should just drop support for this again.
      
      Signed-off-by: Eli Schwartz's avatarEli Schwartz <eschwartz@archlinux.org>
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      d03409cc