1. yocto@lists.yoctoproject.org
  2. Messages
   Date   
Re: [meta-raspberrypi] Problem with RPI_USE_U_BOOT with RaspberryPi4

Jean-Philippe Lebel
 

Thanks Matthias for your input.

I have the same problem using the raspberrypi4-64 target. On my end, the mere fact of enabling RPI_USE_U_BOOT yields a non-bootable image.

The image I generated/burned can be found here:

Thanks a lot.

-------------
Jean-Philippe Lebel, ing. MBA
jp@...
http://www.lebel.pro
cell: 418-931-3800

AVIS IMPORTANT: Ce courriel est strictement réservé à l'usage de la (des) personne(s) à qui il est adressé et peut contenir de l'information privilégiée et confidentielle. Toute divulgation, distribution, copie, ou autre utilisation de ce courriel par une autre personne est strictement prohibée. Si vous avez reçu ce courriel par erreur, veuillez s'il vous plaît communiquer immédiatement avec l'expéditeur et détruire le courriel sans en faire de copie sous quelque forme.

WARNING: This e-mail contains confidential information intended only for the person(s) named above. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution, or any other use of this e-mail is strictly prohibited. If you have received this e-mail by mistake, please notify us immediately and destroy this e-mail without making any copy of any kind.


On Wed, Jan 12, 2022 at 3:59 AM Matthias Klein <matthias.klein@...> wrote:

Hello Jean-Philippe,

 

>I'm trying to create a simple image that uses the RPI_USE_U_BOOT option but the pi hangs with the rainbow image. I'm able to generate bootable images when not using the RPI_USE_U_BOOT option (but I need to use swupdate).

>I have the same problem with using the Hardknott branch, leading me to think the problem is not the layer but the way I use it.

For me the combination of raspberrypi4-64 machine, U-Boot and RAUC (instead of swupdate) works.

I think the raspberrypi4 should also work (but haven't tested it).

 

I built and tested my (Poky master branch based) image this morning: https://github.com/matthiasklein/meta-yocto-coffee-rpi

 

I don't use HDMI output though, but a serial console (ENABLE_UART = "1").

 

Best regards,

Matthias

 
Re: [meta-raspberrypi][PATCH] Use protocol=https for all github SRC_URIs

Andrei Gherzan
 

Hi,

On Wed, 12 Jan 2022, at 11:15, Janne Kiiskila wrote:
Hei,

would not the "easier" approach be to change the bitbake tooling to use https as the default git fetching protocol, rather than modify every single recipe in the world?
Not really. Because this is a GitLab specific behaviour. Changing the default to https would change the general assumptions everyone has in their layers.

Andrei
Re: [meta-raspberrypi][PATCH] Use protocol=https for all github SRC_URIs

Janne Kiiskila <janne.kiiskila@...>
 

Hei,

would not the "easier" approach be to change the bitbake tooling to use https as the default git fetching protocol, rather than modify every single recipe in the world?

Best Regards,


Janne Kiiskilä
Re: [meta-raspberrypi] Problem with RPI_USE_U_BOOT with RaspberryPi4

Matthias Klein
 

Hello Jean-Philippe,

 

>I'm trying to create a simple image that uses the RPI_USE_U_BOOT option but the pi hangs with the rainbow image. I'm able to generate bootable images when not using the RPI_USE_U_BOOT option (but I need to use swupdate).

>I have the same problem with using the Hardknott branch, leading me to think the problem is not the layer but the way I use it.

For me the combination of raspberrypi4-64 machine, U-Boot and RAUC (instead of swupdate) works.

I think the raspberrypi4 should also work (but haven't tested it).

 

I built and tested my (Poky master branch based) image this morning: https://github.com/matthiasklein/meta-yocto-coffee-rpi

 

I don't use HDMI output though, but a serial console (ENABLE_UART = "1").

 

Best regards,

Matthias

 
[meta-raspberrypi] Problem with RPI_USE_U_BOOT with RaspberryPi4

Jean-Philippe Lebel
 

Hello,

I'm trying to create a simple image that uses the RPI_USE_U_BOOT option but the pi hangs with the rainbow image. I'm able to generate bootable images when not using the RPI_USE_U_BOOT option (but I need to use swupdate). I have the same problem with using the Hardknott branch, leading me to think the problem is not the layer but the way I use it.

For my last test, I used the latest meta-raspberrypi without any modification. In other words, I'm using the default/basic configuration.

the default local.conf file has been edited to add the following two lines at the end
MACHINE = 'raspberrypi4'
RPI_USE_U_BOOT = "1"

I'm building the image using
> bitbake core-image-base

And I'm burning the generated .wic image to my sd card.

What am I missing? Is there any other configuration I must do?

Thanks
 
 
Reproducible build website broken (CORS setting on git.yoctoproject.org?)

Joshua Watt
 

Michael,

I noticed that the
https://www.yoctoproject.org/reproducible-build-results/ website went
down (it always shows "Error fetching test results"). I did a little
debugging and I think that the CORS setting on git.yoctoproject.org is
not allowing www.yoctoproject.org to request the data anymore. I
thought we had fixed this at one point in the past and maybe it got
lost somewhere along the way?

If that's something we can fix, that would be great, otherwise we
might need to look into another solution for fetching the
reproducibility data.

Thanks,
Joshua Watt
Re: [docs] [yocto] How to unpack a .tgz archive in a .zip file?

Michael Opdenacker
 

Hi Quentin,

Thanks for the advice!

On 1/11/22 7:46 PM, Quentin Schulz wrote:
Hi Michael,

On January 11, 2022 11:38:06 AM GMT+01:00, Michael Opdenacker <michael.opdenacker@...> wrote:
Hello

I'm working on adding the wiki guidelines for dealing with pre-compiled
libraries
(https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries#Versioned_Libraries)
into the main documentation.

I'm trying to test the example recipe, but the latest pre-compiled
versions of libft4422.so are now available in
https://ftdichip.com/wp-content/uploads/2021/01/libft4222-linux-1.4.4.44.zip,
which actually contains a .tgz file!

I know that's absurd, but how would you handle this case? Through a
custom "do_unpack" task in the recipe?
IMO that makes it unsuitable for the docs as we strive to have "simple" examples and having some custom unpack task seems a bit too much to me. Anyway, just my 2¢ and I don't have any other prebuilt lib to suggest as replacement right now.

Right, I was thinking of leaving this aside, and just working with a
local archive instead, as fetching the files is not the primary concern
here.


Back to the topic:
I think you could have an :append for do_unpack and probably call oe_unpack ( https://github.com/openembedded/openembedded/blob/fabd8e6d07d3cd0cc93c2a0fc804f8c8f316c649/classes/base.bbclass#L158) on this specific file (after it's been unzipped), or even call unpack_file from the OE libs directly ( https://github.com/openembedded/openembedded/blob/fabd8e6d07d3cd0cc93c2a0fc804f8c8f316c649/lib/oe/unpack.py#L50) like oe_unpack is doing. Be aware though that since it is a Python task, your :append shall be Python code too.

Maybe there's another way but I don't see it right now.

Many thanks. It's good to have this idea at least documented in the
mailing list archives. That's good for my own understanding too. I
didn't think about appends.
Thanks again
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: How to unpack a .tgz archive in a .zip file?

Quentin Schulz
 

Hi Michael,

On January 11, 2022 11:38:06 AM GMT+01:00, Michael Opdenacker <michael.opdenacker@...> wrote:
Hello

I'm working on adding the wiki guidelines for dealing with pre-compiled
libraries
(https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries#Versioned_Libraries)
into the main documentation.

I'm trying to test the example recipe, but the latest pre-compiled
versions of libft4422.so are now available in
https://ftdichip.com/wp-content/uploads/2021/01/libft4222-linux-1.4.4.44.zip,
which actually contains a .tgz file!

I know that's absurd, but how would you handle this case? Through a
custom "do_unpack" task in the recipe?
IMO that makes it unsuitable for the docs as we strive to have "simple" examples and having some custom unpack task seems a bit too much to me. Anyway, just my 2¢ and I don't have any other prebuilt lib to suggest as replacement right now.

Back to the topic:
I think you could have an :append for do_unpack and probably call oe_unpack ( https://github.com/openembedded/openembedded/blob/fabd8e6d07d3cd0cc93c2a0fc804f8c8f316c649/classes/base.bbclass#L158) on this specific file (after it's been unzipped), or even call unpack_file from the OE libs directly ( https://github.com/openembedded/openembedded/blob/fabd8e6d07d3cd0cc93c2a0fc804f8c8f316c649/lib/oe/unpack.py#L50) like oe_unpack is doing. Be aware though that since it is a Python task, your :append shall be Python code too.

Maybe there's another way but I don't see it right now.

Cheers,
Quentin

Thanks in advance for your insights...
Cheers
Michael.
[PATCH 3/3] poky: set default kernel to 5.15

Bruce Ashfield
 

From: Bruce Ashfield <bruce.ashfield@...>

5.14 is no longer actively maintained, so we bump our default
to the 5.15 LTS.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
meta-poky/conf/distro/poky-tiny.conf | 2 +-
meta-poky/conf/distro/poky.conf | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta-poky/conf/distro/poky-tiny.conf b/meta-poky/conf/distro/poky-tiny.conf
index 756c65a2f9..b6c4eeccd0 100644
--- a/meta-poky/conf/distro/poky-tiny.conf
+++ b/meta-poky/conf/distro/poky-tiny.conf
@@ -43,7 +43,7 @@ FULL_OPTIMIZATION="-Os -pipe ${DEBUG_FLAGS}"
# Distro config is evaluated after the machine config, so we have to explicitly
# set the kernel provider to override a machine config.
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tiny"
-PREFERRED_VERSION_linux-yocto-tiny ?= "5.14%"
+PREFERRED_VERSION_linux-yocto-tiny ?= "5.15%"

# We can use packagegroup-core-boot, but in the future we may need a new packagegroup-core-tiny
#POKY_DEFAULT_EXTRA_RDEPENDS += "packagegroup-core-boot"
diff --git a/meta-poky/conf/distro/poky.conf b/meta-poky/conf/distro/poky.conf
index b92784fdc4..2dc3606ae5 100644
--- a/meta-poky/conf/distro/poky.conf
+++ b/meta-poky/conf/distro/poky.conf
@@ -19,8 +19,8 @@ POKY_DEFAULT_EXTRA_RRECOMMENDS = "kernel-module-af-packet"

DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${POKY_DEFAULT_DISTRO_FEATURES}"

-PREFERRED_VERSION_linux-yocto ?= "5.14%"
-PREFERRED_VERSION_linux-yocto-rt ?= "5.14%"
+PREFERRED_VERSION_linux-yocto ?= "5.15%"
+PREFERRED_VERSION_linux-yocto-rt ?= "5.15%"

SDK_NAME = "${DISTRO}-${TCLIBC}-${SDKMACHINE}-${IMAGE_BASENAME}-${TUNE_PKGARCH}-${MACHINE}"
SDKPATHINSTALL = "/opt/${DISTRO}/${SDK_VERSION}"
--
2.19.1
[PATCH 2/3] yocto-bsp/5.14: drop recipes

Bruce Ashfield
 

From: Bruce Ashfield <bruce.ashfield@...>

5.14 has been removed from core, so we drop our bbappend. 5.15
is now the default kernel version for the reference BSPs.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
.../linux/linux-yocto_5.14.bbappend | 23 -------------------
1 file changed, 23 deletions(-)
delete mode 100644 meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.14.bbappend

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.14.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.14.bbappend
deleted file mode 100644
index af4a7392f0..0000000000
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.14.bbappend
+++ /dev/null
@@ -1,23 +0,0 @@
-KBRANCH:genericx86 = "v5.14/standard/base"
-KBRANCH:genericx86-64 = "v5.14/standard/base"
-KBRANCH:edgerouter = "v5.14/standard/edgerouter"
-KBRANCH:beaglebone-yocto = "v5.14/standard/beaglebone"
-
-KMACHINE:genericx86 ?= "common-pc"
-KMACHINE:genericx86-64 ?= "common-pc-64"
-KMACHINE:beaglebone-yocto ?= "beaglebone"
-
-SRCREV_machine:genericx86 ?= "9d5572038eacda2e2a86e3f743f35ec415319fb4"
-SRCREV_machine:genericx86-64 ?= "9d5572038eacda2e2a86e3f743f35ec415319fb4"
-SRCREV_machine:edgerouter ?= "7ae156be3bdbf033839f7f3ec2e9a0ffffb18818"
-SRCREV_machine:beaglebone-yocto ?= "7ae156be3bdbf033839f7f3ec2e9a0ffffb18818"
-
-COMPATIBLE_MACHINE:genericx86 = "genericx86"
-COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
-COMPATIBLE_MACHINE:edgerouter = "edgerouter"
-COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto"
-
-LINUX_VERSION:genericx86 = "5.14.21"
-LINUX_VERSION:genericx86-64 = "5.14.21"
-LINUX_VERSION:edgerouter = "5.14.6"
-LINUX_VERSION:beaglebone-yocto = "5.14.6"
--
2.19.1
[PATCH 1/3] yocto-bsp: change default to 5.15

Bruce Ashfield
 

From: Bruce Ashfield <bruce.ashfield@...>

5.14 has been removed from core, so we change our default version
to the 5.15 LTS kernel.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
meta-yocto-bsp/conf/machine/beaglebone-yocto.conf | 2 +-
meta-yocto-bsp/conf/machine/edgerouter.conf | 2 +-
meta-yocto-bsp/conf/machine/include/genericx86-common.inc | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
index b3d960a8cd..a5cb16cd93 100644
--- a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
+++ b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
@@ -24,7 +24,7 @@ SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyO0 115200;ttyAMA0"
SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"

PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-PREFERRED_VERSION_linux-yocto ?= "5.14%"
+PREFERRED_VERSION_linux-yocto ?= "5.15%"

KERNEL_IMAGETYPE = "zImage"
KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb"
diff --git a/meta-yocto-bsp/conf/machine/edgerouter.conf b/meta-yocto-bsp/conf/machine/edgerouter.conf
index 32be4b9c39..249864e9ce 100644
--- a/meta-yocto-bsp/conf/machine/edgerouter.conf
+++ b/meta-yocto-bsp/conf/machine/edgerouter.conf
@@ -11,7 +11,7 @@ KERNEL_ALT_IMAGETYPE = "vmlinux.bin"
KERNEL_IMAGE_STRIP_EXTRA_SECTIONS = ".comment"

PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-PREFERRED_VERSION_linux-yocto ?= "5.14%"
+PREFERRED_VERSION_linux-yocto ?= "5.15%"

SERIAL_CONSOLES = "115200;ttyS0"
USE_VT ?= "0"
diff --git a/meta-yocto-bsp/conf/machine/include/genericx86-common.inc b/meta-yocto-bsp/conf/machine/include/genericx86-common.inc
index 4651b37e5d..8c5e5522bc 100644
--- a/meta-yocto-bsp/conf/machine/include/genericx86-common.inc
+++ b/meta-yocto-bsp/conf/machine/include/genericx86-common.inc
@@ -2,7 +2,7 @@ include conf/machine/include/x86/x86-base.inc
require conf/machine/include/x86/qemuboot-x86.inc
MACHINE_FEATURES += "wifi efi pcbios"

-PREFERRED_VERSION_linux-yocto ?= "5.14%"
+PREFERRED_VERSION_linux-yocto ?= "5.15%"
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
XSERVER ?= "${XSERVER_X86_BASE} \
--
2.19.1
Yocto Project Status WW02`22

Stephen Jolley
 

Current Dev Position: YP 3.5 M2

Next Deadline: 17th Jan. 2022 YP 3.5 M2 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.5 M2 is due to build next week
  • The autobuilder updates have now mostly stabilized and we are potentially seeing a reduction in intermittent failures.
  • On modern kernels, we now have the capability within bitbake to disable networking on a per task basis without extra user privileges. There is discussion on the mailing list on how we should enable this and whether it should be on an opt-in or opt-out basis. A second patchset has been proposed for discussion where tasks using the network would need to be explicitly marked as such.
  • The openssl and webkit reproducibility issues have been fixed.
  • We have also fixed the reproducibility issues with rust-llvm and golang. With ruby docs disabled, this means we have no reproducibility patch exclusions in OE-Core, thanks Alex Kanavin!
  • The “oldest kernel” setting used for qemu which is architecture specific is causing issues for allarch packages but the various patches to fix it have also caused other issues and highlighted gaps in our sstate hash tests. There are hopefully now patches ready to merge to fix these issues and the gaps in testing.
  • CVE issues against master have risen from 7 to 17 so help in addressing those issues would be very welcome.
  • Intermittent issues continue to be at record high levels and help is very much welcome in trying to resolve them. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

 

Ways to contribute:

 

YP 3.5 Milestone Dates:

  • YP 3.5 M2 build date 2022/01/17
  • YP 3.5 M2 Release date 2022/01/28
  • YP 3.5 M3 build date 2022/02/21
  • YP 3.5 M3 Release date 2022/03/04
  • YP 3.5 M4 build date 2022/04/04
  • YP 3.5 M4 Release date 2022/04/29

 

Upcoming dot releases:

  • YP 3.1.14 build date 2022/01/24
  • YP 3.1.14 Release date 2022/02/04
  • YP 3.4.2 build date 2022/02/07
  • YP 3.4.2 Release date 2022/02/18
  • YP 3.3.5 build date 2022/02/14
  • YP 3.3.5 Release date 2022/02/25
  • YP 3.1.15 build date 2022/03/14
  • YP 3.1.15 Release date 2022/03/25
  • YP 3.4.3 build date 2022/03/21
  • YP 3.4.3 Release date 2022/04/01
  • YP 3.3.6 build date 2022/03/28
  • YP 3.3.6 Release date 2022/04/08
  • YP 3.1.16 build date 2022/04/25
  • YP 3.1.16 Release date 2022/05/06

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 
Re: [docs] No more nightly builds?

Richard Purdie
 

On Tue, 2022-01-11 at 12:12 +0100, Michael Opdenacker wrote:
On 1/11/22 12:09 PM, Richard Purdie wrote:
On Tue, 2022-01-11 at 12:01 +0100, Michael Opdenacker wrote:
Hi Richard,

On 1/11/22 11:41 AM, Richard Purdie wrote:
On Tue, 2022-01-11 at 10:47 +0100, Michael Opdenacker wrote:
Greetings,

Do we still have nightly builds? I cannot find them anywhere, but the
documentation still refer to a broken location
(https://autobuilder.yocto.io/pub/nightly/).
We do run them but they're "a-quick" six nights a week with an "a-full" on a
weekend. The results of all non-release builds go here:

https://autobuilder.yocto.io/pub/non-release/

The "nightly" builds don't produce shared artefacts any more, just test result
files and reports.
Right. So the documentation can stop referring to them as a way to get
the latest code.
I think it should be replaced with something about "latest test results"?
Maybe, but then in the test manual, because the section referring to
nightly builds about getting Yocto Project code
(https://docs.yoctoproject.org/dev-manual/start.html#locating-yocto-project-source-files).
Right, in that context I agree it can be removed and probably wasn't that useful
anyway.

Cheers,

Richard
Re: [docs] No more nightly builds?

Michael Opdenacker
 

On 1/11/22 12:09 PM, Richard Purdie wrote:
On Tue, 2022-01-11 at 12:01 +0100, Michael Opdenacker wrote:
Hi Richard,

On 1/11/22 11:41 AM, Richard Purdie wrote:
On Tue, 2022-01-11 at 10:47 +0100, Michael Opdenacker wrote:
Greetings,

Do we still have nightly builds? I cannot find them anywhere, but the
documentation still refer to a broken location
(https://autobuilder.yocto.io/pub/nightly/).
We do run them but they're "a-quick" six nights a week with an "a-full" on a
weekend. The results of all non-release builds go here:

https://autobuilder.yocto.io/pub/non-release/

The "nightly" builds don't produce shared artefacts any more, just test result
files and reports.
Right. So the documentation can stop referring to them as a way to get
the latest code.
I think it should be replaced with something about "latest test results"?
Maybe, but then in the test manual, because the section referring to
nightly builds about getting Yocto Project code
(https://docs.yoctoproject.org/dev-manual/start.html#locating-yocto-project-source-files).

Thanks

Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [docs] No more nightly builds?

Richard Purdie
 

On Tue, 2022-01-11 at 12:01 +0100, Michael Opdenacker wrote:
Hi Richard,

On 1/11/22 11:41 AM, Richard Purdie wrote:
On Tue, 2022-01-11 at 10:47 +0100, Michael Opdenacker wrote:
Greetings,

Do we still have nightly builds? I cannot find them anywhere, but the
documentation still refer to a broken location
(https://autobuilder.yocto.io/pub/nightly/).
We do run them but they're "a-quick" six nights a week with an "a-full" on a
weekend. The results of all non-release builds go here:

https://autobuilder.yocto.io/pub/non-release/

The "nightly" builds don't produce shared artefacts any more, just test result
files and reports.

Right. So the documentation can stop referring to them as a way to get
the latest code.
I think it should be replaced with something about "latest test results"?

Cheers,

Richard
Re: [docs] No more nightly builds?

Michael Opdenacker
 

Hi Richard,

On 1/11/22 11:41 AM, Richard Purdie wrote:
On Tue, 2022-01-11 at 10:47 +0100, Michael Opdenacker wrote:
Greetings,

Do we still have nightly builds? I cannot find them anywhere, but the
documentation still refer to a broken location
(https://autobuilder.yocto.io/pub/nightly/).
We do run them but they're "a-quick" six nights a week with an "a-full" on a
weekend. The results of all non-release builds go here:

https://autobuilder.yocto.io/pub/non-release/

The "nightly" builds don't produce shared artefacts any more, just test result
files and reports.

Right. So the documentation can stop referring to them as a way to get
the latest code.
Thanks
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [docs] No more nightly builds?

Richard Purdie
 

On Tue, 2022-01-11 at 10:47 +0100, Michael Opdenacker wrote:
Greetings,

Do we still have nightly builds? I cannot find them anywhere, but the
documentation still refer to a broken location
(https://autobuilder.yocto.io/pub/nightly/).
We do run them but they're "a-quick" six nights a week with an "a-full" on a
weekend. The results of all non-release builds go here:

https://autobuilder.yocto.io/pub/non-release/

The "nightly" builds don't produce shared artefacts any more, just test result
files and reports.

Cheers,

Richard
How to unpack a .tgz archive in a .zip file?

Michael Opdenacker
 

Hello

I'm working on adding the wiki guidelines for dealing with pre-compiled
libraries
(https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries#Versioned_Libraries)
into the main documentation.

I'm trying to test the example recipe, but the latest pre-compiled
versions of libft4422.so are now available in
https://ftdichip.com/wp-content/uploads/2021/01/libft4222-linux-1.4.4.44.zip,
which actually contains a .tgz file!

I know that's absurd, but how would you handle this case? Through a
custom "do_unpack" task in the recipe?

Thanks in advance for your insights...
Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
No more nightly builds?

Michael Opdenacker
 

Greetings,

Do we still have nightly builds? I cannot find them anywhere, but the
documentation still refer to a broken location
(https://autobuilder.yocto.io/pub/nightly/).

I'll be happy to remove the corresponding chapter
(https://docs.yoctoproject.org/dev-manual/start.html#accessing-nightly-builds)
if indeed we no longer produce such builds.

Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: How to clean the cache for a package?

Tony He
 

Thanks a lot. This is root cause. I did not update the SRCREV because
I have not added this SRCREV in my recipe.

Tony

Chen, Qi <Qi.Chen@...> 于2022年1月11日周二 14:28写道：


In theory, there's no need to run 'bitbake -c clean'. Did you update the SRCREV? It would be easier if you could share some info of your recipe.

Regards,
Qi

-----Original Message-----
From: yocto@... <yocto@...> On Behalf Of Tony He
Sent: Tuesday, January 11, 2022 2:12 PM
To: yocto@...
Subject: [yocto] How to clean the cache for a package?

Hi,

I'm new to yocto. I write a reciple for my own package. The source code of package is in my PC and maintained by GIT. When I change the source code of the package, I need to compile this package again with "bitbake -c clean package" and "bitbake -c compile package".
However, even though I can see the code in the folder downloads/git2/package.git is updated, but bitbake still use the last commit of the git repo to compile. After debugging, I found the old commit ID is stored in build-project/cache/bb_persist_data.sqlite3. Is this normal?
Is it caused by my own wrong reciple or is there any command to clean the cache for a package? Thank you!

Tony
1641 - 1660 of 57410