All of lore.kernel.org
 help / color / mirror / Atom feed
* RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
@ 2021-06-25  7:37 Rasmus Villemoes
  2021-06-25 12:16 ` [OE-core] " Richard Purdie
  0 siblings, 1 reply; 11+ messages in thread
From: Rasmus Villemoes @ 2021-06-25  7:37 UTC (permalink / raw)
  To: OE Core mailing list

I noticed that if I have an image recipe that says

IMAGE_INSTALL += "kernel-module-foo"

it fails as expected when the kernel hasn't been built with CONFIG_FOO=m.

However, if at the same time some other package which happens to get
installed in the same image says

RRECOMMENDS_${PN} += "kernel-module-foo"

the image build silently succeeds, obviously without any foo.ko
included. This doesn't seem right. [I'm well aware that the RRECOMMENDS
line alone works as expected, this is about the case where both the
above lines are in play.]

=====

So I discovered this while trying to figure out how to be able to say
IMAGE_INSTALL += "kernel-module-ext4" , and have that succeed whenever
ext4 is builtin or modular, and have it be a build time error if the
kernel was built with EXT4=n - so the recommends approach is out.  It
obviously doesn't work out-of-the-box for the EXT4=y case. So now I'm
contemplating doing

python kernel_base_provide_builtin () {
    kname = d.getVar("KERNEL_PACKAGE_NAME") or "kernel"
    builtin = os.path.join(d.getVar("PKGD"), "lib/modules",
d.getVar("KERNEL_VERSION"), "modules.builtin")
    if not os.path.exists(builtin):
        return
    builtin_mods = []
    with open(builtin) as f:
        for mod in f:
            mod = mod.strip()
            mod = os.path.basename(mod)
            if not mod.endswith(".ko"):
                continue
            mod = mod[:-3]
            mod = mod.lower().replace("_", "-")
            builtin_mods.append("%s-module-%s" % (kname, mod))

    basepkg = kname + "-base"
    rprovides = (d.getVar("RPROVIDES_" + basepkg) or "").split()
    rprovides += builtin_mods
    d.setVar("RPROVIDES_" + basepkg, " ".join(rprovides))
}
PACKAGESPLITFUNCS += "kernel_base_provide_builtin"

i.e., make sure that the kernel-base package is an rprovider of
kernel-module-ext4 for the EXT4=y case [*]. That seems to work as
expected in the cases I've tried (provided nobody rrecommends ext4, per
above). Does anybody see anything wrong with that approach? EXT4 is just
an example, I'm gonna use it for other modules/subsystems with more
complicated dependencies that might not be satisfied in a base .config,
so a fragment saying CONFIG_FOO=m might have been ignored due to that,
and I'd prefer catching that no later than at image build time.

I'm not necessarily suggesting the above for oe-core, I can live with it
in my own kernel recipes.

[*] kernel-base and not the package containing the actual kernel binary,
because kernel-base contains the modules.builtin file which is what
modprobe consults first to see if it actually has to do anything, so it
makes sense to have kernel-module-ext4 pull in that file and the other
/lib/modules/ metadata when EXT4=y. The kernel binary is as often as not
not actually in the rootfs image, and wouldn't be useful to modprobe anyway.

Rasmus

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
  2021-06-25  7:37 RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL Rasmus Villemoes
@ 2021-06-25 12:16 ` Richard Purdie
  2021-06-25 15:45   ` Rasmus Villemoes
  0 siblings, 1 reply; 11+ messages in thread
From: Richard Purdie @ 2021-06-25 12:16 UTC (permalink / raw)
  To: rasmus.villemoes, OE Core mailing list

On Fri, 2021-06-25 at 09:37 +0200, Rasmus Villemoes via lists.openembedded.org wrote:
> I noticed that if I have an image recipe that says
> 
> IMAGE_INSTALL += "kernel-module-foo"
> 
> it fails as expected when the kernel hasn't been built with CONFIG_FOO=m.
> 
> However, if at the same time some other package which happens to get
> installed in the same image says
> 
> RRECOMMENDS_${PN} += "kernel-module-foo"
> 
> the image build silently succeeds, obviously without any foo.ko
> included. This doesn't seem right. [I'm well aware that the RRECOMMENDS
> line alone works as expected, this is about the case where both the
> above lines are in play.]

Which package backend are you using and does this happen if you
use a different one, particularly swapping ipk and rpm?

That might tell us if this is a package manager issue or a bitbake
metadata one.

Cheers,

Richard



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
  2021-06-25 12:16 ` [OE-core] " Richard Purdie
@ 2021-06-25 15:45   ` Rasmus Villemoes
  2021-06-25 16:13     ` Richard Purdie
  0 siblings, 1 reply; 11+ messages in thread
From: Rasmus Villemoes @ 2021-06-25 15:45 UTC (permalink / raw)
  To: Richard Purdie, OE Core mailing list

On 25/06/2021 14.16, Richard Purdie wrote:
> On Fri, 2021-06-25 at 09:37 +0200, Rasmus Villemoes via lists.openembedded.org wrote:
>> I noticed that if I have an image recipe that says
>>
>> IMAGE_INSTALL += "kernel-module-foo"
>>
>> it fails as expected when the kernel hasn't been built with CONFIG_FOO=m.
>>
>> However, if at the same time some other package which happens to get
>> installed in the same image says
>>
>> RRECOMMENDS_${PN} += "kernel-module-foo"
>>
>> the image build silently succeeds, obviously without any foo.ko
>> included. This doesn't seem right. [I'm well aware that the RRECOMMENDS
>> line alone works as expected, this is about the case where both the
>> above lines are in play.]
> 
> Which package backend are you using and does this happen if you
> use a different one, particularly swapping ipk and rpm?
> 
> That might tell us if this is a package manager issue or a bitbake
> metadata one.

I was using ipk. It seems to work as expected (i.e. fail the build) when
using rpm.

Rasmus

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
  2021-06-25 15:45   ` Rasmus Villemoes
@ 2021-06-25 16:13     ` Richard Purdie
  2021-06-28  9:17       ` Rasmus Villemoes
  0 siblings, 1 reply; 11+ messages in thread
From: Richard Purdie @ 2021-06-25 16:13 UTC (permalink / raw)
  To: Rasmus Villemoes, OE Core mailing list; +Cc: Alex Stewart

On Fri, 2021-06-25 at 17:45 +0200, Rasmus Villemoes wrote:
> On 25/06/2021 14.16, Richard Purdie wrote:
> > On Fri, 2021-06-25 at 09:37 +0200, Rasmus Villemoes via lists.openembedded.org wrote:
> > > I noticed that if I have an image recipe that says
> > > 
> > > IMAGE_INSTALL += "kernel-module-foo"
> > > 
> > > it fails as expected when the kernel hasn't been built with CONFIG_FOO=m.
> > > 
> > > However, if at the same time some other package which happens to get
> > > installed in the same image says
> > > 
> > > RRECOMMENDS_${PN} += "kernel-module-foo"
> > > 
> > > the image build silently succeeds, obviously without any foo.ko
> > > included. This doesn't seem right. [I'm well aware that the RRECOMMENDS
> > > line alone works as expected, this is about the case where both the
> > > above lines are in play.]
> > 
> > Which package backend are you using and does this happen if you
> > use a different one, particularly swapping ipk and rpm?
> > 
> > That might tell us if this is a package manager issue or a bitbake
> > metadata one.
> 
> I was using ipk. It seems to work as expected (i.e. fail the build) when
> using rpm.

That is probably a bug that needs opening against opkg in bugzilla then.
Added Alex to Cc: (opkg maintainer).

Cheers,

Richard


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
  2021-06-25 16:13     ` Richard Purdie
@ 2021-06-28  9:17       ` Rasmus Villemoes
  2021-06-28  9:45         ` Richard Purdie
  2021-07-06 19:39         ` Alex Stewart
  0 siblings, 2 replies; 11+ messages in thread
From: Rasmus Villemoes @ 2021-06-28  9:17 UTC (permalink / raw)
  To: Richard Purdie, OE Core mailing list; +Cc: Alex Stewart

On 25/06/2021 18.13, Richard Purdie wrote:
> On Fri, 2021-06-25 at 17:45 +0200, Rasmus Villemoes wrote:
>> On 25/06/2021 14.16, Richard Purdie wrote:
>>> On Fri, 2021-06-25 at 09:37 +0200, Rasmus Villemoes via lists.openembedded.org wrote:
>>>> I noticed that if I have an image recipe that says
>>>>
>>>> IMAGE_INSTALL += "kernel-module-foo"
>>>>
>>>> it fails as expected when the kernel hasn't been built with CONFIG_FOO=m.
>>>>
>>>> However, if at the same time some other package which happens to get
>>>> installed in the same image says
>>>>
>>>> RRECOMMENDS_${PN} += "kernel-module-foo"
>>>>
>>>> the image build silently succeeds, obviously without any foo.ko
>>>> included. This doesn't seem right. [I'm well aware that the RRECOMMENDS
>>>> line alone works as expected, this is about the case where both the
>>>> above lines are in play.]
>>>
>>> Which package backend are you using and does this happen if you
>>> use a different one, particularly swapping ipk and rpm?
>>>
>>> That might tell us if this is a package manager issue or a bitbake
>>> metadata one.
>>
>> I was using ipk. It seems to work as expected (i.e. fail the build) when
>> using rpm.
> 
> That is probably a bug that needs opening against opkg in bugzilla then.
> Added Alex to Cc: (opkg maintainer).

Indeed, thanks. Alex, do you have enough context from the above, or do I
need to do anything explicitly to file a bug?

Rasmus

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
  2021-06-28  9:17       ` Rasmus Villemoes
@ 2021-06-28  9:45         ` Richard Purdie
  2021-07-06 19:39         ` Alex Stewart
  1 sibling, 0 replies; 11+ messages in thread
From: Richard Purdie @ 2021-06-28  9:45 UTC (permalink / raw)
  To: Rasmus Villemoes, OE Core mailing list; +Cc: Alex Stewart

On Mon, 2021-06-28 at 11:17 +0200, Rasmus Villemoes wrote:
> On 25/06/2021 18.13, Richard Purdie wrote:
> > On Fri, 2021-06-25 at 17:45 +0200, Rasmus Villemoes wrote:
> > > On 25/06/2021 14.16, Richard Purdie wrote:
> > > > On Fri, 2021-06-25 at 09:37 +0200, Rasmus Villemoes via lists.openembedded.org wrote:
> > > > > I noticed that if I have an image recipe that says
> > > > > 
> > > > > IMAGE_INSTALL += "kernel-module-foo"
> > > > > 
> > > > > it fails as expected when the kernel hasn't been built with CONFIG_FOO=m.
> > > > > 
> > > > > However, if at the same time some other package which happens to get
> > > > > installed in the same image says
> > > > > 
> > > > > RRECOMMENDS_${PN} += "kernel-module-foo"
> > > > > 
> > > > > the image build silently succeeds, obviously without any foo.ko
> > > > > included. This doesn't seem right. [I'm well aware that the RRECOMMENDS
> > > > > line alone works as expected, this is about the case where both the
> > > > > above lines are in play.]
> > > > 
> > > > Which package backend are you using and does this happen if you
> > > > use a different one, particularly swapping ipk and rpm?
> > > > 
> > > > That might tell us if this is a package manager issue or a bitbake
> > > > metadata one.
> > > 
> > > I was using ipk. It seems to work as expected (i.e. fail the build) when
> > > using rpm.
> > 
> > That is probably a bug that needs opening against opkg in bugzilla then.
> > Added Alex to Cc: (opkg maintainer).
> 
> Indeed, thanks. Alex, do you have enough context from the above, or do I
> need to do anything explicitly to file a bug?

Please open a bug in bugzilla: https://bugzilla.yoctoproject.org/

That way we ensure it is tracked and doesn't get lost.

Cheers,

Richard


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
  2021-06-28  9:17       ` Rasmus Villemoes
  2021-06-28  9:45         ` Richard Purdie
@ 2021-07-06 19:39         ` Alex Stewart
  2021-07-06 20:12           ` Richard Purdie
  2021-07-26 13:48           ` Rasmus Villemoes
  1 sibling, 2 replies; 11+ messages in thread
From: Alex Stewart @ 2021-07-06 19:39 UTC (permalink / raw)
  To: Rasmus Villemoes, Richard Purdie, OE Core mailing list

Hey Rasmus,

Sorry for the delay; I was OOO for the holidays and I'm just now working 
through my inbox.

On 6/28/21 4:17 AM, Rasmus Villemoes wrote:
> On 25/06/2021 18.13, Richard Purdie wrote:
>> That is probably a bug that needs opening against opkg in bugzilla then.
>> Added Alex to Cc: (opkg maintainer).
> Indeed, thanks. Alex, do you have enough context from the above, or do I
> need to do anything explicitly to file a bug?
>
> Rasmus

Could you expand a bit on how OE is supposed to fail when the kernel 
module package is unsatisfiable? Does it propagate a opkg satisfaction 
error, or is the misconfiguration caught in the OE python modules?

I ask because it seems most likely to me that the inconsistency here is 
in the OE opkg interface modules, rather than opkg itself - which 
obviously has no concept of IMAGE_INSTALL or the kernel configuration.

Can you identify the set of packages that OE is requesting opkg to 
install, with and without the RRECOMMENDS? That would help to 
distinguish between an inconsistency in the OE PackageManager modules 
and a bug in opkg itself.

Thanks,

-- 
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stewart@ni.com


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
  2021-07-06 19:39         ` Alex Stewart
@ 2021-07-06 20:12           ` Richard Purdie
  2021-07-06 20:46             ` Alex Stewart
  2021-07-26 13:48           ` Rasmus Villemoes
  1 sibling, 1 reply; 11+ messages in thread
From: Richard Purdie @ 2021-07-06 20:12 UTC (permalink / raw)
  To: Alex Stewart, Rasmus Villemoes, OE Core mailing list

On Tue, 2021-07-06 at 14:39 -0500, Alex Stewart wrote:
> Hey Rasmus,
> 
> Sorry for the delay; I was OOO for the holidays and I'm just now working 
> through my inbox.
> 
> On 6/28/21 4:17 AM, Rasmus Villemoes wrote:
> > On 25/06/2021 18.13, Richard Purdie wrote:
> > > That is probably a bug that needs opening against opkg in bugzilla then.
> > > Added Alex to Cc: (opkg maintainer).
> > Indeed, thanks. Alex, do you have enough context from the above, or do I
> > need to do anything explicitly to file a bug?
> > 
> > Rasmus
> 
> Could you expand a bit on how OE is supposed to fail when the kernel 
> module package is unsatisfiable? Does it propagate a opkg satisfaction 
> error, or is the misconfiguration caught in the OE python modules?
> 
> I ask because it seems most likely to me that the inconsistency here is 
> in the OE opkg interface modules, rather than opkg itself - which 
> obviously has no concept of IMAGE_INSTALL or the kernel configuration.
> 
> Can you identify the set of packages that OE is requesting opkg to 
> install, with and without the RRECOMMENDS? That would help to 
> distinguish between an inconsistency in the OE PackageManager modules 
> and a bug in opkg itself.

Kernel modules can be:

a) not built at all
b) built into the kernel
c) built as separate packages

For OE, where something needs a kernel module, we suggest people:

RRECOMMEND_XXX += "kernel-module-xxx"

and the kernel recipe has PACKAGES_DYNAMIC = "kernel-module-*".

From bitbake's perspective, it builds the kernel (since the PACKAGES_DYNAMIC 
covers kernel-modules-xxx) and then hands off to the package manager.

In the case it was built in, the Recommends will be passed over by the 
package manager since it is just a suggestion. If the module is present,
it would be included in the image.

The issue as described is that if someone has IMAGE_INSTALL containing
kernel-module-xxx *and* some other package in the image RRECOMMENDS that 
module, it doesn't error if the package doesn't exist.

I have to admit I don't remember how IMAGE_INSTALL is being passed into
opkg but the change in behaviour due to the addition of a RRECOMMENDS does
not sound right to me. The rpm backend does not do that but errors 
consistently.

It sounds like the "Depends" from IMAGE_INSTALL is somehow being overruled
by the Recommends from some sub package dependency.

If we're driving opkg incorrectly, we should fix that but I'm not sure
where the issue is, I suspect opkg...

Cheers,

Richard



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
  2021-07-06 20:12           ` Richard Purdie
@ 2021-07-06 20:46             ` Alex Stewart
  0 siblings, 0 replies; 11+ messages in thread
From: Alex Stewart @ 2021-07-06 20:46 UTC (permalink / raw)
  To: Richard Purdie, Rasmus Villemoes, OE Core mailing list

On 7/6/21 3:12 PM, Richard Purdie wrote:
> Kernel modules can be:
>
> a) not built at all
> b) built into the kernel3
> c) built as separate packages
>
> For OE, where something needs a kernel module, we suggest people:
>
> RRECOMMEND_XXX += "kernel-module-xxx"
>
> and the kernel recipe has PACKAGES_DYNAMIC = "kernel-module-*".
>
>  From bitbake's perspective, it builds the kernel (since the PACKAGES_DYNAMIC
> covers kernel-modules-xxx) and then hands off to the package manager.
>
> In the case it was built in, the Recommends will be passed over by the
> package manager since it is just a suggestion. If the module is present,
> it would be included in the image.
>
> The issue as described is that if someone has IMAGE_INSTALL containing
> kernel-module-xxx *and* some other package in the image RRECOMMENDS that
> module, it doesn't error if the package doesn't exist.
>
> I have to admit I don't remember how IMAGE_INSTALL is being passed into
> opkg but the change in behaviour due to the addition of a RRECOMMENDS does
> not sound right to me. The rpm backend does not do that but errors
> consistently.

Yep; I understand all of that and agree. My goal here is just to make 
sure that the bug is filed to the correct location. As it stands, the 
only description of the error is from OE's perspective, and I'd like to 
get some understanding of the interface between OE and opkg, for this 
special case.

> It sounds like the "Depends" from IMAGE_INSTALL is somehow being overruled
> by the Recommends from some sub package dependency.

I know that IMAGE_INSTALL gets consumed into PACKAGE_INSTALL, which gets 
pass off to the PM modules (iirc.) And I also recall there being a 
PACKAGE_INSTALL_ATTEMPTONLY variable[1]. I wonder if RRECOMMENDS are 
being ATTEMPTed (either through that variable, or a similar one), and 
the failed attempt is pre-empting the mandatory install attempt. Worth 
looking into.

[1] 
https://git.openembedded.org/openembedded-core/tree/meta/classes/image.bbclass#n79

> If we're driving opkg incorrectly, we should fix that but I'm not sure
> where the issue is, I suspect opkg...

Why do you suspect opkg? The situation from its perspective is only that 
`kernel-module-xxx` is recommended by another package, but not available 
in the feeds. There's nothing invalid about that state that would cause 
opkg to throw an error.

Thanks,

-- 
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stewart@ni.com


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
  2021-07-06 19:39         ` Alex Stewart
  2021-07-06 20:12           ` Richard Purdie
@ 2021-07-26 13:48           ` Rasmus Villemoes
  2021-07-28 20:40             ` Alex Stewart
  1 sibling, 1 reply; 11+ messages in thread
From: Rasmus Villemoes @ 2021-07-26 13:48 UTC (permalink / raw)
  To: Alex Stewart, Richard Purdie, OE Core mailing list

On 06/07/2021 21.39, Alex Stewart wrote:
> Hey Rasmus,
> 
> Sorry for the delay; I was OOO for the holidays and I'm just now working
> through my inbox.

No need to apologize; as it happens I've just now returned from vacation.

> On 6/28/21 4:17 AM, Rasmus Villemoes wrote:
>> On 25/06/2021 18.13, Richard Purdie wrote:
>>> That is probably a bug that needs opening against opkg in bugzilla then.
>>> Added Alex to Cc: (opkg maintainer).
>> Indeed, thanks. Alex, do you have enough context from the above, or do I
>> need to do anything explicitly to file a bug?
>>
>> Rasmus
> 
> Could you expand a bit on how OE is supposed to fail when the kernel
> module package is unsatisfiable? Does it propagate a opkg satisfaction
> error, or is the misconfiguration caught in the OE python modules?
> 
> I ask because it seems most likely to me that the inconsistency here is
> in the OE opkg interface modules, rather than opkg itself - which
> obviously has no concept of IMAGE_INSTALL or the kernel configuration.
> 
> Can you identify the set of packages that OE is requesting opkg to
> install, with and without the RRECOMMENDS? 

Looking at log.do_rootfs, it seems that opkg gets invoked in exactly the
same way with and without the RRECOMMENDS in play:

With RRECOMMENDS, where the build succeeds:

NOTE: Installing the following packages: [...] glib-2.0 iproute2
kernel-image kernel-module-abcd less libgettextlib [...]
NOTE: [...]/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f
[...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/opkg.conf -t
[...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/temp/ipktemp/ -o
[...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/rootfs  --force_postinstall
--prefer-arch-to-version   --add-ignore-recommends busybox-syslog
--add-ignore-recommends busybox-udhcpc --add-ignore-recommends
kernel-vmlinux --add-ignore-recommends udev-cache install [...] glib-2.0
iproute2 kernel-image kernel-module-abcd less libgettextlib [...]

And no further mention of kernel-module-abcd.

Without the RRECOMMENDS:

NOTE: Installing the following packages: [...] glib-2.0 iproute2
kernel-image kernel-module-abcd less libgettextlib [...]
NOTE: [...]/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f
[...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/opkg.conf -t
[...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/temp/ipktemp/ -o
[...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/rootfs  --force_postinstall
--prefer-arch-to-version   --add-ignore-recommends busybox-syslog
--add-ignore-recommends busybox-udhcpc --add-ignore-recommends
kernel-vmlinux --add-ignore-recommends udev-cache install [...] glib-2.0
iproute2 kernel-image kernel-module-abcd less libgettextlib [...]
ERROR: Unable to install packages. Command
'[...]/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f
[...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/opkg.conf -t
[...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/temp/ipktemp/ -o
[...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/rootfs  --force_postinstall
--prefer-arch-to-version   --add-ignore-recommends busybox-syslog
--add-ignore-recommends busybox-udhcpc --add-ignore-recommends
kernel-vmlinux --add-ignore-recommends udev-cache install [...] glib-2.0
iproute2 kernel-image kernel-module-abcd less libgettextlib [...]'
returned 255:
 * opkg_prepare_url_for_install: Couldn't find anything to satisfy
'kernel-module-abcd'.


So I assume the difference must be in some of the metadata files
(opkg.conf or the ipktemp/ dir argument to the -t flag), but I know
nothing about how opkg/ipk works internally or what to look for.

Thanks,
Rasmus

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
  2021-07-26 13:48           ` Rasmus Villemoes
@ 2021-07-28 20:40             ` Alex Stewart
  0 siblings, 0 replies; 11+ messages in thread
From: Alex Stewart @ 2021-07-28 20:40 UTC (permalink / raw)
  To: Rasmus Villemoes, OE Core mailing list; +Cc: Richard Purdie



On 7/26/21 8:48 AM, Rasmus Villemoes wrote:
> Looking at log.do_rootfs, it seems that opkg gets invoked in exactly the
> same way with and without the RRECOMMENDS in play:
>
> With RRECOMMENDS, where the build succeeds:
>
> NOTE: Installing the following packages: [...] glib-2.0 iproute2
> kernel-image kernel-module-abcd less libgettextlib [...]
> NOTE: [...]/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f
> [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/opkg.conf -t
> [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/temp/ipktemp/ -o
> [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/rootfs  --force_postinstall
> --prefer-arch-to-version   --add-ignore-recommends busybox-syslog
> --add-ignore-recommends busybox-udhcpc --add-ignore-recommends
> kernel-vmlinux --add-ignore-recommends udev-cache install [...] glib-2.0
> iproute2 kernel-image kernel-module-abcd less libgettextlib [...]
>
> And no further mention of kernel-module-abcd.
>
> Without the RRECOMMENDS:
>
> NOTE: Installing the following packages: [...] glib-2.0 iproute2
> kernel-image kernel-module-abcd less libgettextlib [...]
> NOTE: [...]/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f
> [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/opkg.conf -t
> [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/temp/ipktemp/ -o
> [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/rootfs  --force_postinstall
> --prefer-arch-to-version   --add-ignore-recommends busybox-syslog
> --add-ignore-recommends busybox-udhcpc --add-ignore-recommends
> kernel-vmlinux --add-ignore-recommends udev-cache install [...] glib-2.0
> iproute2 kernel-image kernel-module-abcd less libgettextlib [...]
> ERROR: Unable to install packages. Command
> '[...]/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f
> [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/opkg.conf -t
> [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/temp/ipktemp/ -o
> [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/rootfs  --force_postinstall
> --prefer-arch-to-version   --add-ignore-recommends busybox-syslog
> --add-ignore-recommends busybox-udhcpc --add-ignore-recommends
> kernel-vmlinux --add-ignore-recommends udev-cache install [...] glib-2.0
> iproute2 kernel-image kernel-module-abcd less libgettextlib [...]'
> returned 255:
>   * opkg_prepare_url_for_install: Couldn't find anything to satisfy
> 'kernel-module-abcd'.

That's helpful info; thanks. I'll paste it to the bug in the opkg 
bugzilla and we can continue tracking there.

-- 
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stewart@ni.com


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2021-07-28 20:41 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-25  7:37 RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL Rasmus Villemoes
2021-06-25 12:16 ` [OE-core] " Richard Purdie
2021-06-25 15:45   ` Rasmus Villemoes
2021-06-25 16:13     ` Richard Purdie
2021-06-28  9:17       ` Rasmus Villemoes
2021-06-28  9:45         ` Richard Purdie
2021-07-06 19:39         ` Alex Stewart
2021-07-06 20:12           ` Richard Purdie
2021-07-06 20:46             ` Alex Stewart
2021-07-26 13:48           ` Rasmus Villemoes
2021-07-28 20:40             ` Alex Stewart

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.