| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
non-x86_64-build, so we do not use any-packages from x86_64 mirrors, and cross-mount inside to /var/cache/pacman/pkg
|
|
|
|
pentium4 is unknown to setarch - we must replace it by i686 if used as argument to setarch
|
|
|
|
(http[s]://mirror.url/path/$arch/$repo)
|
|
We had trouble in the past with not properly initialized keyrings.
This change aims at fixing this.
|
|
|
|
--verifysource"
|
|
non-x86_64-build, so we do not use any-packages from x86_64 mirrors, and cross-mount inside to /var/cache/pacman/pkg
|
|
pacman-staging-with-build-support-i686.conf: reorder repositories and add repo build-support for i686
|
|
|
|
|
|
This reverts commit 7259e7def07a5f6ee04a34db61a87361ad0b5ac7, except for commitpkg.in
|
|
|
|
|
|
If arch-nspawn is called with -C, pacman inside the chroot will use
the provided configuration file. This should also be the case for
$pacconf_cmd and pacman outside the chroot.
If arch-nspawn is called without -C, pacman inside the chroot will
use $workdir/etc/pacman.conf -- again, $pacconf_cmd and pacman
outside the chroot should use that, too. So lets just set $pac_conf
in that case.
For example, Arch Linux 32 provides separate pacman configurations
inside /usr/share/devtools which use /etc/pacman.d/mirrorlist32 as
mirrorlist for their build commands (extra-i686-build, etc.). This
way, we can build i686 and x86_64 packages on the same x86_64 host
with very minimal changes to devtools.
|
|
|
|
|
|
This ensures we take user specific config values for PKGDEST into
account when printing the package list. This is required as devtools
archbuild_cmd puts packages potentially into the user defined PKGDEST
which the package list would otherwise miss.
|
|
This fixes an issue with the usage of makepkg --packagelist to get the
produced artifacts filenames according to the PKGEXT used in devtools'
makepkg.conf instead of the one defined in pacman.
One goal we want to preserve is that devtools configuration should be
self contained and not require any editing of non owned files like
the host /etc/makepkg.conf to produce expected results.
Additionally modify the archbuild_cmd override for multilib builds to
use an independent variable and not fiddle with the actual arch
variable to select the appropriate cmd.
|
|
|
|
This ensures we use the same configuration for reproducing packages as
we use for building them via devtools.
One example of why we care about this are the COMPRESS* settings that
may differ from the guest's pacman shipped makepkg.conf that affect the
reproducibility of packages.
|
|
We don't want the default PKGEXT in the current version of devtools, we
want the PKGEXT we *know* the input file used.
Signed-off-by: Levente Polyak <anthraxx@archlinux.org>
|
|
|
|
|
|
|
|
|
|
We need to modify the matching of valid package files to support formats
like zstd. Let's try to use an eager approach instead of a simple
whitelist in order to be functional for arbitrary formats that may be
introduced in the future without the need to adjust any code.
Allow any single fragment word as compression type but filter out known
non-package content like signature files.
Signed-off-by: Levente Polyak <anthraxx@archlinux.org>
|
|
This means that the remote command died at some stage earlier than the
printing of created files.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
|
|
Use pacman's --dbpath feature to sync fresh databases inside an isolated
location and split up the database sync and package location calls to
remove the need of weird grep calls.
It isn't nice of makechrootpkg to modify the host database state just by
building packages. No foreign program shall automatically modify
the host database other than by the explicit will of a system
maintainer, which is the major reason this changes get incorporated.
However, there is certain indoctrinated believe that using -Sy is
the prime evil. In fact it has been declared as a social rule to a
technical problem of not getting into potential partial upgrade states.
This is not a proper loophole less solution as there are multiple ways
and use cases that lead to such a state, like aborting a -Syu on the
prompt for whatever reason, what really matters is that it is not a
technically bullet proof solution to solve the problem.
Databases shall have the freedom to be as up to date as databases or
their owner wishes, allowing querying on latest database state without
fear. The only loophole-less contract that _really_ is from importance
is always using -Su instead of plain -S to install packages. Installing
packages is what actually brings one into a potential partial upgrade
state and by using -Su an outstanding upgrade is forced when installing
a new package. This properly solves all edge cases in a technical
manner instead of declaring people who abort the prompt of -Syu to be
the problem. In fact, using this simple contract allows whatever system
maintenance workflow a host owner wants to follow, which may still be to
always use -Syu and deal with system upgrades explicitly instead of the
time when installing new packages, but the -Su contract is the real safe
guard to guarantee no edge case can ever slip in. This magically also
opens up the freedom to people who wish to use -Sy to simply query on up
to date data as the currently indoctrinated "never do -Sy" stone plates
not only are not rock solid in technical terms but also make certain use
cases simply impossible and hence cripple the functionality without at
the very least being fully loophole free.
Signed-off-by: Levente Polyak <anthraxx@archlinux.org>
|
|
Avoid re-splitting remotepkg elements used for checkpkg conditions.
|
|
|
|
For build servers or similar infrastructure its relatively common to not
sync/update the database regularly. This leads to problems properly
running checkpkg duo to nonexistent target files that we try to
download. As building on build servers is a very common use case, lets
ensure we sync the local database before trying to resolve the package
locations.
|
|
Avoid always trying to download and output the according message.
Add checks for packages either not being available in the repo or
all variants have up to date versions stored in the local cache.
|
|
|
|
|
|
|
|
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
|
|
This attempts to recreate a package that was probably created using
makechrootpkg, and see if it conforms to the
https://reproducible-builds.org/ specification.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
|
