- 06 11月, 2018 1 次提交
-
-
由 Masahiro Yamada 提交于
Zhenzhong Duan reported that running 'make O=/build/kernel binrpm-pkg' failed with the following errors: Running 'make O=/build/kernel binrpm-pkg' failed with below two errors. Makefile:600: include/config/auto.conf: No such file or directory + cp make -C /mnt/root/kernel O=/build/kernel image_name make -f /mnt/root/kernel/Makefile ... cp: invalid option -- 'C' Try 'cp --help' for more information. Prior to commit 80463f1b ("kbuild: add --include-dir flag only for out-of-tree build"), both srctree and objtree were added to --include-dir redundantly, and the wrong code 'make image_name' was working by relying on that. Now, the potential issue that had previously been hidden just showed up. 'make image_name' recurses to the generated $(objtree)/Makefile and ends up with running in srctree, which is incorrect. It should be invoked with '-f $srctree/Makefile' (or KBUILD_SRC=) to be executed in objtree. Fixes: 80463f1b ("kbuild: add --include-dir flag only for out-of-tree build") Reported-by: NZhenzhong Duan <zhenzhong.duan@oracle.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 28 7月, 2018 12 次提交
-
-
由 Ben Hutchings 提交于
Different generations of the SH architecture are not very compatible, so there are/were separate Debian ports for SH3 and SH4. Move the fallback out of the "case" statement, so that it will also be used in case we find some SH architecture version without a known mapping. Signed-off-by: NBen Hutchings <ben@decadent.org.uk> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Ben Hutchings 提交于
Debian currently only defines "riscv64", but it seems safe to assume that any 32-bit port will now be called "riscv32", also matching $UTS_MACHINE. Signed-off-by: NBen Hutchings <ben@decadent.org.uk> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Ben Hutchings 提交于
Signed-off-by: NBen Hutchings <ben@decadent.org.uk> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Ben Hutchings 提交于
Signed-off-by: NBen Hutchings <ben@decadent.org.uk> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Ben Hutchings 提交于
We currently label 64-bit kernel packages as sparc (32-bit), mostly because it was officially supported while sparc64 was not. Now neither is officially supported, so label these packages as sparc64. Signed-off-by: NBen Hutchings <ben@decadent.org.uk> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Ben Hutchings 提交于
MIPS R6 is not fully backward-compatible, so Debian has separate architecture names for userland built for R6. Label kernel packages accordingly. Signed-off-by: NBen Hutchings <ben@decadent.org.uk> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Ben Hutchings 提交于
We currently label 64-bit little-endian kernel packages as mipsel (32-bit little-endian), mostly it was officially supported while mips64el (64-bit little-endian) was not. Now both are officially supported, so label these packages as mips64el. Signed-off-by: NBen Hutchings <ben@decadent.org.uk> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Ben Hutchings 提交于
We currently label 64-bit big-endian kernel packages as powerpc (32-bit), mostly because it was officially supported while ppc64 (64-bit big-endian) was not. Now neither is officially supported, so label these packages as ppc64. Debian also has a powerpcspe (32-bit with SPE) architecture. Label packages with a suitable configuration as powerpcspe. Signed-off-by: NBen Hutchings <ben@decadent.org.uk> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Ben Hutchings 提交于
We now have many repetitive greps over the kernel config. Refactor them into functions. Signed-off-by: NBen Hutchings <ben@decadent.org.uk> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Ben Hutchings 提交于
s390 now only supports 64-bit configurations. Signed-off-by: NBen Hutchings <ben@decadent.org.uk> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Ben Hutchings 提交于
We currently use dpkg --print-architecture, which reports the architecture of the build machine. We can make a better guess than this by asking dpkg-architecture what the host architecture, i.e. the default architecture for building packages, is. This is sensitive to environment variables such as CC and DEB_HOST_ARCH, which should already be set in a cross-build environment. Signed-off-by: NBen Hutchings <ben@decadent.org.uk> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Ben Hutchings 提交于
If KBUILD_DEBARCH is set then we will not use the result of architecture detection, and we may also warn unnecessarily. Move the check for KBUILD_DEBARCH further up to avoid this. Signed-off-by: NBen Hutchings <ben@decadent.org.uk> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 19 7月, 2018 2 次提交
-
-
由 Olof Johansson 提交于
Make 'make tar-pkg' work on arm64. Cc: Will Deacon <will.deacon@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: NOlof Johansson <olof@lixom.net> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Olof Johansson 提交于
ARCH=vax isn't in mainline; it can be added back if/when it shows up. Signed-off-by: NOlof Johansson <olof@lixom.net> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 17 5月, 2018 1 次提交
-
-
由 Riku Voipio 提交于
There is multiple issues with the genaration of maintainer string It uses DEBEMAIL and EMAIL enviroment variables, which may contain angle brackets, creating invalid maintainer strings. The documented KBUILD_BUILD_USER and KBUILD_BUILD_HOST variables are not used. Undocumented and uncommon NAME variable is used. Refactor the Maintainer string to: - use EMAIL or DEBEMAIL directly if they are in form "name <user@host>" - use KBUILD_BUILD_USER and KBUILD_BUILD_HOST if set before falling back to autodetection - no longer use NAME variable or the useless Anonymous string The logic is switched from multiline if/then/fi statements to compact shell variable substition commands. Reported-by: NMathieu Malaterre <malat@debian.org> Signed-off-by: NRiku Voipio <riku.voipio@linaro.org> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 13 4月, 2018 1 次提交
-
-
由 Javier Martinez Canillas 提交于
The new-kernel-pkg script is only present when grubby is installed, but it may not always be the case. So if the script isn't present, attempt to use the kernel-install script as a fallback instead. Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 07 4月, 2018 1 次提交
-
-
由 Riku Voipio 提交于
Move debian/ directory generation out of builddeb to a new script, mkdebian. The package build commands are kept in builddeb, which is now an internal command called from debian/rules. With these changes in place, we can now use dpkg-buildpackage from deb-pkg and bindeb-pkg removing need for handrolled source/changes generation. This patch is based on the criticism of the current state of builddeb discussed on: https://patchwork.kernel.org/patch/9656403/Signed-off-by: NRiku Voipio <riku.voipio@linaro.org> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 28 3月, 2018 2 次提交
-
-
由 Jason Gunthorpe 提交于
There is a change in how command line parsing is done in this version. Excludes and includes are now ordered with the file list. Since the spec file puts the file list before the exclude list it means newer tar ignores the excludes and packs all the build output into the kernel-devel RPM resulting in a huge package. Simple argument re-ordering fixes the problem. Signed-off-by: NJason Gunthorpe <jgg@mellanox.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Jan Kiszka 提交于
Since d5d332d3, a couple of links in scripts/dtc/include-prefixes are additionally required in order to build device trees with the header package. Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com> Reviewed-by: NRiku Voipio <riku.voipio@linaro.org> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 12 12月, 2017 2 次提交
-
-
由 Masahiro Yamada 提交于
We do not support out-of-tree building of rpm-pkg / deb-pkg. If O= is given, the build should be terminated, but the "false" command is not effective since it is not the last command in the cmd_src_tar. Then, rpm-pkg / deb-pkg tries to continue building, and fails for a different reason. Set -e option so that the "false" terminates the building immediately. I also put the error messages to stderr, and made it stand out more. For example, "make O=foo rpm-pkg" will fail as follows: /bin/bash ../scripts/package/mkspec >./kernel.spec TAR kernel-4.15.0_rc2+.tar.gz ERROR: Building source tarball is not possible outside the kernel source tree. Don't set KBUILD_OUTPUT, or use the binrpm-pkg or bindeb-pkg target instead. ../scripts/package/Makefile:53: recipe for target 'rpm-pkg' failed Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Tested-by: NJim Davis <jim.epost@gmail.com>
-
由 Paolo Pisati 提交于
Following in footsteps of other targets like 'deb-pkg, 'rpm-pkg' and 'tar-pkg', this patch adds a 'snap-pkg' target for the creation of a Linux kernel snap package using the kbuild infrastructure. A snap, in its general form, is a self contained, sandboxed, universal package and it is intended to work across multiple distributions and/or devices. A snap package is distributed as a single compressed squashfs filesystem. A kernel snap is a snap package carrying the Linux kernel, kernel modules, accessory files (DTBs, System.map, etc) and a manifesto file. The purpose of a kernel snap is to carry the Linux kernel during the creation of a system image, eg. Ubuntu Core, and its subsequent upgrades. For more information on snap packages: https://snapcraft.io/docs/Signed-off-by: NPaolo Pisati <paolo.pisati@canonical.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 23 11月, 2017 2 次提交
-
-
由 Masahiro Yamada 提交于
The "rpm" has been kept for backward compatibility since pre-git era. I am planning to remove it after the Linux 4.18 release. Annouce the end of the support, prompting to use "rpm-pkg" instead. If you use "rpm", it will work like "rpm-pkg", but warning messages will be displayed as follows: WARNING: "rpm" target will be removed after Linux 4.18 Please use "rpm-pkg" instead. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
For rpm-pkg and deb-pkg, a source tar file is created. All paths in the archive must be prefixed with the base name of the tar so that everything is contained in the directory when you extract it. Currently, scripts/package/Makefile uses a symlink for that, and removes it after the tar is created. If you terminate the build during the tar creation, the symlink is left over. Then, at the next package build, you will see a warning like follows: ln: '.' and 'kernel-4.14.0+/.' are the same file It is possible to fix it by adding -n (--no-dereference) option to the "ln" command, but a cleaner way is to use --transform option of "tar" command. This option is GNU extension, but it should not hurt to use it in the Linux build system. The 'S' flag is needed to exclude symlinks from the path fixup. Without it, symlinks in the kernel are broken. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 14 11月, 2017 7 次提交
-
-
由 Sven Joachim 提交于
At the end of "make bindeb-pkg" I noticed the following warning: dpkg-genchanges: warning: unknown substitution variable ${kernel:debarch} It turns out that since dpkg version 1.19.0 dpkg-genchanges honors substitution variables in the Description field, while earlier versions silently left them alone, see https://bugs.debian.org/856547. The result is an incomplete description of the linux-headers package in the generated .changes file. Fix it by passing the kernel:debarch substitution variable to dpkg-genchanges. Signed-off-by: NSven Joachim <svenjoac@gmx.de> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
The spec file always passes %{?_smp_mflags}, but we have two problems here. [1] "make -jN rpm-pkg" emits the following warning message: make[2]: warning: -jN forced in submake: disabling jobserver mode. [2] We can not specify the number of jobs that run in parallel. Whether we give -jN or not from the top Makefile, the spec file always passes ${?_smp_mflags} to the build commands. ${?_smp_mflags} will be useful when we run rpmbuild by hand. When we invoke it from Makefile, -jN is propagated down to submake; it should not be overridden because we want to respect the number of jobs given by the user. Set _smp_mflags to empty string in this case. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
If build fails during (bin)rpm-pkg, the spec file is not cleaned by anyone until the next successful build of the package. We do not have to immediately delete the spec file in case somebody may want to take a look at it. Instead, make them ignored by git, and cleaned up by make mrproper. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
If "make rpm-pkg" or "make binrpm-pkg" is run with -j[jobs] option, the following warning message is displayed. warning: jobserver unavailable: using -j1. Add '+' to parent make rule. Follow the suggestion. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
$RPM_BUILD_ROOT must be escaped to prevent shell from expanding it when generating the spec file. %{build_root} is more readable than \$RPM_BUILD_ROOT. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
When CONFIG_MODULES is disabled, make rpm-pkg / binrpm-pkg fails with the following message: The present kernel configuration has modules disabled. Type 'make config' and enable loadable module support. Then build a kernel with module support enabled. Do not install modules in the case. Also, omit the devel package. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
The repeat of echo is unreadable. The here-document is a well-known device for such scripts. One difficulty is we have a bunch of PREBUILT conditionals that would split the here-document. My idea is to add "$S" annotatation to lines only for the source package spec file, then post-process it by sed. I hope it will make our life easier than repeat of "cat <<EOF ..." I confirmed this commit still produced the same (bin)kernel.spec as before. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 02 11月, 2017 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org> Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 09 10月, 2017 3 次提交
-
-
由 Masahiro Yamada 提交于
Clean up the mkspec without changing the behavior. - grep CONFIG_DRM=y more simply - move "EXCLUDE" out of the "%install" section because it can be computed when the spec file is generated - remove "BuildRoot:" field, which is now redundant - do not mkdir $RPM_BUILD_ROOT/lib/modules explicitly because it is automatically created by "make modules_install" - exclude "%package devel" from source package spec file because it does not make sense where "%files devel" is already excluded - exclude "%build" from source package spec file - remove unneeded "make clean" because we had already cleaned before making tar file - merge two %ifarch ia64 conditionals - replace KBUILD_IMAGE with direct use of $(make image_name) - remove trailing empty line from the spec file Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
This conditional was added by commit fc370ecf ("kbuild: add vmlinux to kernel rpm"). Its git-log mentioned vmlinux.bz2 was necessary for debugging, but did not explain why ppc64 was an exception. I see no problem to copy vmlinux.bz2 all the time. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
This conditional was added by commit 1a0f3d42 ("kbuild: fix make rpm for powerpc"). Its git-log explains the default kernel image is zImage, but obviously the current arch/powerpc/Makefile does not set KBUILD_IMAGE, so the image file is actually vmlinux. Moreover, since commit 09549aa1 ("deb-pkg: Remove the KBUILD_IMAGE workaround"), all architectures are supposed to set the full path to the image in KBUILD_IMAGE. I see no good reason to differentiate ppc64 from others. Rip off the conditional. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 20 9月, 2017 3 次提交
-
-
由 Masahiro Yamada 提交于
The "Release:" field of the spec file is determined based on the .version file. However, the .version file is not copied to the source tar file. So, when we build the kernel from the source package, the UTS_VERSION always indicates #1. This does not match with "rpm -q". The kernel UTS_VERSION and "rpm -q" do not agree for binrpm-pkg, either. Please note the kernel has already been built before the spec file is created. Currently, mkspec invokes mkversion. This script returns an incremented version. So, the "Release:" field of the spec file is greater than the version in the kernel by one. For the source package build (where .version file is missing), we can give KBUILD_BUILD_VERSION=%{release} to the build command. For the binary package build, we can simply read out the .version file because it contains the version number that was used for building the kernel image. We can remove scripts/mkversion because scripts/package/Makefile need not touch the .version file. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
Commit 5620a0d1 ("firmware: delete in-kernel firmware") deleted in-kernel firmware support, including the firmware install command. So, the firmware package does not make sense any more. Remove it. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: NRiku Voipio <riku.voipio@linaro.org> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Masahiro Yamada 提交于
Commit 5620a0d1 ("firmware: delete in-kernel firmware") deleted in-kernel firmware support, including "make firmware_install". Since then, "make rpm-pkg" / "make binrpm-pkg" fails to build with the error: make[2]: *** No rule to make target `firmware_install'. Stop. Commit df85b2d7 ("firmware: Restore support for built-in firmware") restored the build infrastructure for CONFIG_EXTRA_FIRMWARE, but this is out of the scope of "make firmware_install". So, the right thing to do is to kill the use of "make firmware_install". Fixes: 5620a0d1 ("firmware: delete in-kernel firmware") Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 12 9月, 2017 2 次提交
-
-
由 Masahiro Yamada 提交于
The previous commit spotted that "Tarball successfully created ..." is displayed even if the "tar" command returns error code because it is followed by "| ${compress}". Let the build fail instead of printing the successful message since if the "tar" command fails, the output may not be what users expect. Avoid the use of the pipe. While we are here, refactor the script removing the use of sub-shell, ${compress}, ${file_ext}. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
$tmpdir/lib is created by "make modules_install". It does not exist if CONFIG_MODULES is disabled, then tar reports the following messages: tar: lib: Cannot stat: No such file or directory tar: Exiting with failure status due to previous errors Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-