[Buildroot] Buildroot defconfig issues

[Buildroot] Buildroot defconfig issues

[Thomas Petazzoni]

Hello,

On Fri, 12 Feb 2021 02:31:24 +0000
GitLab <gitlab@mg.gitlab.com> wrote:

> Pipeline #254673538 ( https://gitlab.com/buildroot.org/buildroot/-/pipelines/254673538 ) triggered by Thomas Petazzoni ( https://gitlab.com/tpetazzoni )
> had 4 failed builds.
> 
> Job #1023448804 ( https://gitlab.com/buildroot.org/buildroot/-/jobs/1023448804/raw )
> 
> Stage: test
> Name: raspberrypi3_qt5we_defconfig

So this is the infamous pkg-config/qt5webengine issue that Peter
Seiderer tried to fix in
https://patchwork.ozlabs.org/project/buildroot/patch/20201221203952.22168-3-ps.report at gmx.net/
but that I didn't like much.

But perhaps what we have at:

  https://patchwork.ozlabs.org/project/buildroot/patch/20191205171517.96639-3-michael.drake at codethink.co.uk/
  https://patchwork.ozlabs.org/project/buildroot/patch/20191205171517.96639-4-michael.drake at codethink.co.uk/

is a better solution for the problem ?

> Job #1023446723 ( https://gitlab.com/buildroot.org/buildroot/-/jobs/1023446723/raw )
> 
> Stage: test
> Name: kontron_smarc_sal28_defconfig

ModuleNotFoundError: No module named 'pkg_resources'

when building U-Boot. I think a patch was posted not long ago about
this. Yes, there:
https://patchwork.ozlabs.org/project/buildroot/patch/20210115170156.917086-1-francois.perrad at gadz.org/

Not sure if we should have another BR2_TARGET_UBOOT_NEEDS_PYsomething
option ?

> Job #1023447067 ( https://gitlab.com/buildroot.org/buildroot/-/jobs/1023447067/raw )
> 
> Stage: test
> Name: microchip_sam9x60ek_mmc_dev_defconfig

WARN: defconfig ./configs/microchip_sam9x60ek_mmc_dev_defconfig can't be used:
      Missing: BR2_PACKAGE_GZIP=y
      Missing: BR2_PACKAGE_GDB=y
      Missing: BR2_PACKAGE_DOSFSTOOLS=y
      Missing: BR2_PACKAGE_DOSFSTOOLS_FATLABEL=y
      Missing: BR2_PACKAGE_DOSFSTOOLS_FSCK_FAT=y
      Missing: BR2_PACKAGE_DOSFSTOOLS_MKFS_FAT=y
      Missing: BR2_PACKAGE_USBUTILS=y
      Missing: BR2_PACKAGE_BLUEZ5_UTILS=y
      Missing: BR2_PACKAGE_IPERF=y
      Missing: BR2_PACKAGE_WGET=y
      Missing: BR2_PACKAGE_VIM=y

I guess this is due to BR2_USE_WCHAR=y being missing in the defconfig.

> Job #1022937103 ( https://gitlab.com/buildroot.org/buildroot/-/jobs/1022937103/raw )
> 
> Stage: test
> Name: avenger96_defconfig

Another case of host-openssl needed:

scripts/extract-cert.c:21:25: fatal error: openssl/bio.h: No such file or directory
 #include <openssl/bio.h>

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] Buildroot defconfig issues

[Arnout Vandecappelle]

On 12/02/2021 09:13, Thomas Petazzoni wrote:
[snip]
>> Job #1023447067 ( https://gitlab.com/buildroot.org/buildroot/-/jobs/1023447067/raw )
>>
>> Stage: test
>> Name: microchip_sam9x60ek_mmc_dev_defconfig
> 
> WARN: defconfig ./configs/microchip_sam9x60ek_mmc_dev_defconfig can't be used:
>       Missing: BR2_PACKAGE_GZIP=y
>       Missing: BR2_PACKAGE_GDB=y
>       Missing: BR2_PACKAGE_DOSFSTOOLS=y
>       Missing: BR2_PACKAGE_DOSFSTOOLS_FATLABEL=y
>       Missing: BR2_PACKAGE_DOSFSTOOLS_FSCK_FAT=y
>       Missing: BR2_PACKAGE_DOSFSTOOLS_MKFS_FAT=y
>       Missing: BR2_PACKAGE_USBUTILS=y
>       Missing: BR2_PACKAGE_BLUEZ5_UTILS=y
>       Missing: BR2_PACKAGE_IPERF=y
>       Missing: BR2_PACKAGE_WGET=y
>       Missing: BR2_PACKAGE_VIM=y
> 
> I guess this is due to BR2_USE_WCHAR=y being missing in the defconfig.

 I propose to just remove this defconfig. We're not really happy with those
non-minimal defconfigs, right. I think it only makes sense to keep something
like that if there really is something board-specific in there, which is not the
case here I think.

 Regards,
 Arnout

[Buildroot] Buildroot defconfig issues

[Thomas Petazzoni]

Hello,

On Fri, 12 Feb 2021 09:17:53 +0100
Arnout Vandecappelle <arnout@mind.be> wrote:

>  I propose to just remove this defconfig. We're not really happy with those
> non-minimal defconfigs, right. I think it only makes sense to keep something
> like that if there really is something board-specific in there, which is not the
> case here I think.

Well, we've got several of these "development" defconfigs for
Atmel/Microchip platforms:

at91sam9x5ek_dev_defconfig
at91sam9x5ek_mmc_dev_defconfig
atmel_sama5d27_som1_ek_mmc_dev_defconfig
atmel_sama5d2_xplained_mmc_dev_defconfig
atmel_sama5d3_xplained_dev_defconfig
atmel_sama5d3_xplained_mmc_dev_defconfig
atmel_sama5d4_xplained_dev_defconfig
atmel_sama5d4_xplained_mmc_dev_defconfig
microchip_sam9x60ek_mmc_dev_defconfig
microchip_sama5d27_wlsom1_ek_mmc_dev_defconfig

There was quite some debate back then on whether we wanted them or not
in upstream Buildroot. Microchip has its own BR2_EXTERNAL layer at
https://github.com/linux4sam/buildroot-external-microchip with a bunch
of other defconfigs.

But Arnout, I thought you were inclined to having "demo" defconfigs in
Buildroot upstream. Have you changed your mind ?

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] Buildroot defconfig issues

[Arnout Vandecappelle]

On 12/02/2021 09:24, Thomas Petazzoni wrote:
> Hello,
> 
> On Fri, 12 Feb 2021 09:17:53 +0100
> Arnout Vandecappelle <arnout@mind.be> wrote:
> 
>>  I propose to just remove this defconfig. We're not really happy with those
>> non-minimal defconfigs, right. I think it only makes sense to keep something
>> like that if there really is something board-specific in there, which is not the
>> case here I think.
> 
> Well, we've got several of these "development" defconfigs for
> Atmel/Microchip platforms:
> 
> at91sam9x5ek_dev_defconfig
> at91sam9x5ek_mmc_dev_defconfig
> atmel_sama5d27_som1_ek_mmc_dev_defconfig
> atmel_sama5d2_xplained_mmc_dev_defconfig
> atmel_sama5d3_xplained_dev_defconfig
> atmel_sama5d3_xplained_mmc_dev_defconfig
> atmel_sama5d4_xplained_dev_defconfig
> atmel_sama5d4_xplained_mmc_dev_defconfig
> microchip_sam9x60ek_mmc_dev_defconfig
> microchip_sama5d27_wlsom1_ek_mmc_dev_defconfig
> 
> There was quite some debate back then on whether we wanted them or not
> in upstream Buildroot. Microchip has its own BR2_EXTERNAL layer at
> https://github.com/linux4sam/buildroot-external-microchip with a bunch
> of other defconfigs.
> 
> But Arnout, I thought you were inclined to having "demo" defconfigs in
> Buildroot upstream. Have you changed your mind ?

"demo", yes. Like qt5we. It's good to have one defconfig which adds qt5we
because otherwise that package hardly ever gets tested (it has so many
dependencies that it's very unlikely to get built in the autobuilders). Also the
other _qt5_ configs make sense, because it can be quite hard to select the
correct graphical stuff for a specific board - the qt5 part is not really
needed, but it's a nice way of showing something actually working rather than
simply building.

 But the _dev_ things simply select a bunch of packages that are useful for
development. It's not at all necessarily the set of tools that any particular
developer will actually use, and it's not very helpful for testing some specific
package, and there's nothing specific for that platform in it.

 It's possible that I'm a bit changing my mind here, because I didn't realize
that last bit before. And for sure: if such a config is giving us pain (e.g., it
doesn't build :-) then rather than spend time on investigating, I'd want to just
remove it!

 Regards,
 Arnout

[Buildroot] Buildroot defconfig issues

[Thomas Petazzoni]

On Fri, 12 Feb 2021 10:41:26 +0100
Arnout Vandecappelle <arnout@mind.be> wrote:

> > But Arnout, I thought you were inclined to having "demo" defconfigs in
> > Buildroot upstream. Have you changed your mind ?  
> 
> "demo", yes. Like qt5we. It's good to have one defconfig which adds qt5we
> because otherwise that package hardly ever gets tested (it has so many
> dependencies that it's very unlikely to get built in the autobuilders). Also the
> other _qt5_ configs make sense, because it can be quite hard to select the
> correct graphical stuff for a specific board - the qt5 part is not really
> needed, but it's a nice way of showing something actually working rather than
> simply building.
> 
>  But the _dev_ things simply select a bunch of packages that are useful for
> development. It's not at all necessarily the set of tools that any particular
> developer will actually use, and it's not very helpful for testing some specific
> package, and there's nothing specific for that platform in it.
> 
>  It's possible that I'm a bit changing my mind here, because I didn't realize
> that last bit before. And for sure: if such a config is giving us pain (e.g., it
> doesn't build :-) then rather than spend time on investigating, I'd want to just
> remove it!

I agree that these "dev" defconfigs simply have a somewhat "random"
selection of tools that are not aimed at providing any particular demo.
So I'm fine with the choice of dropping them.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] Buildroot defconfig issues

[Ludovic.Desroches at microchip.com]

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

On Fri, 12 Feb 2021 10:41:26 +0100
Arnout Vandecappelle <arnout@mind.be> wrote:

> > But Arnout, I thought you were inclined to having "demo" defconfigs in
> > Buildroot upstream. Have you changed your mind ?
>
> "demo", yes. Like qt5we. It's good to have one defconfig which adds qt5we
> because otherwise that package hardly ever gets tested (it has so many
> dependencies that it's very unlikely to get built in the autobuilders). Also the
> other _qt5_ configs make sense, because it can be quite hard to select the
> correct graphical stuff for a specific board - the qt5 part is not really
> needed, but it's a nice way of showing something actually working rather than
> simply building.
>
>  But the _dev_ things simply select a bunch of packages that are useful for
> development. It's not at all necessarily the set of tools that any particular
> developer will actually use, and it's not very helpful for testing some specific
> package, and there's nothing specific for that platform in it.
>
>  It's possible that I'm a bit changing my mind here, because I didn't realize
> that last bit before. And for sure: if such a config is giving us pain (e.g., it
> doesn't build :-) then rather than spend time on investigating, I'd want to just
> remove it!

I agree that these "dev" defconfigs simply have a somewhat "random"
selection of tools that are not aimed at providing any particular demo.
So I'm fine with the choice of dropping them.

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] Buildroot defconfig issues

[Ludovic.Desroches at microchip.com]

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

On 12/02/2021 09:24, Thomas Petazzoni wrote:
> Hello,
>
> On Fri, 12 Feb 2021 09:17:53 +0100
> Arnout Vandecappelle <arnout@mind.be> wrote:
>
>>  I propose to just remove this defconfig. We're not really happy with those
>> non-minimal defconfigs, right. I think it only makes sense to keep something
>> like that if there really is something board-specific in there, which is not the
>> case here I think.
>
> Well, we've got several of these "development" defconfigs for
> Atmel/Microchip platforms:
>
> at91sam9x5ek_dev_defconfig
> at91sam9x5ek_mmc_dev_defconfig
> atmel_sama5d27_som1_ek_mmc_dev_defconfig
> atmel_sama5d2_xplained_mmc_dev_defconfig
> atmel_sama5d3_xplained_dev_defconfig
> atmel_sama5d3_xplained_mmc_dev_defconfig
> atmel_sama5d4_xplained_dev_defconfig
> atmel_sama5d4_xplained_mmc_dev_defconfig
> microchip_sam9x60ek_mmc_dev_defconfig
> microchip_sama5d27_wlsom1_ek_mmc_dev_defconfig
>
> There was quite some debate back then on whether we wanted them or not
> in upstream Buildroot. Microchip has its own BR2_EXTERNAL layer at
> https://github.com/linux4sam/buildroot-external-microchip with a bunch
> of other defconfigs.
>
> But Arnout, I thought you were inclined to having "demo" defconfigs in
> Buildroot upstream. Have you changed your mind ?

"demo", yes. Like qt5we. It's good to have one defconfig which adds qt5we
because otherwise that package hardly ever gets tested (it has so many
dependencies that it's very unlikely to get built in the autobuilders). Also the
other _qt5_ configs make sense, because it can be quite hard to select the
correct graphical stuff for a specific board - the qt5 part is not really
needed, but it's a nice way of showing something actually working rather than
simply building.

 But the _dev_ things simply select a bunch of packages that are useful for
development. It's not at all necessarily the set of tools that any particular
developer will actually use, and it's not very helpful for testing some specific
package, and there's nothing specific for that platform in it.

 It's possible that I'm a bit changing my mind here, because I didn't realize
that last bit before. And for sure: if such a config is giving us pain (e.g., it
doesn't build :-) then rather than spend time on investigating, I'd want to just
remove it!

 Regards,
 Arnout

[Buildroot] Buildroot defconfig issues

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:

Hi,

 > Hello,
 > On Fri, 12 Feb 2021 02:31:24 +0000
 > GitLab <gitlab@mg.gitlab.com> wrote:

 >> Pipeline #254673538 (
 >> https://gitlab.com/buildroot.org/buildroot/-/pipelines/254673538 )
 >> triggered by Thomas Petazzoni ( https://gitlab.com/tpetazzoni )
 >> had 4 failed builds.
 >> 
 >> Job #1023448804 ( https://gitlab.com/buildroot.org/buildroot/-/jobs/1023448804/raw )
 >> 
 >> Stage: test
 >> Name: raspberrypi3_qt5we_defconfig

 > So this is the infamous pkg-config/qt5webengine issue that Peter
 > Seiderer tried to fix in
 > https://patchwork.ozlabs.org/project/buildroot/patch/20201221203952.22168-3-ps.report at gmx.net/
 > but that I didn't like much.

 > But perhaps what we have at:

 >   https://patchwork.ozlabs.org/project/buildroot/patch/20191205171517.96639-3-michael.drake at codethink.co.uk/
 >   https://patchwork.ozlabs.org/project/buildroot/patch/20191205171517.96639-4-michael.drake at codethink.co.uk/

 > is a better solution for the problem ?

Sorry, don't know.


 >> Job #1023446723 ( https://gitlab.com/buildroot.org/buildroot/-/jobs/1023446723/raw )
 >> 
 >> Stage: test
 >> Name: kontron_smarc_sal28_defconfig

 > ModuleNotFoundError: No module named 'pkg_resources'

 > when building U-Boot. I think a patch was posted not long ago about
 > this. Yes, there:
 > https://patchwork.ozlabs.org/project/buildroot/patch/20210115170156.917086-1-francois.perrad at gadz.org/

It is certainly a simple/pragmatic solution, and "building" setuptools
is very fast.


 >> Job #1023447067 ( https://gitlab.com/buildroot.org/buildroot/-/jobs/1023447067/raw )
 >> 
 >> Stage: test
 >> Name: microchip_sam9x60ek_mmc_dev_defconfig

 > WARN: defconfig ./configs/microchip_sam9x60ek_mmc_dev_defconfig can't be used:
 >       Missing: BR2_PACKAGE_GZIP=y
 >       Missing: BR2_PACKAGE_GDB=y
 >       Missing: BR2_PACKAGE_DOSFSTOOLS=y
 >       Missing: BR2_PACKAGE_DOSFSTOOLS_FATLABEL=y
 >       Missing: BR2_PACKAGE_DOSFSTOOLS_FSCK_FAT=y
 >       Missing: BR2_PACKAGE_DOSFSTOOLS_MKFS_FAT=y
 >       Missing: BR2_PACKAGE_USBUTILS=y
 >       Missing: BR2_PACKAGE_BLUEZ5_UTILS=y
 >       Missing: BR2_PACKAGE_IPERF=y
 >       Missing: BR2_PACKAGE_WGET=y
 >       Missing: BR2_PACKAGE_VIM=y

 > I guess this is due to BR2_USE_WCHAR=y being missing in the defconfig.

Yes, I think so too.


 >> Job #1022937103 ( https://gitlab.com/buildroot.org/buildroot/-/jobs/1022937103/raw )
 >> 
 >> Stage: test
 >> Name: avenger96_defconfig

 > Another case of host-openssl needed:

 > scripts/extract-cert.c:21:25: fatal error: openssl/bio.h: No such file or directory
 >  #include <openssl/bio.h>

I've already fixed that.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot defconfig issues

[Peter Seiderer]

Hello *,

On Fri, 12 Feb 2021 09:43:31 +0100, Peter Korsgaard <peter@korsgaard.com> wrote:

> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:
>
> Hi,
>
>  > Hello,
>  > On Fri, 12 Feb 2021 02:31:24 +0000
>  > GitLab <gitlab@mg.gitlab.com> wrote:
>
>  >> Pipeline #254673538 (
>  >> https://gitlab.com/buildroot.org/buildroot/-/pipelines/254673538 )
>  >> triggered by Thomas Petazzoni ( https://gitlab.com/tpetazzoni )
>  >> had 4 failed builds.
>  >>
>  >> Job #1023448804 ( https://gitlab.com/buildroot.org/buildroot/-/jobs/1023448804/raw )
>  >>
>  >> Stage: test
>  >> Name: raspberrypi3_qt5we_defconfig
>
>  > So this is the infamous pkg-config/qt5webengine issue that Peter
>  > Seiderer tried to fix in
>  > https://patchwork.ozlabs.org/project/buildroot/patch/20201221203952.22168-3-ps.report at gmx.net/
>  > but that I didn't like much.
>
>  > But perhaps what we have at:
>
>  >   https://patchwork.ozlabs.org/project/buildroot/patch/20191205171517.96639-3-michael.drake at codethink.co.uk/
>  >   https://patchwork.ozlabs.org/project/buildroot/patch/20191205171517.96639-4-michael.drake at codethink.co.uk/
>
>  > is a better solution for the problem ?
>
> Sorry, don't know.
>

Nope, using using pkgconf-personality does not fix the problem..., I believe
the qt5webengine GN build system is really just (false) requesting the host
versions of enabled qt5 target features, but did not find out where or
how to fix it...., other as by applying the one or the other hack ;-)

Regards,
Peter