| Age | Commit message (Collapse) | Author |
|---|
|
this is a major change since 'pacman' v5.2.1-4 and 'file' v5.38
nearly all arch packages use this now
|
|
|
|
Currently, when processing [community], db-import-any spits:
comm: file 1 is not in sorted order
comm: file 2 is not in sorted order
IDK what weirdness causes the entries to not be sorted in the .db
|
|
|
|
|
|
With some new ALARM repos being imported in
435025e98adc3db8628fbe8e08d68766737d2943, we're hitting the problem that
some of their older packages don't have .BUILDINFO.
|
|
|
|
If you're seeing this in `git blame`, it chose to follow the wrong
ancestor of a merge commit.
|
|
If you're seeing this in `git blame`, it chose to follow the wrong
ancestor of a merge commit.
|
|
If you're seeing this in `git blame`, it chose to follow the wrong
ancestor of a merge commit.
|
|
If you're seeing this in `git blame`, it chose to follow the wrong
ancestor of a merge commit.
|
|
If you're seeing this in `git blame`, it chose to follow the wrong
ancestor of a merge commit.
|
|
If you're seeing this in `git blame`, it chose to follow the wrong
ancestor of a merge commit.
|
|
If you're seeing this in `git blame`, it chose to follow the wrong
ancestor of a merge commit.
|
|
If you're seeing this in `git blame`, it chose to follow the wrong
ancestor of a merge commit.
|
|
|
|
If you're seeing this in `git blame`, it chose to follow the wrong
ancestor of a merge commit.
|
|
The makepkg.conf that was being used didn't set SRCPKGDEST, so the results
ended up in the current directory. If the external makepkg.conf sets
SRCPKGDEST, that will no longer be true. So, force that behavior by
setting SRCPKGDEST=. in the environment.
|
|
|
|
|
|
|
|
|
|
This reverts commit f11014797ff002eaea04c4290115965d2b78082e.
|
|
This means that *only* `config` needs to exist in /opt/dbscripts, there
don't need to be symlinks for all of the local files, they can be in /etc
only.
|
|
|
|
instead of pkgbase
This makes it harder to accidentally do the wrong thing and easier to say
"this is exactly what I mean."
When using "pkgname=", it won't vcs_move or vcs_remove the package. Which
is... fine, since if you gave it a pkgname before it was broken anyway, as
they expect a pkgbase. Perhaps they should track which members of a
split package have been moved/removed?
This reverts commit 2d3abfdc8bb035f4ae0b652c1362c68ca10e76e2.
|
|
|
|
|
|
|
|
Consider glibc, for which pkgname=(glibc lib32-glibc). It wouldn't include
lib32-glibc on any architecture other than x86_64.
|
|
arches [ci-skip]
|
|
Currently, it first figures staging_repos=(), which look like
"$STAGING/whatever/repo", then it maps and filters that list to be
repos=(), which looks like "repo". We can do this all in one pass, for
less code and greater clarity.
Note that this subsumes fauno's previous commit 86b3d7c0 that protected
against duplicate repos.
|
|
|
|
|
|
- db-functions:set_repo_permission(): Align arguments to chgrp
- db-move: Reword a comment
- test: db-update: Fix typo in test name: "aregular" -> "a regular"
|
|
|
|
|
|
|
|
You may verify that the only differences between the lines removed and
lines added are double-quotes:
diff -u \
<(git show|sed -n 's/^-//p'|grep -v '^-- a/'|sed 's/"//g') \
<(git show|sed -n 's/^+//p'|grep -v '^++ b/'|sed 's/"//g')
|
|
Earlier versions of this patch added VCS=xbs, but XBS is
non-functional. It provided something useful before db-functions-$VCS
was a thing, but now it's dead.
We don't use SVN, and XBS non-functional, just add a null VCS that
does nothing.
|
|
This does not make any "real" changes, it just gets rid of saying "svn" in
function-names, variable-names, file-names, and comments; when the code is
actually now VCS-agnostic.
This makes no changes more sophisticated than the simple search/replace.
|
|
Currently, vcs_move_preflight_check and vcs_move_arch require the
exact pkgarch (i.e. "any" or "x86_64"). Modify them so that they take
the tarch (i.e. "x86_64") and figure out themselves if it needs to set
pkgarch=$tarch or pkgarch=any.
vcs_export could probably stand to be modified to do something
similar, but it's more work to adjust its callers.
"Ignore space change" might be useful when viewing this diff.
|
|
'common-svn.bash' file
Similarly to the main code, factor out all SVN-specific code in the tests
in to a separate `common-$VCS.bash`. This will allow anyone writing a
different `db-functions-$VCS` file to actually test that file.
|
|
Moving all SVN code in to a separate file means both that:
1. It is easier to identify the interactions with SVN, when considering a
replacement.
2. It is easier to swap out the one file if/when replacing SVN with
something else.
Put another way: try to be less tightly coupled with SVN.
Some of these functions could stand to be cleaned up a touch--for
obviousness' sake, to the extent possible, the code is copied verbatim
from where it was inline before, and modified as little as possible.
|
|
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.
(Luke Shumaker: this is a partial cherry pick of commit 3bb6775dea3e6dda58d94e8ef9a19026cb9248a4)
|
|
testing2x needs to:
1. Verify that the new version of the package is found in TESTING_REPO
2. Determine which of STABLE_REPOS the old version of the package is in
Currently, to do those things, it checks for the existence of PKGBUILD
files in SVN. That information is already stored in the DBEXT files; get
it from there, instead of talking to SVN.
"Ignore space change" might be useful when viewing this diff.
|
|
This should have the same result, but be a bit less confusing to read.
Also, have a slightly more specific error message on a missing PKGBUILD.
|
|
Don't try to parse PKGBUILD files from SVN; all of the information we need
is already in the DBEXT files. Several programs use [[ -f PKGBUILD ]] or
[[ -r PKGBUILD ]] on files from SVN; those checks can stay, just remove all
instances of actually trying to *parse* those files.
As an exception, don't modify parse_pkgbuilds.sh (which is called by
check_packages.py, which is called by cron-jobs/integrity-check).
Most of the attributes we need have been present in the DBEXT files for as
long as `repo-add` has been part of pacman:
attribute | git | git date | ver | ver date
----------+----------+------------+-------+-----------
FILENAME | aa1c0ba9 | 2006-11-20 | 3.0.0 | 2007-03-25
NAME | aa1c0ba9 | 2006-11-20 | 3.0.0 | 2007-03-25
VERSION | aa1c0ba9 | 2006-11-20 | 3.0.0 | 2007-03-25
ARCH | aa1c0ba9 | 2006-11-20 | 3.0.0 | 2007-03-25
BASE | 4b21504f | 2009-07-22 | 3.3.0 | 2009-08-02
However, `BASE` for split packages is slightly newer, and its presence
relies not only on the `repo-add` version, but also the `makepkg` version
used to build the package.
As of 2018-06-15, the oldest package in any of the Arch Linux repos is
community/gimp-refocus, built on 2013-07-22; I don't believe it is
necessary to handle packages from before that change was made (before
`BASE` was set).
"Ignore space change" might be useful when viewing this diff.
|
|
In a patchset that I recently submitted, Eli was concerned that I was
parsing .db files with bsdtar+awk, when the format of .db files isn't
"public"; the only guarantees made about it are that libalpm can parse it.
https://lists.archlinux.org/pipermail/arch-projects/2018-June/004932.html
I wasn't too concerned, because `ftpdir-cleanup` and `sourceballs` already
parse the .db files in the same way. Nonetheless, I think Eli is right: we
shouldn't be parsing these files ourselves.
So, add an `arch_expac` function that uses `expac` to parse the .db files.
`expac` is particularly palatable as a new dependency, as it seems likely
that it will be included in future releases of pacman. `expac` (like the
underlying libalpm) doesn't offer an easy way to say "parse this DB file
for me"; instead, we must construct a pacman.conf that has a repo pointing
to that file with a `Server=file://...` line.
|
|
- 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, just use an array assignment to do glob expansion, 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 made me nervous.
|
