Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [autobuild.buildroot.net] Your build results for 2017-05-02
From: Thomas Petazzoni @ 2017-05-04 15:46 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1493912093.7376.14.camel@synopsys.com>

Hello,

On Thu, 4 May 2017 15:34:55 +0000, Alexey Brodkin wrote:

> Unfortunately in the beginning of the current toolchain development cycle
> we decided to stay on uClibc-ng 1.0.17 + backported ARC-related patches
> due to different reasons and given we're now on rc2 stage there's no chance
> to switch to any other version unfortunately. I hope next dev cycle we'll use just
> latest upstream uClibc-ng release.

OK. Can you make sure to enable wordexp as well?

> We're talking only about __prebuilt__ ARC toolchain right?
> Because Buildroot-built tools use latest uClibc-ng with correct config.

Wow, I just discovered that our autobuilders were not properly setup.
They are not supposed to test the Synopsys pre-built toolchain, but a
Buildroot pre-built toolchain. But they are testing the Synopsys
pre-built toolchain.

To clarify things, we have three toolchain possibilities:

 - The internal toolchain backend, Buildroot builds the entire
   toolchain from scratch for every build. This is what the base
   configuration
   http://autobuild.buildroot.net/toolchains/configs/br-arc-full-internal.config
   is doing.

 - The external toolchain backend that uses a custom toolchain, itself
   built by Buildroot. This one I have rebuilt recently with uClibc-ng
   1.0.24 and wordexp. It is the toolchain configuration supposed to be
   tested by
   http://autobuild.buildroot.net/toolchains/configs/br-arcle-hs38.config.
   Except that this file lacks BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y, so
   instead of using the custom toolchain specified in this defconfig,
   it uses the Synopsys pre-built toolchain. Weird that Arnout's check
   that all lines of the base configuration are still present in the
   final configuration doesn't detect this.

 - The external toolchain backend that uses the Synopsys provided
   pre-built toolchain, through the toolchain-external-synopsys-arc
   package. This is *NOT* supposed to be tested by the autobuilders
   currently.

> Ideally I'd prefer to update affected packages so they are disabled for
> ARC prebuilt tools with some easily greppable comment like:
> ----------------->8-----------------  
> ?xxx yyy zzz # arc_prebuilt lacks wordexp
> ----------------->8-----------------  
> that will help us to track missing parts we need to work on in the future.
> Otherwise we may just disable autobuilder for ARC prebuilt tools because:
> 
> 1) There's no such thing as prebuilt engineering builds i.e. autobuilder
> ? ?only will test either RCs or final releases of ARC prebuilt tools which
> ? ?IMHO makes not much sense as that's a bit too late, rgiht?
> 
> 2) We know there're differences in ARC prebuilt tools from what gets built in
> ? ?Buildroot still having ARC prebuilt tools is a nice opportunity to
> ? ?simplify life for some people who prefers to not build toolchain
> ? ?themselves and for basic stuff it usually works quite fine.

Sorry, but I don't understand what you suggested here. In the light of
my explanation above, could you clarify what you mean by "ARC prebuilt
tools" ?

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* [Buildroot] [autobuild.buildroot.net] Your build results for 2017-05-02
From: Alexey Brodkin @ 2017-05-04 15:34 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <87r305au17.fsf@dell.be.48ers.dk>

Hi Thomas, Peter, Waldemar, all,

On Thu, 2017-05-04 at 10:46 +0200, Peter Korsgaard wrote:
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > "Thomas" == Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> writes:
> 
> ?> Hello,
> ?> On Thu, 4 May 2017 09:48:57 +0200, Waldemar Brodkorb wrote:
> 
> ?>> I wouldn't say it was wrong.
> ?>> We have all internal toolchains fixed and we get a good idea about the quality of the latest release.
> ?>>?
> ?>> May be it will motivate Synopsis to release a new tarball, as other important ARC Bugfixes are included
> ?>> in this release.?
> 
> ?> Well the problem is that in the mean time, we have autobuilder failures
> ?> caused by this. We are about to release -rc1, so we will try to reduce
> ?> the number of autobuilder failures, and this will get in the way. Which
> ?> is why we need to find a solution here.
> 
> ?> Options:
> 
> ?>??(1) Synopsys quickly publishes a new pre-built toolchain with uClibc
> ?>??????1.0.24 + wordexp

Unfortunately in the beginning of the current toolchain development cycle
we decided to stay on uClibc-ng 1.0.17 + backported ARC-related patches
due to different reasons and given we're now on rc2 stage there's no chance
to switch to any other version unfortunately. I hope next dev cycle we'll use just
latest upstream uClibc-ng release.

In other words (1) won't happen in coming days.
> 
> ?>??(2) We disable the Synopsys toolchain from our autobuilders

We're talking only about __prebuilt__ ARC toolchain right?
Because Buildroot-built tools use latest uClibc-ng with correct config.

Ideally I'd prefer to update affected packages so they are disabled for
ARC prebuilt tools with some easily greppable comment like:
----------------->8-----------------
?xxx yyy zzz # arc_prebuilt lacks wordexp
----------------->8-----------------
that will help us to track missing parts we need to work on in the future.
Otherwise we may just disable autobuilder for ARC prebuilt tools because:

1) There's no such thing as prebuilt engineering builds i.e. autobuilder
? ?only will test either RCs or final releases of ARC prebuilt tools which
? ?IMHO makes not much sense as that's a bit too late, rgiht?

2) We know there're differences in ARC prebuilt tools from what gets built in
? ?Buildroot still having ARC prebuilt tools is a nice opportunity to
? ?simplify life for some people who prefers to not build toolchain
? ?themselves and for basic stuff it usually works quite fine.

-Alexey

^ permalink raw reply

* [Buildroot] [PATCH] binutils: disallow selection of 2.27 on ARM/noMMU
From: Thomas Petazzoni @ 2017-05-04 15:28 UTC (permalink / raw)
  To: buildroot

binutils 2.27 triggers a segfault in elf2flt on ARM/noMMU. While Arnout
has identified a binutils 2.28 commit that can be backported on 2.27,
this commit is huge and we don't clearly understand the impact.

Since both binutils 2.26 and 2.28 are unaffected by this issue, we
simply disallow the selection of binutils 2.27 on ARM/noMMU, and default
to binutils 2.28.

Fixes:

  http://autobuild.buildroot.net/results/e14cadb290b0b86cac12c4bfb681eb6eee9e6dea/
  and lots of other similar ARM/Cortex-M4 failures

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/binutils/Config.in.host | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/package/binutils/Config.in.host b/package/binutils/Config.in.host
index aa24fd7..e147ef0 100644
--- a/package/binutils/Config.in.host
+++ b/package/binutils/Config.in.host
@@ -3,6 +3,7 @@ comment "Binutils Options"
 choice
 	prompt "Binutils Version"
 	default BR2_BINUTILS_VERSION_2_27_X
+	default BR2_BINUTILS_VERSION_2_28_X if (BR2_arm && !BR2_USE_MMU)
 	depends on !BR2_arc
 	help
 	  Select the version of binutils you wish to use.
@@ -12,6 +13,8 @@ config BR2_BINUTILS_VERSION_2_26_X
 
 config BR2_BINUTILS_VERSION_2_27_X
 	bool "binutils 2.27"
+	# binutils 2.27 triggers a bug in elf2flt on ARM/noMMU
+	depends on !(BR2_arm && !BR2_USE_MMU)
 
 config BR2_BINUTILS_VERSION_2_28_X
 	bool "binutils 2.28"
-- 
2.7.4

^ permalink raw reply related

* [Buildroot] [PATCH 3/3] package/mke2img: remove package
From: Sébastien Szymanski @ 2017-05-04 15:26 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1493911563-2453-1-git-send-email-sebastien.szymanski@armadeus.com>

Now that we use mkfs to generate ext2/3/4 filesystem image by calling
mkfs directly from fs/ext2/ext2.mk, we can remove this package.

Signed-off-by: S?bastien Szymanski <sebastien.szymanski@armadeus.com>
---
 Config.in.legacy               |   6 ++
 DEVELOPERS                     |   1 -
 package/mke2img/Config.in.host |  11 ---
 package/mke2img/mke2img        | 196 -----------------------------------------
 package/mke2img/mke2img.mk     |  13 ---
 5 files changed, 6 insertions(+), 221 deletions(-)
 delete mode 100644 package/mke2img/Config.in.host
 delete mode 100755 package/mke2img/mke2img
 delete mode 100644 package/mke2img/mke2img.mk

diff --git a/Config.in.legacy b/Config.in.legacy
index 5fc37ec..b8e33af 100644
--- a/Config.in.legacy
+++ b/Config.in.legacy
@@ -145,6 +145,12 @@ endif
 ###############################################################################
 comment "Legacy options removed in 2017.05"
 
+config BR2_PACKAGE_HOST_MKE2IMG
+	bool "host mke2img has been removed"
+	select BR2_LEGACY
+	help
+	  We now call mkfs directly to generate ext2/3/4 filesystem image.
+
 config BR2_TARGET_ROOTFS_EXT2_INODES
 	int "exact number of inodes has been removed"
 	default 0
diff --git a/DEVELOPERS b/DEVELOPERS
index 82eb819..9c79d8b 100644
--- a/DEVELOPERS
+++ b/DEVELOPERS
@@ -1699,7 +1699,6 @@ F:	package/libiscsi/
 F:	package/libseccomp/
 F:	package/linux-tools/
 F:	package/mesa3d-headers/
-F:	package/mke2img/
 F:	package/nbd/
 F:	package/nut/
 F:	package/nvidia-driver/
diff --git a/package/mke2img/Config.in.host b/package/mke2img/Config.in.host
deleted file mode 100644
index b5bcb84..0000000
--- a/package/mke2img/Config.in.host
+++ /dev/null
@@ -1,11 +0,0 @@
-config BR2_PACKAGE_HOST_MKE2IMG
-	bool "host mke2img"
-	select BR2_PACKAGE_HOST_E2FSPROGS
-	select BR2_PACKAGE_HOST_GENEXT2FS
-	help
-	  Easily create filesystems of the extend familly: ext2/3/4.
-
-	  This tool is bundled by, and specific to Buildroot. However, it can
-	  be used from post-images scripts is needed.
-
-	  https://code.google.com/p/mke2img/
diff --git a/package/mke2img/mke2img b/package/mke2img/mke2img
deleted file mode 100755
index b773aa9..0000000
--- a/package/mke2img/mke2img
+++ /dev/null
@@ -1,196 +0,0 @@
-#!/usr/bin/env bash
-
-# Buildroot wrapper to the collection of ext2/3/4 filesystem tools:
-# - genext2fs, to generate ext2 filesystem images
-# - tune2fs, to modify an ext2/3/4 filesystem (possibly in an image file)
-# - e2fsck, to check and fix an ext2/3/4 filesystem (possibly in an image file)
-
-set -e
-
-main() {
-    local OPT OPTARG
-    local nb_blocks nb_inodes nb_res_blocks root_dir image gen rev label uuid
-    local -a genext2fs_opts
-    local -a tune2fs_opts
-    local tune2fs_O_opts
-
-    # Default values
-    gen=2
-    rev=1
-    nb_extra_inodes=0
-
-    while getopts :hb:i:I:r:d:o:G:R:l:u: OPT; do
-        case "${OPT}" in
-        h)  help; exit 0;;
-        b)  nb_blocks=${OPTARG};;
-        i)  nb_inodes=${OPTARG};;
-        I)  nb_extra_inodes=${OPTARG};;
-        r)  nb_res_blocks=${OPTARG};;
-        d)  root_dir="${OPTARG}";;
-        o)  image="${OPTARG}";;
-        G)  gen=${OPTARG};;
-        R)  rev=${OPTARG};;
-        l)  label="${OPTARG}";;
-        u)  uuid="${OPTARG}";;
-        :)  error "option '%s' expects a mandatory argument\n" "${OPTARG}";;
-        \?) error "unknown option '%s'\n" "${OPTARG}";;
-        esac
-    done
-
-    # Sanity checks
-    if [ -z "${root_dir}" ]; then
-        error "you must specify a root directory with '-d'\n"
-    fi
-    if [ -z "${image}" ]; then
-        error "you must specify an output image file with '-o'\n"
-    fi
-    case "${gen}:${rev}" in
-    2:0|2:1|3:1|4:1)
-        ;;
-    3:0|4:0)
-        error "revision 0 is invalid for ext3 and ext4\n"
-        ;;
-    *)  error "unknown ext generation '%s' and/or revision '%s'\n" \
-               "${gen}" "${rev}"
-        ;;
-    esac
-
-    # calculate needed inodes
-    if [ -z "${nb_inodes}" ]; then
-        nb_inodes=$(find "${root_dir}" | wc -l)
-        nb_inodes=$((nb_inodes+400))
-    fi
-    nb_inodes=$((nb_inodes+nb_extra_inodes))
-
-    # Upgrade to rev1 if needed
-    if [ ${rev} -ge 1 ]; then
-        tune2fs_O_opts+=",filetype,sparse_super"
-    fi
-
-    # Add a journal for ext3 and above
-    if [ ${gen} -ge 3 ]; then
-        tune2fs_opts+=( -j -J size=1 )
-    fi
-
-    # Add ext4 specific features
-    if [ ${gen} -ge 4 ]; then
-        tune2fs_O_opts+=",extents,uninit_bg,dir_index"
-    fi
-
-    # Add our -O options (there will be at most one leading comma, remove it)
-    if [ -n "${tune2fs_O_opts}" ]; then
-        tune2fs_opts+=( -O "${tune2fs_O_opts#,}" )
-    fi
-
-    # Add the label if specified
-    if [ -n "${label}" ]; then
-        tune2fs_opts+=( -L "${label}" )
-    fi
-
-    # Generate the filesystem
-    genext2fs_opts=( -z -b ${nb_blocks} -N ${nb_inodes} -d "${root_dir}" )
-    if [ -n "${nb_res_blocks}" ]; then
-        genext2fs_opts+=( -m ${nb_res_blocks} )
-    fi
-    genext2fs "${genext2fs_opts[@]}" "${image}"
-
-    # genext2fs does not generate a UUID, but fsck will whine if one
-    # is missing, so we need to add a UUID.
-    # Of course, this has to happen _before_ we run fsck.
-    # Also, some ext4 metadata are based on the UUID, so we must
-    # set it before we can convert the filesystem to ext4.
-    # If the user did not specify a UUID, we generate a random one.
-    # Although a random UUID may seem bad for reproducibility, there
-    # already are so many things that are not reproducible in a
-    # filesystem: file dates, file ordering, content of the files...
-    tune2fs -U "${uuid:-random}" "${image}"
-
-    # Upgrade the filesystem
-    if [ ${#tune2fs_opts[@]} -ne 0 ]; then
-        tune2fs "${tune2fs_opts[@]}" "${image}"
-    fi
-
-    # After changing filesystem options, running fsck is required
-    # (see: man tune2fs). Running e2fsck in other cases will ensure
-    # coherency of the filesystem, although it is not required.
-    # 'e2fsck -pDf' means:
-    #  - automatically repair
-    #  - optimise and check for duplicate entries
-    #  - force checking
-    # Sending output to oblivion, as e2fsck can be *very* verbose,
-    # especially with filesystems generated by genext2fs.
-    # Exit codes 1 & 2 are OK, it means fs errors were successfully
-    # corrected, hence our little trick with $ret.
-    ret=0
-    e2fsck -pDf "${image}" >/dev/null || ret=$?
-    case ${ret} in
-       0|1|2) ;;
-       *)   errorN ${ret} "failed to run e2fsck on '%s' (ext%d)\n" \
-                   "${image}" ${gen}
-    esac
-    printf "\n"
-    trace "e2fsck was successfully run on '%s' (ext%d)\n" "${image}" ${gen}
-    printf "\n"
-
-    # Remove count- and time-based checks, they are not welcome
-    # on embedded devices, where they can cause serious boot-time
-    # issues by tremendously slowing down the boot.
-    tune2fs -c 0 -i 0 "${image}"
-}
-
-help() {
-    cat <<_EOF_
-NAME
-    ${my_name} - Create an ext2/3/4 filesystem image
-
-SYNOPSIS
-    ${my_name} [OPTION]...
-
-DESCRIPTION
-    Create ext2/3/4 filesystem image from the content of a directory.
-
-    -b BLOCKS
-        Create a filesystem of BLOCKS 1024-byte blocs. The default is to
-        compute the required number of blocks.
-
-    -i INODES
-        Create a filesystem with INODES inodes. The default is to compute
-        the required number of inodes.
-
-    -r RES_BLOCKS
-        Create a filesystem with RES_BLOCKS reserved blocks. The default
-        is to reserve 0 block.
-
-    -d ROOT_DIR
-        Create a filesystem, using the content of ROOT_DIR as the content
-        of the root of the filesystem. Mandatory.
-
-    -o FILE
-        Create the filesystem in FILE. Madatory.
-
-    -G GEN -R REV
-        Create a filesystem of generation GEN (2, 3 or 4), and revision
-        REV (0 or 1). The default is to generate an ext2 revision 1
-        filesystem; revision 0 is invalid for ext3 and ext4.
-
-    -l LABEL
-        Create a filesystem with label LABEL. The default is to not set
-        a label.
-
-    -u UUID
-        Create filesystem with uuid UUID. The default is to set a random
-        UUID.
-
-  Exit status:
-    0   if OK
-    !0  in case of error
-_EOF_
-}
-
-trace()  { local msg="${1}"; shift; printf "%s: ${msg}" "${my_name}" "${@}"; }
-warn()   { trace "${@}" >&2; }
-errorN() { local ret="${1}"; shift; warn "${@}"; exit ${ret}; }
-error()  { errorN 1 "${@}"; }
-
-my_name="${0##*/}"
-main "$@"
diff --git a/package/mke2img/mke2img.mk b/package/mke2img/mke2img.mk
deleted file mode 100644
index 9de387a..0000000
--- a/package/mke2img/mke2img.mk
+++ /dev/null
@@ -1,13 +0,0 @@
-################################################################################
-#
-# mke2img
-#
-################################################################################
-
-HOST_MKE2IMG_DEPENDENCIES = host-genext2fs host-e2fsprogs
-
-define HOST_MKE2IMG_INSTALL_CMDS
-	$(INSTALL) -D -m 0755 package/mke2img/mke2img $(HOST_DIR)/usr/bin/mke2img
-endef
-
-$(eval $(host-generic-package))
-- 
2.7.3

^ permalink raw reply related

* [Buildroot] [PATCH 2/3] fs/ext2: Add BR2_TARGET_ROOTFS_EXT2_FEATURES option
From: Sébastien Szymanski @ 2017-05-04 15:26 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1493911563-2453-1-git-send-email-sebastien.szymanski@armadeus.com>

This option lets the user specify ext2/3/4 features.

Signed-off-by: S?bastien Szymanski <sebastien.szymanski@armadeus.com>
---
 fs/ext2/Config.in | 10 ++++++++++
 fs/ext2/ext2.mk   |  5 +++++
 2 files changed, 15 insertions(+)

diff --git a/fs/ext2/Config.in b/fs/ext2/Config.in
index 842000a..eaf9aee 100644
--- a/fs/ext2/Config.in
+++ b/fs/ext2/Config.in
@@ -57,6 +57,16 @@ config BR2_TARGET_ROOTFS_EXT2_RESBLKS
 	int "reserved blocks percentage"
 	default 0
 
+config BR2_TARGET_ROOTFS_EXT2_FEATURES
+	string "Filesystem features"
+	default "^64bit"
+	help
+	  Specify a comma-separated list of ext2/3/4 features.
+	  For more information about this option, see the mkefs' -O option in
+	  the manual page mke2fs(8).
+	  For more information about the features which can be set, see then
+	  manual page ext4(5).
+
 choice
 	prompt "Compression method"
 	default BR2_TARGET_ROOTFS_EXT2_NONE
diff --git a/fs/ext2/ext2.mk b/fs/ext2/ext2.mk
index 1da74d5..2d93258 100644
--- a/fs/ext2/ext2.mk
+++ b/fs/ext2/ext2.mk
@@ -12,6 +12,11 @@ endif
 EXT2_OPTS = -d $(TARGET_DIR)
 EXT2_OPTS += -r $(BR2_TARGET_ROOTFS_EXT2_REV)
 
+EXT2_FEATURES = $(call qstrip,$(BR2_TARGET_ROOTFS_EXT2_FEATURES))
+ifneq ($(EXT2_FEATURES),)
+EXT2_OPTS += -O "$(EXT2_FEATURES)"
+endif
+
 ifneq ($(strip $(BR2_TARGET_ROOTFS_EXT2_RESBLKS)),0)
 EXT2_OPTS += -m $(BR2_TARGET_ROOTFS_EXT2_RESBLKS)
 endif
-- 
2.7.3

^ permalink raw reply related

* [Buildroot] [PATCH 1/3] fs/ext2: use mkfs to generate rootfs image
From: Sébastien Szymanski @ 2017-05-04 15:26 UTC (permalink / raw)
  To: buildroot

mkfs is now capable of generating rootfs images. Use mkfs intead of
genext2fs. As we let mkfs calculate the block size and the number of
inodes needed we can drop BR2_TARGET_ROOTFS_EXT2_INODES and
BR2_TARGET_ROOTFS_EXT2_EXTRA_INODES and rename
BR2_TARGET_ROOTFS_EXT2_BLOCKS to BR2_TARGET_ROOTFS_EXT2_SIZE

Signed-off-by: S?bastien Szymanski <sebastien.szymanski@armadeus.com>
---

This patch is a rework of the previous series I sent. [1] [2] [3]
Now it directly modifies fs/ext2 instead of mke2img script which is dropped at the
end. It also takes into account the comments from Thomas and Arnout.

[1] http://patchwork.ozlabs.org/patch/743281/
[2] http://patchwork.ozlabs.org/patch/743278/
[3] http://patchwork.ozlabs.org/patch/743282/

 Config.in.legacy  | 34 ++++++++++++++++++++++++++++++++++
 fs/ext2/Config.in | 24 ++++++++----------------
 fs/ext2/ext2.mk   | 22 +++++++++++-----------
 3 files changed, 53 insertions(+), 27 deletions(-)

diff --git a/Config.in.legacy b/Config.in.legacy
index 98b9eeb..5fc37ec 100644
--- a/Config.in.legacy
+++ b/Config.in.legacy
@@ -145,6 +145,40 @@ endif
 ###############################################################################
 comment "Legacy options removed in 2017.05"
 
+config BR2_TARGET_ROOTFS_EXT2_INODES
+	int "exact number of inodes has been removed"
+	default 0
+	help
+	  Buildroot uses mkfs.ext2/3/4 to generate ext2/3/4 images. So let mkfs
+	  automatically selects the number of inodes needed. Set this option to
+	  0.
+
+config BR2_TARGET_ROOTFS_EXT2_INODES_WRAP
+	bool
+	default y if BR2_TARGET_ROOTFS_EXT2_INODES != 0
+	select BR2_LEGACY
+
+config BR2_TARGET_ROOTFS_EXT2_EXTRA_INODES
+	int "extra inodes has been removed" if BR2_TARGET_ROOTFS_EXT2_INODES = 0
+	default 0
+	help
+	  Buildroot uses mkfs.ext2/3/4 to generate ext2/3/4 images. So let mkfs
+	  automatically selects the number of inodes needed. Set this option to
+	  0.
+
+config BR2_TARGET_ROOTFS_EXT2_EXTRA_INODES_WRAP
+	bool
+	default y if BR2_TARGET_ROOTFS_EXT2_EXTRA_INODES != 0
+	select BR2_LEGACY
+
+config BR2_TARGET_ROOTFS_EXT2_BLOCKS
+	int "exact size in blocks has been removed"
+	default 0
+	help
+	  This option has been removed in favor of BR2_TARGET_ROOTFS_EXT2_SIZE.
+
+# Note: BR2_TARGET_ROOTFS_EXT2_BLOCKS still reference in fs/ext2/Config.in
+
 config BR2_PACKAGE_OPENOCD_FT2XXX
 	bool "openocd ft2232 support has been removed"
 	select BR2_PACKAGE_OPENOCD_FTDI
diff --git a/fs/ext2/Config.in b/fs/ext2/Config.in
index 19ed140..842000a 100644
--- a/fs/ext2/Config.in
+++ b/fs/ext2/Config.in
@@ -1,6 +1,6 @@
 config BR2_TARGET_ROOTFS_EXT2
 	bool "ext2/3/4 root filesystem"
-	select BR2_PACKAGE_HOST_MKE2IMG
+	select BR2_PACKAGE_HOST_E2FSPROGS
 	help
 	  Build an ext2/3/4 root filesystem
 
@@ -44,22 +44,14 @@ config BR2_TARGET_ROOTFS_EXT2_REV
 config BR2_TARGET_ROOTFS_EXT2_LABEL
 	string "filesystem label"
 
-# 61440 = 60MB, i.e usually small enough to fit on a 64MB media
-config BR2_TARGET_ROOTFS_EXT2_BLOCKS
-	int "exact size in blocks"
-	default 61440
-
-config BR2_TARGET_ROOTFS_EXT2_INODES
-	int "exact number of inodes (leave at 0 for auto calculation)"
-	default 0
-
-config BR2_TARGET_ROOTFS_EXT2_EXTRA_INODES
-	int "extra inodes" if BR2_TARGET_ROOTFS_EXT2_INODES = 0
-	default 0
+config BR2_TARGET_ROOTFS_EXT2_SIZE
+	string "exact size"
+	default BR2_TARGET_ROOTFS_EXT2_BLOCKS if BR2_TARGET_ROOTFS_EXT2_BLOCKS != 0 # legacy 2017.02
 	help
-	  Enter here the number of extra free inodes you want on
-	  your filesystem. By default, Buildroot will not leave
-	  many free inodes.
+	  The size of the filesystem image. If it does not have a suffix, it is
+	  interpreted as power-of-two kilobytes. If it is suffixed by 'k', 'm',
+	  'g', 't' (either upper-case or lower-case), then it is interpreted in
+	  power-of-two kilobytes, megabytes, gigabytes, terabytes, etc.
 
 config BR2_TARGET_ROOTFS_EXT2_RESBLKS
 	int "reserved blocks percentage"
diff --git a/fs/ext2/ext2.mk b/fs/ext2/ext2.mk
index 9d3e8fd..1da74d5 100644
--- a/fs/ext2/ext2.mk
+++ b/fs/ext2/ext2.mk
@@ -4,30 +4,30 @@
 #
 ################################################################################
 
-EXT2_OPTS = -G $(BR2_TARGET_ROOTFS_EXT2_GEN) -R $(BR2_TARGET_ROOTFS_EXT2_REV)
-
-EXT2_OPTS += -b $(BR2_TARGET_ROOTFS_EXT2_BLOCKS)
-
-ifneq ($(strip $(BR2_TARGET_ROOTFS_EXT2_INODES)),0)
-EXT2_OPTS += -i $(BR2_TARGET_ROOTFS_EXT2_INODES)
+EXT2_SIZE = $(call qstrip,$(BR2_TARGET_ROOTFS_EXT2_SIZE))
+ifeq ($(EXT2_SIZE),)
+$(error BR2_TARGET_ROOTFS_EXT2_SIZE cannot be empty)
 endif
-EXT2_OPTS += -I $(BR2_TARGET_ROOTFS_EXT2_EXTRA_INODES)
+
+EXT2_OPTS = -d $(TARGET_DIR)
+EXT2_OPTS += -r $(BR2_TARGET_ROOTFS_EXT2_REV)
 
 ifneq ($(strip $(BR2_TARGET_ROOTFS_EXT2_RESBLKS)),0)
-EXT2_OPTS += -r $(BR2_TARGET_ROOTFS_EXT2_RESBLKS)
+EXT2_OPTS += -m $(BR2_TARGET_ROOTFS_EXT2_RESBLKS)
 endif
 
 # qstrip results in stripping consecutive spaces into a single one. So the
 # variable is not qstrip-ed to preserve the integrity of the string value.
 EXT2_LABEL := $(subst ",,$(BR2_TARGET_ROOTFS_EXT2_LABEL))
 ifneq ($(EXT2_LABEL),)
-EXT2_OPTS += -l "$(EXT2_LABEL)"
+EXT2_OPTS += -L "$(EXT2_LABEL)"
 endif
 
-ROOTFS_EXT2_DEPENDENCIES = host-mke2img
+ROOTFS_EXT2_DEPENDENCIES = host-e2fsprogs
 
 define ROOTFS_EXT2_CMD
-	PATH=$(BR_PATH) mke2img -d $(TARGET_DIR) $(EXT2_OPTS) -o $@
+	rm -f $@
+	PATH=$(BR_PATH) mkfs.ext$(BR2_TARGET_ROOTFS_EXT2_GEN) $(EXT2_OPTS) $@ $(EXT2_SIZE)
 endef
 
 rootfs-ext2-symlink:
-- 
2.7.3

^ permalink raw reply related

* [Buildroot] [PATCH 1/9] ext2: add help text for BR2_TARGET_ROOTFS_EXT2_BLOCKS
From: Thomas Petazzoni @ 2017-05-04 15:15 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <78e1595a645865a4e5862b84abf8a66173f2ccf6.1493654310.git.yann.morin.1998@free.fr>

Hello,

On Mon,  1 May 2017 17:58:36 +0200, Yann E. MORIN wrote:
> From: J Evans <g4@novadsp.com>
> 
> Signed-off-by: J Evans <g4@novadsp.com>
> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
> ---
>  fs/ext2/Config.in | 2 ++
>  1 file changed, 2 insertions(+)

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply

* [Buildroot] [git commit] ext2: add help text for BR2_TARGET_ROOTFS_EXT2_BLOCKS
From: Thomas Petazzoni @ 2017-05-04 15:15 UTC (permalink / raw)
  To: buildroot

commit: https://git.buildroot.net/buildroot/commit/?id=426fd787fa4f76d293e3b2e4f405c9a9b7d42666
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master

Signed-off-by: J Evans <g4@novadsp.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 fs/ext2/Config.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/ext2/Config.in b/fs/ext2/Config.in
index 19ed140..a1e3647 100644
--- a/fs/ext2/Config.in
+++ b/fs/ext2/Config.in
@@ -48,6 +48,8 @@ config BR2_TARGET_ROOTFS_EXT2_LABEL
 config BR2_TARGET_ROOTFS_EXT2_BLOCKS
 	int "exact size in blocks"
 	default 61440
+	help
+	  Specify the file system size as a number of 1024-byte blocks.
 
 config BR2_TARGET_ROOTFS_EXT2_INODES
 	int "exact number of inodes (leave at 0 for auto calculation)"

^ permalink raw reply related

* [Buildroot] [PATCH 1/1] libqmi: musl compat canonicalize_file_name
From: Thomas Petazzoni @ 2017-05-04 15:13 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1493688546-37339-1-git-send-email-matthew.weber@rockwellcollins.com>

Hello,

On Mon,  1 May 2017 20:29:06 -0500, Matt Weber wrote:
> Adds an inline equivalent of canonicalize_file_name
> using realpath().
> 
> Bug report (origin of this patch):
> https://bugs.freedesktop.org/show_bug.cgi?id=99944
> 
> Resolves:
> http://autobuild.buildroot.net/results/afa/afa4b97e012586585b11be1e70ed3c63a7c48a4d/
> 
>   CCLD     test-generated
>   CCLD     test-utils
>   CCLD     test-message
> ../../../src/libqmi-glib/.libs/libqmi-glib.so: undefined reference to `canonicalize_file_name'
> collect2: error: ld returned 1 exit status
> Makefile:440: recipe for target 'test-generated' failed
> 
> Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
> ---
>  .../0001-musl-compat-canonicalize_file_name.patch  | 48 ++++++++++++++++++++++
>  1 file changed, 48 insertions(+)
>  create mode 100644 package/libqmi/0001-musl-compat-canonicalize_file_name.patch

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply

* [Buildroot] [git commit] libqmi: musl compat canonicalize_file_name
From: Thomas Petazzoni @ 2017-05-04 15:13 UTC (permalink / raw)
  To: buildroot

commit: https://git.buildroot.net/buildroot/commit/?id=c78b65c4f161ec101ff02880788ef22eb7c87d76
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master

Adds an inline equivalent of canonicalize_file_name
using realpath().

Bug report (origin of this patch):
https://bugs.freedesktop.org/show_bug.cgi?id=99944

Resolves:
http://autobuild.buildroot.net/results/afa/afa4b97e012586585b11be1e70ed3c63a7c48a4d/

  CCLD     test-generated
  CCLD     test-utils
  CCLD     test-message
../../../src/libqmi-glib/.libs/libqmi-glib.so: undefined reference to `canonicalize_file_name'
collect2: error: ld returned 1 exit status
Makefile:440: recipe for target 'test-generated' failed

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 .../0001-musl-compat-canonicalize_file_name.patch  | 48 ++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/package/libqmi/0001-musl-compat-canonicalize_file_name.patch b/package/libqmi/0001-musl-compat-canonicalize_file_name.patch
new file mode 100644
index 0000000..5656d55
--- /dev/null
+++ b/package/libqmi/0001-musl-compat-canonicalize_file_name.patch
@@ -0,0 +1,48 @@
+From 2f44edc9fbcbf2202174aec723e8a8d191c13d2f Mon Sep 17 00:00:00 2001
+From: Matt Weber <matthew.weber@rockwellcollins.com>
+Date: Mon, 1 May 2017 19:55:07 -0500
+Subject: [PATCH] musl compat canonicalize_file_name()
+
+Adds an inline equivalent of canonicalize_file_name
+using realpath().
+
+Bug report (origin of this patch):
+https://bugs.freedesktop.org/show_bug.cgi?id=99944
+
+Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
+---
+ src/libqmi-glib/qmi-utils.h | 18 ++++++++++++++++++
+ 1 file changed, 18 insertions(+)
+
+diff --git a/src/libqmi-glib/qmi-utils.h b/src/libqmi-glib/qmi-utils.h
+index 4fd5199..4869da5 100644
+--- a/src/libqmi-glib/qmi-utils.h
++++ b/src/libqmi-glib/qmi-utils.h
+@@ -29,6 +29,24 @@
+ #error "Only <libqmi-glib.h> can be included directly."
+ #endif
+ 
++#ifndef HAVE_CANONICALIZE_FILE_NAME
++#include <limits.h>
++#include <string.h>
++#include <stdlib.h>
++#include <stdio.h>
++static char * canonicalize_file_name(const char *path)
++{
++       char buf[PATH_MAX] = { };
++
++       snprintf(buf, sizeof(buf) - 1, "%s", path);
++
++       if (!realpath(path, buf))
++               return NULL;
++
++       return strdup(buf);
++}
++#endif
++
+ #include <glib.h>
+ 
+ G_BEGIN_DECLS
+-- 
+1.9.1
+

^ permalink raw reply related

* [Buildroot] [PATCH 1/1] uboot-tools: disable libfdt swig wrapper
From: Thomas Petazzoni @ 2017-05-04 15:12 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1493697677-24802-1-git-send-email-matthew.weber@rockwellcollins.com>

Hello,

On Mon,  1 May 2017 23:01:17 -0500, Matt Weber wrote:
> The current tools build assumes the host system
> when trying to detect if swig/python are present.
> It then uses those tools from the path.
> 
> The upstream RFC included this commit set's patch
> but offered up discussion on how to cleanly
> introduce a better method for detecting swig and
> using the tools.  The tools build really needs to
> be sysroot and prefix/host dir tools aware.
> 
> Upsteam submission for RFC:
> https://lists.denx.de/pipermail/u-boot/2017-May/289520.html
> 
> Workaround for:
> http://autobuild.buildroot.net/results/6d5/6d52ac8bb71012aea6fc4c679691b31a3366728b
> 
> Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
> ---
>  ...nditionally-disable-python-libfdt-wrapper.patch | 44 ++++++++++++++++++++++
>  package/uboot-tools/uboot-tools.mk                 |  5 +++
>  2 files changed, 49 insertions(+)
>  create mode 100644 package/uboot-tools/0005-tools-conditionally-disable-python-libfdt-wrapper.patch

As I said, I'm not entirely happy with this solution, but it does the
job for now, and nobody has provided a different patch.

So: applied, thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply

* [Buildroot] [git commit] uboot-tools: disable libfdt swig wrapper
From: Thomas Petazzoni @ 2017-05-04 15:11 UTC (permalink / raw)
  To: buildroot

commit: https://git.buildroot.net/buildroot/commit/?id=f4891c398e599f18bbf41eb33885930431f5e1c8
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master

The current tools build assumes the host system when trying to detect if
swig/python are present.  It then uses those tools from the path.

The upstream RFC included this commit set's patch but offered up
discussion on how to cleanly introduce a better method for detecting
swig and using the tools.  The tools build really needs to be sysroot
and prefix/host dir tools aware.

Upsteam submission for RFC:
https://lists.denx.de/pipermail/u-boot/2017-May/289520.html

Workaround for:
http://autobuild.buildroot.net/results/6d52ac8bb71012aea6fc4c679691b31a3366728b

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 ...nditionally-disable-python-libfdt-wrapper.patch | 44 ++++++++++++++++++++++
 package/uboot-tools/uboot-tools.mk                 |  5 +++
 2 files changed, 49 insertions(+)

diff --git a/package/uboot-tools/0005-tools-conditionally-disable-python-libfdt-wrapper.patch b/package/uboot-tools/0005-tools-conditionally-disable-python-libfdt-wrapper.patch
new file mode 100644
index 0000000..e48f72b
--- /dev/null
+++ b/package/uboot-tools/0005-tools-conditionally-disable-python-libfdt-wrapper.patch
@@ -0,0 +1,44 @@
+From 4dc3139cc9fa12882792053bdce7b69aca9b91bf Mon Sep 17 00:00:00 2001
+From: Matt Weber <matthew.weber@rockwellcollins.com>
+Date: Mon, 1 May 2017 22:19:57 -0500
+Subject: [PATCH] tools: conditionally disable python libfdt wrapper
+
+Not all host systems want the default swig to be
+used when building the tools.  Allow for the
+disabling of the wrapper to enable cross-compiling
+of the tools on a host system with swig.
+
+Upsteam submission for RFC:
+https://lists.denx.de/pipermail/u-boot/2017-May/289520.html
+
+Workaround for:
+http://autobuild.buildroot.net/results/6d5/6d52ac8bb71012aea6fc4c679691b31a3366728b
+
+Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
+---
+ tools/Makefile | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/tools/Makefile b/tools/Makefile
+index 2fc4a58..7f6c29d 100644
+--- a/tools/Makefile
++++ b/tools/Makefile
+@@ -114,6 +114,7 @@ fit_check_sign-objs   := $(dumpimage-mkimage-objs) fit_check_sign.o
+ 
+ # Build a libfdt Python module if swig is available
+ # Use 'sudo apt-get install swig libpython-dev' to enable this
++ifndef CONFIG_TOOLS_PYTHON_WRAPPER_DISABLE
+ hostprogs-y += \
+ 	$(if $(shell which swig 2> /dev/null),_libfdt.so)
+ _libfdt.so-sharedobjs += $(LIBFDT_OBJS)
+@@ -126,6 +127,7 @@ tools/_libfdt.so: $(patsubst %.o,%.c,$(LIBFDT_OBJS)) tools/libfdt_wrap.c
+ 
+ tools/libfdt_wrap.c: $(srctree)/lib/libfdt/libfdt.swig
+ 	swig -python -o $@ $<
++endif
+ 
+ # TODO(sjg@chromium.org): Is this correct on Mac OS?
+ 
+-- 
+1.9.1
+
diff --git a/package/uboot-tools/uboot-tools.mk b/package/uboot-tools/uboot-tools.mk
index 2585c7b..352f53d 100644
--- a/package/uboot-tools/uboot-tools.mk
+++ b/package/uboot-tools/uboot-tools.mk
@@ -21,6 +21,11 @@ UBOOT_TOOLS_MAKE_OPTS = CROSS_COMPILE="$(TARGET_CROSS)" \
 	LDFLAGS="$(TARGET_LDFLAGS)" \
 	STRIP=$(TARGET_STRIP)
 
+# This option was added through an additional patch
+# and allows the disabling of a host python swig
+# detect which as of 2017.5 assumes the host systems swig.
+UBOOT_TOOLS_MAKE_OPTS += CONFIG_TOOLS_PYTHON_WRAPPER_DISABLE=y
+
 ifeq ($(BR2_PACKAGE_UBOOT_TOOLS_FIT_SUPPORT),y)
 UBOOT_TOOLS_MAKE_OPTS += CONFIG_FIT=y
 UBOOT_TOOLS_DEPENDENCIES += dtc

^ permalink raw reply related

* [Buildroot] [PATCH] tinyxml2: fix build in static libs configuration
From: Thomas Petazzoni @ 2017-05-04 15:09 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1493838254-3658-1-git-send-email-rahulbedarkar89@gmail.com>

Hello,

Adding Samuel Martin here, for CMake related discussion below.

On Thu,  4 May 2017 00:34:14 +0530, Rahul Bedarkar wrote:
> tinyxml2 can build both static and shared libraries. By default, only
> shared library is built. Shared/static builds are controlled using
> separate cmake flags BUILD_SHARED_LIBS and BUILD_STATIC_LIBS.
> 
> In static libs configuration, we internally pass -DBUILD_SHARED_LIBS=OFF
> cmake flag to build system which disables both shared and static builds
> of library, resulting in failures while linking executable with library.
> 
> So pass -DBUILD_STATIC_LIBS=ON cmake flag in case of static libs
> configuration.
> 
> fixes:
>   http://autobuild.buildroot.net/results/d30/d301bcbe5db26068b35eaa94bd816ae8cf8ef2e1
> 
> Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com>
> ---
>  package/tinyxml2/tinyxml2.mk | 4 ++++
>  1 file changed, 4 insertions(+)

Applied to master, thanks.

I think we need to refactor things more globally here though. Why is
pkg-cmake.mk passing BUILD_SHARED_LIBS and not BUILD_STATIC_LIBS ? Why
are some packages passing BUILD_SHARED_LIBS even if it's already passed
by pkg-cmake.mk ?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply

* [Buildroot] [git commit] tinyxml2: fix build in static libs configuration
From: Thomas Petazzoni @ 2017-05-04 15:08 UTC (permalink / raw)
  To: buildroot

commit: https://git.buildroot.net/buildroot/commit/?id=a598a7109c3b518898f38b433f865801d1c1163f
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master

tinyxml2 can build both static and shared libraries. By default, only
shared library is built. Shared/static builds are controlled using
separate cmake flags BUILD_SHARED_LIBS and BUILD_STATIC_LIBS.

In static libs configuration, we internally pass -DBUILD_SHARED_LIBS=OFF
cmake flag to build system which disables both shared and static builds
of library, resulting in failures while linking executable with library.

So pass -DBUILD_STATIC_LIBS=ON cmake flag in case of static libs
configuration.

fixes:
  http://autobuild.buildroot.net/results/d30/d301bcbe5db26068b35eaa94bd816ae8cf8ef2e1

Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/tinyxml2/tinyxml2.mk | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/package/tinyxml2/tinyxml2.mk b/package/tinyxml2/tinyxml2.mk
index bb1e167..e289ca9 100644
--- a/package/tinyxml2/tinyxml2.mk
+++ b/package/tinyxml2/tinyxml2.mk
@@ -10,4 +10,8 @@ TINYXML2_LICENSE = Zlib
 TINYXML2_LICENSE_FILES = readme.md
 TINYXML2_INSTALL_STAGING = YES
 
+ifeq ($(BR2_STATIC_LIBS),y)
+TINYXML2_CONF_OPTS += -DBUILD_STATIC_LIBS=ON
+endif
+
 $(eval $(cmake-package))

^ permalink raw reply related

* [Buildroot] [PATCH] toolchains/configs: make external toolchain explicit
From: Thomas Petazzoni @ 2017-05-04 15:05 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170504070745.13349-1-arnout@mind.be>

Hello,

On Thu, 4 May 2017 09:07:45 +0200, Arnout Vandecappelle
(Essensium/Mind) wrote:
> Some of the toolchain configs rely on the default to select which
> external toolchain to use. However, this is wrong for two reasons:
> - when the defaults change in Buildroot, the toolchain config will
>   change under the hood;
> - when the autobuild-run script adds some options (in particular,
>   BR2_STATIC_LIBS), it is possible that the default changes (or is
>   no longer available).
> 
> Both can be fixed by explicitly adding the external toolchain option
> we want to the config file. Indeed, the autobuild-run script will
> then detect that there is a difference between the generated config
> and the base one, and will discard it.
> 
> Fixes:
> http://autobuild.buildroot.net/results/39888c188c0d13219a8419897a833275fcc81597
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
> ---
> I didn't really test this change, I just manually ran a config which
> each of them and checked if it was OK.
> ---
>  web/toolchains/configs/linaro-aarch64.config      | 1 +
>  web/toolchains/configs/linaro-arm.config          | 1 +
>  web/toolchains/configs/sourcery-arm-thumb2.config | 1 +
>  web/toolchains/configs/sourcery-nios2.config      | 1 +
>  4 files changed, 4 insertions(+)

Applied to buildroot-test and deployed. Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply

* [Buildroot] [autobuild.buildroot.net] Your build results for 2017-05-02
From: Thomas Petazzoni @ 2017-05-04 15:04 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170504093049.27618dbf@free-electrons.com>

Hello,

On Thu, 4 May 2017 09:30:49 +0200, Thomas Petazzoni wrote:

> Those ones are due to me having forgotten to rebuild the Microblaze
> toolchain. I've just started the build, I will deploy once the build is
> finished.

Build finished, toolchain deployed and used by the autobuilders.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* [Buildroot] [PATCH v2] package: protobuf, python-protobuf: bump to v3.3.0
From: Mario Rugiero @ 2017-05-04 13:34 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170504145610.39ba9d06@free-electrons.com>

2017-05-04 9:56 GMT-03:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Hello,
>
> On Wed,  3 May 2017 17:59:45 -0300, Mario J. Rugiero wrote:
>> Includes upstream patch working around a gcc bug which got fixed in version 4.5.0.
>>
>> Fixes:
>> http://autobuild.buildroot.org/results/77d/77dbb6bbbc0ea9e9bcdd22b10011ef9728c20d54/
>> http://autobuild.buildroot.org/results/21f/21f5e1ea4f37e1d174604d6da78c0e916c89f1e3/
>> http://autobuild.buildroot.org/results/24e/24e880086c87d40b5d79a90d805acc75b33d484c/
>>
>> Tested with:
>> qemu_aarch64_virt_defconfig
>>
>> Signed-off-by: Mario J. Rugiero <mrugiero@gmail.com>
>
> I've applied this patch, and then tried building with a gcc 4.3
> toolchain, and still get:
>
> libtool: compile:  /home/thomas/projets/buildroot/output/host/usr/bin/arm-none-linux-gnueabi-g++ -DHAVE_CONFIG_H -I. -I.. -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pthread -DHAVE_PTHREAD=1 -Wall -Wno-sign-compare -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -c google/protobuf/util/type_resolver_util.cc  -fPIC -DPIC -o google/protobuf/util/.libs/type_resolver_util.o
> In file included from ./google/protobuf/metadata.h:41,
>                  from ./google/protobuf/type.pb.h:27,
>                  from google/protobuf/util/type_resolver_util.cc:33:
> ./google/protobuf/metadata_lite.h: In constructor 'google::protobuf::internal::InternalMetadataWithArenaLite::InternalMetadataWithArenaLite(google::protobuf::Arena*)':
> ./google/protobuf/metadata_lite.h:170: error: class 'google::protobuf::internal::InternalMetadataWithArenaLite' does not have any field named 'InternalMetadataWithArenaBase'
> In file included from ./google/protobuf/metadata.h:41,
>                  from ./google/protobuf/compiler/plugin.pb.h:27,
>                  from google/protobuf/compiler/code_generator.cc:37:
> ./google/protobuf/metadata_lite.h: In constructor 'google::protobuf::internal::InternalMetadataWithArenaLite::InternalMetadataWithArenaLite(google::protobuf::Arena*)':
> ./google/protobuf/metadata_lite.h:170: error: class 'google::protobuf::internal::InternalMetadataWithArenaLite' does not have any field named 'InternalMetadataWithArenaBase'
> In file included from ./google/protobuf/metadata.h:41,
>                  from ./google/protobuf/duration.pb.h:27,
>                  from ./google/protobuf/util/time_util.h:45,
>                  from google/protobuf/util/time_util.cc:31:
> ./google/protobuf/metadata_lite.h: In constructor 'google::protobuf::internal::InternalMetadataWithArenaLite::InternalMetadataWithArenaLite(google::protobuf::Arena*)':
> ./google/protobuf/metadata_lite.h:170: error: class 'google::protobuf::internal::InternalMetadataWithArenaLite' does not have any field named 'InternalMetadataWithArenaBase'
> In file included from ./google/protobuf/metadata.h:41,
>                  from ./google/protobuf/type.pb.h:27,
>                  from ./google/protobuf/util/internal/type_info.h:35,
>                  from ./google/protobuf/util/internal/default_value_objectwriter.h:43,
>                  from google/protobuf/util/json_util.cc:36:
> ./google/protobuf/metadata_lite.h: In constructor 'google::protobuf::internal::InternalMetadataWithArenaLite::InternalMetadataWithArenaLite(google::protobuf::Arena*)':
> ./google/protobuf/metadata_lite.h:170: error: class 'google::protobuf::internal::InternalMetadataWithArenaLite' does not have any field named 'InternalMetadataWithArenaBase'
> Makefile:4068: recipe for target 'google/protobuf/util/time_util.lo' failed
> make[5]: *** [google/protobuf/util/time_util.lo] Error 1
> make[5]: *** Waiting for unfinished jobs....
> Makefile:4068: recipe for target 'google/protobuf/util/type_resolver_util.lo' failed
> make[5]: *** [google/protobuf/util/type_resolver_util.lo] Error 1
> Makefile:4068: recipe for target 'google/protobuf/util/json_util.lo' failed
> make[5]: *** [google/protobuf/util/json_util.lo] Error 1
> Makefile:4068: recipe for target 'google/protobuf/compiler/code_generator.lo' failed
> make[5]: *** [google/protobuf/compiler/code_generator.lo] Error 1
> Makefile:2076: recipe for target 'all' failed
> make[4]: *** [all] Error 2
> Makefile:1396: recipe for target 'all-recursive' failed
> make[3]: *** [all-recursive] Error 1
> Makefile:1302: recipe for target 'all' failed
> make[2]: *** [all] Error 2
> package/pkg-generic.mk:227: recipe for target '/home/thomas/projets/buildroot/output/build/protobuf-3.3.0/.stamp_built' failed
> make[1]: *** [/home/thomas/projets/buildroot/output/build/protobuf-3.3.0/.stamp_built] Error 2
> Makefile:79: recipe for target '_all' failed
> make: *** [_all] Error 2
>
> You can reproduce this by using the following configuration:
>
> BR2_arm=y
> BR2_TOOLCHAIN_EXTERNAL=y
> BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
> BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
> BR2_TOOLCHAIN_EXTERNAL_URL="http://sources.buildroot.net/arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2"
> BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX="arm-none-linux-gnueabi"
> BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y
> BR2_TOOLCHAIN_EXTERNAL_CXX=y
> BR2_INIT_NONE=y
> # BR2_PACKAGE_BUSYBOX is not set
> BR2_PACKAGE_PROTOBUF=y
> # BR2_TARGET_ROOTFS_TAR is not set
>
> Best regards,
>
> Thomas Petazzoni
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
Thanks, I'll look into it.

^ permalink raw reply

* [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-03
From: Matthew Weber @ 2017-05-04 13:29 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170504152451.14c7153d@free-electrons.com>

Thomas

On Thu, May 4, 2017 at 8:24 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
> Hello,
>
> On Thu, 4 May 2017 08:10:05 -0500, Matthew Weber wrote:
>
> > >            uboot-tools-2017.03 | 6
> >
> > Worked around with this patchset
> > https://patchwork.ozlabs.org/patch/757382/
>
> Seen it, but I'm not sure this solution will be accepted upstream. That
> being said, it's quite simple and straightforward, so maybe we should
> take it, until upstream does something to resolve the issue.


Agree, I don't really like it but the uboot tools folder needs some
work to make things flexible.  I need to follow up on my email and see
where it goes.



-- 
Matthew L Weber / Pr Software Engineer
Airborne Information Systems / Security Systems and Software / Secure Platforms
MS 131-100, C Ave NE, Cedar Rapids, IA, 52498, USA
www.rockwellcollins.com

Note: Any Export License Required Information and License Restricted
Third Party Intellectual Property (TPIP) content must be encrypted and
sent to matthew.weber at corp.rockwellcollins.com.

^ permalink raw reply

* [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-03
From: Thomas Petazzoni @ 2017-05-04 13:24 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <CANQCQpZXApJkf7WPJjzVEXSyodyWZF5DJ2_OzfiYpe-jG6ruxg@mail.gmail.com>

Hello,

On Thu, 4 May 2017 08:10:05 -0500, Matthew Weber wrote:

> >            uboot-tools-2017.03 | 6  
> 
> Worked around with this patchset
> https://patchwork.ozlabs.org/patch/757382/

Seen it, but I'm not sure this solution will be accepted upstream. That
being said, it's quite simple and straightforward, so maybe we should
take it, until upstream does something to resolve the issue.

> >                     mpir-3.0.0 | 5
> >                acpica-20170303 | 4
> >                  libqmi-1.18.0 | 4  
> 
> Resolved by this patchset
> https://patchwork.ozlabs.org/patch/757363/

ACK.

Thanks for following up on those issues, very useful!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* [Buildroot] [autobuild.buildroot.net] Build results for 2017-05-03
From: Matthew Weber @ 2017-05-04 13:10 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170504062805.21F8320C54@mail.free-electrons.com>

Thomas,

On Thu, May 4, 2017 at 1:28 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> Build statistics for 2017-05-03
> ================================
>
>       successes : 202
>        failures : 86
>        timeouts : 0
>           TOTAL : 288
>
> Classification of failures by reason
> ====================================
>
>            host-protobuf-3.2.0 | 27
>            uboot-tools-2017.03 | 6

Worked around with this patchset
https://patchwork.ozlabs.org/patch/757382/

>                     mpir-3.0.0 | 5
>                acpica-20170303 | 4
>                  libqmi-1.18.0 | 4

Resolved by this patchset
https://patchwork.ozlabs.org/patch/757363/

<snip>

- Matt

^ permalink raw reply

* [Buildroot] [autobuild.buildroot.net] Your build results for 2017-05-01
From: Fabio Estevam @ 2017-05-04 13:03 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170504145816.351b3345@free-electrons.com>

On Thu, May 4, 2017 at 9:58 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:

> No, this has absolutely nothing to do with atest. Lots of other
> packages fail to build with the same reason. There is an issue between
> binutils 2.27 and elf2flt.
>
> I think we instead need to disable binutils 2.27 on !mmu, and use
> binutils 2.28.

Thanks for the clarification!

^ permalink raw reply

* [Buildroot] [autobuild.buildroot.net] Your build results for 2017-05-01
From: Thomas Petazzoni @ 2017-05-04 12:58 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <CAOMZO5CG_H47Xcpo=eTF+K7Rm0YMd9XTjfvzwktrYrsCKULWgA@mail.gmail.com>

Hello,

On Thu, 4 May 2017 09:11:09 -0300, Fabio Estevam wrote:
> On Tue, May 2, 2017 at 3:28 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > Hello,
> >
> > This is the list of Buildroot build failures that occured on
> > 2017-05-01, and for which you are a registered architecture developer
> > or package developer. Please help us improving the quality of
> > Buildroot by investigating those build failures and sending patches to
> > fix them. Thanks!
> >
> > Build failures related to your packages:
> >
> >          arm | atest-895b0183a89c15f5e2305... | http://autobuild.buildroot.net/results/24081a28132899e9853dcb33a345db55c7c9d04a  
> 
> What about adding a "depends on BR2_USE_MMU" to  package/atest/Config.in?
> 
> Would this be the correct fix for this issue?

No, this has absolutely nothing to do with atest. Lots of other
packages fail to build with the same reason. There is an issue between
binutils 2.27 and elf2flt.

I think we instead need to disable binutils 2.27 on !mmu, and use
binutils 2.28.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* [Buildroot] [PATCH v2] package: protobuf, python-protobuf: bump to v3.3.0
From: Thomas Petazzoni @ 2017-05-04 12:56 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170503205945.7065-1-mrugiero@gmail.com>

Hello,

On Wed,  3 May 2017 17:59:45 -0300, Mario J. Rugiero wrote:
> Includes upstream patch working around a gcc bug which got fixed in version 4.5.0.
> 
> Fixes:
> http://autobuild.buildroot.org/results/77d/77dbb6bbbc0ea9e9bcdd22b10011ef9728c20d54/
> http://autobuild.buildroot.org/results/21f/21f5e1ea4f37e1d174604d6da78c0e916c89f1e3/
> http://autobuild.buildroot.org/results/24e/24e880086c87d40b5d79a90d805acc75b33d484c/
> 
> Tested with:
> qemu_aarch64_virt_defconfig
> 
> Signed-off-by: Mario J. Rugiero <mrugiero@gmail.com>

I've applied this patch, and then tried building with a gcc 4.3
toolchain, and still get:

libtool: compile:  /home/thomas/projets/buildroot/output/host/usr/bin/arm-none-linux-gnueabi-g++ -DHAVE_CONFIG_H -I. -I.. -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pthread -DHAVE_PTHREAD=1 -Wall -Wno-sign-compare -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -c google/protobuf/util/type_resolver_util.cc  -fPIC -DPIC -o google/protobuf/util/.libs/type_resolver_util.o
In file included from ./google/protobuf/metadata.h:41,
                 from ./google/protobuf/type.pb.h:27,
                 from google/protobuf/util/type_resolver_util.cc:33:
./google/protobuf/metadata_lite.h: In constructor 'google::protobuf::internal::InternalMetadataWithArenaLite::InternalMetadataWithArenaLite(google::protobuf::Arena*)':
./google/protobuf/metadata_lite.h:170: error: class 'google::protobuf::internal::InternalMetadataWithArenaLite' does not have any field named 'InternalMetadataWithArenaBase'
In file included from ./google/protobuf/metadata.h:41,
                 from ./google/protobuf/compiler/plugin.pb.h:27,
                 from google/protobuf/compiler/code_generator.cc:37:
./google/protobuf/metadata_lite.h: In constructor 'google::protobuf::internal::InternalMetadataWithArenaLite::InternalMetadataWithArenaLite(google::protobuf::Arena*)':
./google/protobuf/metadata_lite.h:170: error: class 'google::protobuf::internal::InternalMetadataWithArenaLite' does not have any field named 'InternalMetadataWithArenaBase'
In file included from ./google/protobuf/metadata.h:41,
                 from ./google/protobuf/duration.pb.h:27,
                 from ./google/protobuf/util/time_util.h:45,
                 from google/protobuf/util/time_util.cc:31:
./google/protobuf/metadata_lite.h: In constructor 'google::protobuf::internal::InternalMetadataWithArenaLite::InternalMetadataWithArenaLite(google::protobuf::Arena*)':
./google/protobuf/metadata_lite.h:170: error: class 'google::protobuf::internal::InternalMetadataWithArenaLite' does not have any field named 'InternalMetadataWithArenaBase'
In file included from ./google/protobuf/metadata.h:41,
                 from ./google/protobuf/type.pb.h:27,
                 from ./google/protobuf/util/internal/type_info.h:35,
                 from ./google/protobuf/util/internal/default_value_objectwriter.h:43,
                 from google/protobuf/util/json_util.cc:36:
./google/protobuf/metadata_lite.h: In constructor 'google::protobuf::internal::InternalMetadataWithArenaLite::InternalMetadataWithArenaLite(google::protobuf::Arena*)':
./google/protobuf/metadata_lite.h:170: error: class 'google::protobuf::internal::InternalMetadataWithArenaLite' does not have any field named 'InternalMetadataWithArenaBase'
Makefile:4068: recipe for target 'google/protobuf/util/time_util.lo' failed
make[5]: *** [google/protobuf/util/time_util.lo] Error 1
make[5]: *** Waiting for unfinished jobs....
Makefile:4068: recipe for target 'google/protobuf/util/type_resolver_util.lo' failed
make[5]: *** [google/protobuf/util/type_resolver_util.lo] Error 1
Makefile:4068: recipe for target 'google/protobuf/util/json_util.lo' failed
make[5]: *** [google/protobuf/util/json_util.lo] Error 1
Makefile:4068: recipe for target 'google/protobuf/compiler/code_generator.lo' failed
make[5]: *** [google/protobuf/compiler/code_generator.lo] Error 1
Makefile:2076: recipe for target 'all' failed
make[4]: *** [all] Error 2
Makefile:1396: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
Makefile:1302: recipe for target 'all' failed
make[2]: *** [all] Error 2
package/pkg-generic.mk:227: recipe for target '/home/thomas/projets/buildroot/output/build/protobuf-3.3.0/.stamp_built' failed
make[1]: *** [/home/thomas/projets/buildroot/output/build/protobuf-3.3.0/.stamp_built] Error 2
Makefile:79: recipe for target '_all' failed
make: *** [_all] Error 2

You can reproduce this by using the following configuration:

BR2_arm=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="http://sources.buildroot.net/arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX="arm-none-linux-gnueabi"
BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_INIT_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_PROTOBUF=y
# BR2_TARGET_ROOTFS_TAR is not set

Best regards,

Thomas Petazzoni
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* [Buildroot] [PATCH] imx6q-sabresd: Add a qt5 defconfig variant
From: Fabio Estevam @ 2017-05-04 12:36 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1492870186-31678-1-git-send-email-festevam@gmail.com>

On Sat, Apr 22, 2017 at 11:09 AM, Fabio Estevam <festevam@gmail.com> wrote:
> Introduce imx6q-sabresd_qt5_defconfig that supports the opensource
> Etnaviv graphical stack.
>
> This defconfig provides a way to quickly test some graphical applications,
> such as kmscube, qt5, glmark2.
>
> Currently kernel mainline exhibits issues when running cpufreq as ondemand
> governor on mx6, so add a linux fragment that disables such option for the
> time being.
>
> Signed-off-by: Fabio Estevam <festevam@gmail.com>

Would it be possible to have this defconfig as part of the next
Buildroot release?

It would be very convenient for testing mx6 with kernel
mainline/Mesa/Etnaviv/Qt5.

Thanks

^ permalink raw reply

* [Buildroot] [autobuild.buildroot.net] Your build results for 2017-05-01
From: Fabio Estevam @ 2017-05-04 12:11 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170502062817.7C03E207D4@mail.free-electrons.com>

On Tue, May 2, 2017 at 3:28 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> This is the list of Buildroot build failures that occured on
> 2017-05-01, and for which you are a registered architecture developer
> or package developer. Please help us improving the quality of
> Buildroot by investigating those build failures and sending patches to
> fix them. Thanks!
>
> Build failures related to your packages:
>
>          arm | atest-895b0183a89c15f5e2305... | http://autobuild.buildroot.net/results/24081a28132899e9853dcb33a345db55c7c9d04a

What about adding a "depends on BR2_USE_MMU" to  package/atest/Config.in?

Would this be the correct fix for this issue?

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox