[arch-projects] [dbscripts] [GIT] Official repo DB scripts branch master updated. 20131102-59-g36b71d3
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Official repo DB scripts".
The branch, master has been updated
discards be2971eca4cb08aa5c128d8b206f6943d58a7dd9 (commit)
via 36b71d3231aca071ad635b995342b786676ef8fe (commit)
via b61a7148eaf546a31597b74d9dd8948e4a39dea1 (commit)
via f4f9d1a0099c1f784c4a964e2b5651b56f629b82 (commit)
via a7b497e8347fc964f8738d4dfc3c3ef23806fdc7 (commit)
via 5afac1ed83479c5ff7aab134b54245ec4f5b59fe (commit)
via eec8e35eba84658bdd03230c83f449d2bb437b10 (commit)
This update added new revisions after undoing existing revisions. That is
to say, the old revision is not a strict subset of the new revision. This
situation occurs when you --force push a change and generate a repository
containing something like this:
* -- * -- B -- O -- O -- O (be2971eca4cb08aa5c128d8b206f6943d58a7dd9)
\
N -- N -- N (36b71d3231aca071ad635b995342b786676ef8fe)
When this happens we assume that you've already had alert emails for all
of the O revisions, and so we here report only the revisions in the N
branch from the common base, B.
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 36b71d3231aca071ad635b995342b786676ef8fe
Author: Eli Schwartz
On Thu, 15 Feb 2018 10:48:11 -0500, Eli Schwartz via arch-projects wrote:
commit b61a7148eaf546a31597b74d9dd8948e4a39dea1 Author: Eli Schwartz
Date: Mon Feb 12 20:50:57 2018 -0500 Use more bashisms
Fix numerous instances of POSIX `[ ... ]`, including reliance on ugly deprecated constructs like POSIX `-a`. Since we require bash regardless, it makes sense to take full advantage of it.
bash `[[ ... ]]` does not require quoting variables as the shell natively recognizes them as variables rather than expanded strings.
Use shell arithmetic rather than test, when checking numerical values.
diff --git a/db-functions b/db-functions index d66955b..c0af03c 100644 --- a/db-functions +++ b/db-functions @@ -381,10 +380,10 @@ check_pkgrepos() { local pkgver="$(getpkgver ${pkgfile})" || return 1 local pkgarch="$(getpkgarch ${pkgfile})" || return 1
- [ -f "${FTP_BASE}/${PKGPOOL}/${pkgname}-${pkgver}-${pkgarch}"${PKGEXT} ] && return 1 - [ -f "${FTP_BASE}/${PKGPOOL}/${pkgname}-${pkgver}-${pkgarch}"${PKGEXT}.sig ] && return 1 + [[ -f ${FTP_BASE}/${PKGPOOL}/${pkgname}-${pkgver}-${pkgarch}${PKGEXT} ]] && return 1 + [[ -f ${FTP_BASE}/${PKGPOOL}/${pkgname}-${pkgver}-${pkgarch}${PKGEXT}.sig ]] && return 1
You don't want to do that here. In dbscripts, PKGEXT is a glob pattern--it needs to be "unquoted"; and `[[ ... ]]`'s magic-quoting breaks that. The closing-quote coming before ${PKGEXT} was quite intentional. -- Happy hacking, ~ Luke Shumaker
On 02/15/2018 02:04 PM, Luke Shumaker wrote:
- [ -f "${FTP_BASE}/${PKGPOOL}/${pkgname}-${pkgver}-${pkgarch}"${PKGEXT} ] && return 1 - [ -f "${FTP_BASE}/${PKGPOOL}/${pkgname}-${pkgver}-${pkgarch}"${PKGEXT}.sig ] && return 1 + [[ -f ${FTP_BASE}/${PKGPOOL}/${pkgname}-${pkgver}-${pkgarch}${PKGEXT} ]] && return 1 + [[ -f ${FTP_BASE}/${PKGPOOL}/${pkgname}-${pkgver}-${pkgarch}${PKGEXT}.sig ]] && return 1
You don't want to do that here. In dbscripts, PKGEXT is a glob pattern--it needs to be "unquoted"; and `[[ ... ]]`'s magic-quoting breaks that. The closing-quote coming before ${PKGEXT} was quite intentional.
Seems like an easy thing to fix, we always use .pkg.tar.xz and using a glob there seems quite ugly. (What happens if it magically matches two files? The POSIX [ construct explodes and burns your house down.) But what you're saying is that check_pkgrepos should never fail even if the package already exists, since it doesn't exist with a literal ? char -- this should be caught by test/cases/db-update.bats in @test "update same any package to different repositories fails" And that test does not fail... looks like it needs to test the case where the second package is renamed... -- Eli Schwartz Bug Wrangler and Trusted User
On Thu, 15 Feb 2018 15:09:57 -0500, Eli Schwartz wrote:
On 02/15/2018 02:04 PM, Luke Shumaker wrote:
- [ -f "${FTP_BASE}/${PKGPOOL}/${pkgname}-${pkgver}-${pkgarch}"${PKGEXT} ] && return 1 - [ -f "${FTP_BASE}/${PKGPOOL}/${pkgname}-${pkgver}-${pkgarch}"${PKGEXT}.sig ] && return 1 + [[ -f ${FTP_BASE}/${PKGPOOL}/${pkgname}-${pkgver}-${pkgarch}${PKGEXT} ]] && return 1 + [[ -f ${FTP_BASE}/${PKGPOOL}/${pkgname}-${pkgver}-${pkgarch}${PKGEXT}.sig ]] && return 1
You don't want to do that here. In dbscripts, PKGEXT is a glob pattern--it needs to be "unquoted"; and `[[ ... ]]`'s magic-quoting breaks that. The closing-quote coming before ${PKGEXT} was quite intentional.
Seems like an easy thing to fix, we always use .pkg.tar.xz and using a glob there seems quite ugly. (What happens if it magically matches two files? The POSIX [ construct explodes and burns your house down.)
Disregard the bit about my version not being broken in my last message---my spam filter had eaten this message. You are correct; both versions are broken. -- Happy hacking, ~ Luke Shumaker
participants (3)
-
Eli Schwartz
-
eschwartz@archlinux.org
-
Luke Shumaker