This project is mirrored from https://git.archlinux.org/dbscripts.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 14 Mar, 2021 5 commits
  2. 12 Mar, 2021 1 commit
  3. 05 Jun, 2020 2 commits
  4. 20 Oct, 2019 1 commit
  5. 17 Oct, 2019 1 commit
    • Eli Schwartz's avatar
      db-update: performance optimization when checking if a buildinfo exists · 60d036ea
      Eli Schwartz authored
      Use the --fast-read option to quit as soon as the file is first found. A
      package file should never contain two of these anyway, but even if it
      did, we simply want to know that one exists!
      
      makepkg guarantees its internal .METADATA files are tar'ed up first, so
      this should usually be quite rapidly found. For very large packages,
      crawling the entire package file to check for a later entry overriding
      the first one, is... pointless... and worst of all, slow.
      
      This reflects the identical mode used for extracting the pkginfo file,
      which was inconsistently implemented from the initial feature addition.
      60d036ea
  6. 13 Jul, 2019 1 commit
    • Florian Pritz's avatar
      Look for repro packages in live repo pool too · 0706db69
      Florian Pritz authored
      
      
      I've cleaned older packages from the archive, but sometimes we do not
      rebuild packages in a long long time. We still keep have them in the
      repository, but this check does not look for the package there, thus
      when trying to db-update, the user sees an error. We fix this by also
      looking at currently live packages instead of only relying on the
      archive.
      
      This is mostly a hotfix until a better solution is created. Depending on
      when/how the ftpdir-cleanup cronjob removes such packages, users may
      still see errors when an old package is updated and the cronjob removes
      it from the repository before db-update is run.
      Signed-off-by: default avatarFlorian Pritz <bluewind@xinu.at>
      0706db69
  7. 13 Jan, 2019 1 commit
  8. 11 Jan, 2019 2 commits
  9. 10 Jan, 2019 4 commits
    • Eli Schwartz's avatar
      db-move: also block moving package from staging to extra without handling testing · d5970df3
      Eli Schwartz authored
      Don't allow anomalous testing packages floating around after a rebuild
      which are older than stable.
      d5970df3
    • Eli Schwartz's avatar
      db-update: die when trying to update a package without updating a pending rebuild · 8804e63f
      Eli Schwartz authored
      A semi-common pattern is for one maintainer to stage a rebuild of a
      package due to e.g. cascading repository-wide python/boost/whatever
      rebuilds, and then for the original maintainer of the package to not
      notice and update the package in the stable repo, leaving an out of date
      rebuild in staging or testing.
      
      Then the the out of date package gets moved and ends up breaking things,
      possibly via a package downgrade, possibly via breaking compatibility
      with a much more targeted rebuild uploaded all at once. Ultimately,
      Things Happen™ and the repository hierarchy gets broken.
      
      Prevent this by enforcing for all packages that exist in
      multiple levels of the repo: staging -> testing -> stable
      
      That updates to one must come with an update to all the others.
      8804e63f
    • Eli Schwartz's avatar
      testing2x: be more generic and accept multiple testing repos · 863818f2
      Eli Schwartz authored
      Currently multilib is a second-class citizen the way it is lumped into
      community, and dbscripts cannot even keep track of whether it
      constitutes a testing repo. Teach config to track both testing and
      staging repos just like the stable ones, and teach testing2x to search
      through TESTING_REPOS to determine which one it is operating on.
      863818f2
    • Eli Schwartz's avatar
      Fix db-archive not running at the correct time. · 948a181f
      Eli Schwartz authored
      At the point when it was being run, the signature was not yet moved to
      PKGPOOL.
      948a181f
  10. 09 Jan, 2019 1 commit
    • Eli Schwartz's avatar
      Add reproducible archive of packages. · f11a038c
      Eli Schwartz authored
      Whenever adding new package files to the pool of distributed packages,
      copy the file into a longterm archive. This is the first step to merging
      the functionality of archivetools, as this implements the shared pool
      while also guaranteeing that all packages are archived at the time of
      entry rather than once per day if they still exist.
      f11a038c
  11. 08 Jan, 2019 1 commit
  12. 16 Oct, 2018 2 commits
    • Luke Shumaker's avatar
      test: Resolve "TODO: Does not fail if one arch is missing" · 549fe001
      Luke Shumaker authored
       - Implement the TODO by keeping a list/set of architectures found via
         "$repo-$arch" directory names, and another list/set of architectures
         named in arch=() in the PKGBUILD(s).  This means turning the simple
         `compgen` in to a loop.
      
       - While we're at it loading PKGBUILDs in a loop, fix that it clearly
         isn't doing anything with the $pkgver argument; it should verify that
         the version in the found PKGBUILD(s) matches that argument.
      
       - Use extglob to more strictly match the "arch" part of the "repo-arch"
         dirname; the existing glob wouldn't have behaved correctly for values
         of $repo containing a "-" (like "community-testing").  We don't
         currently test with any of those, but it makes me nervous.
      
       - Also make that extglob change in checkRemovedPackage.  While we're at
         it, let Bash do the glob expansion normally and check it with
         __isGlobfile, instead of compgen; it means we don't have to worry about
         escaping the non-glob part of the string.  Not that we expect it to
         contain anything needing escaping, but again, it makes me nervous.
      549fe001
    • Luke Shumaker's avatar
      test: db-remove: Verify that it accepts pkgname (in addition to pkgbase) · 1bf2b35e
      Luke Shumaker authored
      It is important that db-remove be able to remove a single pkgname, without
      being able to look it up by pkgbase in SVN.  For instance, when a split
      package update removes one of its members; there will be no reference to
      the removed pkgname in SVN, and it won't be removed by db-update.  If
      db-remove doesn't accept pkgnames, then this outdated orphan could not be
      removed.
      1bf2b35e
  13. 08 Oct, 2018 7 commits
    • Eli Schwartz's avatar
    • Eli Schwartz's avatar
    • Eli Schwartz's avatar
      Factor out the exporting of files/folders from svn. · 37a493d3
      Eli Schwartz authored
      As of the source_pkgbuild rewrite, this is only ever done once.
      37a493d3
    • Eli Schwartz's avatar
      Preliminary work to break out svn-specific code. · d6b48bd6
      Eli Schwartz authored
      Introduce "db-functions-$VCS" which will eventually contain all
      VCS-specific code, and make this configurable in config.
      
      Move private arch_svn function and svn acl handling here, and introduce
      a new source_pkgbuild function to handle discovering PKGBUILDs from the
      configured VCS and sourcing them to extract metadata.
      
      The PKGBUILD is the only file we ever check out from version control,
      and only ever to scrape information from it, except for when we actually
      want to db-move a whole directory (which is by necessity considerably
      dependent on the VCS in use).
      
      source_pkgbuild is inspired by commits from the dbscripts rewrite,
      authored by Florian Pritz <bluewind@xinu.at>
      d6b48bd6
    • Luke Shumaker's avatar
      test: checkPackageDB(): Resolve "FIXME: We guess the location of the PKGBUILD" · 971181bf
      Luke Shumaker authored
      The problem statement:
      
        checkPackageDB and checkRemovedPackageDB need bit of information on the
        package they're checking: a full list of pkgnames with that pkgbase, the
        list of pkgarches, and (for checkPackageDB only) the full version.  In
        dbscripts itself, we can get that directly from the .db files; however,
        since the test suite is checking the ability of dbscripts to edit those
        .db files, that's obviously not a good solution.
      
        The current solution is to get this information from the PKGBUILD...
        which we also count on dbscripts to correctly keep track of.  Wait,
        that's skipping ahead, let's back up.
      
        The current solution is to get this information from the PKGBUILD.  For
        checkRemovedPackageDB, that's easy; we just get it from trunk, as that's
        the most up-to-date information on the package as-it-would-have-existed
        (if that sounded a little hand-wavey, it was).  But for checkPackageDB,
        it's a little trickier, because of 2 factors working together: (1) there
        might be different versions on different repos, and (2) unlike
        checkRemovedPackageDB, checkPackageDB actually cares about pkgver.  So,
        checkPackageDB "guesses" the location in a slightly sloppy way, and is
        tagged with a "FIXME".
      
      What todo about it?
      
        There are a couple of things to observe:
      
         - Hidden in the hand-waving in assuming that "trunk" is fine for
           checkRemovedPackageDB is the assumption that neither pkgname=() nor
           arch=() is going to change between versions.  Which is a fine
           assumption, because we don't change those things between versions in
           any of our test cases.
         - We're counting on dbscripts correctly keeping track of which PKGBUILD
           is correct for which repo... which is one of the thing's we're trying
           to test, we shouldn't be counting on it.  That's actually a bigger
           problem than the original "FIXME"!
      
        So, putting those things together, let's (1) take the code under test out
        of the equation, and (2) remove any suggestion that the version of the
        PKGBUILD makes a difference to pkgnames/pkgarches: Let's have both
        functions that that information from the PKGBUILDs under "fixtures/",
        rather than getting PKGBUILDs from VCS.
      
        That just leaves one question: How to get the correct pkgver in
        checkPackageDB?  The obvious answer is: Each test case knows what the
        version should be; add it as an argument, and adjust every testcase that
        calls it.
      971181bf
    • Luke Shumaker's avatar
      test: Don't use "! cmd" except as the last statement in a function · a75e4ee5
      Luke Shumaker authored
      With BATS setting up error traps, we get used to writing simple `[[ foo ]]`
      assertions and not having to check the result.  However, using `!` to
      invert the result DOESN'T trigger the trap.  It works OK when it is the
      last command in a function, as it still affects the function's return
      value, so then the trap triggers in the caller (rather than in the
      function).  This means that a check may run successfully when it should
      fail.
      
      So, replace all uses of bare `! cmd` with `if cmd; then return 1; fi`,
      unless it is the final statement in a function (as it is in
      sourceballs.bats:__checkRemovedSourcePackage())
      
      The mistake meant that checkRemovedPackage() was effectively equivalent to
      checkRemovedPackageDB().  This meant that no one noticed that db-updates's
      "add package with inconsistent name fails" test called checkRemovedPackage
      instead of checkRemovedPackageDB.  Fixing the ! issue means that the test
      now fails, so change which function it calls.
      a75e4ee5
    • Luke Shumaker's avatar
  14. 09 Sep, 2018 2 commits
    • anthraxx's avatar
      fix potential bsdtar stream close error by grep · 0b630e25
      anthraxx authored
      This silences a useless error message that confuses the user.
      
      bsdtar doesn't like it when the stream gets closed before it finishes
      which may be the case when grep found its match on potentially huge
      archives. Instead of suppressing the whole stderr , we find all matches
      with grep, then use a second pass with `tail` to find only the last
      match, which ensures the stream remains open for bsdtar but we may still
      catch and see useful messages on stderr.
      
      This works because tail has the useful property of not closing early.
      0b630e25
    • anthraxx's avatar
      readme: switch to travis-ci.com build status badge · 57a307d6
      anthraxx authored
      The old travis-ci.org is deprecated and this project was migrated.
      57a307d6
  15. 26 Aug, 2018 1 commit
  16. 04 Jul, 2018 1 commit
  17. 27 Jun, 2018 2 commits
  18. 19 Jun, 2018 1 commit
    • Eli Schwartz's avatar
      test: BUILDDIR must be owned by build user · 05dd9be0
      Eli Schwartz authored
      pacman 5.1 enforces this restriction. OTOH it is a simpler setup to set
      this as the user homedir directly in account creation (just like
      makechrootpkg has always done) than to create an additional,
      world-writable, directory.
      
      dockerfile: don't use tmpfs for /build
      05dd9be0
  19. 28 May, 2018 1 commit
  20. 08 Apr, 2018 3 commits