| Age | Commit message (Collapse) | Author |
|---|
|
|
|
(http[s]://mirror.url/path/$arch/$repo)
|
|
It's important to ensure the guest has up to date data because updating
a chroot after quite some time can potentially rely on updated
archlinux-keyring, something which the host machine either kept up to
date on or manually fixed, but it kills automation to mess around with
chroot configs like that. Alternatively, signed packages added with -I
need to work, and we assume the host is configured to accept these.
That is *not* a good reason to completely nuke whatever is in the guest,
though. A guest might have been manually configured to accept keys which
aren't accepted by the host; one example of this happening in practice,
is archlinux32 when building 32-bit packages from an archlinux host.
A simple solution is to use pacman-key's native facility to dump the
known keys and trust status from one gpg configuration, and import it
into another. Use this to append to, rather than overwrite, the chrooted
guest's pacman keyring.
While we are at it, fix a bug where we didn't respect the host's
pacman.conf settings for the GpgDir. While it isn't wildly likely a user
will choose to customize this, it is a valid and supported use case and
we must think about this ourselves.
|
|
|
|
--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
|
|
|
|
Some lines are indented by spaces, while adjacent lines are indentet by tabs.
We should use tabs on both.
|
|
|
|
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 fixes a regression introduced in eeb1c0e59ee8a5f7be4a6742ba6689af54e9ac7d
|
|
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
|
|
This is the new and improved, canonical sogrep command, now with a valid
license.
The previous version of sogrep had several issues and inefficiencies,
and ultimately wasn't really the finished project I wanted it to be. Due
to a mistake in communication, I was totally unaware it was in the
process of being merged at all, nor that there was a licensing issue, or
I would have recommended waiting for both further improvements, and a
declaration of license intent; nevertheless, here it is now, and I
formally give this over into the GPLv2+ domain.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
|
|
Partition the Makefile targets to only clean configured files, and make
the configured files be a subset of the bin programs.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
|
|
Introduce a README which describes where to send patches and how to
release a new version of devtools.
Signed-off-by: Jelle van der Waa <jelle@vdwaa.nl>
|
|
If makechrootpkg is called as non-root, the {SRC,SRCPKG,PKG,LOG}DEST,
MAKEFLAGS and PACKAGER environment variables are lost in the call to
check_root().
Add these to the passed keepenv list so that they are preserved instead.
|
|
Now that pacconf gives us all mirrors we can use them, instead of just
the first one.
Signed-off-by: Christian Hesse <mail@eworm.de>
|
|
The rename of sogrep to sogrep.in failed to remove sogrep and adding it
to .gitignore.
Signed-off-by: Jelle van der Waa <jelle@archlinux.org>
|
|
Signed-off-by: Jelle van der Waa <jelle@vdwaa.nl>
|
|
make clean removes all .in converted files to a file without .in which
in the make clean step is removed. So running make clean will remove
sogrep since it's specified as BINPROGS. In the future this steps should
be removed for sogrep since it is a standalone script.
Signed-off-by: Jelle van der Waa <jelle@vdwaa.nl>
|
|
Signed-off-by: Jelle van der Waa <jelle@vdwaa.nl>
|
|
Add a simple man page for find-libdeps and find-libprovides.
Signed-off-by: Jelle van der Waa <jelle@vdwaa.nl>
|
|
Add a section about environment variables which influence sogrep's
behaviour.
Signed-off-by: Jelle van der Waa <jelle@vdwaa.nl>
|
|
|
|
svn propset's where determined to be non-reproducible and therefore
where removed from svn. Don't introduce them when moving packages
between repos.
Signed-off-by: Jelle van der Waa <jelle@vdwaa.nl>
|
|
This is from Eli's dotfiles after he'd cleaned it up but never actually went ahead and made this PR.
I figure it's time to add it.
|
|
archrm is a not much more fancy rm -rf and therefore not really useful
to ship.
|
|
|
|
|
|
Even if continue would work, it does exactly the same as a return
in the way this function is being used.
|
|
makechrootpkg's download_sources() leaves a stray directory if
"makepkg --verifysource" failed. We use "setup_workdir" instead
of "mktemp -d", because this ensures the correct garbage collection.
Signed-off-by: Erich Eckner <git@eckner.net>
|
|
Les us source makepkg.conf settings from the environemnt. This also includes
`GNUPGHOME` which is present in `makechrootpkg`, but not included in archbuild.
Signed-off-by: Morten Linderud <foxboron@archlinux.org>
|
|
|
|
|
|
|
|
|
|
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>
|
|
Signed-off-by: Allan McRae <allan@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
|
|
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>
|