Re: [yocto] Yocto recipe license

[Contrib Open Source]

Hello,

thanks for pointing me to oe-core LICENSE file.

Just to be sure, from:
https://github.com/openembedded/openembedded-core/blob/master/LICENSE
   "All metadata is MIT licensed unless otherwise stated. Source code
included in tree for individual recipes is under the LICENSE stated in
the associated recipe (.bb file) unless otherwise stated.

License information for any other files is either explicitly stated
or defaults to GPL version 2."

Here "metadata" stands for "oe-core recipe", right ?

What if we extend (*.bbappend) a GPLv2 recipe: is it "contaminated" or not ?

Regards,
contrib

2016-10-13 12:37 GMT+02:00 Burton, Ross :

>
> On 13 October 2016 at 09:49, Contrib Open Source <
> contrib.open.sou...@gmail.com> wrote:
>
>> it seems that license.manifest file describes application/lib/etc.
>> source code license,
>> but what about Yocto recipe license itself ?
>> So what is the license of a Yocto recipe ?
>> How to know it ?
>> If a Yocto recipe is GPL2, and we extend (*.bbappend) this recipe,
>> does contamination effect applies to the extented recipe ?
>>
>
> The oe-core metadata is licensed under MIT, as explained in the LICENSE
> file.
>
> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Migration info - runqemu

[Robert Yang]

Hi Paul and Scott,

Here it is, and please feel free to comment, most of them are from
qemuboot.bbclass:

The new runqemu is a python script, it requires a
-.qemuboot.conf to boot the bsp, the qemuboot.conf
is generated by qemuboot.bbclass during build rootfs, qemu boot
arguments can be set in bsp's conf file, and qemuboot.bbclass will save
them to qemuboot.conf.

Note, "QB" means Qemu Boot, the following vars can be set in conf
files, such as  to make it can be boot by runqemu:

QB_SYSTEM_NAME: qemu name, e.g., "qemu-system-i386"
QB_OPT_APPEND: options to append to qemu, e.g., "-show-cursor"
QB_DEFAULT_KERNEL: default kernel to boot, e.g., "bzImage"
QB_DEFAULT_FSTYPE: default FSTYPE to boot, e.g., "ext4"
QB_MEM: memory, e.g., "-m 512"
QB_MACHINE: qemu machine, e.g., "-machine virt"
QB_CPU: qemu cpu, e.g., "-cpu qemu32"
QB_CPU_KVM: the similar to QB_CPU, but used when kvm, e.g., '-cpu kvm64',
set it when support kvm.
QB_KERNEL_CMDLINE_APPEND: options to append to kernel's -append
  option, e.g., "console=ttyS0 console=tty"
QB_DTB: qemu dtb name
QB_AUDIO_DRV: qemu audio driver, e.g., "alsa", set it when support audio
QB_AUDIO_OPT: qemu audio option, e.g., "-soundhw ac97,es1370", used
  when QB_AUDIO_DRV is set.
QB_KERNEL_ROOT: kernel's root, e.g., /dev/vda
QB_TAP_OPT: netowrk option for 'tap' mode, e.g.,
"-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no -device 
virtio-net-device,netdev=net0"
 Note, runqemu will replace "@TAP@" with the one which is used, 
such as tap0, tap1 ...

QB_SLIRP_OPT: network option for SLIRP mode, e.g.,
"-netdev user,id=net0 -device virtio-net-device,netdev=net0"
QB_ROOTFS_OPT: used as rootfs, e.g.,
  "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device 
virtio-blk-device,drive=disk0"
 Note, runqemu will replace "@ROOTFS@" with the one which is used, 
such as core-image-minimal-qemuarm64.ext4.

QB_SERIAL_OPT: serial port, e.g., "-serial mon:stdio"
QB_TCPSERIAL_OPT: tcp serial port option, e.g.,
  " -device virtio-serial-device -chardev 
socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device virtconsole,chardev=virtcon"
  Note, runqemu will replace "@PORT@" with the port number 
which is used.


Usage:
IMAGE_CLASSES += "qemuboot"
See "runqemu help" for more info

// Robert

On 10/14/2016 09:48 AM, Paul Eggleton wrote:

Hi folks,

We need some info for the migration section of the 2.2 manual about what the
user needs to do to adapt to the new python-based runqemu. Robert / Joshua,
can one of you please write something short that explains what users need to
do (i.e. changes to the metadata for BSPs, or any other changes in operation)?
It doesn't need to be polished, Scott Rifenbark will take care of that. Just
replying to this email with Scott on CC should be sufficient.

Thanks,
Paul


--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Migration info - runqemu

[Paul Eggleton]

Hi folks,

We need some info for the migration section of the 2.2 manual about what the 
user needs to do to adapt to the new python-based runqemu. Robert / Joshua, 
can one of you please write something short that explains what users need to 
do (i.e. changes to the metadata for BSPs, or any other changes in operation)? 
It doesn't need to be polished, Scott Rifenbark will take care of that. Just 
replying to this email with Scott on CC should be sufficient.

Thanks,
Paul

-- 
Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-autobuilder][PATCH] PublishArtifacts.py: deal only with built toolchains, cp also md5 and manifests

[gmane]

Hi,

On 2016-10-13 16:29, Lock, Joshua G wrote:

Can you help me understand why you needed to create this patch?

We've run into some issues recently where toolchains we expected to be
built weren't and the PublishArtifacts buildstep failing because
they're missing is useful. With this change we'll no longer get that,
right?


Yes that's right (and not intended).

I would hope that you'll be able to detect such kind of problems before 
the PublishArtifacts buildstep because there should be some error in 
previous steps. The toolchain did not build!


I made this patch because I just want to build a 64 bit toolchain as 
opposed to both (like I used to do with some older version of Y-AB) and 
don't want the PublishArtifacts step to fail just because there is no 
32-bit toolchain. There is no 32 bit toolchain on purpose.


As a bonus the patch also copies md5sums and friends over and not just 
the .sh files.


I do not want PublishArtifacts toolchain(s) to find out that something 
went wrong in previous build steps, but I would want it to copy over 
whatever was built (and not to fail if something I did not build is 
missing).


As a quick and dirty alternative I would also be happy with a solution 
based on additional PublishArtifacts steps like:


toolchain_i686 for 32 bit only   (only the 32 bit toolchain)
toolchain_x86_64 for 64 bit only (only the 64 bit toolchain)

if that helps.

Then in my config file I just use toolchain_x86_64 instead of toolchain 
in my PublishArtifacts step to indicate that I just want the 64 bit 
version.


To publish both you could use toolchain_i686 and toolchain_x86_64 in the 
PublishArtifacts step.


I find it a bit confusing to write toolchain and to expect various 64 
bit and 32 bit toolchains to be published.


BTW what happens here[1] if one toolchain does not build?

I think even without my patch you'll not be able to detect the problem, 
since BuildToolchainImages is being called 4 times so two 32 bit and two 
64 bit toolchains should be built. You'll just get an error in 
PublishArtifacts before my patch if no 32 bit or no 64 bit toolchain is 
being built. Nobody counts how many should be there.


So I would say the best would be to count how many toolchains should be 
built (count BuildToolchainImages in combination with SDKMACHINE) and 
check if that's the case in PublishArtifacts. No idea if and how this 
can be done.




Thanks,

Joshua


Regards,

Robert

[1] 
http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/tree/buildset-config.controller/nightly-arm.conf



-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-autobuilder][PATCH] PublishArtifacts.py: deal only with built toolchains, cp also md5 and manifests

[Joshua Lock]

On Wed, 2016-10-12 at 17:29 +0200, Beth 'pidge' Flanagan wrote:
> On Mon, 2016-10-10 at 01:44 -0500, gm...@reliableembeddedsystems.com
> wrote:
> > 
> > 
> 
> 
> A few notes (not picking on this patch but it does point out some
> design failures and I want to at least get this on folks radar).
> 
> I've been unhappy with how DeployArtifacts work for sometime.
> 
> Long ago, when I wrote DeployArtifacts, it was "get it working, we'll
> refactor later" and that refactor never happened. So I'm up for
> ideas.
> 
> I would like a deploy infrastructure that:
> 
> a. Is distro/image name/etc agnostic (aka, poky and image names and
> paths hardcoded. ick.).
> b. Is perhaps config file driven.
> c. Had much less of the cruft that exists withing DeployArtifacts.
> 
> So. Thoughts on this? I'd be willing to hear suggestions on how to do
> this before I go and spend some time ripping this apart post release?

It's quite useful to have a list of expected output of the build so
that this step can fail if a component which should be published is
missing.

I'd been planning to take a look at rewriting this build step after the
release and my initial thoughts were towards something config file
driven.

Thanks,

Joshua
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-autobuilder][PATCH] PublishArtifacts.py: deal only with built toolchains, cp also md5 and manifests

[Lock, Joshua G]

Can you help me understand why you needed to create this patch?

We've run into some issues recently where toolchains we expected to be
built weren't and the PublishArtifacts buildstep failing because
they're missing is useful. With this change we'll no longer get that,
right?

Thanks,

Joshua
-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Big endian ARM machine with NEON wanted

[Andreas Müller]

Hi,

Does anybody know a big endian and common machine supporting NEON? I
would need one for testing my port of portaudio.

Thanks in advance

Andreas
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] add dejavu-fonts to image

[Michel D'HOOGE]

After solving all the QA issues, this bbappend creates RPM packages with fonts 
in the expected folder. I didn't try to generate an image but I'm quite 
confident about the result.
Michel


do_install() {
install -d ${D}${libdir}/fonts/
find ./ -name '*.tt[cf]' -exec install -m 0644 {} ${D}${libdir}/fonts/ \;
install -d ${D}${sysconfdir}/fonts/conf.d/
install -m 0644 ${WORKDIR}/30-dejavu-aliases.conf 
${D}${sysconfdir}/fonts/conf.d/
}

FILES_${PN}-sans= "${libdir}/fonts/DejaVuSans.ttf 
${libdir}/fonts/DejaVuSans-*.ttf"
FILES_${PN}-sans-mono   = "${libdir}/fonts/DejaVuSansMono*.ttf"
FILES_${PN}-sans-condensed  = "${libdir}/fonts/DejaVuSansCondensed*.ttf"
FILES_${PN}-serif   = "${libdir}/fonts/DejaVuSerif.ttf 
${libdir}/fonts/DejaVuSerif-*.ttf"
FILES_${PN}-serif-condensed = "${libdir}/fonts/DejaVuSerifCondensed*.ttf"
FILES_${PN}-mathtexgyre = "${libdir}/fonts/DejaVuMathTeXGyre.ttf"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Release Candidate Build for yocto-2.2.rc1.rc1 now available.

[Lock, Joshua G]

On Thu, 2016-10-13 at 15:36 +, Poky Build User wrote:
> A release candidate build for yocto-2.2.rc1 is now available at:
> 
> 
> http://autobuilder.yoctoproject.org/pub/releases/yocto-2.2.rc1
> 
> 
> Please begin QA on this build as soon as possible.

Please don't, this build isn't ready for QA.

The debian8 builder recently failed to send a QA mail (no sendmail in
PATH) and this mail is testing it now works.

Thanks,

Joshua

> Build hash information: 
> meta-qt4 : fc9b050569e94b5176bed28b69ef28514e4e4553 
> meta-intel : 9052773016727a9398d1e6b6830dc94f3203f754 
> meta-minnow : 9c965ef5252e383843d796cd8b50c61b3034b6ae 
> meta-qt3 : f33b73a9563f2dfdfd0ee37b61d65d90197a456f 
> poky : 371ab635086e2878ada1f00a59c7ec826481ba0a 
> 
> \nThis is an automated message from\nThe Yocto Project
> Autobuilder\nGit: git://git.yoctoproject.org/yocto-
> autobuilder\nEmail: pi...@toganlabs.com
-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] add dejavu-fonts to image

[idealsim]

Thanks for this. I will try and let you know the solution worked for me !

regards

Le Thu, 13 Oct 2016 16:56:34 +0200, Michel D'HOOGE   
a écrit:



Hello, thanks a lot the build work now !
I'm very proud: this is the 1st time I can help someone on Yocto! This  
means a lot to me ;-)


But i have another issue, i would like to install the font in  
/usr/lib/fonts, this is not the case for the moment (it 's >>for Qt5.7  
use). How i can said to yocto to install font (.ttf) on this folder  
please ?
I also need to use Qt5.7, but since I'm currently on other tasks, you  
discover the troubles a couple of hours before >me. So let's try to  
debug this together…


1/ File ttf-dejavu_2.37.bb includes (requires) `ttf.inc` that is in the  
same folder.

2/ File ttf.inc has the following method:
do_install() {
   install -d ${D}${datadir}/fonts/truetype/
   find ./ -name '*.tt[cf]' -exec install -m 0644 {}  
${D}${datadir}/fonts/>truetype/ \;

}


which is in turn appended by dejavu with:

do_install_append () {
   install -d ${D}${sysconfdir}/fonts/conf.d/
   install -m 0644 ${WORKDIR}/30-dejavu-aliases.conf  
${D}${sysconfdir}/fonts/>conf.d/

}

3/ The log of the install task of the recipe is  
/tmp/work/all-poky-linux/ttf-dejavu/2.37-r7/temp/run.do_install

We have:
export datadir="/usr/share"
export sysconfdir="/etc"

I compared to my Debian system: the files are stored in the same  
folders. So it seems this is qt that doesn't search >in the "correct"  
place.


4/ After some grepping in meta-qt5, I have:

classes/qmake5_paths.bbclass
OE_QMAKE_PATH_LIBS = "${libdir}"

classes/qmake5_paths.bbclass
OE_QMAKE_PATH_QT_FONTS = "${OE_QMAKE_PATH_LIBS}/fonts"

5/ But I don't know what is the best solution now. We could change the  
OE_QMAKE_PATH_QT_FONTS variable. >But this implies to recompile many  
pieces, I believe.


So I opt for changing the do_install function. The quick & dirty  
solution is to create a ttf-dejavu_2.37.bbappend file >that totally  
redefine the do_install method.


do_install() {
   install -d ${D}${datadir}/fonts/truetype/
   find ./ -name '*.tt[cf]' -exec install -m 0644 {}  
${D}${libdir}/fonts/>truetype/ \;

   install -d ${D}${sysconfdir}/fonts/conf.d/
   install -m 0644 ${WORKDIR}/30-dejavu-aliases.conf  
${D}${sysconfdir}/fonts/>conf.d/

}



I can't test it right now, but I hope this helps you.


Michel








--
Utilisant le logiciel de courrier d'Opera : http://www.opera.com/mail/-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Release Candidate Build for yocto-2.2.rc1.rc1 now available.

[Poky Build User]

A release candidate build for yocto-2.2.rc1 is now available at:


http://autobuilder.yoctoproject.org/pub/releases/yocto-2.2.rc1


Please begin QA on this build as soon as possible.


Build hash information: 
meta-qt4 : fc9b050569e94b5176bed28b69ef28514e4e4553 
meta-intel : 9052773016727a9398d1e6b6830dc94f3203f754 
meta-minnow : 9c965ef5252e383843d796cd8b50c61b3034b6ae 
meta-qt3 : f33b73a9563f2dfdfd0ee37b61d65d90197a456f 
poky : 371ab635086e2878ada1f00a59c7ec826481ba0a 

\nThis is an automated message from\nThe Yocto Project Autobuilder\nGit: 
git://git.yoctoproject.org/yocto-autobuilder\nEmail: pi...@toganlabs.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Release Candidate Build for yocto-2.2.rc1.rc1 now available.

[Poky Build User]

A release candidate build for yocto-2.2.rc1 is now available at:


http://autobuilder.yoctoproject.org/pub/releases/yocto-2.2.rc1


Please begin QA on this build as soon as possible.


Build hash information: 
meta-qt4 : fc9b050569e94b5176bed28b69ef28514e4e4553 
meta-intel : 9052773016727a9398d1e6b6830dc94f3203f754 
meta-minnow : 9c965ef5252e383843d796cd8b50c61b3034b6ae 
meta-qt3 : f33b73a9563f2dfdfd0ee37b61d65d90197a456f 
poky : 371ab635086e2878ada1f00a59c7ec826481ba0a 

\nThis is an automated message from\nThe Yocto Project Autobuilder\nGit: 
git://git.yoctoproject.org/yocto-autobuilder\nEmail: pi...@toganlabs.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] add dejavu-fonts to image

[Michel D'HOOGE]

Hello, thanks a lot the build work now ! 

I'm very proud: this is the 1st time I can help someone on Yocto! This means a 
lot to me ;-) 





But i have another issue, i would like to install the font in /usr/lib/fonts, 
this is not the case for the moment (it 's for Qt5.7 use). How i can said to 
yocto to install font (.ttf) on this folder please ? 

I also need to use Qt5.7, but since I'm currently on other tasks, you discover 
the troubles a couple of hours before me. So let's try to debug this together… 







1/ File ttf-dejavu_2.37.bb includes (requires) `ttf.inc` that is in the same 
folder. 
2/ File ttf.inc has the following method: 

do_install() { 
install -d ${D}${datadir}/fonts/truetype/ 
find ./ -name '*.tt[cf]' -exec install -m 0644 {} 
${D}${datadir}/fonts/truetype/ \; 
} 


which is in turn appended by dejavu with: 

do_install_append () { 
install -d ${D}${sysconfdir}/fonts/conf.d/ 
install -m 0644 ${WORKDIR}/30-dejavu-aliases.conf 
${D}${sysconfdir}/fonts/conf.d/ 
} 


3/ The log of the install task of the recipe is 
/tmp/work/all-poky-linux/ttf-dejavu/2.37-r7/temp/run.do_install 
We have: 

export datadir="/usr/share" 

export sysconfdir="/etc" 



I compared to my Debian system: the files are stored in the same folders. So it 
seems this is qt that doesn't search in the "correct" place. 


4/ After some grepping in meta-qt5, I have: 



classes/qmake5_paths.bbclass 
OE_QMAKE_PATH_LIBS = "${libdir}" 



classes/qmake5_paths.bbclass 
OE_QMAKE_PATH_QT_FONTS = "${OE_QMAKE_PATH_LIBS}/fonts" 


5/ But I don't know what is the best solution now. We could change the 
OE_QMAKE_PATH_QT_FONTS variable. But this implies to recompile many pieces, I 
believe. 


So I opt for changing the do_install function. The quick & dirty solution is to 
create a ttf-dejavu_2.37.bbappend file that totally redefine the do_install 
method. 




do_install() { 
install -d ${D}${datadir}/fonts/truetype/ 
find ./ -name '*.tt[cf]' -exec install -m 0644 {} ${D}${ libdir 
}/fonts/truetype/ \; 

install -d ${D}${sysconfdir}/fonts/conf.d/ 
install -m 0644 ${WORKDIR}/30-dejavu-aliases.conf 
${D}${sysconfdir}/fonts/conf.d/ 
} 




I can't test it right now, but I hope this helps you. 


Michel 







-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] add dejavu-fonts to image

[idealsim]

Hello, thanks a lot the build work now !
But i have another issue, i would like to install the font in  
/usr/lib/fonts, this is not the case for the moment (it 's for Qt5.7 use).  
How i can said to yocto to install font (.ttf) on this folder please ?


regards

Mickaël

Le Thu, 13 Oct 2016 12:07:24 +0200, Michel D'HOOGE   
a écrit:



Hello,

In fact, the ttf-dejavu recipe doesn't provide a package with the same  
name. If you look at the PACKAGES variable, you'll find that it  
>provides ${PN}-sans, ${PN}-sans-mono, ${PN}-sans-condensed, ${PN}-serif  
, ${PN}-serif-condensed & ${PN}-mathtexgyre.



So you have to explicitly choose the packages you want.



Michel




--
Utilisant le logiciel de courrier d'Opera : http://www.opera.com/mail/-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto recipe license

[Burton, Ross]

On 13 October 2016 at 09:49, Contrib Open Source <
contrib.open.sou...@gmail.com> wrote:

> it seems that license.manifest file describes application/lib/etc.
> source code license,
> but what about Yocto recipe license itself ?
> So what is the license of a Yocto recipe ?
> How to know it ?
> If a Yocto recipe is GPL2, and we extend (*.bbappend) this recipe,
> does contamination effect applies to the extented recipe ?
>

The oe-core metadata is licensed under MIT, as explained in the LICENSE
file.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] add dejavu-fonts to image

[Michel D'HOOGE]

Hello, 

In fact, the ttf-dejavu recipe doesn't provide a package with the same name. If 
you look at the PACKAGES variable, you'll find that it provides ${PN}-sans, 
${PN}-sans-mono, ${PN}-sans-condensed, ${PN}-serif , ${PN}-serif-condensed & 
${PN}-mathtexgyre. 

So you have to explicitly choose the packages you want. 

Michel 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto recipe license

[Contrib Open Source]

Hello,

it seems that license.manifest file describes application/lib/etc.
source code license,
but what about Yocto recipe license itself ?
So what is the license of a Yocto recipe ?
How to know it ?
If a Yocto recipe is GPL2, and we extend (*.bbappend) this recipe,
does contamination effect applies to the extented recipe ?

Thanks for your help,
contrib
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi][PATCH 2/2] linux-raspberrypi_4.7.bb: Update to 4.7.7

[Khem Raj]

Signed-off-by: Khem Raj 
---
 recipes-kernel/linux/linux-raspberrypi_4.7.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-kernel/linux/linux-raspberrypi_4.7.bb 
b/recipes-kernel/linux/linux-raspberrypi_4.7.bb
index 44ac961..0315f8f 100644
--- a/recipes-kernel/linux/linux-raspberrypi_4.7.bb
+++ b/recipes-kernel/linux/linux-raspberrypi_4.7.bb
@@ -1,8 +1,8 @@
 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
 
-LINUX_VERSION ?= "4.7.0"
+LINUX_VERSION ?= "4.7.7"
 
-SRCREV = "d38b45a21294eaf01aa7568aaeb161d7553477e9"
+SRCREV = "a45a35c08598b23f9fd82e49c83b46c7d536244f"
 SRC_URI = 
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.7.y \
file://0001-fix-dtbo-rules.patch \
 "
-- 
2.10.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi][PATCH V2 1/2] linux-raspberrypi: Add recipe for 4.8 release

[Khem Raj]

Signed-off-by: Khem Raj 
---
 recipes-kernel/linux/linux-raspberrypi_4.8.bb | 8 
 1 file changed, 8 insertions(+)
 create mode 100644 recipes-kernel/linux/linux-raspberrypi_4.8.bb

diff --git a/recipes-kernel/linux/linux-raspberrypi_4.8.bb 
b/recipes-kernel/linux/linux-raspberrypi_4.8.bb
new file mode 100644
index 000..02623f4
--- /dev/null
+++ b/recipes-kernel/linux/linux-raspberrypi_4.8.bb
@@ -0,0 +1,8 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
+
+LINUX_VERSION ?= "4.8.1"
+
+SRCREV = "5b7970b19bbb2ea1620591bfb6517848696ed0b9"
+SRC_URI = 
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.8.y \
+"
+require linux-raspberrypi.inc
-- 
2.10.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Can I change the version of Yocto Project ?

[Dengke Du]

On 2016年10月12日 22:05, 蔡尚義 wrote:

Hi Yocto Project:

Recently I downloaded the yocto project with the latest version 
("krogoth") on my Ubuntu14.04 LTS.


But I found that Jethro version is the real version that I need to use 
for BSP on APQ8053(Qualcomm chip)


So, How can I downgrade the version of yocto project to do this ?


Why not download Jethro directly?


Another question is that I found that the Desktop can not fit my 
desktop monitor very well.


Maybe it was because your virtual-machine on windows.


So, how can I change the setting to let this issue disappeared ?


--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] yocto - linaro's lava integration

[alfonso]

Hi Mark,

thanks a lot for replying to my message. On the last few days I managed 
to find the missing key of the puzzle on some lava slides on the 
internet. In fact you can boot and test an image having the kernel and 
fs separately.


here is the job description:

device_type: qemu
job_name: qemu-x86-test

timeouts:
  job:
minutes: 6
  action:
minutes: 2
priority: medium
visibility: public

context:
  arch: i386

actions:
- deploy:
timeout:
  minutes: 3
to: tmpfs
images:
kernel:
  image_arg: -kernel {kernel} -append "console=ttyS0 
root=/dev/vda rw"

  url: file:///opt/image/kernel.bin
rootfs:
  image_arg: -drive format=raw,file={rootfs},if=virtio
  url: file:///opt/image/fs.ext4
os: debian
root_partition: 1

- boot:
method: qemu
timeout:
  minutes: 2
media: tmpfs
prompts:
- "root@debian:"
auto_login:
  login_prompt: "login:"
  username: root

it is as you say, quite intuitive but i had some trouble finding the 
proper description of this job definition. Now I am focus on how to set 
up the integration process, how to submit the job after the building 
process have been triggered in the git repo and so on.


Its actually easy once you find the pieces of information that you need.

Thanks again and let's see how it goes :P

Best,

Alfonso

On 12.10.2016 17:03, Mark Asselstine wrote:

On Monday, October 10, 2016 12:23:07 PM EDT alfonso wrote:

Hello everyone,

I'm trying to integrate the testing of the resulting yocto images using
Linaro's LAVA project.

For now I am only using qemux86 images.

Now, I am quite a newbie in both projects and maybe in general on the
subject of images so I might be asking the wrong questions.

So far, to test a qemu image using LAVA it is required a .img file. That
would be the simplest configuration. On the other hand, my yocto project
produces a .bin kernel file + .ext4 filesystem file. I don't seem to
find a proper configuration in LAVA for .bin + .ext4 file testing. I
presume there is a way to configure yocto to produce a .img file out of
these two guys but I don't seem to find how.

Would anyone have a recommendation?

We have been using LAVA to test our Yocto based product for about 1 1/2years
now using the produced .ext[34] and bzImage produced from a typical Yocto
build. We have been using LAVA 1 however and I am only now starting to move to
the latest LAVA 2. We have also been using hardware targets and not qemu but
that is overall inconsequential.

Since our move to LAVA 2 is in progress I can't currently give you a step by
step guide to accomplishing this. Let me look quickly today to see if the
existing definition of the qemu device type will allow for specifying a disk
image and kernel. If not then it either needs to be added or a new device type
created with allows it. On the bright side the LAVA folks have done a good job
about the layout of their code so jumping in to do this may seem to be a big
hurdle but once you jump in you will find most things where you would expect
them to be.

Alternatively you could use either a chroot or VM to update the .ext4 image
with a kernel and grub.

Anyways, sorry for sparse information. Again if you give me some time I can
provide you with more details. But definitely go ahead and dig in, you will
find that what you want to do is possible.

Mark Asselstine







Thanks in advance for your help :)

Best,
Alfonso




--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] resize2fs

[Nicolas Dechesne]

On Thu, Oct 13, 2016 at 9:03 AM, Peter Balazovic 
wrote:

> > First, you need an extra space when you use _append operator.
> I got within my local.conf and building for big size SD card.
>
> IMAGE_ROOTFS_EXTRA_SPACE = "25165824"
>

that's not what I meant, you need a leasding space char in the variable like

IMAGE_INSTALL_append = " e2fsprogs-resize2fs"


> > So you need to include e2fsprogs-resize2fs
>
> that's what I'm looking for - where to include ...
>

local.conf would work.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] resize2fs

[Peter Balazovic]

> First, you need an extra space when you use _append operator.
I got within my local.conf and building for big size SD card.

IMAGE_ROOTFS_EXTRA_SPACE = "25165824"

> So you need to include e2fsprogs-resize2fs

that's what I'm looking for - where to include ...

On Thu, Oct 13, 2016 at 8:49 AM, Nicolas Dechesne <
nicolas.deche...@linaro.org> wrote:

> Le 13 oct. 2016 08:44, "Peter Balazovic"  a
> écrit :
> >
> > Dears,
> >
> > I just build the yocto image and within local.conf I got
> >
> > IMAGE_INSTALL_append = "e2fsprogs"
>
> First, you need an extra space when you use _append operator.
>
> .
> >
> > but unfortunately I do not get resize2fs utility installed. I do not not
> why?
>
> Then if you look at the recipe each app is packaged separately so that you
> can pick and choose only the one you need. So you need to include
> e2fsprogs-resize2fs
>
> > this how e2fsprogs_1.42.9.bb looks like
> >
> >
> >
> > require e2fsprogs.inc
> >
> >
> > SRC_URI += "file://acinclude.m4 \
> > file://remove.ldconfig.call.patch \
> > file://fix-icache.patch \
> > file://quiet-debugfs.patch \
> > 
> > file://0001-mke2fs-add-the-ability-to-copy-files-from-a-given-di.patch
> \
> > file://0002-misc-create_inode.c-copy-files-recursively.patch
> \
> > file://0003-misc-create_inode.c-create-special-file.patch \
> > file://0004-misc-create_inode.c-create-symlink.patch \
> > file://0005-misc-create_inode.c-copy-regular-file.patch \
> > file://0006-misc-create_inode.c-create-directory.patch \
> > 
> > file://0007-misc-create_inode.c-set-owner-mode-time-for-the-inod.patch
> \
> > file://0008-mke2fs.c-add-an-option-d-root-directory.patch \
> > file://0009-misc-create_inode.c-handle-hardlinks.patch \
> > 
> > file://0010-debugfs-use-the-functions-in-misc-create_inode.c.patch
> \
> > file://0011-mke2fs.8.in-update-the-manual-for-the-d-option.patch
> \
> > file://0012-Fix-musl-build-failures.patch \
> > file://0001-e2fsprogs-fix-cross-compilation-problem.patch \
> > 
> > file://misc-mke2fs.c-return-error-when-failed-to-populate-fs.patch
> \
> > file://cache_inode.patch \
> > file://CVE-2015-0247.patch \
> > 
> > file://0001-libext2fs-fix-potential-buffer-overflow-in-closefs.patch
> \
> > "
> >
> > SRC_URI[md5sum] = "3f8e41e63b432ba114b33f58674563f7"
> > SRC_URI[sha256sum] = "2f92ac06e92fa00f2ada3ee67dad01
> 2d74d685537527ad1241d82f2d041f2802"
> >
> > EXTRA_OECONF += "--libdir=${base_libdir} --sbindir=${base_sbindir}
> --enable-elf-shlibs --disable-libuuid --disable-uuidd
> --enable-verbose-makecmds"
> > EXTRA_OECONF_darwin = "--libdir=${base_libdir} --sbindir=${base_sbindir}
> --enable-bsd-shlibs"
> >
> > do_configure_prepend () {
> > cp ${WORKDIR}/acinclude.m4 ${S}/
> > }
> >
> > do_install () {
> > oe_runmake 'DESTDIR=${D}' install
> > oe_runmake 'DESTDIR=${D}' install-libs
> > # We use blkid from util-linux now so remove from here
> > rm -f ${D}${base_libdir}/libblkid*
> > rm -rf ${D}${includedir}/blkid
> > rm -f ${D}${base_libdir}/pkgconfig/blkid.pc
> > rm -f ${D}${base_sbindir}/blkid
> > rm -f ${D}${base_sbindir}/fsck
> > rm -f ${D}${base_sbindir}/findfs
> >
> > # e2initrd_helper and the pkgconfig files belong in libdir
> > if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then
> > install -d ${D}${libdir}
> > mv ${D}${base_libdir}/e2initrd_helper ${D}${libdir}
> > mv ${D}${base_libdir}/pkgconfig ${D}${libdir}
> > fi
> >
> > oe_multilib_header ext2fs/ext2_types.h
> > install -d ${D}${base_bindir}
> > mv ${D}${bindir}/chattr ${D}${base_bindir}/chattr.e2fsprogs
> >
> > install -v -m 755 ${S}/contrib/populate-extfs.sh ${D}${base_sbindir}/
> > }
> >
> > do_install_append_class-target() {
> > # Clean host path in compile_et, mk_cmds
> > sed -i -e "s,ET_DIR=\"${S}/lib/et\",ET_DIR=\"${datadir}/et\",g"
> ${D}${bindir}/compile_et
> > sed -i -e "s,SS_DIR=\"${S}/lib/ss\",SS_DIR=\"${datadir}/ss\",g"
> ${D}${bindir}/mk_cmds
> > }
> >
> > RDEPENDS_e2fsprogs = "e2fsprogs-badblocks"
> > RRECOMMENDS_e2fsprogs = "e2fsprogs-mke2fs e2fsprogs-e2fsck"
> >
> > PACKAGES =+ "e2fsprogs-e2fsck e2fsprogs-mke2fs e2fsprogs-tune2fs
> e2fsprogs-badblocks e2fsprogs-resize2fs"
> > PACKAGES =+ "libcomerr libss libe2p libext2fs"
> >
> > FILES_e2fsprogs-resize2fs = "${base_sbindir}/resize2fs*"
> > FILES_e2fsprogs-e2fsck = "${base_sbindir}/e2fsck
> ${base_sbindir}/fsck.ext*"
> > FILES_e2fsprogs-mke2fs = "${base_sbindir}/mke2fs
> ${base_sbindir}/mkfs.ext* ${sysconfdir}/mke2fs.conf"
> > FILES_e2fsprogs-tune2fs = "${base_sbindir}/tune2fs
> ${base_sbindir}/e2label"
> > FILES_e2fsprogs-badblocks = "${base_sbindir}/badblocks"
> > FILES_libcomerr = "${base_libdir}/libcom_err.so.*"
> > FILES_libss = "${base_libdir}/libss.so.*"
> > FILES_libe2p = "${base_libdir}/libe2p.so.*"
> > FILES_libext2fs = 

Re: [yocto] resize2fs

[Nicolas Dechesne]

Le 13 oct. 2016 08:44, "Peter Balazovic"  a
écrit :
>
> Dears,
>
> I just build the yocto image and within local.conf I got
>
> IMAGE_INSTALL_append = "e2fsprogs"

First, you need an extra space when you use _append operator.

.
>
> but unfortunately I do not get resize2fs utility installed. I do not not
why?

Then if you look at the recipe each app is packaged separately so that you
can pick and choose only the one you need. So you need to include
e2fsprogs-resize2fs

> this how e2fsprogs_1.42.9.bb looks like
>
>
>
> require e2fsprogs.inc
>
>
> SRC_URI += "file://acinclude.m4 \
> file://remove.ldconfig.call.patch \
> file://fix-icache.patch \
> file://quiet-debugfs.patch \
>
file://0001-mke2fs-add-the-ability-to-copy-files-from-a-given-di.patch \
> file://0002-misc-create_inode.c-copy-files-recursively.patch \
> file://0003-misc-create_inode.c-create-special-file.patch \
> file://0004-misc-create_inode.c-create-symlink.patch \
> file://0005-misc-create_inode.c-copy-regular-file.patch \
> file://0006-misc-create_inode.c-create-directory.patch \
>
file://0007-misc-create_inode.c-set-owner-mode-time-for-the-inod.patch \
> file://0008-mke2fs.c-add-an-option-d-root-directory.patch \
> file://0009-misc-create_inode.c-handle-hardlinks.patch \
>
file://0010-debugfs-use-the-functions-in-misc-create_inode.c.patch \
>
file://0011-mke2fs.8.in-update-the-manual-for-the-d-option.patch \
> file://0012-Fix-musl-build-failures.patch \
> file://0001-e2fsprogs-fix-cross-compilation-problem.patch \
>
file://misc-mke2fs.c-return-error-when-failed-to-populate-fs.patch \
> file://cache_inode.patch \
> file://CVE-2015-0247.patch \
>
file://0001-libext2fs-fix-potential-buffer-overflow-in-closefs.patch \
> "
>
> SRC_URI[md5sum] = "3f8e41e63b432ba114b33f58674563f7"
> SRC_URI[sha256sum] =
"2f92ac06e92fa00f2ada3ee67dad012d74d685537527ad1241d82f2d041f2802"
>
> EXTRA_OECONF += "--libdir=${base_libdir} --sbindir=${base_sbindir}
--enable-elf-shlibs --disable-libuuid --disable-uuidd
--enable-verbose-makecmds"
> EXTRA_OECONF_darwin = "--libdir=${base_libdir} --sbindir=${base_sbindir}
--enable-bsd-shlibs"
>
> do_configure_prepend () {
> cp ${WORKDIR}/acinclude.m4 ${S}/
> }
>
> do_install () {
> oe_runmake 'DESTDIR=${D}' install
> oe_runmake 'DESTDIR=${D}' install-libs
> # We use blkid from util-linux now so remove from here
> rm -f ${D}${base_libdir}/libblkid*
> rm -rf ${D}${includedir}/blkid
> rm -f ${D}${base_libdir}/pkgconfig/blkid.pc
> rm -f ${D}${base_sbindir}/blkid
> rm -f ${D}${base_sbindir}/fsck
> rm -f ${D}${base_sbindir}/findfs
>
> # e2initrd_helper and the pkgconfig files belong in libdir
> if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then
> install -d ${D}${libdir}
> mv ${D}${base_libdir}/e2initrd_helper ${D}${libdir}
> mv ${D}${base_libdir}/pkgconfig ${D}${libdir}
> fi
>
> oe_multilib_header ext2fs/ext2_types.h
> install -d ${D}${base_bindir}
> mv ${D}${bindir}/chattr ${D}${base_bindir}/chattr.e2fsprogs
>
> install -v -m 755 ${S}/contrib/populate-extfs.sh ${D}${base_sbindir}/
> }
>
> do_install_append_class-target() {
> # Clean host path in compile_et, mk_cmds
> sed -i -e "s,ET_DIR=\"${S}/lib/et\",ET_DIR=\"${datadir}/et\",g"
${D}${bindir}/compile_et
> sed -i -e "s,SS_DIR=\"${S}/lib/ss\",SS_DIR=\"${datadir}/ss\",g"
${D}${bindir}/mk_cmds
> }
>
> RDEPENDS_e2fsprogs = "e2fsprogs-badblocks"
> RRECOMMENDS_e2fsprogs = "e2fsprogs-mke2fs e2fsprogs-e2fsck"
>
> PACKAGES =+ "e2fsprogs-e2fsck e2fsprogs-mke2fs e2fsprogs-tune2fs
e2fsprogs-badblocks e2fsprogs-resize2fs"
> PACKAGES =+ "libcomerr libss libe2p libext2fs"
>
> FILES_e2fsprogs-resize2fs = "${base_sbindir}/resize2fs*"
> FILES_e2fsprogs-e2fsck = "${base_sbindir}/e2fsck
${base_sbindir}/fsck.ext*"
> FILES_e2fsprogs-mke2fs = "${base_sbindir}/mke2fs
${base_sbindir}/mkfs.ext* ${sysconfdir}/mke2fs.conf"
> FILES_e2fsprogs-tune2fs = "${base_sbindir}/tune2fs
${base_sbindir}/e2label"
> FILES_e2fsprogs-badblocks = "${base_sbindir}/badblocks"
> FILES_libcomerr = "${base_libdir}/libcom_err.so.*"
> FILES_libss = "${base_libdir}/libss.so.*"
> FILES_libe2p = "${base_libdir}/libe2p.so.*"
> FILES_libext2fs = "${libdir}/e2initrd_helper
${base_libdir}/libext2fs.so.*"
> FILES_${PN}-dev += "${datadir}/*/*.awk ${datadir}/*/*.sed
${base_libdir}/*.so"
>
> BBCLASSEXTEND = "native nativesdk"
>
> inherit update-alternatives
>
> ALTERNATIVE_${PN} = "chattr"
> ALTERNATIVE_PRIORITY = "100"
> ALTERNATIVE_LINK_NAME[chattr] = "${base_bindir}/chattr"
> ALTERNATIVE_TARGET[chattr] = "${base_bindir}/chattr.e2fsprogs"
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] resize2fs

[Peter Balazovic]

Dears,

I just build the yocto image and within local.conf I got

IMAGE_INSTALL_append = "e2fsprogs"

but unfortunately I do not get resize2fs utility installed. I do not not
why?

this how e2fsprogs_1.42.9.bb looks like



require e2fsprogs.inc


SRC_URI += "file://acinclude.m4 \
file://remove.ldconfig.call.patch \
file://fix-icache.patch \
file://quiet-debugfs.patch \

file://0001-mke2fs-add-the-ability-to-copy-files-from-a-given-di.patch \
file://0002-misc-create_inode.c-copy-files-recursively.patch \
file://0003-misc-create_inode.c-create-special-file.patch \
file://0004-misc-create_inode.c-create-symlink.patch \
file://0005-misc-create_inode.c-copy-regular-file.patch \
file://0006-misc-create_inode.c-create-directory.patch \

file://0007-misc-create_inode.c-set-owner-mode-time-for-the-inod.patch \
file://0008-mke2fs.c-add-an-option-d-root-directory.patch \
file://0009-misc-create_inode.c-handle-hardlinks.patch \

file://0010-debugfs-use-the-functions-in-misc-create_inode.c.patch \

file://0011-mke2fs.8.in-update-the-manual-for-the-d-option.patch \
file://0012-Fix-musl-build-failures.patch \
file://0001-e2fsprogs-fix-cross-compilation-problem.patch \

file://misc-mke2fs.c-return-error-when-failed-to-populate-fs.patch \
file://cache_inode.patch \
file://CVE-2015-0247.patch \

file://0001-libext2fs-fix-potential-buffer-overflow-in-closefs.patch \
"

SRC_URI[md5sum] = "3f8e41e63b432ba114b33f58674563f7"
SRC_URI[sha256sum] =
"2f92ac06e92fa00f2ada3ee67dad012d74d685537527ad1241d82f2d041f2802"

EXTRA_OECONF += "--libdir=${base_libdir} --sbindir=${base_sbindir}
--enable-elf-shlibs --disable-libuuid --disable-uuidd
--enable-verbose-makecmds"
EXTRA_OECONF_darwin = "--libdir=${base_libdir} --sbindir=${base_sbindir}
--enable-bsd-shlibs"

do_configure_prepend () {
cp ${WORKDIR}/acinclude.m4 ${S}/
}

do_install () {
oe_runmake 'DESTDIR=${D}' install
oe_runmake 'DESTDIR=${D}' install-libs
# We use blkid from util-linux now so remove from here
rm -f ${D}${base_libdir}/libblkid*
rm -rf ${D}${includedir}/blkid
rm -f ${D}${base_libdir}/pkgconfig/blkid.pc
rm -f ${D}${base_sbindir}/blkid
rm -f ${D}${base_sbindir}/fsck
rm -f ${D}${base_sbindir}/findfs

# e2initrd_helper and the pkgconfig files belong in libdir
if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then
install -d ${D}${libdir}
mv ${D}${base_libdir}/e2initrd_helper ${D}${libdir}
mv ${D}${base_libdir}/pkgconfig ${D}${libdir}
fi

oe_multilib_header ext2fs/ext2_types.h
install -d ${D}${base_bindir}
mv ${D}${bindir}/chattr ${D}${base_bindir}/chattr.e2fsprogs

install -v -m 755 ${S}/contrib/populate-extfs.sh ${D}${base_sbindir}/
}

do_install_append_class-target() {
# Clean host path in compile_et, mk_cmds
sed -i -e "s,ET_DIR=\"${S}/lib/et\",ET_DIR=\"${datadir}/et\",g"
${D}${bindir}/compile_et
sed -i -e "s,SS_DIR=\"${S}/lib/ss\",SS_DIR=\"${datadir}/ss\",g"
${D}${bindir}/mk_cmds
}

RDEPENDS_e2fsprogs = "e2fsprogs-badblocks"
RRECOMMENDS_e2fsprogs = "e2fsprogs-mke2fs e2fsprogs-e2fsck"

PACKAGES =+ "e2fsprogs-e2fsck e2fsprogs-mke2fs e2fsprogs-tune2fs
e2fsprogs-badblocks e2fsprogs-resize2fs"
PACKAGES =+ "libcomerr libss libe2p libext2fs"

FILES_e2fsprogs-resize2fs = "${base_sbindir}/resize2fs*"
FILES_e2fsprogs-e2fsck = "${base_sbindir}/e2fsck ${base_sbindir}/fsck.ext*"
FILES_e2fsprogs-mke2fs = "${base_sbindir}/mke2fs ${base_sbindir}/mkfs.ext*
${sysconfdir}/mke2fs.conf"
FILES_e2fsprogs-tune2fs = "${base_sbindir}/tune2fs ${base_sbindir}/e2label"
FILES_e2fsprogs-badblocks = "${base_sbindir}/badblocks"
FILES_libcomerr = "${base_libdir}/libcom_err.so.*"
FILES_libss = "${base_libdir}/libss.so.*"
FILES_libe2p = "${base_libdir}/libe2p.so.*"
FILES_libext2fs = "${libdir}/e2initrd_helper ${base_libdir}/libext2fs.so.*"
FILES_${PN}-dev += "${datadir}/*/*.awk ${datadir}/*/*.sed
${base_libdir}/*.so"

BBCLASSEXTEND = "native nativesdk"

inherit update-alternatives

ALTERNATIVE_${PN} = "chattr"
ALTERNATIVE_PRIORITY = "100"
ALTERNATIVE_LINK_NAME[chattr] = "${base_bindir}/chattr"
ALTERNATIVE_TARGET[chattr] = "${base_bindir}/chattr.e2fsprogs"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Resizing root flash partition/filesystem on first boot

[Peter Balazovic]

Hello Jason,

I'm interested in your code + BitBake recipe to be able to *automatically
resize on first boot*.

Thank you.
Peter
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto