* 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.