| Age | Commit message (Collapse) | Author |
|---|
|
makepkg 5.1 implements error codes, and 14 means that installing the
packages after they were built has failed. We don't care about this
error and would like makechrootpkg to succeed regardless, e.g. for split
packages that are mutually exclusive.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
(cherry picked from commit 98ff92f4675aeab379b9d5ed85e68778e1cc0dfe)
|
|
This reverts commit ad54ac08ae475134f1ef6242cf4a831aa4ab770a.
|
|
|
|
|
|
It also sets SRCEXT="-$pkgarch$SRCEXT", so that two runs of makechrootpkg on
different architectures don't overwrite eachothers source packages.
|
|
|
|
|
|
|
|
2017-02-15: (070092d) Import from libretools.
2017-02-19: (7c55e79) Tidy formatting (2018-01-02: erroneously
removing newlines that had been added to avoid confusing
xgettext).
2017-05-05: (c4d5957) Don't say "local var" and "var=$(subshell)" in
the same command (shellcheck complains about this).
2017-09-24: Update to work with loading the message
functions from /usr/share/makepkg/util.sh
2018-01-02: Avoid confusing xgettext.
|
|
The change in arch-nspawn is subtle:
This was the source of "infamous" "it fails every other time" bug that
took me over a year to solve. <https://labs.parabola.nu/issues/435>
By having a repository of local packages (rather than simply running
`pacman -U`), we are inviting pacman to cache them in
`/var/cache/pacman/pkg`. Besides being needless disk writes, this
actually causes a real issue. If the package gets rebuilt, pacman
will balk, as the file no longer matches the cached signature.
So, how do we prevent pacman from caching these local packages?
Simple: include the directory they are already in in the
pacman.conf:CacheDir list. This will prevent pacman from copying
the files to one of the other cache directories.
|
|
The table is just armv7h->armv7l for now.
|
|
|
|
This affects both the usage() text, and the error message if the
`/.arch-chroot` version doesn't match. The latter is the one that I
really care about, and motivates this change.
On Parabola, the `arch-nspawn` program isn't in PATH, it's somewhere
under `/usr/lib/`, and gets called as a helper to user-facing
programs; and the error message is displayed directly to the user.
These programs consistently put two spaces after a period when
printing a message to the terminal.
|
|
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
|
|
|
|
It also sets SRCEXT="-$pkgarch$SRCEXT", so that two runs of makechrootpkg on
different architectures don't overwrite eachothers source packages.
|
|
|
|
|
|
|
|
2017-02-15: (070092d) Import from libretools.
2017-02-19: (7c55e79) Tidy formatting (2018-01-02: erroneously
removing newlines that had been added to avoid confusing
xgettext).
2017-05-05: (c4d5957) Don't say "local var" and "var=$(subshell)" in
the same command (shellcheck complains about this).
2017-09-24: Update to work with loading the message
functions from /usr/share/makepkg/util.sh
2018-01-02: Avoid confusing xgettext.
|
|
The change in arch-nspawn is subtle:
This was the source of "infamous" "it fails every other time" bug that
took me over a year to solve. <https://labs.parabola.nu/issues/435>
By having a repository of local packages (rather than simply running
`pacman -U`), we are inviting pacman to cache them in
`/var/cache/pacman/pkg`. Besides being needless disk writes, this
actually causes a real issue. If the package gets rebuilt, pacman
will balk, as the file no longer matches the cached signature.
So, how do we prevent pacman from caching these local packages?
Simple: include the directory they are already in in the
pacman.conf:CacheDir list. This will prevent pacman from copying
the files to one of the other cache directories.
|
|
The table is just armv7h->armv7l for now.
|
|
|
|
This affects both the usage() text, and the error message if the
`/.arch-chroot` version doesn't match. The latter is the one that I
really care about, and motivates this change.
On Parabola, the `arch-nspawn` program isn't in PATH, it's somewhere
under `/usr/lib/`, and gets called as a helper to user-facing
programs; and the error message is displayed directly to the user.
These programs consistently put two spaces after a period when
printing a message to the terminal.
|
|
This allows signature verification by `makepkg --verifysource`, `git
verify-tag`, and such without requiring the user to manually retrieve
the keys first.
This is based off of devtools32 commit 009695b (2017-06-27) by
Erich Eckner <git@eckner.net>. There are 2 differences from that
commit:
- In this version, gpg.conf is owned by builduser, not by root
- In this version, we don't keep appending duplicate lines if we
re-use a chroot
|
|
chown support "$user:$group" but also "$user:" which infers $group
rather than leaving it as root. This looks up the group name in cases
where the default group is e.g. "users" and users do not get their own
unique groups.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
|
|
chown support "$user:$group" but also "$user:" which infers $group
rather than leaving it as root. This looks up the group name in cases
where the default group is e.g. "users" and users do not get their own
unique groups.
|
|
It is much nicer to use a proper configuration parser to retrieve the
primary mirror, rather than clever hacks using undocumented APIs,
especially when their behavior as used then breaks in later releases.
Fortunately, pacutils exists now and pacconf handles this quite
elegantly. It has since been moved to pacman-git proper.
Check if pacman-conf from a new enough version of pacman exists and
fallback on pacconf from pacutils.
|
|
cache"
This reverts commit eb6b0e3f11279b6512b1469ff042d2982eaaeef4.
This never worked, as pacman-git returns file urls from the cache anyway
and pacman stable doesn't have any problem at all. Having useless code
which makes people think the issue is solved when it really isn't, is
bloat, so remove it.
|
|
Since commit 75fdff1811a0487f82c75b2e260da905102b4eea we no longer run
integrity checks inside the chroot anyway, so this is no longer needed
and will never be used.
|
|
Without it, sudo 1.8.23 will return an error:
sudo: PAM account management error: Authentication
service cannot retrieve authentication info
|
|
|
|
|
|
It also sets SRCEXT="-$pkgarch$SRCEXT", so that two runs of makechrootpkg on
different architectures don't overwrite eachothers source packages.
|
|
|
|
|
|
|
|
2017-02-15: (070092d) Import from libretools.
2017-02-19: (7c55e79) Tidy formatting (2018-01-02: erroneously
removing newlines that had been added to avoid confusing
xgettext).
2017-05-05: (c4d5957) Don't say "local var" and "var=$(subshell)" in
the same command (shellcheck complains about this).
2017-09-24: Update to work with loading the message
functions from /usr/share/makepkg/util.sh
2018-01-02: Avoid confusing xgettext.
|
|
The change in arch-nspawn is subtle:
This was the source of "infamous" "it fails every other time" bug that
took me over a year to solve. <https://labs.parabola.nu/issues/435>
By having a repository of local packages (rather than simply running
`pacman -U`), we are inviting pacman to cache them in
`/var/cache/pacman/pkg`. Besides being needless disk writes, this
actually causes a real issue. If the package gets rebuilt, pacman
will balk, as the file no longer matches the cached signature.
So, how do we prevent pacman from caching these local packages?
Simple: include the directory they are already in in the
pacman.conf:CacheDir list. This will prevent pacman from copying
the files to one of the other cache directories.
|
|
The table is just armv7h->armv7l for now.
|
|
|
|
This affects both the usage() text, and the error message if the
`/.arch-chroot` version doesn't match. The latter is the one that I
really care about, and motivates this change.
On Parabola, the `arch-nspawn` program isn't in PATH, it's somewhere
under `/usr/lib/`, and gets called as a helper to user-facing
programs; and the error message is displayed directly to the user.
These programs consistently put two spaces after a period when
printing a message to the terminal.
|
|
This allows signature verification by `makepkg --verifysource`, `git
verify-tag`, and such without requiring the user to manually retrieve
the keys first.
This is based off of devtools32 commit 009695b (2017-06-27) by
Erich Eckner <git@eckner.net>. There are 2 differences from that
commit:
- In this version, gpg.conf is owned by builduser, not by root
- In this version, we don't keep appending duplicate lines if we
re-use a chroot
|
|
In pacman-git commit d8717a6a9666ec80c8645d190d6f9c7ab73084ac makepkg
started checking that the setuid/setgid bit could be removed on the
$BUILDDIR in order to prevent this propagating to the packages
themselves. Unfortunately, this requires the temporary builddir used
during the --verifysource stage of makepkg, to be owned by $makepkg_user
which was not the case as it is created as root using mktemp (and given
world rwx in addition to the restricted deletion bit.)
Obviously makepkg cannot chmod a directory that it does not own. Fix
this by making $makepkg_user the owner of that directory, as should have
been the case all along.
(Giving world rwx is illogical on general principle. The fact that this
is a workaround for makepkg demanding these directories be writable even
when they are not going to be used for the makepkg options in question,
is not justification for being careless.)
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
|
|
Previously, makechrootpkg hardcoded ~/.gnupg. Therefore, if a user
uses a custom GPG home directory, the siganture checking would fail.
Now makechrootpkg uses $GNUPGHOME, with a fallback to ~/.gnupg.
Signed-off-by: Emiel Wiedijk <me@aimileus.nl>
|
|
While still possible with 'commitpkg core', there is a chance it will
prevent accidental pushes straight to [core].
|
|
|
|
This worked properly until eab5aba.
|
|
Support for working with `set -u` was broken by 94160d6. Egg on my
face; I'm the one who wants `set -u` support, and I'm the author of
that commit!
libmakepkg does not work with `set -u`; but mostly because of the include
guards! So we just need to temporarily disable `set -u` (nounset) while
loading libmakepkg. Instead of introducing a new variable, just store the
initial nounset status in _INCLUDE_COMMON_SH; rather than a useless
fixed-string "true".
While we're at it, disable POSIX-mode (just in case we're running as "sh"
instead of "bash"), since libmakepkg uses bash-isms that won't parse in
POSIX mode.
|