We fixed this up to check architecture specific sources in ec679e09b2,
but fudged the array name in the in_array call.
Signed-off-by: Allan McRae <allan@archlinux.org>
Previously, we used a single boolean value to determine correlation of
sources to checksums. Since the introduction of arch-specific sources,
this is no longer sufficient, as we must ensure that we have checksums
for (potentially) multiple source arrays.
This change inlines the logic of have_sources to build an associative
array of source array names, unsetting them as we discover their
checksums. The error condition then becomes a non-empty correlation
array.
Fixes: https://bugs.archlinux.org/task/43192
Signed-off-by: Allan McRae <allan@archlinux.org>
Following commit 086bbc5 (Use O_CLOEXEC as much as possible when opening
files), the log file would be created by pacman with blank permissions.
Signed-off-by: Allan McRae <allan@archlinux.org>
This prevents the database from becoming inaccessible for non-root
users when the script was executed with a umask of 027.
Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Allan McRae <allan@archlinux.org>
We validated all sources when making a source package, whether or not they
are included in the tarball.
Signed-off-by: Allan McRae <allan@archlinux.org>
People have mentioned that the silent upgrade to DB version 9 when no
adjustments are needed for directory symlinks is confusion. Always print
the upgrading message.
Signed-off-by: Allan McRae <allan@archlinux.org>
I'm pretty sure this is some kind of left over stuff that was supposed
to print the filename, linenumber and line content. This is already
done so just remove it.
Signed-off-by: Florian Pritz <bluewind@xinu.at>
Signed-off-by: Allan McRae <allan@archlinux.org>
Re-add some paranoia which was inadvertently lost with 768b65e934. In
case 'makepkg -g' fails to generate new sums (e.g. when a remote
resource cannot be fetched), or awk fails to write the new file (i have
no idea when this would happen), bail out with an error.
Signed-off-by: Allan McRae <allan@archlinux.org>
For parity with alpm_option_match_noextract.
Signed-off-by: Andrew Gregory <andrew.gregory.8@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
This apparently exposes (what I think is) a subtle bug in cygwin's
handling of subst'd drives. Let's just drop the hackery and use a
tempfile, which should always work.
Also, introduce a proper die() function which replaces previous
hand-rolled error+exit pattern, but which wrote to stdout.
Signed-off-by: Allan McRae <allan@archlinux.org>
Before this, we'd see bizzare behavior of:
-> Adding changelog file (systemd.install)...
And, changelog files in the global section would not be added at all.
The code is clearly wrong here, as it references 'install' within a
loop of 'changelog' and 'install'. Let's use parameter indirection to
ensure that the proper file is identified and added.
Signed-off-by: Allan McRae <allan@archlinux.org>
Refactored inconsistent pointer declarations to better improve consistency
throughout the pacman codebase which will, in turn, increase readability to
the user.
Expected format of a pointer declaration:
`typename *varname`
Signed-off-by: Micah Saint Germain <micah@lexme.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
This script parsed pacman output and was broken by the change to the use
of appropriate units for package sizes.
Signed-off-by: Allan McRae <allan@archlinux.org>
This moves most of the parsing work out of the sorting path. The explode
and splitfile functions now call input_new and append input_t structs
to the list of sort candidates instead of raw strings. This lets us
make smarter and easier decisions in the sorting callbacks, which are
now also split into the version and file comparison methods for clarity.
This fixes two bugs:
1) Incorrect ordering with filenames containing epoch in the pkgver
2) Incorrect ordering with package names which are substrings of
each other (e.g. "systemd" and "systemd-sysvcompat").
Performance of the --files mode degrades slightly as a result of this
change, but not unreasonably. Sorting with small inputs (5-10) doubles
in runtime, but larger inputs (4000+) only increase by 20%.
ref: https://bugs.archlinux.org/task/37631
Signed-off-by: Allan McRae <allan@archlinux.org>
File in noextract should still be symlinked into $srcdir so that they
can be accessed without using $SRCDEST. Using noextract on VCS files
makes no sense as these are not being extracted, so now this does
nothing.
Signed-off-by: Allan McRae <allan@archlinux.org>
With globbing in NoExtract, these log events can quickly pile up hiding
important information from the log.
Signed-off-by: Allan McRae <allan@archlinux.org>
Commit 9d96bed9 attempts to use the same effective URL for the db and its
signature download. However, this information is not available when we use
an external downloader, resulting in a crash.
Fall back to the old method when the effective URL is unavailable.
Signed-off-by: Allan McRae <allan@archlinux.org>
This matches the behaviour with non-VCS sources. It also allows incremental
builds when subversion is used to obtain sources.
Signed-off-by: Lukáš Jirkovský <l.jirkovsky@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
bzr does not recognize bare ssh:// urls.
Fixes FS#41811
Signed-off-by: Andrew Gregory <andrew.gregory.8@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
The local changes are discarded when updating. This matches the behaviour
when non-VCS sources are used. It also allows incremental builds.
This also changes the checkout during bzr source "extraction" to a heavyweight
checkout so that pulling a specific revision does not alter the original
download.
Original-work-by: Lukáš Jirkovský <l.jirkovsky@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
The local changes are discarded when updating. This matches the behaviour
when non-VCS sources are used. It also allows incremental builds.
Signed-off-by: Lukáš Jirkovský <l.jirkovsky@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
Previously the sources were dowloaded in HEAD revision in the download_svn().
If a specific revision was requested in fragment, the code was updated to that
revision in extract_svn(). However, because SVN is a centralized system,
this means that the changed sources has to be downloaded again.
By moving the fragment handling to download_svn(), we get the correct revision
without having to download it later in extract_svn().
Signed-off-by: Lukáš Jirkovský <l.jirkovsky@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
The local changes are discarded when updating. This matches the behaviour
when non-VCS sources are used. It also allows incremental builds.
Signed-off-by: Lukáš Jirkovský <l.jirkovsky@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
Similar to .PKGINFO, .SRCINFO provides structured metadata from the
PKGBUILD to be included with source packages.
The format is structured such that it contains a "pkgbase" and one to
many "pkgname" sections. Each "pkgname" section represents an "output
package", and inherits all of the attributes of the "pkgbase" section,
and then can define their own additive fields.
For example, a simple PKGBUILD:
pkgbase=ponies
pkgname=('applejack' 'pinkiepie')
pkgver=1.2.3
pkgrel=1
arch=('x86_64' 'i686')
depends=('friendship' 'magic')
build() { ...; }
package_applejack() {
provides=('courage')
...;
}
package_pinkiepie() {
provides=('laughter')
...;
}
Would yield the following .SRCINFO file:
pkgbase = ponies
pkgdesc = friendship is magic
pkgver = 1.2.3
pkgrel = 1
arch = x86_64
arch = i686
depends = friendship
depends = magic
pkgname = applejack
provides = courage
pkgname = pinkiepie
provides = laughter
The code to generate this new file is taken a project which I've been
incubating[0] under the guise of 'mkaurball', which creates .AURINFO
files for the AUR. AURINFO is the exactly same file as .SRCINFO, but
named as such to make it clear that this is specific to the AUR.
Because we're parsing shell in the packaging functions rather than
executing it, there *are* some limitations, but these only really crop
up in more "exotic" PKGBUILDs. Smoketesting[1] for accuracy in the Arch
repos yields 100% accuracy for [core] and [extra]. [community] clocks in
at ~98% accuracy (.3% difference per PKGBUILD), largely due to silly
haskell packages calling pacman from inside the PKGBUILD to determine
dependencies. [multilib] currently shows about 92% accuracy -- a
statistic which can be largely improved by utilizing the recently merged
arch-specific attribute work. This is also a smaller repo so the numbers
are somewhat inflated. In reality, this is only a .8% variance per
PKGBUILD.
Together, we can make PKGBUILD better.
[0] https://github.com/falconindy/pkgbuild-introspection
[1] https://github.com/falconindy/pkgbuild-introspection/blob/master/test/smoketest
Signed-off-by: Allan McRae <allan@archlinux.org>
