[yocto] Parsing bug in packagegroup

[Einar Vading]

Hi,
I'm having some problems with a packagegroup of ours.

It basically looks like this:

inherit packagegroup

RDEPENDS_${PN} = "\
libdomain-somelib \
libsomeotherlib \
served-util \
"

Where served-util also is a lib.

 Now depending on what I put in my RDEPENDS my build either succeeds
or fails with:

Error:
  Problem: conflicting requests
  - nothing provides libserved-utilsoversion needed by
packagegroup-base-1.0-r0.0.noarch

I can go from a failing build to a successful build just by moving the
quote up to the served-util line:


served-util"

It also works if I swap served-util with the package above:

served-util \
libsomeotherlib \
"

I realize this might be a bit vague but I'm happy to look around for
this bug if I could just get some pointers as to where I should be
looking. I have grepped for soversion in my packages image and
package* dirs in tmp/work and I have grepped for it in the
poky/bitbake dir without success.

But to me it looks like "soversion" in libserved-utilsoversion is
leaking in from some script somewhere

I'd love some pointers to which parts of bitbake is handling this stuff.

Best Regards,
Einar
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] dnf fail in do_rootfs cannot find shared library

[Einar Vading]

I'm not sure this is your problem but if you don't version your
so-libs you could get this since the .so (without version) is not
shipped by default I think.

Try putting this in your recipe:
SOLIBS = ".so*"
FILES_SOLIBSDEV = ""
ERROR_QA_remove = "dev-so"

If that works I think the proper solution is to give your so-lib a version.

// Einar

On Tue, Jan 22, 2019 at 6:00 PM Måns Zigher  wrote:
>
> Hi,
>
> I am struggling with a recipe which more or less just downloads binaries and 
> creating a package. We have previously been using ipkg but now we have 
> switched to rpm in our builds. One of the binaries in the packages is a 
> library let's call it libx_media_1.0.so. This library is part of the package 
> that the recipe is producing. The library is placed under /usr/lib/. When 
> building the image I am getting the following error
>
> ERROR: base-image-1.0-r0 do_rootfs: Could not invoke dnf. Command
> .
> ...
> Error:
>  Problem: package packagegroup-x-media-1.0-r11.noarch requires x_media, but 
> none of the providers can be installed
>   - conflicting requests
>   - nothing provides libx_media_1.0.so()(64bit) needed by 
> x_media-1.0-r44.imx8mq
>
> ERROR: base-image-1.0-r0 do_rootfs: Function failed: do_rootfs
>
> Here is the output from running the command file on the library
>
> usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64, version 
> 1 (SYSV), dynamically linked, stripped
>
> I have also verified that the library is part of the produced rpm so that is 
> not the issue.
>
> Dose anyone have any suggestion on how to debug this problem? Because I am 
> out of ideas
>
> BR
> Måns Zigher
> --
> ___
> 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] dnf fail in do_rootfs cannot find shared library

[Måns Zigher]

Hi,

I have verified that the so-lib file is part of the rpm package and I am
using INSANE_SKIP where I have added dev-so but I am willing to try
anything right now so thanks. The so-files is not something I have control
of it is something that is delivered to us.

BR
Måns Zigher

Den ons 23 jan. 2019 kl 10:12 skrev Einar Vading :

> I'm not sure this is your problem but if you don't version your
> so-libs you could get this since the .so (without version) is not
> shipped by default I think.
>
> Try putting this in your recipe:
> SOLIBS = ".so*"
> FILES_SOLIBSDEV = ""
> ERROR_QA_remove = "dev-so"
>
> If that works I think the proper solution is to give your so-lib a version.
>
> // Einar
>
> On Tue, Jan 22, 2019 at 6:00 PM Måns Zigher  wrote:
> >
> > Hi,
> >
> > I am struggling with a recipe which more or less just downloads binaries
> and creating a package. We have previously been using ipkg but now we have
> switched to rpm in our builds. One of the binaries in the packages is a
> library let's call it libx_media_1.0.so. This library is part of the
> package that the recipe is producing. The library is placed under
> /usr/lib/. When building the image I am getting the following error
> >
> > ERROR: base-image-1.0-r0 do_rootfs: Could not invoke dnf. Command
> > .
> > ...
> > Error:
> >  Problem: package packagegroup-x-media-1.0-r11.noarch requires x_media,
> but none of the providers can be installed
> >   - conflicting requests
> >   - nothing provides libx_media_1.0.so()(64bit) needed by
> x_media-1.0-r44.imx8mq
> >
> > ERROR: base-image-1.0-r0 do_rootfs: Function failed: do_rootfs
> >
> > Here is the output from running the command file on the library
> >
> > usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64,
> version 1 (SYSV), dynamically linked, stripped
> >
> > I have also verified that the library is part of the produced rpm so
> that is not the issue.
> >
> > Dose anyone have any suggestion on how to debug this problem? Because I
> am out of ideas
> >
> > BR
> > Måns Zigher
> > --
> > ___
> > 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] dnf fail in do_rootfs cannot find shared library

[Måns Zigher]

I have toke the rpm file that was produced. I found the file under the
build directory under
tmp/work/imx8mq-strix-linux/x_media/1.0-r44/deploy-rpms/imx8mq/temp/x_media-1.0-r44.imx8mq.rpm.
I used the following commands
7z x x_media-1.0-r44.imx8mq.rpm
7z x x_media-1.0-r44.imx8mq.cpio

The result from this gave me the file tree where I then could run
file usr/lib/libx_media_1.0.so

usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64,
version 1 (SYSV), dynamically linked, stripped

So I believe that I have concluded that the rpm include the file that dnf
is complaining about. I don't understand why dnf thinks that this
dependency is not meet when it clearly is part of the package. I have added
verbose flags to the dnf call but dose not give any more information.
I am not sure how I can proceed to find out what I have done wrong. The
recipe is a bit of a freak of nature because the binaries that I am
packaging is actually built using another toolchain but it is for the same
arch can dnf detect that?

BR
Måns Zigher

Den tis 22 jan. 2019 kl 17:59 skrev Måns Zigher :

> Hi,
>
> I am struggling with a recipe which more or less just downloads binaries
> and creating a package. We have previously been using ipkg but now we have
> switched to rpm in our builds. One of the binaries in the packages is a
> library let's call it libx_media_1.0.so. This library is part of the
> package that the recipe is producing. The library is placed under
> /usr/lib/. When building the image I am getting the following error
>
> ERROR: base-image-1.0-r0 do_rootfs: Could not invoke dnf. Command
> .
> ...
> Error:
>  Problem: package packagegroup-x-media-1.0-r11.noarch requires x_media,
> but none of the providers can be installed
>   - conflicting requests
>   - nothing provides libx_media_1.0.so()(64bit) needed by
> x_media-1.0-r44.imx8mq
>
> ERROR: base-image-1.0-r0 do_rootfs: Function failed: do_rootfs
>
> Here is the output from running the command file on the library
>
> usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64,
> version 1 (SYSV), dynamically linked, stripped
>
> I have also verified that the library is part of the produced rpm so that
> is not the issue.
>
> Dose anyone have any suggestion on how to debug this problem? Because I am
> out of ideas
>
> BR
> Måns Zigher
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] dnf fail in do_rootfs cannot find shared library

[Alexander Kanavin]

One more thing: can you provide the .spec file that is generated
during build and used to create .rpm packages? You will find it under
tmp/work//x_media/

Please try not to edit anything out of it.

Alex

On Wed, 23 Jan 2019 at 12:02, Måns Zigher  wrote:
>
> I have toke the rpm file that was produced. I found the file under the build 
> directory under 
> tmp/work/imx8mq-strix-linux/x_media/1.0-r44/deploy-rpms/imx8mq/temp/x_media-1.0-r44.imx8mq.rpm.
>  I used the following commands
> 7z x x_media-1.0-r44.imx8mq.rpm
> 7z x x_media-1.0-r44.imx8mq.cpio
>
> The result from this gave me the file tree where I then could run
> file usr/lib/libx_media_1.0.so
> usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64, version 
> 1 (SYSV), dynamically linked, stripped
>
> So I believe that I have concluded that the rpm include the file that dnf is 
> complaining about. I don't understand why dnf thinks that this dependency is 
> not meet when it clearly is part of the package. I have added verbose flags 
> to the dnf call but dose not give any more information.
> I am not sure how I can proceed to find out what I have done wrong. The 
> recipe is a bit of a freak of nature because the binaries that I am packaging 
> is actually built using another toolchain but it is for the same arch can dnf 
> detect that?
>
> BR
> Måns Zigher
>
> Den tis 22 jan. 2019 kl 17:59 skrev Måns Zigher :
>>
>> Hi,
>>
>> I am struggling with a recipe which more or less just downloads binaries and 
>> creating a package. We have previously been using ipkg but now we have 
>> switched to rpm in our builds. One of the binaries in the packages is a 
>> library let's call it libx_media_1.0.so. This library is part of the package 
>> that the recipe is producing. The library is placed under /usr/lib/. When 
>> building the image I am getting the following error
>>
>> ERROR: base-image-1.0-r0 do_rootfs: Could not invoke dnf. Command
>> .
>> ...
>> Error:
>>  Problem: package packagegroup-x-media-1.0-r11.noarch requires x_media, but 
>> none of the providers can be installed
>>   - conflicting requests
>>   - nothing provides libx_media_1.0.so()(64bit) needed by 
>> x_media-1.0-r44.imx8mq
>>
>> ERROR: base-image-1.0-r0 do_rootfs: Function failed: do_rootfs
>>
>> Here is the output from running the command file on the library
>>
>> usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64, 
>> version 1 (SYSV), dynamically linked, stripped
>>
>> I have also verified that the library is part of the produced rpm so that is 
>> not the issue.
>>
>> Dose anyone have any suggestion on how to debug this problem? Because I am 
>> out of ideas
>>
>> BR
>> Måns Zigher
>
> --
> ___
> 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] dnf fail in do_rootfs cannot find shared library

[Einar Vading]

This is a longshot but I am currently investigating an issue we have
with a packagegroup.

I get a similar error but I can fix it by moving the package in my
RDEPENDS in the packagegroup.

If you move your libx_media up or down in the packagegroup, does it help?

For me i got:
Error:
  Problem: conflicting requests
  - nothing provides libserved-utilsoversion needed by
packagegroup-base-1.0-r0.0.noarch

When I had:
RDEPENDS_${PN} = "\
libdomain-somelib \
libsomeotherlib \
served-util \
"

But changing to:
RDEPENDS_${PN} = "\
libdomain-somelib \
served-util \
libsomeotherlib \
"
Made it work.

If you're down to trying anything you might as well try this =)

// Einar

On Wed, Jan 23, 2019 at 12:03 PM Måns Zigher  wrote:
>
> I have toke the rpm file that was produced. I found the file under the build 
> directory under 
> tmp/work/imx8mq-strix-linux/x_media/1.0-r44/deploy-rpms/imx8mq/temp/x_media-1.0-r44.imx8mq.rpm.
>  I used the following commands
> 7z x x_media-1.0-r44.imx8mq.rpm
> 7z x x_media-1.0-r44.imx8mq.cpio
>
> The result from this gave me the file tree where I then could run
> file usr/lib/libx_media_1.0.so
> usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64, version 
> 1 (SYSV), dynamically linked, stripped
>
> So I believe that I have concluded that the rpm include the file that dnf is 
> complaining about. I don't understand why dnf thinks that this dependency is 
> not meet when it clearly is part of the package. I have added verbose flags 
> to the dnf call but dose not give any more information.
> I am not sure how I can proceed to find out what I have done wrong. The 
> recipe is a bit of a freak of nature because the binaries that I am packaging 
> is actually built using another toolchain but it is for the same arch can dnf 
> detect that?
>
> BR
> Måns Zigher
>
> Den tis 22 jan. 2019 kl 17:59 skrev Måns Zigher :
>>
>> Hi,
>>
>> I am struggling with a recipe which more or less just downloads binaries and 
>> creating a package. We have previously been using ipkg but now we have 
>> switched to rpm in our builds. One of the binaries in the packages is a 
>> library let's call it libx_media_1.0.so. This library is part of the package 
>> that the recipe is producing. The library is placed under /usr/lib/. When 
>> building the image I am getting the following error
>>
>> ERROR: base-image-1.0-r0 do_rootfs: Could not invoke dnf. Command
>> .
>> ...
>> Error:
>>  Problem: package packagegroup-x-media-1.0-r11.noarch requires x_media, but 
>> none of the providers can be installed
>>   - conflicting requests
>>   - nothing provides libx_media_1.0.so()(64bit) needed by 
>> x_media-1.0-r44.imx8mq
>>
>> ERROR: base-image-1.0-r0 do_rootfs: Function failed: do_rootfs
>>
>> Here is the output from running the command file on the library
>>
>> usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64, 
>> version 1 (SYSV), dynamically linked, stripped
>>
>> I have also verified that the library is part of the produced rpm so that is 
>> not the issue.
>>
>> Dose anyone have any suggestion on how to debug this problem? Because I am 
>> out of ideas
>>
>> BR
>> Måns Zigher
>
> --
> ___
> 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] dnf fail in do_rootfs cannot find shared library

[Måns Zigher]

Hi,

I am sorry but I cannot locate the .spec file. I tried searching for .spec
in the tmp/work but I could not find any .spec file. Do I have to build
with a flag to get this .spec file?

BR
Måns Zigher

Den ons 23 jan. 2019 kl 12:07 skrev Alexander Kanavin <
alex.kana...@gmail.com>:

> One more thing: can you provide the .spec file that is generated
> during build and used to create .rpm packages? You will find it under
> tmp/work//x_media/
>
> Please try not to edit anything out of it.
>
> Alex
>
> On Wed, 23 Jan 2019 at 12:02, Måns Zigher  wrote:
> >
> > I have toke the rpm file that was produced. I found the file under the
> build directory under
> tmp/work/imx8mq-strix-linux/x_media/1.0-r44/deploy-rpms/imx8mq/temp/x_media-1.0-r44.imx8mq.rpm.
> I used the following commands
> > 7z x x_media-1.0-r44.imx8mq.rpm
> > 7z x x_media-1.0-r44.imx8mq.cpio
> >
> > The result from this gave me the file tree where I then could run
> > file usr/lib/libx_media_1.0.so
> > usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64,
> version 1 (SYSV), dynamically linked, stripped
> >
> > So I believe that I have concluded that the rpm include the file that
> dnf is complaining about. I don't understand why dnf thinks that this
> dependency is not meet when it clearly is part of the package. I have added
> verbose flags to the dnf call but dose not give any more information.
> > I am not sure how I can proceed to find out what I have done wrong. The
> recipe is a bit of a freak of nature because the binaries that I am
> packaging is actually built using another toolchain but it is for the same
> arch can dnf detect that?
> >
> > BR
> > Måns Zigher
> >
> > Den tis 22 jan. 2019 kl 17:59 skrev Måns Zigher :
> >>
> >> Hi,
> >>
> >> I am struggling with a recipe which more or less just downloads
> binaries and creating a package. We have previously been using ipkg but now
> we have switched to rpm in our builds. One of the binaries in the packages
> is a library let's call it libx_media_1.0.so. This library is part of the
> package that the recipe is producing. The library is placed under
> /usr/lib/. When building the image I am getting the following error
> >>
> >> ERROR: base-image-1.0-r0 do_rootfs: Could not invoke dnf. Command
> >> .
> >> ...
> >> Error:
> >>  Problem: package packagegroup-x-media-1.0-r11.noarch requires x_media,
> but none of the providers can be installed
> >>   - conflicting requests
> >>   - nothing provides libx_media_1.0.so()(64bit) needed by
> x_media-1.0-r44.imx8mq
> >>
> >> ERROR: base-image-1.0-r0 do_rootfs: Function failed: do_rootfs
> >>
> >> Here is the output from running the command file on the library
> >>
> >> usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64,
> version 1 (SYSV), dynamically linked, stripped
> >>
> >> I have also verified that the library is part of the produced rpm so
> that is not the issue.
> >>
> >> Dose anyone have any suggestion on how to debug this problem? Because I
> am out of ideas
> >>
> >> BR
> >> Måns Zigher
> >
> > --
> > ___
> > 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] dnf fail in do_rootfs cannot find shared library

[Måns Zigher]

Hi,

Yes I noticed it so I tried that out but without any success but I will
investigate that also to see if change it can in another result.

BR
Måns Zigher

Den ons 23 jan. 2019 kl 12:33 skrev Einar Vading :

> This is a longshot but I am currently investigating an issue we have
> with a packagegroup.
>
> I get a similar error but I can fix it by moving the package in my
> RDEPENDS in the packagegroup.
>
> If you move your libx_media up or down in the packagegroup, does it help?
>
> For me i got:
> Error:
>   Problem: conflicting requests
>   - nothing provides libserved-utilsoversion needed by
> packagegroup-base-1.0-r0.0.noarch
>
> When I had:
> RDEPENDS_${PN} = "\
> libdomain-somelib \
> libsomeotherlib \
> served-util \
> "
>
> But changing to:
> RDEPENDS_${PN} = "\
> libdomain-somelib \
> served-util \
> libsomeotherlib \
> "
> Made it work.
>
> If you're down to trying anything you might as well try this =)
>
> // Einar
>
> On Wed, Jan 23, 2019 at 12:03 PM Måns Zigher 
> wrote:
> >
> > I have toke the rpm file that was produced. I found the file under the
> build directory under
> tmp/work/imx8mq-strix-linux/x_media/1.0-r44/deploy-rpms/imx8mq/temp/x_media-1.0-r44.imx8mq.rpm.
> I used the following commands
> > 7z x x_media-1.0-r44.imx8mq.rpm
> > 7z x x_media-1.0-r44.imx8mq.cpio
> >
> > The result from this gave me the file tree where I then could run
> > file usr/lib/libx_media_1.0.so
> > usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64,
> version 1 (SYSV), dynamically linked, stripped
> >
> > So I believe that I have concluded that the rpm include the file that
> dnf is complaining about. I don't understand why dnf thinks that this
> dependency is not meet when it clearly is part of the package. I have added
> verbose flags to the dnf call but dose not give any more information.
> > I am not sure how I can proceed to find out what I have done wrong. The
> recipe is a bit of a freak of nature because the binaries that I am
> packaging is actually built using another toolchain but it is for the same
> arch can dnf detect that?
> >
> > BR
> > Måns Zigher
> >
> > Den tis 22 jan. 2019 kl 17:59 skrev Måns Zigher :
> >>
> >> Hi,
> >>
> >> I am struggling with a recipe which more or less just downloads
> binaries and creating a package. We have previously been using ipkg but now
> we have switched to rpm in our builds. One of the binaries in the packages
> is a library let's call it libx_media_1.0.so. This library is part of the
> package that the recipe is producing. The library is placed under
> /usr/lib/. When building the image I am getting the following error
> >>
> >> ERROR: base-image-1.0-r0 do_rootfs: Could not invoke dnf. Command
> >> .
> >> ...
> >> Error:
> >>  Problem: package packagegroup-x-media-1.0-r11.noarch requires x_media,
> but none of the providers can be installed
> >>   - conflicting requests
> >>   - nothing provides libx_media_1.0.so()(64bit) needed by
> x_media-1.0-r44.imx8mq
> >>
> >> ERROR: base-image-1.0-r0 do_rootfs: Function failed: do_rootfs
> >>
> >> Here is the output from running the command file on the library
> >>
> >> usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64,
> version 1 (SYSV), dynamically linked, stripped
> >>
> >> I have also verified that the library is part of the produced rpm so
> that is not the issue.
> >>
> >> Dose anyone have any suggestion on how to debug this problem? Because I
> am out of ideas
> >>
> >> BR
> >> Måns Zigher
> >
> > --
> > ___
> > 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] dnf fail in do_rootfs cannot find shared library

[Måns Zigher]

Hi guys,

I found the issue and dnf is doing exactly what it should. The problem is
the shared library

readelf -d libx_media_1.0.so


Dynamic section at offset 0xf31c8 contains 40 entries:
  TagType Name/Value

...
 0x000e (SONAME) Library soname: [
libx_media_1.0_wtf.so]

So the SONAME of the file is actually set to libx_media_1.0_wtf.so but the
file is named libx_media_1.0.so and the executable that is part of the
package is linked against libx_media_1.0.so also.
I manage to figure this out when I was going
through /tmp/work/path/to/xmedia/1.0-r43/pkgdata/shlibs2 and I noticed that
in xmedia.lst file actually did not include the libx_media_1.0.so but
libx_media_1.0_wtf.so.
Thanks for your efforts.

BR
Måns Zigher

Den ons 23 jan. 2019 kl 13:01 skrev Måns Zigher :

> Hi,
>
> Yes I noticed it so I tried that out but without any success but I will
> investigate that also to see if change it can in another result.
>
> BR
> Måns Zigher
>
> Den ons 23 jan. 2019 kl 12:33 skrev Einar Vading :
>
>> This is a longshot but I am currently investigating an issue we have
>> with a packagegroup.
>>
>> I get a similar error but I can fix it by moving the package in my
>> RDEPENDS in the packagegroup.
>>
>> If you move your libx_media up or down in the packagegroup, does it help?
>>
>> For me i got:
>> Error:
>>   Problem: conflicting requests
>>   - nothing provides libserved-utilsoversion needed by
>> packagegroup-base-1.0-r0.0.noarch
>>
>> When I had:
>> RDEPENDS_${PN} = "\
>> libdomain-somelib \
>> libsomeotherlib \
>> served-util \
>> "
>>
>> But changing to:
>> RDEPENDS_${PN} = "\
>> libdomain-somelib \
>> served-util \
>> libsomeotherlib \
>> "
>> Made it work.
>>
>> If you're down to trying anything you might as well try this =)
>>
>> // Einar
>>
>> On Wed, Jan 23, 2019 at 12:03 PM Måns Zigher 
>> wrote:
>> >
>> > I have toke the rpm file that was produced. I found the file under the
>> build directory under
>> tmp/work/imx8mq-strix-linux/x_media/1.0-r44/deploy-rpms/imx8mq/temp/x_media-1.0-r44.imx8mq.rpm.
>> I used the following commands
>> > 7z x x_media-1.0-r44.imx8mq.rpm
>> > 7z x x_media-1.0-r44.imx8mq.cpio
>> >
>> > The result from this gave me the file tree where I then could run
>> > file usr/lib/libx_media_1.0.so
>> > usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64,
>> version 1 (SYSV), dynamically linked, stripped
>> >
>> > So I believe that I have concluded that the rpm include the file that
>> dnf is complaining about. I don't understand why dnf thinks that this
>> dependency is not meet when it clearly is part of the package. I have added
>> verbose flags to the dnf call but dose not give any more information.
>> > I am not sure how I can proceed to find out what I have done wrong. The
>> recipe is a bit of a freak of nature because the binaries that I am
>> packaging is actually built using another toolchain but it is for the same
>> arch can dnf detect that?
>> >
>> > BR
>> > Måns Zigher
>> >
>> > Den tis 22 jan. 2019 kl 17:59 skrev Måns Zigher > >:
>> >>
>> >> Hi,
>> >>
>> >> I am struggling with a recipe which more or less just downloads
>> binaries and creating a package. We have previously been using ipkg but now
>> we have switched to rpm in our builds. One of the binaries in the packages
>> is a library let's call it libx_media_1.0.so. This library is part of
>> the package that the recipe is producing. The library is placed under
>> /usr/lib/. When building the image I am getting the following error
>> >>
>> >> ERROR: base-image-1.0-r0 do_rootfs: Could not invoke dnf. Command
>> >> .
>> >> ...
>> >> Error:
>> >>  Problem: package packagegroup-x-media-1.0-r11.noarch requires
>> x_media, but none of the providers can be installed
>> >>   - conflicting requests
>> >>   - nothing provides libx_media_1.0.so()(64bit) needed by
>> x_media-1.0-r44.imx8mq
>> >>
>> >> ERROR: base-image-1.0-r0 do_rootfs: Function failed: do_rootfs
>> >>
>> >> Here is the output from running the command file on the library
>> >>
>> >> usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64,
>> version 1 (SYSV), dynamically linked, stripped
>> >>
>> >> I have also verified that the library is part of the produced rpm so
>> that is not the issue.
>> >>
>> >> Dose anyone have any suggestion on how to debug this problem? Because
>> I am out of ideas
>> >>
>> >> BR
>> >> Måns Zigher
>> >
>> > --
>> > ___
>> > 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] [meta-security][PATCH] checksec: Upgrade to latest upstream

[Scott Ellis]

More kernel checks, particularly arm64.

Signed-off-by: Scott Ellis 
---
 recipes-security/checksec/checksec_1.11.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-security/checksec/checksec_1.11.bb 
b/recipes-security/checksec/checksec_1.11.bb
index 59a67bd..0ca6e07 100644
--- a/recipes-security/checksec/checksec_1.11.bb
+++ b/recipes-security/checksec/checksec_1.11.bb
@@ -6,7 +6,7 @@ HOMEPAGE="https://github.com/slimm609/checksec.sh";
 
 LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=93fddcca19f6c897871f9b5f9a035f4a"
 
-SRCREV = "a57e03c4f62dbaca0ec949bbc58491fb0c461447"
+SRCREV = "afcbaf954169771fc88ebba7727acdd2d26c27c7"
 SRC_URI = "git://github.com/slimm609/checksec.sh"
 
 S = "${WORKDIR}/git"
-- 
2.7.4

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

Re: [yocto] Error: file provided by multiple packages

[João Gonçalves]

I just found that one systemd append recipe was installed the conflict file.
Fixed.

João Gonçalves  escreveu no dia terça,
22/01/2019 à(s) 22:11:

> I'm using master branch or embedded core to build a most recent toolchain
> with gcc 8.2 (I previously had 7.3 but it didn't provide the libstdc++fs
> that I needed).
>
> I almost made this build work but now I'm having the following error on my
> image do_rootfs:
>
> Package systemd wants to install file
> /home/joao/master_imx6/build/tmp-glibc/work/thomson_apalis_imx6-angstrom-linux-gnueabi/kelvin-base-image/0.2.4-r0/thomson-apalis-imx6_kelvin-base-image_2.8.5/rootfs/etc/systemd/journald.conf
> But that file is already provided by package  * systemd-conf
>
> Then I checked that systemd_239.bb do_install() remove installed conf
> files that should be handled by systemd-conf.
> What I suppose is that systemd-conf do_install() is executed first and
> then systemd do_install() eventually breaks when installs the file (before
> removing it).
>
> Does anyone know if is possible to specify the install order? or if this
> is really the problem
>
> Thanks,
> Joao Goncalves
>
>
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] wic utility

[Srinivasan, Raja]

I am using wic 0.2.0 from the rocko build.

wic cp file wifile:part/path

appears to succeed (no errors reported).

But when I perform wic ls I don't find the file in the target.

Are there any switches the I should be using?

Thanks for any pointers, srini



CONFIDENTIALITY NOTICE: This email message and any attachments are confidential 
and may be privileged and are meant to be read by the intended recipient only. 
If you are not the intended recipient, please notify sender immediately and 
destroy all copies of this message and any attachments without reading or 
disclosing their contents. Thank you
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Exclude kernel module from image

[John Klug]

I am looking for a way to create an image with an exclusion list of kernel 
modules packages.

If I use PACKAGE_EXCLUDE, I see the following:

Collected errors:
 * calculate_dependencies_for: Cannot satisfy the following dependencies 
for kernel-modules:

The list of modules that follows are the very kernel module packages I am 
trying to exclude.

I would prefer not to create a list of every kernel module I wish to include.

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

Re: [yocto] Exclude kernel module from image

[Nicolas Dechesne]

On Wed, Jan 23, 2019 at 7:35 PM John Klug  wrote:
>
> I am looking for a way to create an image with an exclusion list of kernel 
> modules packages.
>
> If I use PACKAGE_EXCLUDE, I see the following:
>
> Collected errors:
>  * calculate_dependencies_for: Cannot satisfy the following dependencies 
> for kernel-modules:
>
> The list of modules that follows are the very kernel module packages I am 
> trying to exclude.

if you want to exclude *all* kernel modules it's simple, you can
achieve that with the following in your image recipe.

BAD_RECOMMENDATIONS = "kernel-modules"

This is easy because kernel-modules comes as RRECOMMENDS from
packagegroup-core-boot.. but if you exclude just some modules, then
you are breaking an RDEPENDS relationship which is a fatal error..

>
> I would prefer not to create a list of every kernel module I wish to include.

right.. can't you disable these modules in the kernel recipe instead
using some config fragment?

>
>
>
>
>
>
> --
> ___
> 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] Exclude kernel module from image

[John Klug]

>>
>> I would prefer not to create a list of every kernel module I wish to include.

>right.. can't you disable these modules in the kernel recipe instead
>using some config fragment?


We would like to use the same kernel .config across multiple images, as all we 
are changing is the removal of the modules, unless you can somehow specify 
which image recipe deletes certain modules in the kernel recipe.





From: Nicolas Dechesne 
Sent: Wednesday, January 23, 2019 1:04:48 PM
To: John Klug
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Exclude kernel module from image

On Wed, Jan 23, 2019 at 7:35 PM John Klug  wrote:
>
> I am looking for a way to create an image with an exclusion list of kernel 
> modules packages.
>
> If I use PACKAGE_EXCLUDE, I see the following:
>
> Collected errors:
>  * calculate_dependencies_for: Cannot satisfy the following dependencies 
> for kernel-modules:
>
> The list of modules that follows are the very kernel module packages I am 
> trying to exclude.

if you want to exclude *all* kernel modules it's simple, you can
achieve that with the following in your image recipe.

BAD_RECOMMENDATIONS = "kernel-modules"

This is easy because kernel-modules comes as RRECOMMENDS from
packagegroup-core-boot.. but if you exclude just some modules, then
you are breaking an RDEPENDS relationship which is a fatal error..

>
> I would prefer not to create a list of every kernel module I wish to include.

right.. can't you disable these modules in the kernel recipe instead
using some config fragment?

>
>
>
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> http://mail2.multitech.com:32224/?dmVyPTEuMDAxJiY0YmM3Zjk1YTkyYTYwMjg3ND01QzQ4QkFERV8xNzcwNl8xNjMxOF8yJiZlYmI5Zjc2MGY3NjAzOTQ9MTMzMyYmdXJsPWh0dHBzJTNBJTJGJTJGbGlzdHMlMkV5b2N0b3Byb2plY3QlMkVvcmclMkZsaXN0aW5mbyUyRnlvY3Rv
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project support for Numeric/Scientific Python

[Smith, Virgil (US)]

Is there a current or relatively recent recipe for SciPy and related libraries?

Further and more importantly, is having a maintainer for (recipes for) those 
libraries a priority for the active members of the Project?
(i.e. does interest rise above the general welcoming of participants to 
periodically asking "Hey has anyone put out a call to fill this slot?" if/when 
the slot is vacant).

BTW: If this is the wrong list for this query, please let me know.


Why?  We are trying to gauge community interest before making long term plans.
We would like to know if this horse is at all likely to have healthcare before 
betting on it (without sacrificing other patients to obtain the proper 
veterinary degree and keep up practice to treat it ourselves).


NOTE:  I see from the RRS emails that Derek Straka is currently maintaining the 
python-numpy recipe.  THANK YOU!




Notice to recipient: This email is meant for only the intended recipient of the 
transmission, and may be a communication privileged by law, subject to export 
control restrictions or that otherwise contains proprietary information. If you 
receive this email by mistake, please notify us immediately by replying to this 
message and then destroy it and do not review, disclose, copy or distribute it. 
Thank you in advance for your cooperation.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto Project support for Numeric/Scientific Python

[Randy MacLeod]

On 1/23/19 2:54 PM, Smith, Virgil (US) wrote:
Is there a current or relatively recent recipe for SciPy and related 
libraries?


People have worked on it at least once before but found some problems
with blas and atlas:

https://lists.yoctoproject.org/pipermail/yocto/2018-March/thread.html#40348

I'd say that there is interest.
I CCed Peter who started one of the threads
and BCCed 5 other people who seemed to be interested
since I didn't want to drag them all into the thread.




Further and more importantly, is having a maintainer for (recipes for) 
those libraries a priority for the active members of the Project?
(i.e. does interest rise above the general welcoming of participants to 
periodically asking “Hey has anyone put out a call to fill this slot?” 
if/when the slot is vacant).


It's always nice to have a maintainer but community members sometimes
keep recipes up to date even if they aren't direct users.



BTW: If this is the wrong list for this query, please let me know.


It a reasonable list for general discussion.
If you get to a point where patches are being submitted,
it should probably go to another list such as:



Why?  We are trying to gauge community interest before making long term 
plans.


We would like to know if this horse is at all likely to have healthcare 
before betting on it (without sacrificing other patients to obtain the 
proper veterinary degree and keep up practice to treat it ourselves).

heh.

Thanks!
../Randy



NOTE:  I see from the RRS emails that Derek Straka is currently 
maintaining the python-numpy recipe.  THANK YOU!





Notice to recipient: This email is meant for only the intended recipient 
of the transmission, and may be a communication privileged by law, 
subject to export control restrictions or that otherwise contains 
proprietary information. If you receive this email by mistake, please 
notify us immediately by replying to this message and then destroy it 
and do not review, disclose, copy or distribute it. Thank you in advance 
for your cooperation.





--
# Randy MacLeod
# Wind River Linux
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto Project support for Numeric/Scientific Python

[Philip Balister]

I care :)

On 01/23/2019 04:28 PM, Randy MacLeod wrote:
> On 1/23/19 2:54 PM, Smith, Virgil (US) wrote:
>> Is there a current or relatively recent recipe for SciPy and related
>> libraries?
> 
> People have worked on it at least once before but found some problems
> with blas and atlas:
> 
> https://lists.yoctoproject.org/pipermail/yocto/2018-March/thread.html#40348
> 
> I'd say that there is interest.
> I CCed Peter who started one of the threads
> and BCCed 5 other people who seemed to be interested
> since I didn't want to drag them all into the thread.
> 
> 
>>
>> Further and more importantly, is having a maintainer for (recipes for)
>> those libraries a priority for the active members of the Project?
>> (i.e. does interest rise above the general welcoming of participants
>> to periodically asking “Hey has anyone put out a call to fill this
>> slot?” if/when the slot is vacant).
> 
> It's always nice to have a maintainer but community members sometimes
> keep recipes up to date even if they aren't direct users.
> 
>>
>> BTW: If this is the wrong list for this query, please let me know.
> 
> It a reasonable list for general discussion.
> If you get to a point where patches are being submitted,
> it should probably go to another list such as:
> 
>>
>> Why?  We are trying to gauge community interest before making long
>> term plans.
>>
>> We would like to know if this horse is at all likely to have
>> healthcare before betting on it (without sacrificing other patients to
>> obtain the proper veterinary degree and keep up practice to treat it
>> ourselves).
> heh.
> 
> Thanks!
> ../Randy
> 
>>
>> NOTE:  I see from the RRS emails that Derek Straka is currently
>> maintaining the python-numpy recipe.  THANK YOU!
>>
>>
>> 
>>
>> Notice to recipient: This email is meant for only the intended
>> recipient of the transmission, and may be a communication privileged
>> by law, subject to export control restrictions or that otherwise
>> contains proprietary information. If you receive this email by
>> mistake, please notify us immediately by replying to this message and
>> then destroy it and do not review, disclose, copy or distribute it.
>> Thank you in advance for your cooperation.
>>
> 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto Project support for Numeric/Scientific Python

[Randy MacLeod]

On 1/23/19 4:28 PM, Randy MacLeod wrote:

It a reasonable list for general discussion.
If you get to a point where patches are being submitted,
it should probably go to another list such as:

oops... such as the meta-openembedded list:
  openembedded-de...@lists.openembedded.org
or whatever list the package(s) land in.

--
# Randy MacLeod
# Wind River Linux
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ipv6

[Philip Balister]

Turn off ipv6 in the kernel config?

Also see:

https://www.internetsociety.org/blog/2013/07/the-legacy-ip-only-ipv6-horse-and-buggy-stickers-how-to-get-copies-2/

I can mail you some stickers :)

Philip


On 01/18/2019 04:28 PM, Srinivasan, Raja wrote:
> All
> 
> I am using "rocko"
> 
> How can we turn off ipv6 altogether? We are not doing anything to startup 
> ipv6. Still I see several lines in the logs which look like:
> 
> kernel: IPv6: wlan0: IPv6 duplicate address . detected
> kernel[288]: IPv6: wlan0: IPv6 duplicate address ... detected
> 
> thanks, srini
> 
> 
> 
> CONFIDENTIALITY NOTICE: This email message and any attachments are 
> confidential and may be privileged and are meant to be read by the intended 
> recipient only. If you are not the intended recipient, please notify sender 
> immediately and destroy all copies of this message and any attachments 
> without reading or disclosing their contents. Thank you
> 
> 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto Project support for Numeric/Scientific Python

[Smith, Virgil (US)]

Discussing only the question of making a SciPy recipe today:

> > Is there a current or relatively recent recipe for SciPy and related 
> > libraries?
>
> People have worked on it at least once before but found some problems with 
> blas and atlas:
> https://lists.yoctoproject.org/pipermail/yocto/2018-March/thread.html#40348
> # Randy MacLeod
> Wind River Linux

Thanks Randy, my own brief foray landed on the following thread as the most 
promising lead:
https://lists.yoctoproject.org/pipermail/yocto/2018-March/040450.html

I didn't have any success with those pieces, but the telling point in that 
discussion are the patches to numpy (numpy.distutils).  When you dig into 
SciPy's installation instructions and therefore its setup.py file, you find 
that it is using code packaged into the numpy library as effectively its own 
configure/build toolchain.  It is full of Linux vs Windows vs MacOS 
distinctions and path probing for recognized compilers/tools.  Patching that 
into something that can be tuned for cross compiling was beyond my allowances 
for an "investigative effort".

I did manage to *compile* OpenBlas just by blending its standard build 
instructions (pure make based) with oe_runmake, a libgfortran DEPENDS/RDEPENDS, 
(FORTRAN_forcevariable = ",fortran" in local.conf), and some regex mapping from 
TUNE_FEATURES to the defines used by OpenBlas.

If I ever find out it actually worked (once), I'll post it in case someone has 
bandwidth to add
checks for mapping other MACHINE/TUNE... values to OpenBlas "TargetList.txt" 
entries, testing that it works in newer Yocto releases (I'm using Sumo), and 
add update-alternatives integration.





Notice to recipient: This email is meant for only the intended recipient of the 
transmission, and may be a communication privileged by law, subject to export 
control restrictions or that otherwise contains proprietary information. If you 
receive this email by mistake, please notify us immediately by replying to this 
message and then destroy it and do not review, disclose, copy or distribute it. 
Thank you in advance for your cooperation.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] wic utility

[Kevin Hao]

On Wed, Jan 23, 2019 at 04:39:07PM +, Srinivasan, Raja wrote:
> I am using wic 0.2.0 from the rocko build.
> 
>  
> 
> wic cp file wifile:part/path
> 
>  
> 
> appears to succeed (no errors reported).
> 
>  
> 
> But when I perform wic ls I don’t find the file in the target.
> 
>  
> 
> Are there any switches the I should be using?

It seems that it works fine on the master branch.
$ wic ls 
tmp/deploy/images/beaglebone-yocto/core-image-sato-beaglebone-yocto.wic:2
debugfs 1.43.5 (04-Aug-2017)
  2   40755 (2)  0  04096 23-Jan-2019 14:04 .
  2   40755 (2)  0  04096 23-Jan-2019 14:04 ..
 11   40700 (2)  0  0   16384 23-Jan-2019 14:04 lost+found
 12   40755 (2)  0  04096 23-Jan-2019 13:56 lib
456   40755 (2)  0  04096 23-Jan-2019 13:43 dev
457   40555 (2)  0  04096 23-Jan-2019 13:43 proc
458   40755 (2)  0  04096 23-Jan-2019 13:43 media
459   40755 (2)  0  04096 23-Jan-2019 14:04 boot
465   40755 (2)  0  04096 23-Jan-2019 14:03 mnt
467   40755 (2)  0  04096 23-Jan-2019 13:57 usr
   9582   40755 (2)  0  04096 23-Jan-2019 13:56 var
   9639   40555 (2)  0  04096 23-Jan-2019 13:43 sys
   9640   40755 (2)  0  04096 23-Jan-2019 14:04 etc
  10373   40755 (2)  0  04096 23-Jan-2019 14:03 sbin
  10437   40755 (2)  0  04096 23-Jan-2019 13:43 run
  10438   41777 (2)  0  04096 23-Jan-2019 13:43 tmp
  10439   40755 (2)  0  04096 23-Jan-2019 14:03 home
  10441   40755 (2)  0  04096 23-Jan-2019 14:03 bin
$ wic cp a.txt 
tmp/deploy/images/beaglebone-yocto/core-image-sato-beaglebone-yocto.wic:2
$ wic ls 
tmp/deploy/images/beaglebone-yocto/core-image-sato-beaglebone-yocto.wic:2
debugfs 1.43.5 (04-Aug-2017)
  2   40755 (2)  0  04096 23-Jan-2019 14:04 .
  2   40755 (2)  0  04096 23-Jan-2019 14:04 ..
 11   40700 (2)  0  0   16384 23-Jan-2019 14:04 lost+found
 12   40755 (2)  0  04096 23-Jan-2019 13:56 lib
456   40755 (2)  0  04096 23-Jan-2019 13:43 dev
457   40555 (2)  0  04096 23-Jan-2019 13:43 proc
458   40755 (2)  0  04096 23-Jan-2019 13:43 media
459   40755 (2)  0  04096 23-Jan-2019 14:04 boot
465   40755 (2)  0  04096 23-Jan-2019 14:03 mnt
467   40755 (2)  0  04096 23-Jan-2019 13:57 usr
   9582   40755 (2)  0  04096 23-Jan-2019 13:56 var
   9639   40555 (2)  0  04096 23-Jan-2019 13:43 sys
   9640   40755 (2)  0  04096 23-Jan-2019 14:04 etc
  10373   40755 (2)  0  04096 23-Jan-2019 14:03 sbin
  10437   40755 (2)  0  04096 23-Jan-2019 13:43 run
  10438   41777 (2)  0  04096 23-Jan-2019 13:43 tmp
  10439   40755 (2)  0  04096 23-Jan-2019 14:03 home
  10441   40755 (2)  0  04096 23-Jan-2019 14:03 bin
  10514  100644 (1)  0  0   4 24-Jan-2019 14:23 a.txt

There should be no change for the Disk.copy() function between rocko and master
branch. Anyway could you have a try on the latest master branch?

Thanks,
Kevin

> 
>  
> 
> Thanks for any pointers, srini
> 
> 
> ━━━
> 
> CONFIDENTIALITY NOTICE: This email message and any attachments are 
> confidential
> and may be privileged and are meant to be read by the intended recipient only.
> If you are not the intended recipient, please notify sender immediately and
> destroy all copies of this message and any attachments without reading or
> disclosing their contents. Thank you
> 
> 
> 

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



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