On 02/15/2018 11:04 PM, Luke Shumaker wrote:
> From: Luke Shumaker
>
> This has the test change PKGEXT the second time it tries to release the
> package. Currently, this causes the tests to fail. That's a good thing;
> it's checking for the regression where db-functions:check_pkgrepos isn't
> t
From: Luke Shumaker
This updates the tests to check for the regression we've been
discussing.
This doesn't include a fix. I haven't looked too closely, or actually
tested them, but Eli's fix LGTM so far.
Luke Shumaker (1):
test: db-update: @test "update same any package to same repository
From: Luke Shumaker
This has the test change PKGEXT the second time it tries to release the
package. Currently, this causes the tests to fail. That's a good thing;
it's checking for the regression where db-functions:check_pkgrepos isn't
treating PKGEXT as a glob.
Without this, that regression
As per the previous commits, this never worked and nobody noticed
because the use of globbing was undocumented.
Fortunately, we can fix that now, by using the new is_globfile() proxy
function.
Signed-off-by: Eli Schwartz
---
test/cases/ftpdir-cleanup.bats | 4 ++--
1 file changed, 2 insertions(
This fully removes the use of find from the codebase, leads to a
micro-optimization in a couple cases, and ensures that $PKGEXT is
consistently treated as a shell globbing character (which is important
because it is used as one).
Of the eight instances in these files:
- One was unnecessary as `c
This can be anything makepkg.conf accepts, therefore it needs to be able
to match all that. Document the fact that this has *always* been some
sort of glob, and update the two cases where this was (not!) being
evaluated by bash [[ ... ]], to use a proxy function is_globfile()
Signed-off-by: Eli Sc
Don't bother emitting errors. bash doesn't show globbing errors if it
cannot read a directory to try globbing there. And the former code never
aborted on errors anyway, as without `set -o pipefail` the sort command
swallowed the return code.
Signed-off-by: Eli Schwartz
---
db-functions | 4
This was sort of cobbled together and not really tested, so I'm not 100%
sure it will work, but it looks okay, so I am posting this to get more
eyes on it. I think I've actually gotten this to work properly, which is
yay, and support multiple extensions, which is meh but we may need this
as Luke sa
On Thu, 15 Feb 2018 17:53:08 -0500,
Eli Schwartz via arch-projects wrote:
>
> Since devtools pushes xz, and every single package currently in the
> repos uses xz,
FWIW, devtool's lib/common.sh's find_cached_package() uses the glob
".pkg.tar?(.?z)".
>and AFAIK we haven't actually
This results in unpredictable behavior when used across, variously, bash
[[, POSIX sh [, and find -name
Its usage depended on matching only one result, which is bad practice.
Moreover, it never worked in the first place as
- The majority of alternative compression extensions available in
makep
On 02/15/2018 05:17 PM, Luke Shumaker wrote:
> Huh? My version isn't broken. Unless you mean that the glob is more
> restrictive than the one used by makepkg?
As you saw my other message, this should be answered already, but
consider this additional perspective on globs:
The glob is both *less
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 ] &&
On Thu, 15 Feb 2018 16:57:26 -0500,
Eli Schwartz wrote:
>
> On 02/15/2018 04:43 PM, Luke Shumaker wrote:
> > That's not a bad idea. But then someone reading the code might wonder
> > "why does such a trivial function exist?". I think it would be silly,
> > and ultimately hurt readability to go t
On 02/15/2018 04:43 PM, Luke Shumaker wrote:
> That's not a bad idea. But then someone reading the code might wonder
> "why does such a trivial function exist?". I think it would be silly,
> and ultimately hurt readability to go through and replace all
>
> "[[ -f ... ]]" instances with "file_exi
On Thu, 15 Feb 2018 15:11:13 -0500,
Dave Reisner wrote:
>
> On Thu, Feb 15, 2018 at 02:49:45PM -0500, Luke Shumaker wrote:
> > - [[ -f ${FTP_BASE}/${PKGPOOL}/${pkgname}-${pkgver}-${pkgarch}${PKGEXT}
> > ]] && return 1
> > - [[ -f
> > ${FTP_BASE}/${PKGPOOL}/${pkgname}-${pkgver}-${pkgarch}${PK
On 02/15/2018 03:48 PM, Dave Reisner wrote:
> Nope, changing the kind of glob doesn't work here. There's simply no
> glob expansion of any kind inside [[ -f ]] (or any other stat-like
> check).
I was thinking maybe something like the way makepkg compares filenames
to various extended globs, but a
On Thu, Feb 15, 2018 at 03:14:19PM -0500, Eli Schwartz via arch-projects wrote:
> On 02/15/2018 03:11 PM, Dave Reisner wrote:
> > Rather than making this stand out like a sore thumb for the next person
> > to trip over, why don't we just define a "file_exists" function?
> >
> > file_exists() {
>
On 02/15/2018 03:11 PM, Dave Reisner wrote:
> Rather than making this stand out like a sore thumb for the next person
> to trip over, why don't we just define a "file_exists" function?
>
> file_exists() {
> [[ -f $1 ]]
> }
>
> Now you're free to do this:
>
> file_exists
> "${FTP_BASE}
On Thu, Feb 15, 2018 at 02:49:45PM -0500, Luke Shumaker wrote:
> From: Luke Shumaker
>
> This partially reverts commit b61a7148eaf546a31597b74d9dd8948e4a39dea1.
>
> In dbscripts, PKGEXT is a glob pattern--it needs to be "unquoted"; and
> The magic-quoting done by `[[ ... ]]` breaks that. The cl
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}-${pk
From: Luke Shumaker
This fixes a mistake introduced in b61a714 around quoting PKGEXT, then
renames PKGEXT to PKGEXT_glob to avoid that type of confusion in the
future.
Luke Shumaker (2):
Don't quote $PKGEXT
config: Rename PKGEXT to PKGEXT_glob
config | 4 +++-
cron-
From: Luke Shumaker
Unlike the other *EXT variables, which are prescriptive, PKGEXT is
descriptive, and is a blob. This is confusing because of the other
variables, and because it is used prescriptively in makepkg.conf.
Simply, the configuration variable name PKGEXT is overloaded.
Now, in test
From: Luke Shumaker
This partially reverts commit b61a7148eaf546a31597b74d9dd8948e4a39dea1.
In dbscripts, PKGEXT is a glob pattern--it needs to be "unquoted"; and
The magic-quoting done by `[[ ... ]]` breaks that. The closing-quote
coming before ${PKGEXT} was quite intentional.
---
db-function
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
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
via 134aff74d16331231ed94f34d8417d1325d4600f (commit)
via c7f
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 36b
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
via be2971eca4cb08aa5c128d8b206f6943d58a7dd9 (commit)
from 1ca
27 matches
Mail list logo
