| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise, ob-genchanges looks for files that don't exist:
ob-genchanges: Generating "gcc-4.7_4.7.3+sip1-1_i686-linux-glibc_dev.changes"...
wc: ../../g++-4.7-amd64-linux-glibc_4.7.3+sip1-1_i686-linux-glibc_all.opk: No such file or directory
wc: ../../gcc-4.7-amd64-linux-glibc_4.7.3+sip1-1_i686-linux-glibc_all.opk: No such file or directory
And it tries to describe them too:
Files:
4883209 base cpp-4.7_4.7.3+sip1-1_i686-linux-glibc_all.opk
base g++-4.7-amd64-linux-glibc_4.7.3+sip1-1_i686-linux-glibc_all.opk
5313009 base g++-4.7-i686-linux-glibc_4.7.3+sip1-1_i686-linux-glibc_all.opk
base gcc-4.7-amd64-linux-glibc_4.7.3+sip1-1_i686-linux-glibc_all.opk
1652 base gcc-4.7-common_4.7.3+sip1-1_all_all.opk
7450176 base gcc-4.7-i686-linux-glibc_4.7.3+sip1-1_i686-linux-glibc_all.opk
[...]
|
| |
|
| |
|
|
|
|
| |
If the patches directory exists but is empty, ${patch} will be "../patches/*".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following can happen, for example, when using a "source" target to download
upstream sources:
$ opkbuild -bCT source
[...]
ob-unpacksource: No native or upstream sources found
ob-applypatches: Applying patch "01_fix-ob-applypatches-to-work-with-busybox.patch"...
/usr/local/bin/ob-applypatches: 53: cd: can't cd to src
patch: **** Can't open patch file ../../patches/01_fix-ob-applypatches-to-work-with-busybox.patch : No such file or directory
ob-applypatches: Error: Can't apply patch "01_fix-ob-applypatches-to-work-with-busybox.patch"
[...]
|
|
|
|
|
|
|
|
|
|
| |
This fixes the following superfluous errors:
$ opkbuild -bCT source
[...]
ob-genchanges: Generating "opkbuild_3.0.0~beta1-1_core-linux-eglibc_dev.changes"...
wc: ../../libopkbuild.1_3.0.0~beta1-1_all_all.opk: No such file or directory
wc: ../../opkbuild_3.0.0~beta1-1_all_all.opk: No such file or directory
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BusyBox's patch applet doesn't support the -d option, which is specified by
POSIX.1.
Fixes:
ob-applypatches: Applying patch "01_better-handle-unrecognized-options.patch"...
patch: invalid option -- 'd'
BusyBox v1.21.0 (2013-06-15 09:00:55 EDT) multi-call binary.
Usage: patch [OPTIONS] [ORIGFILE [PATCHFILE]]
-p,--strip N Strip N leading components from file names
-i,--input DIFF Read DIFF instead of stdin
-R,--reverse Reverse patch
-N,--forward Ignore already applied patches
-E,--remove-empty-files Remove output files if they become empty
ob-applypatches: Error: Can't apply patch "01_better-handle-unrecognized-options.patch"
|
|
|
|
| |
Otherwise, the option arguments might be collected by the opt_uid0_cmd.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Some tar archives (e.g. the GNU Binutils source archive) don't have
explicit directory entries.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The contents of the changelog file might be made architecture-dependent
by binary rebuilds. So prepare to make the file's pathname
architecture-specific to support co-installation of multiple
architectures.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This changed in SPF 2.0.
|
|
|
|
|
| |
This should prevent the unintended use of old copies of build helper
utilities that happened to be installed in a directory in the PATH.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
$ ls -l usr/share/doc
total 4
drwxr-xr-x 2 pj pj 4096 Oct 19 23:24 fakeroot-doc
$ ls -l usr/share/doc/fakeroot-doc
total 0
lrwxrwxrwx 1 pj pj 23 Oct 19 23:24 fakeroot -> /usr/share/doc/fakeroot
After:
$ ls -l usr/share/doc
total 0
lrwxrwxrwx 1 pj pj 23 Oct 20 12:58 fakeroot-doc -> /usr/share/doc/fakeroot
$ ls -l usr/share/doc/fakeroot-doc
lrwxrwxrwx 1 pj pj 23 Oct 20 12:58 usr/share/doc/fakeroot-doc -> /usr/share/doc/fakeroot
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
POSIX.1-2008 specifies that comments in makefile syntax start with a "#"
and continue "until an **unescaped** <newline> is reached" (empahsis
added).
FreeBSD's pmake apparently ignores the backslash before the newline in
comments and prints a "Need an operator" error message while parsing a
generated src/Makefile:
$ make
Making executable files...
"Makefile", line 49: Need an operator
make: fatal errors encountered -- cannot continue
NetBSD's pmake on the other hand appears to be POSIX-conformant in this
regard.
See also:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html#tag_20_76_13_01
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Backslash_002dNewline-Comments.html
|
| |
|
| |
|
| |
|
| |
|