Re: [yocto] meta-sunxi maintained?

[Dimitris Tassopoulos]

Hi Belisko,

you can also have a look in to this layer:
http://layers.openembedded.org/layerindex/branch/master/layer/meta-allwinner-hx/
It's for allwinner H2,H3 and H5 boards that already have support on Armbian.
Pretty much is just a Yocto layer with all the patches and BSP support from
Armbian.
It supports 4.14 and 4.19 mainline kernels only and also the PREEMPT-RT
patches.
Warrior support was added recently, too.

A similar one is also this:
http://layers.openembedded.org/layerindex/branch/master/layer/meta-nanopi-neo4/

Dimitris

On Mon, May 27, 2019 at 7:33 PM Belisko Marek 
wrote:

> Hi Enrico,
>
> On Mon, May 27, 2019 at 5:44 PM Enrico 
> wrote:
> >
> > Hi,
> >
> > i try to keep it maintained, but now i just have a lime2 for testing
> > on real hardware, and i don't have the resources to do test builds for
> > all the supported boards.
> > Your help would be welcome, i can't check right now if i have the
> > rights to add you as co-maintainer, anyway i will add you.
> Thanks I have few sunxi based boards so can do tests also on my setup.
> Pls ping me when you will add me. Thanks.
> >
> > Thanks for the help!
> >
> > Enrico
>
> Marek
> >
> > On Mon, May 27, 2019 at 4:50 PM Belisko Marek 
> wrote:
> > >
> > > Hello,
> > >
> > > I'm just curious if meta-sunxi is still maintained? I was contributed
> > > to layer back while and when look now thud branch is un-compilable
> > > (dri2proto not replaced) and warrior branch not created yet. There is
> > > 14 issues + 6 pending pull requests. Added maintainers also in CC. I
> > > think it would be good to have sunxi properly maintained as boards
> > > with sunxi processors are popular. I can give a hand as co-maintainer
> > > if necessary. Thanks a lot.
> > >
> > > BR,
> > >
> > > marek
> > >
> > > --
> > > as simple and primitive as possible
> > > -
> > > Marek Belisko - OPEN-NANDRA
> > > Freelance Developer
> > >
> > > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> > > Tel: +421 915 052 184
> > > skype: marekwhite
> > > twitter: #opennandra
> > > web: http://open-nandra.com
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [poky] yocto is unstable to build final image when recipe has slash in SRCBRANCH

[Paul Barker]

On 24/05/2019 20:38, Davis Roman wrote:

Hello,

In my recipe, I've found that a forward slash in SRCBRANCH, results in 
an error during the final image construction,


SRCBRANCH = "feature/compile_with_gcc7_4_rocko_toolchain"


Error given:

Collected errors:
  * opkg_prepare_url_for_install: Couldn't find anything to satisfy 
'tron-app'.


ERROR: tron-image-grip-1.0-r0 do_rootfs: Function failed: do_rootfs


Does anyone have a way to make the slash in the SRCBRANCH variable work?



SRCBRANCH is not a standard variable to my knowledge. You'll probably 
have to give some more specific info on the recipe that's using it, what 
bitbake command you ran and the full error message.


Thanks,

--
Paul Barker
Managing Director & Principal Engineer
Beta Five Ltd
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building single package as image, respecting dependencies

[Paul Barker]

On 24/05/2019 15:28, Norman Stetter wrote:
Is there no way to simply force bitbake to only build the packages I 
want, ignoring dependencies? We used to build the image like this 
before, using PTXDist.


Everything else seems to be a dirty hack.


Can you just collect the extra packages (ipk/deb/rpm as appropriate), 
put them in a package feed and install them on-target as required?


The package feed doesn't have to be on a webserver, you could put it in 
a directory in a separate partition on the target if that's what you need.


Thanks,

--
Paul Barker
Managing Director & Principal Engineer
Beta Five Ltd
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-sunxi maintained?

[Maciej Pijanowski]

On 27.05.2019 19:32, Belisko Marek wrote:
> Hi Enrico,
Hi,
>
> On Mon, May 27, 2019 at 5:44 PM Enrico  wrote:
>> Hi,
>>
>> i try to keep it maintained, but now i just have a lime2 for testing
>> on real hardware, and i don't have the resources to do test builds for
>> all the supported boards.
>> Your help would be welcome, i can't check right now if i have the
>> rights to add you as co-maintainer, anyway i will add you.
> Thanks I have few sunxi based boards so can do tests also on my setup.
> Pls ping me when you will add me. Thanks.
>> Thanks for the help!
>>
>> Enrico
> Marek
>> On Mon, May 27, 2019 at 4:50 PM Belisko Marek  
>> wrote:
>>> Hello,
>>>
>>> I'm just curious if meta-sunxi is still maintained? I was contributed
>>> to layer back while and when look now thud branch is un-compilable
>>> (dri2proto not replaced) and warrior branch not created yet. There is
>>> 14 issues + 6 pending pull requests. Added maintainers also in CC. I
>>> think it would be good to have sunxi properly maintained as boards
>>> with sunxi processors are popular. I can give a hand as co-maintainer
>>> if necessary. Thanks a lot.
I think I have some of the dirty code for integration of the recent Mali
blobs
with the mainline kernel as described here:
https://bootlin.com/blog/more-opengl-binaries-for-the-mali-support-on-allwinner-platforms-with-mainline-linux/
We were testing Qt + Wayland on mainline Linux IIRC.
Let me know if you think this could be beneficial to the community.
We are not actively using at the moment, though. meta-sunxi was not that
active when we worked on
that so maybe we were not motivated enough to polish things up and
submit a PR.

We use orange-pi-zero as a base for our product we use for on-hardware
validation:
https://3mdeb.com/products/open-source-hardware/rte/ so I believe we can
help
with maintenance of this platform / SoC (we use meta-sunxi for building
images for it:
https://github.com/3mdeb/meta-rte).
We have quite a number of other Allwinner platforms as well (H3 and A20
mostly).

>>>
>>> BR,
>>>
>>> marek
>>>
>>> --
>>> as simple and primitive as possible
>>> -
>>> Marek Belisko - OPEN-NANDRA
>>> Freelance Developer
>>>
>>> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
>>> Tel: +421 915 052 184
>>> skype: marekwhite
>>> twitter: #opennandra
>>> web: http://open-nandra.com

-- 
Maciej Pijanowski
Embedded Systems Engineer
https://3mdeb.com | @3mdeb_com




signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-sunxi maintained?

[Belisko Marek]

Hi Dimitris,

On Tue, May 28, 2019 at 11:01 AM Dimitris Tassopoulos  wrote:
>
> Hi Belisko,
>
> you can also have a look in to this layer: 
> http://layers.openembedded.org/layerindex/branch/master/layer/meta-allwinner-hx/
> It's for allwinner H2,H3 and H5 boards that already have support on Armbian.
> Pretty much is just a Yocto layer with all the patches and BSP support from 
> Armbian.
> It supports 4.14 and 4.19 mainline kernels only and also the PREEMPT-RT 
> patches.
> Warrior support was added recently, too.
OK thanks. I think I'll stick with meta-sunxi ;). What about join
forces and maintains one layer properly instead having it separated?
>
> A similar one is also this: 
> http://layers.openembedded.org/layerindex/branch/master/layer/meta-nanopi-neo4/
>
> Dimitris
>
> On Mon, May 27, 2019 at 7:33 PM Belisko Marek  wrote:
>>
>> Hi Enrico,
>>
>> On Mon, May 27, 2019 at 5:44 PM Enrico  wrote:
>> >
>> > Hi,
>> >
>> > i try to keep it maintained, but now i just have a lime2 for testing
>> > on real hardware, and i don't have the resources to do test builds for
>> > all the supported boards.
>> > Your help would be welcome, i can't check right now if i have the
>> > rights to add you as co-maintainer, anyway i will add you.
>> Thanks I have few sunxi based boards so can do tests also on my setup.
>> Pls ping me when you will add me. Thanks.
>> >
>> > Thanks for the help!
>> >
>> > Enrico
>>
>> Marek
>> >
>> > On Mon, May 27, 2019 at 4:50 PM Belisko Marek  
>> > wrote:
>> > >
>> > > Hello,
>> > >
>> > > I'm just curious if meta-sunxi is still maintained? I was contributed
>> > > to layer back while and when look now thud branch is un-compilable
>> > > (dri2proto not replaced) and warrior branch not created yet. There is
>> > > 14 issues + 6 pending pull requests. Added maintainers also in CC. I
>> > > think it would be good to have sunxi properly maintained as boards
>> > > with sunxi processors are popular. I can give a hand as co-maintainer
>> > > if necessary. Thanks a lot.
>> > >
>> > > BR,
>> > >
>> > > marek
>> > >
>> > > --
>> > > as simple and primitive as possible
>> > > -
>> > > Marek Belisko - OPEN-NANDRA
>> > > Freelance Developer
>> > >
>> > > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
>> > > Tel: +421 915 052 184
>> > > skype: marekwhite
>> > > twitter: #opennandra
>> > > web: http://open-nandra.com
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto



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

Re: [yocto] meta-sunxi maintained?

[Belisko Marek]

Hi Maciej,


On Tue, May 28, 2019 at 11:48 AM Maciej Pijanowski
 wrote:
>
>
> On 27.05.2019 19:32, Belisko Marek wrote:
> > Hi Enrico,
> Hi,
> >
> > On Mon, May 27, 2019 at 5:44 PM Enrico  
> > wrote:
> >> Hi,
> >>
> >> i try to keep it maintained, but now i just have a lime2 for testing
> >> on real hardware, and i don't have the resources to do test builds for
> >> all the supported boards.
> >> Your help would be welcome, i can't check right now if i have the
> >> rights to add you as co-maintainer, anyway i will add you.
> > Thanks I have few sunxi based boards so can do tests also on my setup.
> > Pls ping me when you will add me. Thanks.
> >> Thanks for the help!
> >>
> >> Enrico
> > Marek
> >> On Mon, May 27, 2019 at 4:50 PM Belisko Marek  
> >> wrote:
> >>> Hello,
> >>>
> >>> I'm just curious if meta-sunxi is still maintained? I was contributed
> >>> to layer back while and when look now thud branch is un-compilable
> >>> (dri2proto not replaced) and warrior branch not created yet. There is
> >>> 14 issues + 6 pending pull requests. Added maintainers also in CC. I
> >>> think it would be good to have sunxi properly maintained as boards
> >>> with sunxi processors are popular. I can give a hand as co-maintainer
> >>> if necessary. Thanks a lot.
> I think I have some of the dirty code for integration of the recent Mali
> blobs
> with the mainline kernel as described here:
> https://bootlin.com/blog/more-opengl-binaries-for-the-mali-support-on-allwinner-platforms-with-mainline-linux/
> We were testing Qt + Wayland on mainline Linux IIRC.
> Let me know if you think this could be beneficial to the community.
> We are not actively using at the moment, though. meta-sunxi was not that
> active when we worked on
> that so maybe we were not motivated enough to polish things up and
> submit a PR.
Sure. Pls submit PR. Have you seen recent discussion:
https://github.com/linux-sunxi/meta-sunxi/issues/144#issuecomment-496408159
?
Does your work use the same components or? Thanks.
>
> We use orange-pi-zero as a base for our product we use for on-hardware
> validation:
> https://3mdeb.com/products/open-source-hardware/rte/ so I believe we can
> help
> with maintenance of this platform / SoC (we use meta-sunxi for building
> images for it:
> https://github.com/3mdeb/meta-rte).
> We have quite a number of other Allwinner platforms as well (H3 and A20
> mostly).
That would be cool. I plan to spend some time on co-maintaining
meta-sunxi so I hope feedback and merging will be much smoother ;)
>
> >>>
> >>> BR,
> >>>
> >>> marek
> >>>
> >>> --
> >>> as simple and primitive as possible
> >>> -
> >>> Marek Belisko - OPEN-NANDRA
> >>> Freelance Developer
> >>>
> >>> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> >>> Tel: +421 915 052 184
> >>> skype: marekwhite
> >>> twitter: #opennandra
> >>> web: http://open-nandra.com
>
> --
> Maciej Pijanowski
> Embedded Systems Engineer
> https://3mdeb.com | @3mdeb_com
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

BR,

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

Re: [yocto] meta-sunxi maintained?

[Dimitris Tassopoulos]

Hi Belisko,

I was thinking about this also, too. The only reason is that in meta-sunxi
they do a great job and they keep their layer clean, which is great I
think. The other layers are just based on the armbian distro, which is a
lot different, but for me it was much easier to integrate their patches,
patching scripts and bootloader scripts to a Yocto layer. That way the only
thing I do is that from time to time I just integrate their new patches and
that's it. There's no development in the layer is just re-use of the
armbian work and a wrapper around it. Therefore, it's hard, even no doable
to put those different architectures together. But definitely that decision
also bothered me a lot before I create the layer and I also don't like time
to be spend on the same thing from different people. Nevertheless, from my
point of view I couldn't find a way to put those things together. I've
tried but I couldn't do it.

Therefore, it was easier for me to do it the way I've done it. And after
all, although it doesn't seem right, at the same time this is the beauty of
the open source. I think the layers are just incompatible in the way that
they are do things. Also it's not bad to have alternatives.

Sunxi is a great community and I believe many of the armbian patches are
coming from there. Others not. Of course, having them all together would be
nice. But I don't think that it's possible because of the different
approach.

I hope this explains your question and even more that explains that was not
a decision to divide things or create more hassle for the same chips.

Regards,
Dimitris

Belisko Marek  schrieb am Di., 28. Mai 2019, 11:49:

> Hi Dimitris,
>
> On Tue, May 28, 2019 at 11:01 AM Dimitris Tassopoulos 
> wrote:
> >
> > Hi Belisko,
> >
> > you can also have a look in to this layer:
> http://layers.openembedded.org/layerindex/branch/master/layer/meta-allwinner-hx/
> > It's for allwinner H2,H3 and H5 boards that already have support on
> Armbian.
> > Pretty much is just a Yocto layer with all the patches and BSP support
> from Armbian.
> > It supports 4.14 and 4.19 mainline kernels only and also the PREEMPT-RT
> patches.
> > Warrior support was added recently, too.
> OK thanks. I think I'll stick with meta-sunxi ;). What about join
> forces and maintains one layer properly instead having it separated?
> >
> > A similar one is also this:
> http://layers.openembedded.org/layerindex/branch/master/layer/meta-nanopi-neo4/
> >
> > Dimitris
> >
> > On Mon, May 27, 2019 at 7:33 PM Belisko Marek 
> wrote:
> >>
> >> Hi Enrico,
> >>
> >> On Mon, May 27, 2019 at 5:44 PM Enrico 
> wrote:
> >> >
> >> > Hi,
> >> >
> >> > i try to keep it maintained, but now i just have a lime2 for testing
> >> > on real hardware, and i don't have the resources to do test builds for
> >> > all the supported boards.
> >> > Your help would be welcome, i can't check right now if i have the
> >> > rights to add you as co-maintainer, anyway i will add you.
> >> Thanks I have few sunxi based boards so can do tests also on my setup.
> >> Pls ping me when you will add me. Thanks.
> >> >
> >> > Thanks for the help!
> >> >
> >> > Enrico
> >>
> >> Marek
> >> >
> >> > On Mon, May 27, 2019 at 4:50 PM Belisko Marek <
> marek.beli...@gmail.com> wrote:
> >> > >
> >> > > Hello,
> >> > >
> >> > > I'm just curious if meta-sunxi is still maintained? I was
> contributed
> >> > > to layer back while and when look now thud branch is un-compilable
> >> > > (dri2proto not replaced) and warrior branch not created yet. There
> is
> >> > > 14 issues + 6 pending pull requests. Added maintainers also in CC. I
> >> > > think it would be good to have sunxi properly maintained as boards
> >> > > with sunxi processors are popular. I can give a hand as
> co-maintainer
> >> > > if necessary. Thanks a lot.
> >> > >
> >> > > BR,
> >> > >
> >> > > marek
> >> > >
> >> > > --
> >> > > as simple and primitive as possible
> >> > > -
> >> > > Marek Belisko - OPEN-NANDRA
> >> > > Freelance Developer
> >> > >
> >> > > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> >> > > Tel: +421 915 052 184
> >> > > skype: marekwhite
> >> > > twitter: #opennandra
> >> > > web: http://open-nandra.com
> >> --
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
> marek
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-sunxi maintained?

[Belisko Marek]

Hi Dimitris,

On Tue, May 28, 2019 at 12:06 PM Dimitris Tassopoulos  wrote:
>
> Hi Belisko,
>
> I was thinking about this also, too. The only reason is that in meta-sunxi 
> they do a great job and they keep their layer clean, which is great I think. 
> The other layers are just based on the armbian distro, which is a lot 
> different, but for me it was much easier to integrate their patches, patching 
> scripts and bootloader scripts to a Yocto layer. That way the only thing I do 
> is that from time to time I just integrate their new patches and that's it. 
> There's no development in the layer is just re-use of the armbian work and a 
> wrapper around it. Therefore, it's hard, even no doable to put those 
> different architectures together. But definitely that decision also bothered 
> me a lot before I create the layer and I also don't like time to be spend on 
> the same thing from different people. Nevertheless, from my point of view I 
> couldn't find a way to put those things together. I've tried but I couldn't 
> do it.
>
> Therefore, it was easier for me to do it the way I've done it. And after all, 
> although it doesn't seem right, at the same time this is the beauty of the 
> open source. I think the layers are just incompatible in the way that they 
> are do things. Also it's not bad to have alternatives.
>
> Sunxi is a great community and I believe many of the armbian patches are 
> coming from there. Others not. Of course, having them all together would be 
> nice. But I don't think that it's possible because of the different approach.
>
> I hope this explains your question and even more that explains that was not a 
> decision to divide things or create more hassle for the same chips.
Yes certainly. Thanks for great explanation and sorry if I wrote it in
not polite way I didn't mean to offence ;). Thanks.
>
> Regards,
> Dimitris
>
> Belisko Marek  schrieb am Di., 28. Mai 2019, 11:49:
>>
>> Hi Dimitris,
>>
>> On Tue, May 28, 2019 at 11:01 AM Dimitris Tassopoulos  
>> wrote:
>> >
>> > Hi Belisko,
>> >
>> > you can also have a look in to this layer: 
>> > http://layers.openembedded.org/layerindex/branch/master/layer/meta-allwinner-hx/
>> > It's for allwinner H2,H3 and H5 boards that already have support on 
>> > Armbian.
>> > Pretty much is just a Yocto layer with all the patches and BSP support 
>> > from Armbian.
>> > It supports 4.14 and 4.19 mainline kernels only and also the PREEMPT-RT 
>> > patches.
>> > Warrior support was added recently, too.
>> OK thanks. I think I'll stick with meta-sunxi ;). What about join
>> forces and maintains one layer properly instead having it separated?
>> >
>> > A similar one is also this: 
>> > http://layers.openembedded.org/layerindex/branch/master/layer/meta-nanopi-neo4/
>> >
>> > Dimitris
>> >
>> > On Mon, May 27, 2019 at 7:33 PM Belisko Marek  
>> > wrote:
>> >>
>> >> Hi Enrico,
>> >>
>> >> On Mon, May 27, 2019 at 5:44 PM Enrico  
>> >> wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > i try to keep it maintained, but now i just have a lime2 for testing
>> >> > on real hardware, and i don't have the resources to do test builds for
>> >> > all the supported boards.
>> >> > Your help would be welcome, i can't check right now if i have the
>> >> > rights to add you as co-maintainer, anyway i will add you.
>> >> Thanks I have few sunxi based boards so can do tests also on my setup.
>> >> Pls ping me when you will add me. Thanks.
>> >> >
>> >> > Thanks for the help!
>> >> >
>> >> > Enrico
>> >>
>> >> Marek
>> >> >
>> >> > On Mon, May 27, 2019 at 4:50 PM Belisko Marek  
>> >> > wrote:
>> >> > >
>> >> > > Hello,
>> >> > >
>> >> > > I'm just curious if meta-sunxi is still maintained? I was contributed
>> >> > > to layer back while and when look now thud branch is un-compilable
>> >> > > (dri2proto not replaced) and warrior branch not created yet. There is
>> >> > > 14 issues + 6 pending pull requests. Added maintainers also in CC. I
>> >> > > think it would be good to have sunxi properly maintained as boards
>> >> > > with sunxi processors are popular. I can give a hand as co-maintainer
>> >> > > if necessary. Thanks a lot.
>> >> > >
>> >> > > BR,
>> >> > >
>> >> > > marek
>> >> > >
>> >> > > --
>> >> > > as simple and primitive as possible
>> >> > > -
>> >> > > Marek Belisko - OPEN-NANDRA
>> >> > > Freelance Developer
>> >> > >
>> >> > > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
>> >> > > Tel: +421 915 052 184
>> >> > > skype: marekwhite
>> >> > > twitter: #opennandra
>> >> > > web: http://open-nandra.com
>> >> --
>> >> ___
>> >> yocto mailing list
>> >> yocto@yoctoproject.org
>> >> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>
>> marek

BR,

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

Re: [yocto] [meta-swupdate] build fails under thud

[Moritz Porst]

Hello Matthias,

Thank you, your help is much appreciated. Seems I have misunderstood how
to add swupdate to my image. However the swupdate package somehow has to
put an initramfs in place since to my understanding it is also possible
to do updates without 2 rootfs available which would require an update
through the initramfs.

Anyway, thank you again ! This should make it work

On 27/05/2019 18:59, Matthias Schoepfer wrote:


Hi Moritz,

I will try to answer what I can inline:

On 5/27/19 5:05 PM, Moritz Porst wrote:

Hi Matthias
Thank you very much for your help, this is not mentioned in the
official repository.
I tried what you said. It enables me (even without .bbappend) to
build the swupdate-image.
Now for the defconfig. I did it with a .bbappend the way the yocto
documentation suggests (FILESEXTRAPATHS and SRC_URI) but which recipe
do I need to append to? I thought just choose swupdate_git.bb, then
swupdate_2018.11.bb. I always receive the following rootfs file:

you can either bbappend the _2018.11 or make a swupdate_%.bbappend,
that is then valid for both _git and _2018.11 if you happen to use the
_git version.

swupdate-image-ccns5.ext4.gz.u-boot   (Clearly still uboot, I don't
know why it managed to build though)
Also I get the following warning on invoking bitbake for swupdate-image:
WARNING:
/opt/thudPoky/meta-swupdate/recipes-support/swupdate/swupdate_2018.11.bb.do_compile
is tainted from a forced run

This is because you bitbake -c menuconfig swupdate. If you clean the
build (bitbake -c cleansstate swupdate), this should disappear. Then
you can check, if your bbappend gets picked up correctly.

Finally I always end up with microcode.cpio in my /boot directory
which comes from meta-intel. I guess swupdate would replace the
initrd/initramfs ?
I put the following lines in my image description:
INITRAMFS_IMAGE = "swupdate-image-ccns5"
INITRAMFS_IMAGE_BUNDLE = "1"
Shouldn't they cause the swupdate-image to be bundled into the
kernel, thus that if I build my image that I end up with the swupdate
initramfs in my /boot directory ?


Errr you want to *add* swupdate to an image recipe. It is not an
image by itself. Well, I guess, there is a rescue image within
swupdate, but that is a different story and I have no experience with
it. There are ways to add packages to an image, for example through
IMAGE_INSTALL_append = " swupdate " in local.conf

https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#usingpoky-extend-customimage-localconf


Sorry for all the questions and thanks in advance !
Best regards
Moritz
*Gesendet:* Montag, 27. Mai 2019 um 15:31 Uhr
*Von:* "Matthias Schoepfer" 
*An:* yocto@yoctoproject.org
*Betreff:* Re: [yocto] [meta-swupdate] build fails under thud

Hi Moritz!

You need to configure swupdate kind of like the linux kernel with
menuconfig:

bitbake -c menuconfig swupdate

do not forget to copy your config then into an bbappend to swupdate
(defconfig).

Hope that helps,

Regards,

   Matthias

On 5/27/19 3:26 PM, Moritz Porst wrote:

Hello
I want to create an update mechanism for our embedded system. I
chose swupdate because it is very well documented and seems flexible.
When trying to build swupdate-image it fails with several
undefined references, just a few as example:
"""

/opt/thudPoky/build/tmp/work/corei7-64-poky-linux/swupdate/2018.11-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/8.2.0/ld:
bootloader/lib.a(uboot.o): in function `bootloader_env_set':
| uboot.c:(.text.bootloader_env_set+0x40): undefined reference to
`fw_env_open'
|

/opt/thudPoky/build/tmp/work/corei7-64-poky-linux/swupdate/2018.11-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/8.2.0/ld:
uboot.c:(.text.bootloader_env_set+0xf8): undefined reference to
`fw_env_write'
"""
I see lots of "uboot" in the trace, but to my understanding
swupdate should also work with grub which I enabled using:
EFI_PROVIDER = "grub-efi"    (First tried to use
PREFERRED_PROVIDER_virtual/bootloader, but this doesn't work with
EFI booting)
When I want to enable "uboot" this way, bitbake tells me there is
no uboot.
I know there is also the option of writing my own init scripts
but this would be just reinventing the wheel (given there is an
swupdate available) and probably more error-prone than a grown
update tool. Thus I would like to get swupdate to work.
Any ideas ?
Best regards
Moritz

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



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

Re: [yocto] meta-sunxi maintained?

[Dimitris Tassopoulos]

Hi Enrico,

I'm totally positive to any possibility for such integration. Personally,
that was the first thing I've tried to do before I start this layer, but
I've failed as it got really complex and the overhead was too much after
some point (at least for me). If you have look it's actually a mix of
meta-sunxi and armbian, but I had to remove or change many stuff to fit the
armbian in the layer.

If you have time to have a look to my layer and you think that such kind of
integration is possible and can be done in a more easy way, then from my
side I'm all in.
I believe that re-using the armbian patches is easier as it makes
maintenance much easier, there are more supported SBCs and also there is
much more testing involved in armbian and frequent updates fix those bugs.

Please consider it and I can help as much as I can and my time allows for
that integration.

Regards,
Dimitris



On Tue, May 28, 2019 at 12:56 PM Enrico 
wrote:

> On Tue, May 28, 2019 at 12:06 PM Dimitris Tassopoulos 
> wrote:
> >
> > >
> > > I was thinking about this also, too. The only reason is that in
> meta-sunxi they do a great job and they keep their layer clean, which is
> great I think. The other layers are just based on the armbian distro, which
> is a lot different, but for me it was much easier to integrate their
> patches, patching scripts and bootloader scripts to a Yocto layer. That way
> the only thing I do is that from time to time I just integrate their new
> patches and that's it. There's no development in the layer is just re-use
> of the armbian work and a wrapper around it. Therefore, it's hard, even no
> doable to put those different architectures together. But definitely that
> decision also bothered me a lot before I create the layer and I also don't
> like time to be spend on the same thing from different people.
> Nevertheless, from my point of view I couldn't find a way to put those
> things together. I've tried but I couldn't do it.
> > >
> > > Therefore, it was easier for me to do it the way I've done it. And
> after all, although it doesn't seem right, at the same time this is the
> beauty of the open source. I think the layers are just incompatible in the
> way that they are do things. Also it's not bad to have alternatives.
> > >
> > > Sunxi is a great community and I believe many of the armbian patches
> are coming from there. Others not. Of course, having them all together
> would be nice. But I don't think that it's possible because of the
> different approach.
>
> It would be great to integrate all those different layers in
> meta-sunxi,the main problem is that usually they come with their own
> bootloader/kernel/etc so you have to *maintain* all these
> different configurations.
> Infact in the past i refused to do such things because i didn't have
> the time to maintain all those different versions, it was just easier
> to support what was already in mainline uboot/kernel.
>
> But of course if someone wants to do it then it's welcome, the worst
> thing that can happen is that once an arch gets unmaintained it will
> be removed.
>
> One thing that can be done anyway is to have those external layers
> linked in the readme, so at least people will know they exist.
>
> Enrico
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] building SDK fails due to libssp missing

[Georgi Georgiev]

Hello community,
Recently our project switched to yocto 2.6.2 "thud" due to a lot of requests 
from SW team for too many package newer versions.
The issue is that when building the image with populate_sdk command it fails 
with the following:
.../tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-perl/5.24.4-r0/recipe-sysroot-native/usr/bin/x86_64-pokysdk-linux/../../libexec/x86_64-pokysdk-linux/gcc/x86_64-pokysdk-linux/7.1.1/ld:
 cannot find -lssp_nonshared
.../tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-perl/5.24.4-r0/recipe-sysroot-native/usr/bin/x86_64-pokysdk-linux/../../libexec/x86_64-pokysdk-linux/gcc/x86_64-pokysdk-linux/7.1.1/ld:
 cannot find -lssp
Any suggestions?

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

[yocto] monit lcrypt issue

[Ronan GAILLARD]

monit lcrypt issue:  Expose lcrypt while building monit with Yocto Thud

When building monit using Yocto Thud the following error pops while building 
monit 5.25.2 :
/usr/src/debug/monit/5.25.2-r0/monit-5.25.2/src/util.c:1675: undefined 
reference to `crypt’

Older versions of glibc supplied a libcrypt library for this purpose, and 
declared the function in .
Newer versions of glibc don't supply libcrypt. In order to prevent the 
undefined lcrypt error we need to add virtual/crypt to the recipe’s DEPENDS

Signed-off-by: Ronan Gaillard 
mailto:ronan.gaill...@live.fr>>
—

diff --git a/meta-cgl-common/recipes-cgl/monit/monit_5.25.2.bb 
b/meta-cgl-common/recipes-cgl/monit/monit_5.25.2.bb
index ab9e922..7a96722 100644
--- a/meta-cgl-common/recipes-cgl/monit/monit_5.25.2.bb
+++ b/meta-cgl-common/recipes-cgl/monit/monit_5.25.2.bb
@@ -9,7 +9,7 @@ HOMEPAGE = "http://mmonit.com/monit/";
 LICENSE = "AGPLv3"
 LIC_FILES_CHKSUM = "file://COPYING;md5=ea116a7defaf0e93b3bb73b2a34a3f51"

-DEPENDS = "openssl zlib"
+DEPENDS = "openssl zlib virtual/crypt"

 SRC_URI = "\
http://mmonit.com/monit/dist/${BP}.tar.gz \

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

[yocto] [prelink-cross][PATCH] Enable prelink-cross to work on binaries built with -fno-plt

[Shane Peelar]

Make an assert in arch-x86_64.c a conditional if to handle things the same
way as other arches.
Enables binaries built with -fno-plt to be prelinked.


0001-arch-x86_64.c-Make-assert-conditional.patch
Description: Binary data
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] samhain: add rconflict for client and server mode

[akuster808]

On 5/27/19 7:37 PM, changqing...@windriver.com wrote:
> From: Changqing Li 
>
> Signed-off-by: Changqing Li 

merged. 

thanks,
Armin
> ---
>  recipes-ids/samhain/samhain-client_4.3.2.bb | 1 +
>  recipes-ids/samhain/samhain-server_4.3.2.bb | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/recipes-ids/samhain/samhain-client_4.3.2.bb 
> b/recipes-ids/samhain/samhain-client_4.3.2.bb
> index 812408e..0f53a8c 100644
> --- a/recipes-ids/samhain/samhain-client_4.3.2.bb
> +++ b/recipes-ids/samhain/samhain-client_4.3.2.bb
> @@ -9,3 +9,4 @@ EXTRA_OECONF += " \
>  "
>  
>  RDEPENDS_${PN} = "acl zlib attr bash"
> +RCONFLICTS_${PN} = "samhain-standalone"
> diff --git a/recipes-ids/samhain/samhain-server_4.3.2.bb 
> b/recipes-ids/samhain/samhain-server_4.3.2.bb
> index 9341d44..d304912 100644
> --- a/recipes-ids/samhain/samhain-server_4.3.2.bb
> +++ b/recipes-ids/samhain/samhain-server_4.3.2.bb
> @@ -18,3 +18,4 @@ do_install_append() {
>  }
>  
>  RDEPENDS_${PN} += "gmp bash perl"
> +RCONFLICTS_${PN} = "samhain-standalone"

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

[yocto] Yocto Project Status WW22'19

[Richard Purdie]

Current Dev Position: YP 2.8 M1Next Deadline: YP 2.8 Milestone 1 Cutoff
June 9th, 2019
SWAT Team Rotation: * SWAT lead is currently: Chen
 * SWAT team rotation: Chen -> Armin on May. 31, 2019
 * SWAT team rotation: Armin -> Anuj on June 7, 2019
 * https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

Next Team Meetings: * Bug Triage meeting Thursday May 30th at 7:30am
PDT (https://zoom.us/j/454367603)
 * Monthly Project Meeting Tuesday June 4th at 8am PDT (
https://zoom.us/j/990892712) 

Key Status/Updates: * Stephen is going to be unavailable for several
weeks, please refer any queries to Richard
 * Mailing lists are moving to groups.io instead of our current mailman
setup. For various reasons the move was delayed and will take place on
3rd June. This shouldn’t impact users directly, more details will be
sent to the mailing lists in due course.
 * We have a new “newcomer” bug category which are bugs suited to
someone new to the project. These can be seen here: 
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs
 * Adrian Bunk has done some much appreciated work in removing patches
which are no longer needed or appropriate.
 * Various upgrades and ptest dependency fixes merged. Work is still
needed on ptest dependencies, particularly on perl modules.
 * Gcc 9 is now the default, thanks to Khem for working around the
remaining bug in OE-Core.


Planned Releases for YP 2.8: * M1 Cutoff June 9th
 * M1 Release June 21st
 * M2 Cutoff 14th July
 * M2 Release 26th July
 * M3 Cutoff (Feature Freeze) 25th Aug
 * M3 Release 6th Sept
 * M4 Cutoff 30th Sept
 * 2.8 (M4) Final Release 25th Oct

Planned upcoming dot releases: * YP 2.6.3 (Thud) is in planning
 * YP 2.7.1 (Warrior) is in planning

Tracking Metrics: * WDD 2524 (last week 2559) (
https://wiki.yoctoproject.org/charts/combo.html)
 * Poky Patch Metrics  
* Total patches found: 1525 (last week 1531)
* Patches in the Pending State: 649 (43%) [last week 655 (43%)]

Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Statushttps://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedulehttps://wiki.yoctoproject.org/wiki/Yocto_2.8_Features
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!]




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

Re: [yocto] [patchtest-oe][PATCH] test_metadata_src_uri: new unittest detecting added patch files without modifying SRC_URI

[akuster]

On 5/27/19 6:00 PM, Changqing Li wrote:
> ping
>
> On 4/29/19 2:10 PM, Changqing Li wrote:
>> ping
>>

Does this mean you have a working knowledge of patchtest?

The one used by the project appears to be off line.  Can you help?

kind regards,
Armin
>> On 3/5/19 5:59 PM, changqing...@windriver.com wrote:
>>> From: Changqing Li 
>>>
>>> Adds new unittest detecting when a patch file is added but no
>>> corresponding
>>> change to the SRC_URI is done.
>>>
>>> This patch is from , get from
>>> commit
>>> 49201c19cfe4cadd127b112d2858d5b28db49c20, this commit is reverted by
>>> commit
>>> 6108d97f83b211f9eb245f339a412debd0ec5db4.
>>>
>>> The added test case is ok, reason of series 9949 patchtest failed is:
>>> recipe weston have REQUIRED_DISTRO_FEATURES, so parse recipe skipped,
>>> cause self.modified is none, actually .bb is mofified, so make the
>>> testcase failed.
>>>
>>> during patchtest, we don't really need DISTRO_FEATURES, so fix the
>>> problem
>>> by set REQUIRED_DISTRO_FEATURES to "" in repo patchtest, meantime,
>>> add this
>>> testcase back.
>>>
>>> [Yocto #13005]
>>>
>>> Signed-off-by: Changqing Li 
>>> ---
>>>   tests/test_metadata_src_uri.py | 25 +
>>>   1 file changed, 25 insertions(+)
>>>
>>> diff --git a/tests/test_metadata_src_uri.py
>>> b/tests/test_metadata_src_uri.py
>>> index a4c5caa..f684ced 100644
>>> --- a/tests/test_metadata_src_uri.py
>>> +++ b/tests/test_metadata_src_uri.py
>>> @@ -85,3 +85,28 @@ class SrcUri(base.Metadata):
>>>     'Amend the patch containing the
>>> software patch file removal',
>>>     data=[('Patch', f) for f in
>>> not_removed])
>>>   +    def test_src_uri_path_not_updated(self):
>>> +    new_patches = set()
>>> +    for patch in self.patchset:
>>> +    if patch.is_added_file and patch.path.endswith('.patch'):
>>> +    new_patches.add(os.path.basename(patch.path))
>>> +
>>> +    if not new_patches:
>>> +    self.skip('No new patches added, skipping test')
>>> +
>>> +    if not self.modified:
>>> +    self.fail('New patch path missing in SRC_URI',
>>> +   "Add the patch path to the recipe's SRC_URI",
>>> +   data=[('New patch(es)',
>>> '\n'.join(new_patches))])
>>> +
>>> +    for pn in self.modified:
>>> +    rd = self.tinfoil.parse_recipe(pn)
>>> +
>>> +    patchtestdata.PatchTestDataStore['%s-%s-%s' %
>>> (self.shortid(), self.metadata, pn)] = rd.getVar(self.metadata)
>>> +    test_src_uri    =
>>> patchtestdata.PatchTestDataStore['%s-%s-%s' % (self.shortid(),
>>> self.metadata, pn)].split()
>>> +    test_files    = set([os.path.basename(patch) for patch
>>> in test_src_uri if patch.startswith('file://')])
>>> +
>>> +    if not test_files.issuperset(new_patches):
>>> +    self.fail('New patch path missing in SRC_URI',
>>> +  "Add the patch path in the recipe's
>>> SRC_URI",
>>> +  data=[('New patch(es)', p) for p in
>>> new_patches.difference(test_files)])
>>

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

[yocto] Using the SDK and CMAKE GNUInstallDirs for multilib target

[Måns Zigher]

Hi,

Not really a Yocto question but I am trying to build an application
using our SDK. We are using CMake to build and are using
GNUInstallDIrs for managing our install paths. I thought
GNUInstallDirs should have the detected that the SDK was a multilib
which it dose in regards to finding packages since it will look for
libraries under /usr/lib64 but when looking into GNUInstallDirs it
will explicitly not try and detect if CMAKE_INSTALL_LIBDIR should be
lib or lib64 when CMAKE_CROSSCOMPILING is set which it is when using
the SDK. When building the same application in our image build it
works as expected and GNUInstallDirs will detect that it is a multilib
dir and install it under /usr/lib64. Could anyone point me to how we
manage this in poky/OE so I could potentially copy that to our SDK
build?

BR
Måns Zigher
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] prelink-cross with -fno-plt

[Mark Hatle]

Sorry for my delayed reply.  I was out on a business trip.

Did you try this with the ld.so statistics to see if the relocations were indeed
reduced at runtime?

One of my worries with these changes (since I am not an ELF expert either) is
that we make a change that doesn't actually do anything -- but people expect it 
to.

$ LD_DEBUG=help /lib/ld-linux.so.2
Valid options for the LD_DEBUG environment variable are:

  libsdisplay library search paths
  reloc   display relocation processing
  files   display progress for input file
  symbols display symbol table processing
  bindingsdisplay information about symbol binding
  versionsdisplay version dependencies
  scopes  display scope information
  all all previous options combined
  statistics  display relocation statistics
  unused  determined unused DSOs
  helpdisplay this help message and exit

To direct the debugging output into a file instead of standard output
a filename can be specified using the LD_DEBUG_OUTPUT environment variable.

I believe that it's the 'statistics' option.

LD_DEBUG=statistics 

Should result in something like:

128820: runtime linker statistics:
128820:   total startup time in dynamic loader: 1974661 cycles
128820: time needed for relocation: 354639 cycles (17.9%)
128820:  number of relocations: 90
128820:   number of relocations from cache: 3
128820: number of relative relocations: 1201
128820:time needed to load objects: 1303654 cycles (66.0%)
128820:
128820: runtime linker statistics:
128820:final number of relocations: 94
128820: final number of relocations from cache: 3

If prelink is working, the number of relocations (relative or otherwise) will be
significantly reduced from the original non-relocated version.

If you can run this test, it would give me the assurance that the patch is safe,
and I'll get it incorporated into the prelink-cross sources.

--Mark

On 5/25/19 2:53 PM, Shane Peelar wrote:
> Patch is attached.  Thank you!
> 
> On Sat, May 25, 2019 at 2:30 AM Khem Raj  > wrote:
> 
> On Fri, May 24, 2019 at 6:58 PM Shane Peelar  > wrote:
> >
> > Great!  Would you be willing to accept a patch that makes arch-x86_64.c
> handle that condition like the other arches?
> >
> 
> yes certainly.
> 
> > -Shane
> >
> > On Fri, May 24, 2019 at 12:27 PM Khem Raj  > wrote:
> >>
> >>
> >>
> >> On 5/24/19 8:10 AM, Shane Peelar wrote:
> >> > I did some reading into the sources in other architectures.  The 
> closest
> >> > match, arch_i386.c, makes the write conditional as you say.
> >> > So do other arches, including |arch_arm.c, |arch_sh.c, |arch-mips.c,
> >> > |arch-s390.c, |arch-s390x.c, and |arch-ia64.c.||
> >> > ||
> >> > ||
> >> > Notably, |||arch-cris.c||| has the same assert as
> >> > |||arch-x86_64.c||| instead of the conditional.
> >> >
> >> > The code roughly looks like follows:||
> >> > ||
> >> > |||
> >> > |||
> >> > 1. Check for dso->info[DT_PLTGOT].  If it does not exist, return 0
> >> > 2. Call addr_to_sec on dso->info[DT_PLTGOT], return 1 if error
> >> > 3. Look for the section named ".plt" in the ELF.
> >> > 4. If the section cannot be found, return 0
> >> > 5. Otherwise, write the address of .plt + constant (dependent on 
> arch)
> >> > to got[1]||
> >> > ||
> >> > |||
> >> > |||
> >> > In |||arch-x86_64.c and arch-cris.c|||, step (4) above is an
> >> > assert:|||
> >> >
> >> > |||1. Check for dso->info[DT_PLTGOT].  If it does not exist, 
> return 0
> >> > 2. Call addr_to_sec on dso->info[DT_PLTGOT], return 1 if error
> >> > 3. Look for the section named ".plt" in the ELF.
> >> > 4. Assert that the section was found
> >> > 5. Write the address of .plt + constant (dependent on arch) to got[1]
> >> >
> >> > I tested out making the assert conditional and nothing seemed to 
> break
> >> > at least.
> >> > |||
> >> > |||
> >>
> >> It seems ok to me.
> >>
> >> >
> >> > On Fri, May 24, 2019 at 12:08 AM Khem Raj  
> >> > >> wrote:
> >> >
> >> >
> >> >
> >> >     On 5/23/19 7:53 PM, Shane Peelar wrote:
> >> >      > Any of them on the system pretty much, and yes they are also
> >> >     built with
> >> >      > -fno-plt.
> >> >
> >> >     OK, I think its better to them conditionally check for .plt 
> section,
> >> >     can you describe more of whats going on when sections are 
> c

Re: [yocto] [patchtest-oe][PATCH] test_metadata_src_uri: new unittest detecting added patch files without modifying SRC_URI

[Changqing Li]

On 5/28/19 10:53 PM, akuster wrote:


On 5/27/19 6:00 PM, Changqing Li wrote:

ping

On 4/29/19 2:10 PM, Changqing Li wrote:

ping


Does this mean you have a working knowledge of patchtest?

The one used by the project appears to be off line.  Can you help?

kind regards,
Armin


I have do some work on this,  and can try to help,  but I don't have

access right of the server,  and I also don't have the admin account of

the patchwork.  if  someone can  provide these info,  I am glad to help.


On 3/5/19 5:59 PM, changqing...@windriver.com wrote:

From: Changqing Li 

Adds new unittest detecting when a patch file is added but no
corresponding
change to the SRC_URI is done.

This patch is from , get from
commit
49201c19cfe4cadd127b112d2858d5b28db49c20, this commit is reverted by
commit
6108d97f83b211f9eb245f339a412debd0ec5db4.

The added test case is ok, reason of series 9949 patchtest failed is:
recipe weston have REQUIRED_DISTRO_FEATURES, so parse recipe skipped,
cause self.modified is none, actually .bb is mofified, so make the
testcase failed.

during patchtest, we don't really need DISTRO_FEATURES, so fix the
problem
by set REQUIRED_DISTRO_FEATURES to "" in repo patchtest, meantime,
add this
testcase back.

[Yocto #13005]

Signed-off-by: Changqing Li 
---
   tests/test_metadata_src_uri.py | 25 +
   1 file changed, 25 insertions(+)

diff --git a/tests/test_metadata_src_uri.py
b/tests/test_metadata_src_uri.py
index a4c5caa..f684ced 100644
--- a/tests/test_metadata_src_uri.py
+++ b/tests/test_metadata_src_uri.py
@@ -85,3 +85,28 @@ class SrcUri(base.Metadata):
     'Amend the patch containing the
software patch file removal',
     data=[('Patch', f) for f in
not_removed])
   +    def test_src_uri_path_not_updated(self):
+    new_patches = set()
+    for patch in self.patchset:
+    if patch.is_added_file and patch.path.endswith('.patch'):
+    new_patches.add(os.path.basename(patch.path))
+
+    if not new_patches:
+    self.skip('No new patches added, skipping test')
+
+    if not self.modified:
+    self.fail('New patch path missing in SRC_URI',
+   "Add the patch path to the recipe's SRC_URI",
+   data=[('New patch(es)',
'\n'.join(new_patches))])
+
+    for pn in self.modified:
+    rd = self.tinfoil.parse_recipe(pn)
+
+    patchtestdata.PatchTestDataStore['%s-%s-%s' %
(self.shortid(), self.metadata, pn)] = rd.getVar(self.metadata)
+    test_src_uri    =
patchtestdata.PatchTestDataStore['%s-%s-%s' % (self.shortid(),
self.metadata, pn)].split()
+    test_files    = set([os.path.basename(patch) for patch
in test_src_uri if patch.startswith('file://')])
+
+    if not test_files.issuperset(new_patches):
+    self.fail('New patch path missing in SRC_URI',
+  "Add the patch path in the recipe's
SRC_URI",
+  data=[('New patch(es)', p) for p in
new_patches.difference(test_files)])



--
BRs

Sandy(Li Changqing)

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

Re: [yocto] Custom eSDK build fails

[Priyanshu Sharma]

I have made changes in populate_sdk_ext.bbclass to copy my layers during
do_populate_sdk and that works fine.
Now, I'm hitting failure at :
*ERROR: Failed to generate filtered task list for extensible SDK *( after
this it prints the contents of my custom conf-notes)

Looking at the source of this error, it comes from populate_sdk_ext.bbclass
-
https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/populate_sdk_ext.bbclass#n170
And its failing because its not finding a tasklist_bb_log.txt.

This text file contains logs of setscene tasks of all the packages built.
For some reason, this file is not getting auto-generated for my custom
image.

Any hints?

Warm Regards,
Priyanshu Sharma

On Wed, May 15, 2019 at 3:57 PM Priyanshu Sharma <
ms.priyanshu.sha...@gmail.com> wrote:

> I see that my custom layers are not being copied in
> /sdk-ext/image/opt/${DISTRO}/${POKY_VERSION}/layers. Though
> the conf files at
> /sdk-ext/image/opt/${DISTRO}/${POKY_VERSION}/conf.
>
> How can I include my layers also in this?
>
> Warm Regards,
> Priyanshu Sharma
>
> On Thu, May 2, 2019 at 3:12 PM Priyanshu Sharma <
> ms.priyanshu.sha...@gmail.com> wrote:
>
>> Hi,
>>
>> I've a custom Yocto layer and use that as TEMPLATECONF for building. My
>> custom layer also contains the image recipe based on pulsar-image (from
>> meta-ivi).
>>
>> I'm using Yocto 2.5. The extensible sdk build fails at
>> do_populate_sdk_ext task for my image recipe.
>>
>> $ bitbake  -f -c populate_sdk_ext
>> Error -
>> Exception: FileNotFoundError: [Errno 2] No such file or directory:
>> '///sdk-ext/image//opt//2.5.1/conf/local.conf.bak'
>> ->
>> '///sdk-ext/image//opt//2.5.1/conf/local.conf'
>>
>> If I check the path, <>/sdk-ext/image//opt//2.5.1 , this
>> directory is getting created but getting deleted afterwards.
>> And  the one left after build fails is -
>> <>/sdk-ext/image//opt//layers
>>
>> Is there any configuration to be modified/added for my custom image?
>>
>> Warm regards,
>> Priyanshu Sharma
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] initramfs in rootfs included

[Alexander Stein]

Hello,

is it possible to include an initramfs image in the rootfs? If so, how can I do 
that?
I want to create a single image including everything: kernel, device tree, 
rootfs and initramfs.
The initramfs shall contain a custom startup to mount / using overlayfs before 
calling pivot_root.
A single image is important in order to ease the usage of rauc for updates.
I know about INITRAMFS_IMAGE_BUNDLE which includes the initramfs into the 
kernel.
This would be great too and creates an kernel containing the initramfs, but 
unfortunately
this kernel is _not_ included in the rootfs, only the kernel without initramfs.
I tried creating a custom image, based on core-image-minimal-initramfs, but 
failed at some
point as do_image depends on do_rootfs which depends on do_package. AFAIK the 
files to install
for a package are installed during do_install which come before do_package, so 
this does not work.

So I'm wondering how to get an initramfs image into the rootfs.

Best regards,
Alexander



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

Re: [yocto] meta-sunxi maintained?

[Belisko Marek]

Hi Dimitris,

On Tue, May 28, 2019 at 1:07 PM Dimitris Tassopoulos  wrote:
>
> Hi Enrico,
>
> I'm totally positive to any possibility for such integration. Personally, 
> that was the first thing I've tried to do before I start this layer, but I've 
> failed as it got really complex and the overhead was too much after some 
> point (at least for me). If you have look it's actually a mix of meta-sunxi 
> and armbian, but I had to remove or change many stuff to fit the armbian in 
> the layer.
>
> If you have time to have a look to my layer and you think that such kind of 
> integration is possible and can be done in a more easy way, then from my side 
> I'm all in.
> I believe that re-using the armbian patches is easier as it makes maintenance 
> much easier, there are more supported SBCs and also there is much more 
> testing involved in armbian and frequent updates fix those bugs.
I did check your layer and it seems that you're not using sunxi-mali
for opengl HW acceleration only mesa so SW rendering? Thanks.
>
> Please consider it and I can help as much as I can and my time allows for 
> that integration.
>
> Regards,
> Dimitris
>
>
Marek
>
> On Tue, May 28, 2019 at 12:56 PM Enrico  wrote:
>>
>> On Tue, May 28, 2019 at 12:06 PM Dimitris Tassopoulos  
>> wrote:
>> >
>> > >
>> > > I was thinking about this also, too. The only reason is that in 
>> > > meta-sunxi they do a great job and they keep their layer clean, which is 
>> > > great I think. The other layers are just based on the armbian distro, 
>> > > which is a lot different, but for me it was much easier to integrate 
>> > > their patches, patching scripts and bootloader scripts to a Yocto layer. 
>> > > That way the only thing I do is that from time to time I just integrate 
>> > > their new patches and that's it. There's no development in the layer is 
>> > > just re-use of the armbian work and a wrapper around it. Therefore, it's 
>> > > hard, even no doable to put those different architectures together. But 
>> > > definitely that decision also bothered me a lot before I create the 
>> > > layer and I also don't like time to be spend on the same thing from 
>> > > different people. Nevertheless, from my point of view I couldn't find a 
>> > > way to put those things together. I've tried but I couldn't do it.
>> > >
>> > > Therefore, it was easier for me to do it the way I've done it. And after 
>> > > all, although it doesn't seem right, at the same time this is the beauty 
>> > > of the open source. I think the layers are just incompatible in the way 
>> > > that they are do things. Also it's not bad to have alternatives.
>> > >
>> > > Sunxi is a great community and I believe many of the armbian patches are 
>> > > coming from there. Others not. Of course, having them all together would 
>> > > be nice. But I don't think that it's possible because of the different 
>> > > approach.
>>
>> It would be great to integrate all those different layers in
>> meta-sunxi,the main problem is that usually they come with their own
>> bootloader/kernel/etc so you have to *maintain* all these
>> different configurations.
>> Infact in the past i refused to do such things because i didn't have
>> the time to maintain all those different versions, it was just easier
>> to support what was already in mainline uboot/kernel.
>>
>> But of course if someone wants to do it then it's welcome, the worst
>> thing that can happen is that once an arch gets unmaintained it will
>> be removed.
>>
>> One thing that can be done anyway is to have those external layers
>> linked in the readme, so at least people will know they exist.
>>
>> Enrico
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto