Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [PATCH v10 2/2] Add defconfig for MIPS Creator ci40
From: Abhimanyu Vishwakarma @ 2017-04-24  5:26 UTC (permalink / raw)
  To: buildroot

From: Abhimanyu Vishwakarma <Abhimanyu.V@gmail.com>

Signed-off-by: Abhimanyu Vishwakarma <Abhimanyu.V@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Rahul Bedarkar <rahulbedarkar89@gmail.com>

---
 Changes v1->v2
  - No change
 Changes v2->v3 (Suggested by Arnout)
  - Remove uImage and add fitImage generation
  - Tidy readme.txt
  - Tidy ci40_defconfig, remove custom toolchain and add wifi helper packages
  Some changes are not done:
  - Using git-helper:
    - Custom kernel doesnt provide tar file, so it didnt work for me
 Changes v3->v4 (Suggested by Arnout)
  - Use github helper for getting kernel/u-boot
  - rename fitImage.its -> fitImage.its.in to reflect as template file,
    remove hardcoded dtb filename
  - Find dtb file in output/images directory and use first dtb in fitImage
  - Remove image size from genimage.cfg
  - Tidy readme.txt and add section to explain how to stop u-boot autoboot,
    how to make it persistent, and other grammar
 Changes v4->v5 (Suggested by Thomas)
  - Use fixed kernel entry addr
  - Generate vmlinux.bin.gz from generate vmlinux.bin
  - Remove generating uImage (not required for anything now)
 Changes v5->v6
  - Use kernel generate fitimage
  - bump up u-boot version
  - Change emailid from imgtec.com -> personal id
 Changes v6->v7 (Suggested by Thomas)
  - Use genimage.sh script
  - Improve and fix grammer in readme.txt
 Changes v7->v8 (Suggested by Arnout)
  - Use genimage.sh script from POST_IMAGE_SCRIPT
  - Use uboot kconfig base config
  - Remove dts config from defconfig
  - Some other small cleanup
  - rebase on master
 Changes v8->v9 (Suggested by Arnout)
  - Use sh instead of bash where bash feature is not needed
  - Use sudo for command run on user PC
  - Update bootloader flashing help text in readme.txt
 Changes v9->v10
  - No changes

 board/ci40/genimage.cfg  | 12 +++++++++
 board/ci40/post-build.sh |  4 +++
 board/ci40/readme.txt    | 65 ++++++++++++++++++++++++++++++++++++++++++++++++
 configs/ci40_defconfig   | 48 +++++++++++++++++++++++++++++++++++
 4 files changed, 129 insertions(+)
 create mode 100644 board/ci40/genimage.cfg
 create mode 100755 board/ci40/post-build.sh
 create mode 100644 board/ci40/readme.txt
 create mode 100644 configs/ci40_defconfig

diff --git a/board/ci40/genimage.cfg b/board/ci40/genimage.cfg
new file mode 100644
index 000000000..0ffc91ce8
--- /dev/null
+++ b/board/ci40/genimage.cfg
@@ -0,0 +1,12 @@
+# Minimal SD card image
+#
+
+image sdcard.img {
+  hdimage {
+  }
+
+  partition rootfs {
+    partition-type = 0x83
+    image = "rootfs.ext4"
+  }
+}
diff --git a/board/ci40/post-build.sh b/board/ci40/post-build.sh
new file mode 100755
index 000000000..9af74c7a7
--- /dev/null
+++ b/board/ci40/post-build.sh
@@ -0,0 +1,4 @@
+#!/bin/sh
+
+# Copy to target
+cp ${BINARIES_DIR}/vmlinux.gz.itb ${TARGET_DIR}/fitImage
diff --git a/board/ci40/readme.txt b/board/ci40/readme.txt
new file mode 100644
index 000000000..ba1eb9388
--- /dev/null
+++ b/board/ci40/readme.txt
@@ -0,0 +1,65 @@
+*********************
+* MIPS Creator CI40 *
+*********************
+
+This document details how to build and run a Buildroot system on the
+MIPS Creator CI40 platform. For more details about the CI40, see
+https://creatordev.io/ci40-iot-hub.html.
+
+How to build
+------------
+
+$ make ci40_defconfig
+$ make
+
+Prepare USB/MMC for boot
+------------------------
+
+On successful build, "sdcard.img" file will be created in 'output/images'
+folder.
+
+Use following command to write image to bootable device
+
+$ sudo dd if=./output/images/sdcard.img of=/dev/<your-microsd-or-usb-device>
+
+Booting from USB/MMC
+--------------------
+
+The boot loader is already present in NOR flash. To boot your newly generated
+Linux and root filesystem, you need to interrupt U-Boot autoboot. Current
+U-Boot is configured with 2 seconds of boot-delay, after expiry of this
+boot-delay timeout U-Boot starts booting the default image. To interrupt
+autoboot, press any key before the boot-delay time expires, U-Boot will
+stop the autoboot process and give a U-Boot prompt. You can now boot to
+your preferred boot method as describe below:
+
+From USB
+  pistachio # run usbboot
+
+From SD-Card
+  pistachio # run mmcboot
+
+Persistent boot command
+-----------------------
+
+To boot automatically to your preferred boot method, use following command to
+make it persistent, for example to automatically boot to usb:
+
+  pistachio # setenv bootcmd run usbboot
+  pistachio # saveenv
+
+Flash new bootloader
+--------------------
+
+The bootloader image will be available in the 'output/images' folder. To flash
+the new bootloader, copy it to the device and use the following command on the
+device:
+
+# flashcp -v u-boot-pistachio_marduk-<version>.img /dev/mtd0
+
+Online docs
+-----------
+
+Mostly for OpenWRT but it is applicable to Buildroot
+https://docs.creatordev.io/ci40/guides/openwrt-platform/#overview
+
diff --git a/configs/ci40_defconfig b/configs/ci40_defconfig
new file mode 100644
index 000000000..2ea3afe47
--- /dev/null
+++ b/configs/ci40_defconfig
@@ -0,0 +1,48 @@
+# architecture
+BR2_mipsel=y
+BR2_mips_32r2=y
+
+# linux header same as custom kernel ie 4.4.x
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_4=y
+
+# kernel
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_TARBALL=y
+BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="$(call github,CreatorDev,linux,openwrt-4.4.14)/linux-openwrt-4.4.14.tar.gz"
+BR2_LINUX_KERNEL_DEFCONFIG="pistachio"
+BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM=y
+# vmlinux.gz.itb image includes img/pistachio_marduk device tree
+BR2_LINUX_KERNEL_IMAGE_TARGET_NAME="vmlinux.gz.itb"
+
+# bootloader flash support
+BR2_PACKAGE_MTD=y
+
+# wireless firmware
+BR2_PACKAGE_UCCP420WLAN=y
+
+# wireless package
+BR2_PACKAGE_WIRELESS_TOOLS=y
+BR2_PACKAGE_WPA_SUPPLICANT=y
+BR2_PACKAGE_WPA_SUPPLICANT_PASSPHRASE=y
+
+# bootloader
+BR2_TARGET_UBOOT=y
+BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
+BR2_TARGET_UBOOT_BOARD_DEFCONFIG="pistachio_marduk"
+BR2_TARGET_UBOOT_CUSTOM_TARBALL=y
+BR2_TARGET_UBOOT_CUSTOM_TARBALL_LOCATION="$(call github,CreatorDev,u-boot,v1.0.5)/u-boot-CreatorDev-v1.0.5.tar.gz"
+BR2_TARGET_UBOOT_FORMAT_CUSTOM=y
+BR2_TARGET_UBOOT_FORMAT_CUSTOM_NAME="u-boot-pistachio_marduk-2015.10-v1.0.5.img"
+
+# fitimage / image generation
+BR2_PACKAGE_HOST_UBOOT_TOOLS=y
+BR2_PACKAGE_HOST_UBOOT_TOOLS_FIT_SUPPORT=y
+BR2_PACKAGE_HOST_UBOOT_TOOLS_FIT_SIGNATURE_SUPPORT=y
+BR2_ROOTFS_POST_BUILD_SCRIPT="board/ci40/post-build.sh"
+
+# image generation
+BR2_TARGET_ROOTFS_EXT2=y
+BR2_TARGET_ROOTFS_EXT2_4=y
+BR2_PACKAGE_HOST_GENIMAGE=y
+BR2_ROOTFS_POST_IMAGE_SCRIPT="support/scripts/genimage.sh"
+BR2_ROOTFS_POST_SCRIPT_ARGS="-c board/ci40/genimage.cfg"
-- 
2.11.0

^ permalink raw reply related

* [Buildroot] [PATCH v10 1/2] genimage.sh: fix calling from BR2_ROOTFS_POST_IMAGE_SCRIPT
From: Abhimanyu Vishwakarma @ 2017-04-24  5:24 UTC (permalink / raw)
  To: buildroot

From: Abhimanyu Vishwakarma <Abhimanyu.V@gmail.com>

When called from BR2_ROOTFS_POST_IMAGE_SCRIPT, this script
ends up with following error:

Error: Missing argument

This is because, an extra positional argument is also passed
along with BR2_ROOTFS_POST_SCRIPT_ARGS. genimage.sh didn't
have support to parse positional and optional arguments
together.

Signed-off-by: Abhimanyu Vishwakarma <Abhimanyu.V@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Rahul Bedarkar <rahulbedarkar89@gmail.com>

---
 Changes v7->v8
   - New file
 Changes v8->v9
   - Fix indentation
   - Use bash basename as script name instead hardcoding (by arnout)
 Changes v9->v10 (Suggested by Arnout)
   - Remove tab indentation (use existing 2 space indent)
   - Fix commit message grammer
   - add reviewed-by tag
   - keep tested-by tag as no code change just indentation

 support/scripts/genimage.sh | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/support/scripts/genimage.sh b/support/scripts/genimage.sh
index 0ed0e8bcc..6c8d9e5ad 100755
--- a/support/scripts/genimage.sh
+++ b/support/scripts/genimage.sh
@@ -5,13 +5,22 @@ die() {
   exit 1
 }
 
+# Parse arguments and put into argument list of the script
+opts="$(getopt -n "${0##*/}" -o c: -- "$@")" || exit $?
+eval set -- "$opts"
+
 GENIMAGE_TMP="${BUILD_DIR}/genimage.tmp"
 
-while getopts c: OPT ; do
-	case "${OPT}" in
-	c) GENIMAGE_CFG="${OPTARG}";;
-	:) die "option '${OPTARG}' expects a mandatory argument\n";;
-	\?) die "unknown option '${OPTARG}'\n";;
+while true ; do
+	case "$1" in
+	-c)
+	  GENIMAGE_CFG="${2}";
+	  shift 2 ;;
+	--) # Discard all non-option parameters
+	  shift 1;
+	  break ;;
+	*)
+	  die "unknown option '${1}'" ;;
 	esac
 done
 
-- 
2.11.0

^ permalink raw reply related

* [Buildroot] [PATCH] xorriso: disable libcdio
From: Baruch Siach @ 2017-04-24  4:57 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <dcda91e6-6425-31a8-0da6-b4f481ed0a7c@ou.edu>

Hi Steve,

On Mon, Apr 24, 2017 at 04:41:23AM +0000, Steve Kenton wrote:
> Looks good to me
> 
> Ack - Steve Kenton

Thanks.

I'll repeat your ack below in a format that patchwork understands:

Acked-by: Steve Kenton <skenton@ou.edu>

The ack should be visible at http://patchwork.ozlabs.org/patch/753835/.

baruch

> On 04/22/2017 08:10 PM, Baruch Siach wrote:
> > xorriso and libcdio define identically named symbols. This breaks static
> > linking.
> > 
> > Besides, upstream suggested that on Linux the built-in libburn adapter is much
> > better tested than libcdio.
> > 
> > Disable libcdio.
> > 
> > Fixes:
> > http://autobuild.buildroot.net/results/430/430a6b548fcc311f20ea71cecaa11fafac1d5a19/
> > http://autobuild.buildroot.net/results/a5d/a5d0f8bec0d39e48f6dfe4ecc07fe0ca3c6bd70a/
> > 
> > Cc: Steve Kenton <skenton@ou.edu>
> > Suggested-by: Thomas Schmitt <scdbackup@gmx.net>
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > ---
> >   package/xorriso/xorriso.mk | 13 ++++---------
> >   1 file changed, 4 insertions(+), 9 deletions(-)
> > 
> > diff --git a/package/xorriso/xorriso.mk b/package/xorriso/xorriso.mk
> > index b2055804302e..1f095911f80f 100644
> > --- a/package/xorriso/xorriso.mk
> > +++ b/package/xorriso/xorriso.mk
> > @@ -18,19 +18,14 @@ HOST_XORRISO_CONF_OPTS = \
> >   	--disable-libedit \
> >   	--disable-libacl
> > +# libcdio doesn't make sense for Linux
> > +# http://lists.gnu.org/archive/html/bug-xorriso/2017-04/msg00004.html
> > +XORRISO_CONF_OPTS = --disable-libcdio
> > +
> >   ifeq ($(BR2_PACKAGE_LIBICONV),y)
> >   XORRISO_DEPENDENCIES += libiconv
> >   endif
> > -ifeq ($(BR2_PACKAGE_LIBCDIO),y)
> > -XORRISO_DEPENDENCIES += host-pkgconf libcdio
> > -XORRISO_CONF_OPTS += \
> > -	--enable-pkg-check-modules \
> > -	--enable-libcdio
> > -else
> > -XORRISO_CONF_OPTS += --disable-libcdio
> > -endif
> > -
> >   ifeq ($(BR2_PACKAGE_READLINE),y)
> >   XORRISO_DEPENDENCIES += readline
> >   XORRISO_CONF_OPTS += --enable-libreadline
> 

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

^ permalink raw reply

* [Buildroot] [PATCH 1/1] Bump version and use github helper
From: Steve Kenton @ 2017-04-24  4:44 UTC (permalink / raw)
  To: buildroot

Signed-off-by: Steve Kenton <skenton@ou.edu>
---
 package/tovid/tovid.mk | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/package/tovid/tovid.mk b/package/tovid/tovid.mk
index 079fada..0aa8c6c 100644
--- a/package/tovid/tovid.mk
+++ b/package/tovid/tovid.mk
@@ -3,9 +3,8 @@
 # tovid
 #
 ################################################################################
-
-TOVID_VERSION = 0.35.0
-TOVID_SITE = https://github.com/tovid-suite/tovid/releases/download/v$(TOVID_VERSION)
+TOVID_VERSION = 0.35.2
+TOVID_SITE = $(call github,<tovid-suite>,<tovid>,$(TOVID_VERSION))
 TOVID_LICENSE = GPL-2.0+
 TOVID_LICENSE_FILES = COPYING
 TOVID_SETUP_TYPE = distutils
-- 
2.9.0.137.gcf4c2cf

^ permalink raw reply related

* [Buildroot] [PATCH] xorriso: disable libcdio
From: Steve Kenton @ 2017-04-24  4:41 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <0a5dac7516bd86eca86510a190385617af60d738.1492891844.git.baruch@tkos.co.il>

Looks good to me

Ack - Steve Kenton



On 04/22/2017 08:10 PM, Baruch Siach wrote:
> xorriso and libcdio define identically named symbols. This breaks static
> linking.
>
> Besides, upstream suggested that on Linux the built-in libburn adapter is much
> better tested than libcdio.
>
> Disable libcdio.
>
> Fixes:
> http://autobuild.buildroot.net/results/430/430a6b548fcc311f20ea71cecaa11fafac1d5a19/
> http://autobuild.buildroot.net/results/a5d/a5d0f8bec0d39e48f6dfe4ecc07fe0ca3c6bd70a/
>
> Cc: Steve Kenton <skenton@ou.edu>
> Suggested-by: Thomas Schmitt <scdbackup@gmx.net>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
>   package/xorriso/xorriso.mk | 13 ++++---------
>   1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/package/xorriso/xorriso.mk b/package/xorriso/xorriso.mk
> index b2055804302e..1f095911f80f 100644
> --- a/package/xorriso/xorriso.mk
> +++ b/package/xorriso/xorriso.mk
> @@ -18,19 +18,14 @@ HOST_XORRISO_CONF_OPTS = \
>   	--disable-libedit \
>   	--disable-libacl
>   
> +# libcdio doesn't make sense for Linux
> +# http://lists.gnu.org/archive/html/bug-xorriso/2017-04/msg00004.html
> +XORRISO_CONF_OPTS = --disable-libcdio
> +
>   ifeq ($(BR2_PACKAGE_LIBICONV),y)
>   XORRISO_DEPENDENCIES += libiconv
>   endif
>   
> -ifeq ($(BR2_PACKAGE_LIBCDIO),y)
> -XORRISO_DEPENDENCIES += host-pkgconf libcdio
> -XORRISO_CONF_OPTS += \
> -	--enable-pkg-check-modules \
> -	--enable-libcdio
> -else
> -XORRISO_CONF_OPTS += --disable-libcdio
> -endif
> -
>   ifeq ($(BR2_PACKAGE_READLINE),y)
>   XORRISO_DEPENDENCIES += readline
>   XORRISO_CONF_OPTS += --enable-libreadline

^ permalink raw reply

* [Buildroot] [PATCH] docs/manual: PEP8 coding style for Python scripts
From: Ricardo Martincoski @ 2017-04-24  1:33 UTC (permalink / raw)
  To: buildroot

The advantages of using a pre-existing coding style instead of creating
our own are:
- documenting on the manual takes a single sentence;
- there are automatic tools to help during development/review.

So document that PEP8 recommendation should be followed.

Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
---
Here is the sentence I didn't add:
The use of https://pypi.python.org/pypi/pycodestyle[Python style guide checker]
is recommended before submitting new scripts.

I mentioned in a thread the tool pep8/pycodestyle
From https://pypi.python.org/pypi/pycodestyle :
"This package used to be called pep8 but was renamed to pycodestyle to
reduce confusion"
Old url: https://pypi.python.org/pypi/pep8

Also Thomas DS mentioned the tool flake8 that seems to me to group:
pycodestyle + pyflakes + mccabe
http://flake8.pycqa.org/en/latest/
---
 docs/manual/writing-rules.txt | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/docs/manual/writing-rules.txt b/docs/manual/writing-rules.txt
index e2ad41ebc..3a2c8dcb3 100644
--- a/docs/manual/writing-rules.txt
+++ b/docs/manual/writing-rules.txt
@@ -143,3 +143,8 @@ http://www.methods.co.nz/asciidoc/[asciidoc] format.
 
 For further details about the http://www.methods.co.nz/asciidoc/[asciidoc]
 syntax, refer to http://www.methods.co.nz/asciidoc/userguide.html[].
+
+=== Support scripts
+
+Some scripts in the +support/+ directory are written in Python and should follow
+the https://www.python.org/dev/peps/pep-0008/[PEP8 Style Guide for Python Code].
-- 
2.11.0

^ permalink raw reply related

* [Buildroot] [RFC] Adopt a coding style for Python scripts
From: Ricardo Martincoski @ 2017-04-24  1:28 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <a6518c83-6421-8957-e11f-15db51d5a346@mind.be>

Arnout,

On Sun, Apr 23, 2017 at 06:41 PM, Arnout Vandecappelle wrote:

> On 20-04-17 08:56, Ricardo Martincoski wrote:
>> Thomas,
>> 
>> I have a local patch for the docs for option D, but I will hold it for few more
>> days to see if we get more input.
>> 
>> On Wed, Apr 19, 2017 at 04:34 PM, Thomas De Schampheleire wrote:
>> 
>>> 2017-04-14 19:14 GMT+02:00 Arnout Vandecappelle <arnout@mind.be>:
>>>> On 14-04-17 01:44, Ricardo Martincoski wrote:
>> [snip]
>>>>> D) adopt the recommendation PEP8 [1] as coding style and the tool pep8 [2] as
>>>>>    automatic checker for coding style before submitting patches;
>>>>>    It checks for a subset of the recommendation (e.g. file naming is not
>>>>>    checked).
>>>>
>>>>  For me, option D is great. It can also be added to the checkpackage script.
>>>>
>>>
>>> I'm not against this either. However, sometimes I feel that pep8 is
>>> being too pedantic. For example, there is a minimum variable name
>>> length of 3. However, for regex searches, it is common to use the
>>> variable 'm' to hold the match, and then use 'if m' or 'm.group(3)' or
>>> whatever, which I feel is perfectly fine.
>> 
>> It seems more people think like you because pep8 tool does not check for that
>> specifically (it's a subset from the recommendation), see my tests at the end.
>> 
>>> I haven't used pep8 so don't know if it can be tweaked.
>> 
>> The warnings can be suppressed by type.
>> pep8 --ignore E302 1.py
>> But AFAIK it can't be configured i.e. to check for 1 or 3 empty lines instead
>> of 2. It's "check for 2" or "don't check for empty lines".
> 
>  I don't think we have a problem with the 2 empty lines. What I understand from
> the previous discussion is that we're OK with changing the Buildroot to standard
> to comply with pep8, also if that means adding an extra line between functions.

Sure. We don't have a problem with 2 empty lines.

Sorry the bad example I gave. What I meant to say is that the tool can be
tweaked but only by toggling on/off which warnings are generated.

>>> There also exist other tools btw, like flake8, which also check other
>>> items than style. They too can be useful, but they too can be 'too
>>> much'.
>> 
>> I haven't used flake8. I installed it after your e-mail.
>> I usually use pep8 for style, pyflakes for common errors (i.e. unused import),
>> and pyflakes3 for Python 3 compatibility (i.e. print without parenthesis).
>> 
>> Last year pep8 got renamed to pycodestyle to reduce confusion with PEP8.
>> 
>> So looking at [4] I had a nice surprise ...   
>>  pycodestyle >= 2.0.0, < 2.1.0
>>  pyflakes >= 0.8.0, != 1.2.0, != 1.2.1, != 1.2.2, < 1.3.0
>>  mccabe >= 0.5.0, < 0.6.0
>> If you use flake8 you already use pep8 = pycodestyle!
>> 
>> The only thing that worries me a bit is this warning from [5]:
>> "In many ways, Flake8 is tied to the version of Python on which it runs."
>> 
>> 
>> Do you (or somebody else) know if it can be a concern in our use case?
>> 
>> 
>> Other than that I am OK to adopt PEP8 + flake8 instead of PEP8 + pep8.
>> Let's call it option E.
>> E) PEP8 + flake8
>> Let's see what others think.
> 
>  Let's start with documenting PEP8 :-)

OK. I hope I understand your suggestion correctly.
I will send a patch for option C (PEP8 recommendation, no tools).
Anyway it can be changed during review/apply if needed.

Regards,
Ricardo

^ permalink raw reply

* [Buildroot] [RFC] Adopt a coding style for Python scripts
From: Ricardo Martincoski @ 2017-04-24  1:25 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <488de6bd-5014-59b4-100b-8a73e9343cb6@mind.be>

Arnout, Thomas P,

On Sun, Apr 23, 2017 at 06:34 PM, Arnout Vandecappelle wrote:

> On 20-04-17 09:17, Thomas Petazzoni wrote:
>> Hello,
>> 
>> On Wed, 19 Apr 2017 14:00:53 -0300, Ricardo Martincoski wrote:
>> 
>>>> On 14-04-17 01:44, Ricardo Martincoski wrote:  
>>>>> D) adopt the recommendation PEP8 [1] as coding style and the tool pep8 [2] as
>>>>>    automatic checker for coding style before submitting patches;
>>>>>    It checks for a subset of the recommendation (e.g. file naming is not
>>>>>    checked).  
>>>>
>>>>  For me, option D is great. It can also be added to the checkpackage script.  
>>>
>>> I can look into this integration.
>> 
>> I have nothing against option (D), but I'm wondering what is the
>> relation with the checkpackage script. checkpackage checks packages,
>> written in Kconfig and Make, what is the relation with complying with
>> the Python PEP8 recommendation?
> 
>  Actually, check-package checks files, not packages. It looks at the filename
> and if it is one it recognizes, it runs the appropriate checker on it. So a
> checker that applies to files ending with .py could certainly be added.

It is feasible, probably using the library file-magic because not all Python
scripts in the tree use .py extension.

But maybe it is too much, at least for now. 

Before submitting a patch for a package one can use check-package.
Before submitting a patch for a Python script one can use pycodestyle (pep8).

It's not really needed to have a unified script to check both a package and a
Python script.
They are in different directories and are sent in separate patches anyway.

Regards,
Ricardo

^ permalink raw reply

* [Buildroot] uboot-tools autobuild failures
From: Fabio Estevam @ 2017-04-23 23:44 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <CANQCQpb0U3tO7Z-Lsz1pxmekaKYC8JyU7BJgtcXwLDWDgh1xNw@mail.gmail.com>

Hi Matthew,

On Wed, Apr 19, 2017 at 10:55 PM, Matthew Weber
<matthew.weber@rockwellcollins.com> wrote:
> It looks like all of these recent failures are because the python swig
> build does a "$(if $(shell which swig 2> /dev/null),_libfdt.so)" to
> determine if the host system has swig and if so, try to build the
> python bindings.  Obviously not taking into account any prefix we'd
> provide to the host/ in out build.
>
> http://autobuild.buildroot.org/?reason=uboot-tools-2017.03
>
> I don't directly have a need for those bindings, would a patch that
> disables this swig detect be reasonable at this point?  Other option
> would be to rewrite how they're doing it to search a prefix path vs
> using the shell's which.  Then work upstreaming of that change.

U-Boot mainline has a fix for this already:
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=9963890b8be1d208035945abc5ba9f77637b6542

My host PC does not have Python 3, so I cannot reproduce this error myself.

Could you please try the attached Buildroot patch?

Regards,

Fabio Estevam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-libfdtfix.patch
Type: text/x-patch
Size: 2173 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170423/d6629d56/attachment.bin>

^ permalink raw reply

* [Buildroot] [PATCH] gcc: Fix build failure related to -fPIC for x86_64 -> i686 builds
From: Arnout Vandecappelle @ 2017-04-23 22:06 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <71cfdaf7-367d-44de-a1c6-9041e269c8de@cesnet.cz>



On 19-04-17 18:23, Jan Kundr?t wrote:
>> Without this patch, I cannot build the toolchain (both host-gcc-initial
>> and -final) on Gentoo's amd64 using GCC 4.9.3:
>>
>>   /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/bin/ld:
>>   gcov.o: relocation R_X86_64_32 against `.rodata.str1.8' can not
>>   be used when making a shared object; recompile with -fPIC
> 
> One important piece I forgot to add -- I'm running "Hardened Gentoo GCC" which
> enables PIE by default [1] [2]. As such, this might explain why other are
> (presumably) not seeing this problem.

 Indeed. However, I wonder, won't you have a similar problem with other host
packages that try to build something without -fPIC?


 We don't like to accept patches where it is not clear what happens, i.e. how
this particular change fixes your problem...


> BTW, I cannot find my original submission on patchwork. Was that e-mail OK? I
> see it in the ML archive [3].

 I believe it's because you sent it base64-encoded, patchwork only likes
plaintext. You didn't use git send-email, did you?

 Regards,
 Arnout

> 
> With kind regards,
> Jan
> 
> [1]
> https://wiki.gentoo.org/wiki/Hardened/Toolchain#Automatic_generation_of_Position_Independent_Executables_.28PIEs.29
> 
> [2]
> https://wiki.gentoo.org/wiki/Hardened/Toolchain#Toolchain_modifications_for_automatic_PIEs
> 
> [3] http://lists.busybox.net/pipermail/buildroot/2017-April/189441.html
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply

* [Buildroot] uboot-tools autobuild failures
From: Arnout Vandecappelle @ 2017-04-23 21:59 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <CANQCQpb0U3tO7Z-Lsz1pxmekaKYC8JyU7BJgtcXwLDWDgh1xNw@mail.gmail.com>



On 20-04-17 03:55, Matthew Weber wrote:
> It looks like all of these recent failures are because the python swig
> build does a "$(if $(shell which swig 2> /dev/null),_libfdt.so)" to
> determine if the host system has swig and if so, try to build the
> python bindings.  Obviously not taking into account any prefix we'd
> provide to the host/ in out build.
> 
> http://autobuild.buildroot.org/?reason=uboot-tools-2017.03
> 
> I don't directly have a need for those bindings, would a patch that
> disables this swig detect be reasonable at this point?  Other option
> would be to rewrite how they're doing it to search a prefix path vs
> using the shell's which.  Then work upstreaming of that change.

 The problem with patching uboot-tools is that you usually also built uboot when
you build uboot-tools, and most likely uboot will also fail to build (at least
if it's a recent version). But we can't patch uboot because we don't know which
version it is... So we'd need to do horrible sed-based "patching" in uboot.mk...

 So the ideal solution would be to convince the U-Boot build system that swig
isn't available, without patching... But that would be difficult...

 How about just touching tools/_libfdt.so, so that it doesn't get rebuilt?

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply

* [Buildroot] [RFC] Adopt a coding style for Python scripts
From: Arnout Vandecappelle @ 2017-04-23 21:41 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <58f85bb0cb8f7_991ae0a6021685@ultri3.mail>



On 20-04-17 08:56, Ricardo Martincoski wrote:
> Thomas,
> 
> I have a local patch for the docs for option D, but I will hold it for few more
> days to see if we get more input.
> 
> On Wed, Apr 19, 2017 at 04:34 PM, Thomas De Schampheleire wrote:
> 
>> 2017-04-14 19:14 GMT+02:00 Arnout Vandecappelle <arnout@mind.be>:
>>> On 14-04-17 01:44, Ricardo Martincoski wrote:
> [snip]
>>>> D) adopt the recommendation PEP8 [1] as coding style and the tool pep8 [2] as
>>>>    automatic checker for coding style before submitting patches;
>>>>    It checks for a subset of the recommendation (e.g. file naming is not
>>>>    checked).
>>>
>>>  For me, option D is great. It can also be added to the checkpackage script.
>>>
>>
>> I'm not against this either. However, sometimes I feel that pep8 is
>> being too pedantic. For example, there is a minimum variable name
>> length of 3. However, for regex searches, it is common to use the
>> variable 'm' to hold the match, and then use 'if m' or 'm.group(3)' or
>> whatever, which I feel is perfectly fine.
> 
> It seems more people think like you because pep8 tool does not check for that
> specifically (it's a subset from the recommendation), see my tests at the end.
> 
>> I haven't used pep8 so don't know if it can be tweaked.
> 
> The warnings can be suppressed by type.
> pep8 --ignore E302 1.py
> But AFAIK it can't be configured i.e. to check for 1 or 3 empty lines instead
> of 2. It's "check for 2" or "don't check for empty lines".

 I don't think we have a problem with the 2 empty lines. What I understand from
the previous discussion is that we're OK with changing the Buildroot to standard
to comply with pep8, also if that means adding an extra line between functions.


>> There also exist other tools btw, like flake8, which also check other
>> items than style. They too can be useful, but they too can be 'too
>> much'.
> 
> I haven't used flake8. I installed it after your e-mail.
> I usually use pep8 for style, pyflakes for common errors (i.e. unused import),
> and pyflakes3 for Python 3 compatibility (i.e. print without parenthesis).
> 
> Last year pep8 got renamed to pycodestyle to reduce confusion with PEP8.
> 
> So looking at [4] I had a nice surprise ...   
>  pycodestyle >= 2.0.0, < 2.1.0
>  pyflakes >= 0.8.0, != 1.2.0, != 1.2.1, != 1.2.2, < 1.3.0
>  mccabe >= 0.5.0, < 0.6.0
> If you use flake8 you already use pep8 = pycodestyle!
> 
> The only thing that worries me a bit is this warning from [5]:
> "In many ways, Flake8 is tied to the version of Python on which it runs."
> 
> 
> Do you (or somebody else) know if it can be a concern in our use case?
> 
> 
> Other than that I am OK to adopt PEP8 + flake8 instead of PEP8 + pep8.
> Let's call it option E.
> E) PEP8 + flake8
> Let's see what others think.

 Let's start with documenting PEP8 :-)

> 
> 
> Here is the output for all current Python scripts in Buildroot:
> $ flake8 --statistics $(find support/ -type f | xargs file | grep Python \
>   | sed -e 's,:.*,,g')
> 4     E101 indentation contains mixed spaces and tabs
> 2     E122 continuation line missing indentation or outdented
> 2     E127 continuation line over-indented for visual indent
> 2     E128 continuation line under-indented for visual indent
> 1     E129 visually indented line with same indent as next logical line
> 5     E201 whitespace after '['
> 7     E202 whitespace before ']'
> 3     E203 whitespace before ':'
> 1     E221 multiple spaces before operator
> 1     E225 missing whitespace around operator
> 16    E231 missing whitespace after ','
> 3     E261 at least two spaces before inline comment
> 54    E302 expected 2 blank lines, found 1
> 12    E305 expected 2 blank lines after class or function definition, found 1
> 6     E402 module level import not at top of file
> 41    E501 line too long (80 > 79 characters)
 This one is probably a bit too much to try to fix.
> 6     E502 the backslash is redundant between brackets
> 2     E711 comparison to None should be 'if cond is None:'
> 2     E713 test for membership should be 'not in'
> 15    F401 'checkpackagelib.ConsecutiveEmptyLines' imported but unused
> 1     F821 undefined name 'sys'
> 2     W191 indentation contains tabs
> 2     W391 blank line at end of file
> 3     W601 .has_key() is deprecated, use 'in'

 Otherwise looks like all of them are OK to change.

[snip]
> (my original e-mail used [3], so I incremented the number to avoid confusion)
> [4] http://flake8.pycqa.org/en/latest/faq.html#why-does-flake8-use-ranges-for-its-dependencies
> [5] http://flake8.pycqa.org/en/latest/
> 
> Regards,
> Ricardo
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply

* [Buildroot] [RFC] Adopt a coding style for Python scripts
From: Arnout Vandecappelle @ 2017-04-23 21:34 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170420091731.3de60ee5@free-electrons.com>



On 20-04-17 09:17, Thomas Petazzoni wrote:
> Hello,
> 
> On Wed, 19 Apr 2017 14:00:53 -0300, Ricardo Martincoski wrote:
> 
>>> On 14-04-17 01:44, Ricardo Martincoski wrote:  
>>>> D) adopt the recommendation PEP8 [1] as coding style and the tool pep8 [2] as
>>>>    automatic checker for coding style before submitting patches;
>>>>    It checks for a subset of the recommendation (e.g. file naming is not
>>>>    checked).  
>>>
>>>  For me, option D is great. It can also be added to the checkpackage script.  
>>
>> I can look into this integration.
> 
> I have nothing against option (D), but I'm wondering what is the
> relation with the checkpackage script. checkpackage checks packages,
> written in Kconfig and Make, what is the relation with complying with
> the Python PEP8 recommendation?

 Actually, check-package checks files, not packages. It looks at the filename
and if it is one it recognizes, it runs the appropriate checker on it. So a
checker that applies to files ending with .py could certainly be added.

 Regards,
 Arnout

> 
> Best regards,
> 
> Thomas
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply

* [Buildroot] [PATCH 1/1] busybox: ncurses progs equiv as default
From: Arnout Vandecappelle @ 2017-04-23 21:32 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <CANQCQpZ_6yXNSgpNLGmGLmNwGRsQy84EUPkDoCBMhOTuh49Jsg@mail.gmail.com>



On 20-04-17 15:01, Matthew Weber wrote:
> Baruch,
> 
> On Wed, Apr 19, 2017 at 11:00 PM, Baruch Siach <baruch@tkos.co.il> wrote:
>> Hi Matt,
>>
>> On Wed, Apr 19, 2017 at 09:13:28PM -0500, Matt Weber wrote:
>>> By default, enable the busybox equivalents of the ncurses
>>> clear and reset if ncurses progs are not enabled.
>>
>> Our default busybox.config enables these applets. If the user chooses to
>> disable them in a custom config, why should we force them back on?
>>
> 
> True, I was thinking the use case of build time changing (then doing
> incremental build)if you use ncurses progs vs not and forcing the
> busybox reconfig to have it update the target folder respectively.

 This is a use case we certainly don't want to support. On the other hand, we
*do* want to support the use case where the user has a custom busybox config,
doesn't have ncurses, and doesn't want to have clear and reset in his system.

 Regards,
 Arnout

> 
> I agree this isn't' ideal for all situations, but with these being
> terminal tools, would/should you ever turn them off and the amount of
> code is small?
> 
> Other discussion related to this:
> https://patchwork.ozlabs.org/patch/750264/
> https://patchwork.ozlabs.org/patch/750721/
> 
> -Matt
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply

* [Buildroot] [PATCH v9 1/2] genimage.sh: fix calling from BR2_ROOTFS_POST_IMAGE_SCRIPT
From: Arnout Vandecappelle @ 2017-04-23 21:27 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20170421185839.17905-1-abhimanyu.v@gmail.com>



On 21-04-17 20:58, Abhimanyu Vishwakarma wrote:
> From: Abhimanyu Vishwakarma <Abhimanyu.V@gmail.com>
> 
> When called from BR2_ROOTFS_POST_IMAGE_SCRIPT, this script
> ends up with following error:
> 
> Error: Missing argument
> 
> This is because, extra positional argument is also passed
                   ^an

> along with BR2_ROOTFS_POST_SCRIPT_ARGS. genimage.sh didnt
                                                          ^'
> had support to parse positional and optional argument
    ^ve                                                ^s

> together.
> 
> Signed-off-by: Abhimanyu Vishwakarma <Abhimanyu.V@gmail.com>
> ---
>  Changes v7->v8
>    - New file
>  Changes v8->v9
>    - Fix indentation
>    - Use bash basename as script name instead hardcoding
> 
>  support/scripts/genimage.sh | 23 ++++++++++++++++-------
>  1 file changed, 16 insertions(+), 7 deletions(-)
> 
> diff --git a/support/scripts/genimage.sh b/support/scripts/genimage.sh
> index 0ed0e8bcc..a2309e224 100755
> --- a/support/scripts/genimage.sh
> +++ b/support/scripts/genimage.sh
> @@ -1,17 +1,26 @@
>  #!/bin/bash
>  
>  die() {
> -  echo "Error: $@" >&2
> -  exit 1
> +	echo "Error: $@" >&2
> +	exit 1

 Avoid mixing whitespace fixes with other fixes in the same patch. I.e., split
this up in a  separate patch (fixing indentation all over).

>  }
>  
> +# Parse arguments and put into argument list of the script
> +opts="$(getopt -n "${0##*/}" -o c: -- "$@")" || exit $?
> +eval set -- "$opts"
> +
>  GENIMAGE_TMP="${BUILD_DIR}/genimage.tmp"
>  
> -while getopts c: OPT ; do
> -	case "${OPT}" in
> -	c) GENIMAGE_CFG="${OPTARG}";;
> -	:) die "option '${OPTARG}' expects a mandatory argument\n";;
> -	\?) die "unknown option '${OPTARG}'\n";;
> +while true ; do
> +	case "$1" in
> +		-c)

 We sometimes do and sometimes don't indent inside a case statement in shell
scripts. Annoying inconsistency. However, this file _didn't_ indent, so stick to
that coding style.

 But all this is just minor things, so

Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

(if you resubmit, make sure you copy the above Reviewed-by, except when you make
changes not mentioned in my review).

 Regards,
 Arnout

> +			GENIMAGE_CFG="${2}";
> +			shift 2 ;;
> +		--) # Discard all non-option parameters
> +			shift 1;
> +			break ;;
> +		*)
> +			die "unknown option '${1}'" ;;
>  	esac
>  done
>  
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply

* [Buildroot] [PATCH 00/29] qt, qt5: only ever use the free/opensource licenses
From: Arnout Vandecappelle @ 2017-04-23 21:12 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <cover.1492979449.git.yann.morin.1998@free.fr>

 Hi all,

On 23-04-17 22:31, Yann E. MORIN wrote:
> Hello All!
> 
> This series drops the option to accept the "free license" (as per the
> current prompts), to only ever use that, and no longer claim to allow
> use of Qt/Qt5 under a proprietary version.
> 
> The rationale behind this change is multi-fold:
> 
>   - the name of the tarballs we download clearly hint that they can
>     only be used under the opensource license;
> 
>   - the proprietary license is unknown to us (the Buildroot community
>     at large); we do not even know if there is a single such license;
> 
>   - we do not have such license choice for any other package in a
>     similar situation (e.g. mongoose); we only ever use the publicly
>     available licenses, always;
> 
>   - finally, we do not have such click-wrap acceptance option for any
>     license, be it free, opensource, or proprietary, and whether it be
>     redistributable or not. The licenses are available in the output
>     of legal-info, which a user should consult before using or
>     distributing the result of a build.

 In addition, this option (if not set) will stop the build for interactive
handling, which is something we want to avoid.

 Big +1 to this series. I gave it a once-over and it looks OK to me (I didn't
look carefully enough to give it a Reviewed-by though). I do have an issue with
the legacy handling, as explained in my reply to that patch. I also wouldn't
have split it up as much, but OK.

> 
> So, we drop the option to "Approve free license" for both Qt and
> Qt5, and do as we do for all packages: just use the publicly-known
> opensource licenses.
> 
> Users interested in using Qt under a proprietary license will have
> to take special steps to use it (as they were already probably doing
> anyway).

 Actually the proprietary Qt licenses that I've seen said that they also apply
to the free download. Admittedly that was a couple of years ago, still Qt4.

 Regards,
 Arnout

> 
> 
> Regards,
> Yann E. MORIN.
> 
> 
> The following changes since commit 4c2b11977a70d418b7ae2cd7d4b62e77bddbc2c6
> 
>   syslog-ng: disable mongodb (2017-04-22 15:59:31 +0200)
> 
> 
> are available in the git repository at:
> 
>   git://git.buildroot.org/~ymorin/git/buildroot.git
> 
> for you to fetch changes up to 0edfc64dedabab8b436312b1212c08dcf9765a05
> 
>   package/qt5: drop option for license approved (2017-04-23 19:09:57 +0200)
> 
> 
> ----------------------------------------------------------------
> Yann E. MORIN (29):
>       package/qt: default to approved license
>       package/qt5base: default to approved license
>       package/qt: always use the opensource license
>       package/qt5base: always use the opensource license
>       package/qt53d: always use the opensource license
>       package/qt5canvas: always use the opensource license
>       package/qt5connectivity: always use the opensource license
>       package/qt5declarative: always use the opensource license
>       package/qt5enginio: always use the opensource license
>       package/qt5graphicaleffects: always use the opensource license
>       package/qt5imageformats: always use the opensource license
>       package/qt5location: always use the opensource license
>       package/qt5multimedia: always use the opensource license
>       package/qt5quickcontrols: always use the opensource license
>       package/qt5quickcontrols2: always use the opensource license
>       package/qt5script: always use the opensource license
>       package/qt5sensors: always use the opensource license
>       package/qt5serialbus: always use the opensource license
>       package/qt5serialport: always use the opensource license
>       package/qt5svg: always use the opensource license
>       package/qt5tools: always use the opensource license
>       package/qt5webchannel: always use the opensource license
>       package/qt5webkit: always use the opensource license
>       package/qt5websockets: always use the opensource license
>       package/qt5x11extras: always use the opensource license
>       package/qt5xmlpatterns: always use the opensource license
>       configs: drop Qt/Qt5 license approval option
>       package/qt: drop option for license approved
>       package/qt5: drop option for license approved
> 
>  Config.in.legacy                                       | 12 ++++++++++++
>  configs/beaglebone_qt5_defconfig                       |  1 -
>  configs/firefly_rk3288_demo_defconfig                  |  1 -
>  package/qt/Config.in                                   | 11 -----------
>  package/qt/qt.mk                                       |  6 +-----
>  package/qt5/qt53d/qt53d.mk                             |  5 -----
>  package/qt5/qt5base/Config.in                          | 12 ------------
>  package/qt5/qt5base/qt5base.mk                         |  5 -----
>  package/qt5/qt5canvas3d/qt5canvas3d.mk                 |  5 -----
>  package/qt5/qt5connectivity/qt5connectivity.mk         |  5 -----
>  package/qt5/qt5declarative/qt5declarative.mk           |  5 -----
>  package/qt5/qt5enginio/qt5enginio.mk                   |  5 -----
>  package/qt5/qt5graphicaleffects/qt5graphicaleffects.mk |  5 -----
>  package/qt5/qt5imageformats/qt5imageformats.mk         |  5 -----
>  package/qt5/qt5location/qt5location.mk                 |  5 -----
>  package/qt5/qt5multimedia/qt5multimedia.mk             |  5 -----
>  package/qt5/qt5quickcontrols/qt5quickcontrols.mk       |  5 -----
>  package/qt5/qt5quickcontrols2/qt5quickcontrols2.mk     |  5 -----
>  package/qt5/qt5script/qt5script.mk                     |  5 -----
>  package/qt5/qt5sensors/qt5sensors.mk                   |  5 -----
>  package/qt5/qt5serialbus/qt5serialbus.mk               |  5 -----
>  package/qt5/qt5serialport/qt5serialport.mk             |  5 -----
>  package/qt5/qt5svg/qt5svg.mk                           |  5 -----
>  package/qt5/qt5tools/qt5tools.mk                       |  5 -----
>  package/qt5/qt5webchannel/qt5webchannel.mk             |  5 -----
>  package/qt5/qt5webkit/qt5webkit.mk                     |  5 -----
>  package/qt5/qt5websockets/qt5websockets.mk             |  5 -----
>  package/qt5/qt5x11extras/qt5x11extras.mk               |  5 -----
>  package/qt5/qt5xmlpatterns/qt5xmlpatterns.mk           |  5 -----
>  29 files changed, 13 insertions(+), 145 deletions(-)
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply

* [Buildroot] [PATCH 28/29] package/qt: drop option for license approved
From: Arnout Vandecappelle @ 2017-04-23 20:59 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <2389cf9ab684f7d56a7ab20b3d8a2be0fa612167.1492979449.git.yann.morin.1998@free.fr>



On 23-04-17 22:31, Yann E. MORIN wrote:
> As stated in previous commits, Buildroot only ever uses the free
> license, and we do not have a click-wrap approval for any such free
> license for any other package.
> 
> The option to approve the license now has no prompt and is no longer
> used anywhere. Drop it and make it a legacy entry.
> 
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Julien Corjon <corjon.j@ecagroup.com>
> Cc: Peter Seiderer <ps.report@gmx.net>
> ---
>  Config.in.legacy     | 6 ++++++
>  package/qt/Config.in | 4 ----
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/Config.in.legacy b/Config.in.legacy
> index 8e9f3d175d..52cda9808e 100644
> --- a/Config.in.legacy
> +++ b/Config.in.legacy
> @@ -145,6 +145,12 @@ endif
>  ###############################################################################
>  comment "Legacy options removed in 2017.05"
>  
> +config BR2_PACKAGE_QT_LICENSE_APPROVED
> +	bool "Qt free license now always approved"
> +	select BR2_LEGACY
> +	help
> +	  Use of Qt in Buildroot now always use the free license of Qt.

 IMO this doesn't bring any value. If the user already has selected to approve
the free license, nothing really changes for them so there's no point drawing
their attention to legacy.

 We should instead give a legacy warning when the user *didn't* have the option
selected. But that's not possible, of course.

 Therefore, I'd say we drop the legacy handling for this option.


 Regards,
 Arnout
> +
>  config BR2_PACKAGE_PORTMAP
>  	bool "portmap has been removed"
>  	select BR2_LEGACY
> diff --git a/package/qt/Config.in b/package/qt/Config.in
> index 5f07bd22f9..d3a01da87f 100644
> --- a/package/qt/Config.in
> +++ b/package/qt/Config.in
> @@ -99,10 +99,6 @@ config BR2_PACKAGE_QT_STATIC
>  
>  endchoice
>  
> -config BR2_PACKAGE_QT_LICENSE_APPROVED
> -	bool
> -	default y
> -
>  config BR2_PACKAGE_QT_CONFIG_FILE
>  	string "Config file"
>  	help
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply

* [Buildroot] [PATCH 1/1] busybox: preserve ncurses progs/tools
From: Arnout Vandecappelle @ 2017-04-23 20:55 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <87pog3ypb1.fsf@dell.be.48ers.dk>



On 23-04-17 20:03, Peter Korsgaard wrote:
>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> 
>  > Hello,
>  > On Fri, 14 Apr 2017 19:00:32 +0200, Arnout Vandecappelle wrote:
> 
>  >> This is the correct approach I think. I think we could also do this for all the
>  >> other cases where we have a -> busybox dependency just because they install the
>  >> same apps.
> 
>  > Yes, I'm also wondering if it isn't better to disable the Busybox
>  > applets (like Matt does in this patch for ncurses) rather then
>  > overwriting the symlinks.
> 
>  > First of all, overwriting the symlinks means that if you "make
>  > busybox-reinstall", you no longer get the right thing (for sure, we
>  > never guarantee that partial builds/rebuilds give the correct output,
>  > but it's nice when they do). And then of course, it means that there is
>  > code in Busybox, consuming some space, that is never used.
> 
>  > The only annoyance that I can see is a potential blotification of
>  > busybox.mk, with lots of conditional for various packages.
> 
> That and the fact that we're adding more "magic" to silently override
> the configuration behind the users' back. I get it that people may be
> less likely to tweak their busybox config than E.G. the kernel, but just
> like for the kernel config I prefer to keep the config overrides to the
> minimum.

 Well, we are "overriding" the user's busybox config, but since the alternative
is deleting the busybox-installed tool, whatever the user has configured is not
available anyway...

 Well, except that it still is available by calling it as "busybox clear".

 So, the choice comes down to:

1. Add a dependency on busybox like we do now, but it's actually a fake
dependency and can lead to circular dependencies. And it's anyway not failsafe
because a "busybox-rebuild" will again overwrite it. On addition, it has the
bloatification that Thomas mentions.

2. Make sure that busybox doesn't overwrite a tool that already exists. Needs to
be done for all the different ways that busybox can install things. Then the
order doesn't matter. Great solution, except for the bloatification. Also, it is
not great when you have FEATURE_INDIVIDUAL selected in busybox, because a
busybox-rebuild will not actually rebuild anything.

3. Like proposed in this patch, adapt busybox config. Has the advantage of no
bloatification, but it means that the user sees his own config overridden which
isn't nice. In addition, it's quite ugly for the busybox.mk to have all these
references to other packages (about 40!).


 Of course, we can also choose to apply solution 3 only to the situation where 1
doesn't work because of circular dependencies.


 I can't say which solution is the best. I therefore tend to say: stick to what
we have, and find a workaround if needed. In other words, apply this patch, but
don't do it for other packages until required.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply

* [Buildroot] [PATCH 1/1] mongoose: bump to version 6.7
From: Davide Viti @ 2017-04-23 20:33 UTC (permalink / raw)
  To: buildroot

Signed-off-by: Davide Viti <zinosat@tiscali.it>
---
 package/mongoose/mongoose.hash | 2 +-
 package/mongoose/mongoose.mk   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/mongoose/mongoose.hash b/package/mongoose/mongoose.hash
index c131e48c4..d5252eb68 100644
--- a/package/mongoose/mongoose.hash
+++ b/package/mongoose/mongoose.hash
@@ -1,2 +1,2 @@
 # Locally computed:
-sha256	94b934da083afe8abb1c0af5abb8f25294050011793f048166b12f000f9433a0  mongoose-6.2.tar.gz
+sha256	ccc971298db70963d3f13766c3246a3c36ae7e388acfab7ba2180149d9c8c64f  mongoose-6.7.tar.gz
diff --git a/package/mongoose/mongoose.mk b/package/mongoose/mongoose.mk
index ad8b08c65..36fd8f899 100644
--- a/package/mongoose/mongoose.mk
+++ b/package/mongoose/mongoose.mk
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-MONGOOSE_VERSION = 6.2
+MONGOOSE_VERSION = 6.7
 MONGOOSE_SITE = $(call github,cesanta,mongoose,$(MONGOOSE_VERSION))
 MONGOOSE_LICENSE = GPL-2.0
 MONGOOSE_LICENSE_FILES = LICENSE
-- 
2.11.0

^ permalink raw reply related

* [Buildroot] [PATCH 29/29] package/qt5: drop option for license approved
From: Yann E. MORIN @ 2017-04-23 20:31 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <cover.1492979449.git.yann.morin.1998@free.fr>

As stated in previous commits, Buildroot only ever uses the free
license, and we do not have a click-wrap approval for any such free
license for any other package.

The option to approve the license now has no prompt and is no longer
used anywhere. Drop it and make it a legacy entry.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Julien Corjon <corjon.j@ecagroup.com>
Cc: Peter Seiderer <ps.report@gmx.net>
---
 Config.in.legacy              | 6 ++++++
 package/qt5/qt5base/Config.in | 4 ----
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/Config.in.legacy b/Config.in.legacy
index 52cda9808e..93df6c52ad 100644
--- a/Config.in.legacy
+++ b/Config.in.legacy
@@ -145,6 +145,12 @@ endif
 ###############################################################################
 comment "Legacy options removed in 2017.05"
 
+config BR2_PACKAGE_QT5BASE_LICENSE_APPROVED
+	bool "Qt5 free license now always approved"
+	select BR2_LEGACY
+	help
+	  Use of Qt5 in Buildroot now always use the free license of Qt5.
+
 config BR2_PACKAGE_QT_LICENSE_APPROVED
 	bool "Qt free license now always approved"
 	select BR2_LEGACY
diff --git a/package/qt5/qt5base/Config.in b/package/qt5/qt5base/Config.in
index 044aa5d545..4796fdb058 100644
--- a/package/qt5/qt5base/Config.in
+++ b/package/qt5/qt5base/Config.in
@@ -27,10 +27,6 @@ config BR2_PACKAGE_QT5BASE_CUSTOM_CONF_OPTS
 	  E.g. to remove the Windows Vista style option, add the option
 	  -no-feature-style_windowsvista.
 
-config BR2_PACKAGE_QT5BASE_LICENSE_APPROVED
-	bool
-	default y
-
 config BR2_PACKAGE_QT5BASE_CONFIG_FILE
 	string "Config file"
 	help
-- 
2.11.0

^ permalink raw reply related

* [Buildroot] [PATCH 28/29] package/qt: drop option for license approved
From: Yann E. MORIN @ 2017-04-23 20:31 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <cover.1492979449.git.yann.morin.1998@free.fr>

As stated in previous commits, Buildroot only ever uses the free
license, and we do not have a click-wrap approval for any such free
license for any other package.

The option to approve the license now has no prompt and is no longer
used anywhere. Drop it and make it a legacy entry.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Julien Corjon <corjon.j@ecagroup.com>
Cc: Peter Seiderer <ps.report@gmx.net>
---
 Config.in.legacy     | 6 ++++++
 package/qt/Config.in | 4 ----
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/Config.in.legacy b/Config.in.legacy
index 8e9f3d175d..52cda9808e 100644
--- a/Config.in.legacy
+++ b/Config.in.legacy
@@ -145,6 +145,12 @@ endif
 ###############################################################################
 comment "Legacy options removed in 2017.05"
 
+config BR2_PACKAGE_QT_LICENSE_APPROVED
+	bool "Qt free license now always approved"
+	select BR2_LEGACY
+	help
+	  Use of Qt in Buildroot now always use the free license of Qt.
+
 config BR2_PACKAGE_PORTMAP
 	bool "portmap has been removed"
 	select BR2_LEGACY
diff --git a/package/qt/Config.in b/package/qt/Config.in
index 5f07bd22f9..d3a01da87f 100644
--- a/package/qt/Config.in
+++ b/package/qt/Config.in
@@ -99,10 +99,6 @@ config BR2_PACKAGE_QT_STATIC
 
 endchoice
 
-config BR2_PACKAGE_QT_LICENSE_APPROVED
-	bool
-	default y
-
 config BR2_PACKAGE_QT_CONFIG_FILE
 	string "Config file"
 	help
-- 
2.11.0

^ permalink raw reply related

* [Buildroot] [PATCH 27/29] configs: drop Qt/Qt5 license approval option
From: Yann E. MORIN @ 2017-04-23 20:31 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <cover.1492979449.git.yann.morin.1998@free.fr>

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 configs/beaglebone_qt5_defconfig      | 1 -
 configs/firefly_rk3288_demo_defconfig | 1 -
 2 files changed, 2 deletions(-)

diff --git a/configs/beaglebone_qt5_defconfig b/configs/beaglebone_qt5_defconfig
index cdf8b96c15..b65ca40ec4 100644
--- a/configs/beaglebone_qt5_defconfig
+++ b/configs/beaglebone_qt5_defconfig
@@ -17,7 +17,6 @@ BR2_LINUX_KERNEL_DTS_SUPPORT=y
 BR2_LINUX_KERNEL_INTREE_DTS_NAME="am335x-evm am335x-bone am335x-boneblack am335x-bonegreen am335x-evmsk"
 BR2_PACKAGE_FBV=y
 BR2_PACKAGE_QT5=y
-BR2_PACKAGE_QT5BASE_LICENSE_APPROVED=y
 BR2_PACKAGE_QT5BASE_EXAMPLES=y
 BR2_PACKAGE_QT5BASE_EGLFS=y
 BR2_PACKAGE_QT5QUICKCONTROLS=y
diff --git a/configs/firefly_rk3288_demo_defconfig b/configs/firefly_rk3288_demo_defconfig
index c2de701934..0f4dd368c4 100644
--- a/configs/firefly_rk3288_demo_defconfig
+++ b/configs/firefly_rk3288_demo_defconfig
@@ -19,7 +19,6 @@ BR2_LINUX_KERNEL_DTS_SUPPORT=y
 BR2_LINUX_KERNEL_INTREE_DTS_NAME="rk3288-firefly"
 BR2_LINUX_KERNEL_INSTALL_TARGET=y
 BR2_PACKAGE_QT5=y
-BR2_PACKAGE_QT5BASE_LICENSE_APPROVED=y
 BR2_PACKAGE_QT5BASE_EXAMPLES=y
 BR2_PACKAGE_QT5BASE_GUI=y
 BR2_PACKAGE_QT5BASE_EGLFS=y
-- 
2.11.0

^ permalink raw reply related

* [Buildroot] [PATCH 26/29] package/qt5xmlpatterns: always use the opensource license
From: Yann E. MORIN @ 2017-04-23 20:31 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <cover.1492979449.git.yann.morin.1998@free.fr>

We never ask the user to confirm their assent about the use of a free
license; there is no reason we do so for Qt.

The output of legal-info is there to gather all the licenses used in a
build; the license for qt5xmlpatterns will be there to be consulted as
well.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Julien Corjon <corjon.j@ecagroup.com>
Cc: Peter Seiderer <ps.report@gmx.net>
---
 package/qt5/qt5xmlpatterns/qt5xmlpatterns.mk | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/package/qt5/qt5xmlpatterns/qt5xmlpatterns.mk b/package/qt5/qt5xmlpatterns/qt5xmlpatterns.mk
index 123e1abf1a..fabca21261 100644
--- a/package/qt5/qt5xmlpatterns/qt5xmlpatterns.mk
+++ b/package/qt5/qt5xmlpatterns/qt5xmlpatterns.mk
@@ -10,7 +10,6 @@ QT5XMLPATTERNS_SOURCE = qtxmlpatterns-opensource-src-$(QT5XMLPATTERNS_VERSION).t
 QT5XMLPATTERNS_DEPENDENCIES = qt5base
 QT5XMLPATTERNS_INSTALL_STAGING = YES
 
-ifeq ($(BR2_PACKAGE_QT5BASE_LICENSE_APPROVED),y)
 ifeq ($(BR2_PACKAGE_QT5_VERSION_LATEST),y)
 QT5XMLPATTERNS_LICENSE = GPL-2.0+ or LGPL-3.0, GPL-3.0 with exception(tools), GFDL-1.3 (docs)
 QT5XMLPATTERNS_LICENSE_FILES = LICENSE.GPL2 LICENSE.GPLv3 LICENSE.GPL3-EXCEPT LICENSE.LGPLv3 LICENSE.FDL
@@ -21,10 +20,6 @@ endif
 ifeq ($(BR2_PACKAGE_QT5BASE_EXAMPLES),y)
 QT5XMLPATTERNS_LICENSE := $(QT5XMLPATTERNS_LICENSE), BSD-3-Clause (examples)
 endif
-else
-QT5XMLPATTERNS_LICENSE = Commercial license
-QT5XMLPATTERNS_REDISTRIBUTE = NO
-endif
 
 define QT5XMLPATTERNS_CONFIGURE_CMDS
 	(cd $(@D); $(TARGET_MAKE_ENV) $(HOST_DIR)/usr/bin/qmake)
-- 
2.11.0

^ permalink raw reply related

* [Buildroot] [PATCH 25/29] package/qt5x11extras: always use the opensource license
From: Yann E. MORIN @ 2017-04-23 20:31 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <cover.1492979449.git.yann.morin.1998@free.fr>

We never ask the user to confirm their assent about the use of a free
license; there is no reason we do so for Qt.

The output of legal-info is there to gather all the licenses used in a
build; the license for qt5x11extras will be there to be consulted as
well.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Julien Corjon <corjon.j@ecagroup.com>
Cc: Peter Seiderer <ps.report@gmx.net>
---
 package/qt5/qt5x11extras/qt5x11extras.mk | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/package/qt5/qt5x11extras/qt5x11extras.mk b/package/qt5/qt5x11extras/qt5x11extras.mk
index 7dc371cbac..00667c72f3 100644
--- a/package/qt5/qt5x11extras/qt5x11extras.mk
+++ b/package/qt5/qt5x11extras/qt5x11extras.mk
@@ -10,7 +10,6 @@ QT5X11EXTRAS_SOURCE = qtx11extras-opensource-src-$(QT5X11EXTRAS_VERSION).tar.xz
 QT5X11EXTRAS_DEPENDENCIES = qt5base
 QT5X11EXTRAS_INSTALL_STAGING = YES
 
-ifeq ($(BR2_PACKAGE_QT5BASE_LICENSE_APPROVED),y)
 ifeq ($(BR2_PACKAGE_QT5_VERSION_LATEST),y)
 QT5X11EXTRAS_LICENSE = GPL-2.0+ or LGPL-3.0, GPL-3.0 with exception(tools), GFDL-1.3 (docs)
 QT5X11EXTRAS_LICENSE_FILES = LICENSE.GPLv2 LICENSE.GPLv3 LICENSE.GPL3-EXCEPT LICENSE.LGPLv3 LICENSE.FDL
@@ -18,10 +17,6 @@ else
 QT5X11EXTRAS_LICENSE = GPL-2.0 or GPL-3.0 or LGPL-2.1 with exception or LGPL-3.0, GFDL-1.3 (docs)
 QT5X11EXTRAS_LICENSE_FILES = LICENSE.GPLv2 LICENSE.GPLv3 LICENSE.LGPLv21 LGPL_EXCEPTION.txt LICENSE.LGPLv3 LICENSE.FDL
 endif
-else
-QT5X11EXTRAS_LICENSE = Commercial license
-QT5X11EXTRAS_REDISTRIBUTE = NO
-endif
 
 define QT5X11EXTRAS_CONFIGURE_CMDS
 	(cd $(@D); $(TARGET_MAKE_ENV) $(HOST_DIR)/usr/bin/qmake)
-- 
2.11.0

^ permalink raw reply related

* [Buildroot] [PATCH 24/29] package/qt5websockets: always use the opensource license
From: Yann E. MORIN @ 2017-04-23 20:31 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <cover.1492979449.git.yann.morin.1998@free.fr>

We never ask the user to confirm their assent about the use of a free
license; there is no reason we do so for Qt.

The output of legal-info is there to gather all the licenses used in a
build; the license for qt5websockets will be there to be consulted as
well.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Julien Corjon <corjon.j@ecagroup.com>
Cc: Peter Seiderer <ps.report@gmx.net>
---
 package/qt5/qt5websockets/qt5websockets.mk | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/package/qt5/qt5websockets/qt5websockets.mk b/package/qt5/qt5websockets/qt5websockets.mk
index bcbc56f1c7..af87435d6d 100644
--- a/package/qt5/qt5websockets/qt5websockets.mk
+++ b/package/qt5/qt5websockets/qt5websockets.mk
@@ -10,7 +10,6 @@ QT5WEBSOCKETS_SOURCE = qtwebsockets-opensource-src-$(QT5WEBSOCKETS_VERSION).tar.
 QT5WEBSOCKETS_DEPENDENCIES = qt5base
 QT5WEBSOCKETS_INSTALL_STAGING = YES
 
-ifeq ($(BR2_PACKAGE_QT5BASE_LICENSE_APPROVED),y)
 ifeq ($(BR2_PACKAGE_QT5_VERSION_LATEST),y)
 QT5WEBSOCKETS_LICENSE = GPL-2.0+ or LGPL-3.0, GPL-3.0 with exception(tools)
 QT5WEBSOCKETS_LICENSE_FILES = LICENSE.GPL2 LICENSE.GPLv3 LICENSE.GPL3-EXCEPT LICENSE.LGPLv3
@@ -21,10 +20,6 @@ endif
 ifeq ($(BR2_PACKAGE_QT5BASE_EXAMPLES),y)
 QT5WEBSOCKETS_LICENSE := $(QT5WEBSOCKETS_LICENSE), BSD-3-Clause (examples)
 endif
-else
-QT5WEBSOCKETS_LICENSE = Commercial license
-QT5WEBSOCKETS_REDISTRIBUTE = NO
-endif
 
 ifeq ($(BR2_PACKAGE_QT5DECLARATIVE),y)
 QT5WEBSOCKETS_DEPENDENCIES += qt5declarative
-- 
2.11.0

^ permalink raw reply related


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