Previously files were always owned by nobody which means trying to write
to them directly would fail because only the owner has +w.
Signed-off-by: Florian Pritz <bluewind@xinu.at>
Signed-off-by: Pierre Schmitz <pierre@archlinux.de>
With bash-completion 2.0, the completion must have the same name as the binary.
Signed-off-by: Eric Bélanger <snowmaniscool@gmail.com>
Signed-off-by: Pierre Schmitz <pierre@archlinux.de>
* bind /sys and /dev/pts from host
* drop support for devtmpfs as it is no longer needed
* add /run and /dev/rtc0
* clone own ipc, uts and mount namespaces for chroot
* set localtime, timezone and locale within chroot environment
* copy /etc/pacman.d/gnupg from host
We need /dev/ptmx -> /dev/pts/ptmx (for devpts -o newinstance)
Other way to do this thing is via bind mount (as said kernel doc[devpts.txt]).
This should be done in this way at least for /dev as devtmpfs in the chroot.
Since we can not touch /dev (devtmpfs), because devtmpfs is "singleton",
just use bind method and avoid interference.
Do it the same for both modes of /dev (tmpfs) and (devtmpfs) to keep it simple.
Currently devpts in chroot is not working without this when using /dev as devtmpfs,
this fixes this issue (opening /dev/ptmx, creates devices nodes on outside /dev/pts)
Signed-off-by: Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>
Signed-off-by: Pierre Schmitz <pierre@archlinux.de>
The "@" sign in file names in SVN marks the beginning of a pegged
version number -- from the Subversion book:
Peg revisions are specified to the Subversion command-line client
using at syntax, so called because the syntax involves appending an
“at sign” (@) and the peg revision to the end of the path with which
the revision is associated.
The trivial workaround is to always append an at sign to the end of the
path in the version control checks.
Before:
$ community-stagingpkg 'Add systemd units.'
==> ERROR: exim-submission@.service is not under version control
$ svn status -v | grep 'exim-submission@.service'
A - ? ? exim-submission@.service
After:
$ community-stagingpkg 'Add systemd units.'
==> Committing changes to trunk...done
==> Signing package exim-4.80-2-x86_64.pkg.tar.xz...
[...]
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
Signed-off-by: Pierre Schmitz <pierre@archlinux.de>
The main intention of this patch is to take advantage of
/dev/loop-control and loop devices.
Signed-off-by: Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>
Signed-off-by: Pierre Schmitz <pierre@archlinux.de>
libperl.so results in soname="libperl.so.so" which is wrong.
This returns the correct string: "libperl.so"
Fix-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Florian Pritz <bluewind@xinu.at>
Signed-off-by: Pierre Schmitz <pierre@archlinux.de>
We do not allow packages to be uploaded without signatures so force
all unsigned packages to be signed. This has the bonus of not
breaking makepkg signing support by requiring you use an internal
makepkg variable.
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Pierre Schmitz <pierre@archlinux.de>
Compare every single tag with a list of valid tags. This prevents broken
releases which occurred whenever someone made a typo on the command
line:
$ ./archrelease community i686
==> ERROR: archrelease: Invalid tag: "community" (use -f to force release)
Since the list is used in the ZSH completion as well, break it out to a
separate file and move it to "lib/". Also, add a command line parameter
to allow for releasing to an unknown repository when necessary.
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
Signed-off-by: Pierre Schmitz <pierre@archlinux.de>
These tags make no sense. Remove them from our valid tag array that is
used for tab completion.
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
Signed-off-by: Pierre Schmitz <pierre@archlinux.de>
This fixes a problem where rsync won't work if the pkgver contains a
colon (epoch). In this case rsync assumes that the colon is a
remote:path separator and having src and dest both being remote
arguments is not supported.
Signed-off-by: Florian Pritz <bluewind@xinu.at>
Signed-off-by: Pierre Schmitz <pierre@archlinux.de>
Passing a directory that does not exist to makechrootpkg results in
an error message:
==> ERROR: No chroot dir defined, or invalid path ''
The path is not being printed as the readlink command blanks it if
the directory does not exist. Fix this.
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Pierre Schmitz <pierre@archlinux.de>
The problem has been introduced in commit
56d4dec19f
Signed-off-by: Florian Pritz <bluewind@xinu.at>
Signed-off-by: Pierre Schmitz <pierre@archlinux.de>
In the case of a .pkg.tar.xz and a .pkg.tar.gz existing in the same
directory, all commitpkg would say is:
==> WARNING: Could not find . Skipping x86_64
Upon digging into the logic, we did a few things poorly, mostly in
getpkgfile:
- getpkgfile tried to die in a subshell (within the command substituion
assignment to 'pkgfile'). This will never work.
- We assumed that proper glob expansion happened when we received
exactly 1 arg. This isn't necessarily true without nullglob in effect.
- We dumped the real error (spewed by getpkgfile) to /dev/null.
- We checked for the package twice in both $PWD and $DESTDIR/.
- We checked for file existance multiple times.
Address this by:
- not hiding errors. revamp the wording a little bit to make it more
obvious why we failed, particularly in the case of a glob expanding to
more than 1 file. Logic here is simplified to pointing out the failure
cases of 0 and >1.
- setting nullglob so the number of arguments passed into getpkgfile is
meaningful from a 'did it decisively resolve' point of view.
- not trying to exit the entire script from a subshell. Just return a
value (and use it).
- avoiding the package file existance check afterwards. this is a
freebie from getpkgfile when the glob passed fails to expand.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Pierre Schmitz <pierre@archlinux.de>
As of filesystem-2011.12 this is not needed anylonger, and indeed blocks the
chroot from being upgraded. As a workaround, recreating the chroot fixes the
problem.
Fixes FS#27640.
Reported-by: Andrea Scarpino <andrea@archlinux.org>
Signed-off-by: Tom Gundersen <teg@jklm.no>
Signed-off-by: Pierre Schmitz <pierre@archlinux.de>
This fixes a compound command such as the one below from continuing even
if the first fails.
extra-x86_64-build && extra-i686-build
The problem is that 'cleanup 0' is triggered in archbuild even after an
unsucessful call to makechrootpkg. Since both archbuild and
makechrootpkg share the exact same cleanup function (from lib/common),
we simply force the shell to exit with the true return value by exec'ing
the call to makechrootpkg.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Pierre Schmitz <pierre@archlinux.de>
This ensures the PATH used when building is the default path and
not the value set by the user calling makechrootpkg.
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Pierre Schmitz <pierre@archlinux.de>
This one fixes all the "Permission denied" errors we got when invoking
make(1) after modifying a source file and removes the need to delete the
generated scripts manually.
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
Signed-off-by: Pierre Schmitz <pierre@archlinux.de>
Pierre Schmitz
Florian Pritz
Eric Bélanger
Allan McRae
Gerardo Exequiel Pozzi
Lukas Fleischer
Jan Alexander Steffens (heftig)
Dave Reisner
Tom Gundersen
Timothy Redaelli