Re: opkg architecture warnings

[Koen Kooi]

Op 12 feb. 2014, om 15:25 heeft Paul Barker <pa...@paulbarker.me.uk> het volgende geschreven:

> On 12 February 2014 10:00, Koen Kooi <ko...@dominion.thruhere.net> wrote:
>> Paul,
>>
>> I've been working on using the meta-fsl-arm layer in angstrom and I'm running into some issues with opkg. Meta-fsl-arm defines a custom architecture for their SoC specific things (${ARCH}-mx6). To keep the angstrom feed layout sane I'm copying those into the main armv7a feed, but on every opkg invocation I get a ton of these:
>>
>> Package libgles2-mx6-dev version 1:3.10.9-1.0.0-hfp-r0.0 has no valid architecture, ignoring.
>> Package libgles2-mx6 version 1:3.10.9-1.0.0-hfp-r0.0 has no valid architecture, ignoring.
>> Package libglslc-mx6 version 1:3.10.9-1.0.0-hfp-r0.0 has no valid architecture, ignoring.
>> Package libgstapp-0.10-0 version 0.10.36-r9.0 has no valid architecture, ignoring.
>> Package libgstaudio-0.10-0 version 0.10.36-r9.0 has no valid architecture, ignoring.
>> Package libgstcdda-0.10-0 version 0.10.36-r9.0 has no valid architecture, ignoring.
>> Package libgstfft-0.10-0 version 0.10.36-r9.0 has no valid architecture, ignoring.
>> Package libgstinterfaces-0.10-0 version 0.10.36-r9.0 has no valid architecture, ignoring.
>> Package libgstnetbuffer-0.10-0 version 0.10.36-r9.0 has no valid architecture, ignoring.
>> Package libgstpbutils-0.10-0 version 0.10.36-r9.0 has no valid architecture, ignoring.
>> Package libgstriff-0.10-0 version 0.10.36-r9.0 has no valid architecture, ignoring.
>> Package libgstrtp-0.10-0 version 0.10.36-r9.0 has no valid architecture, ignoring.
>> Package libgstrtsp-0.10-0 version 0.10.36-r9.0 has no valid architecture, ignoring.
>> Package libgstsdp-0.10-0 version 0.10.36-r9.0 has no valid architecture, ignoring.
>> Package libgsttag-0.10-0 version 0.10.36-r9.0 has no valid architecture, ignoring.
>> Package libgstvideo-0.10-0 version 0.10.36-r9.0 has no valid architecture, ignoring.
>> Package libkms1 version 2.4.49-r0.0 has no valid architecture, ignoring.
>> Package libopencl-mx6 version 1:3.10.9-1.0.0-hfp-r0.0 has no valid architecture, ignoring.
>> Package libopenvg-mx6-dev version 1:3.10.9-1.0.0-hfp-r0.0 has no valid architecture, ignoring.
>> Package libopenvg-mx6 version 1:3.10.9-1.0.0-hfp-r0.0 has no valid architecture, ignoring.
>> Package libsdl-1.2-0 version 1.2.15-r2.0 has no valid architecture, ignoring.
>> Package libsdl-1.2-dev version 1.2.15-r2.0 has no valid architecture, ignoring.
>> Package libsdl-1.2-doc version 1.2.15-r2.0 has no valid architecture, ignoring.
>> Package libsdl-1.2-staticdev version 1.2.15-r2.0 has no valid architecture, ignoring.
>> Package libvdk-mx6-dev version 1:3.10.9-1.0.0-hfp-r0.0 has no valid architecture, ignoring.
>> Package libvdk-mx6 version 1:3.10.9-1.0.0-hfp-r0.0 has no valid architecture, ignoring.
>> Package libvivante-dri-mx6 version 1:3.10.9-1.0.0-hfp-r0.0 has no valid architecture, ignoring.
>> Package libvivante-mx6 version 1:3.10.9-1.0.0-hfp-r0.0 has no valid architecture, ignoring.
>> Package libwayland-viv0 version 1:3.10.9-1.0.0-hfp-r0.0 has no valid architecture, ignoring.
>>
>> Can the opkg default be changed to hide those until someone actually tries to install one of those packages?
>>
>
> Sadly not, that "ignoring" means the package isn't loaded into the
> in-memory list of available packages. So trying to install any of
> those packages later won't find anything to install. I'm pretty sure
> this is because all the later code assumes that every package has a
> valid architecture.

So no way of limiting this debug spew? It even triggers on 'opkg update' :(

regards,

Koen

>
> The mailing list opkg-...@googlegroups.com is probably a better
> place for this sort of questions in the future.
>
> Cheers,
>
> --
> Paul Barker
>
> Email: pa...@paulbarker.me.uk
> http://www.paulbarker.me.uk

[Paul Barker]

It could be limited to debugging output but then people may get
confused as to why packages in the list aren't available to install.

Do the packages in question have an "Architecture" field? Is it just
that that architecture isn't defined in the opkg config on a given
machine?

[Koen Kooi]

Yes, the packaged in question have 'armv7ahf-vfp-neon-mx6' in the architecture field and are present in the 'armv7ahf-vfp-neon' feed. Using non-freescale machines (e.g. beagleboard) will trigger the above spew since it doesn't have 'armv7ahf-vfp-neon-mx6' listed in arch.conf. A similar problem exists for 'core2' where 'core2-emgd' is used for package that depends on the binary only EMGD driver.

I guess it's karmic punishment since I didn't want TI to go the custom arch patch for this situation (SoC specific binary only lib hell) because of the opkg debug spew scaring users. So 4 years later opkg has an actual maintainer so I think we can get this finally fixed :)

regards,

Koen

[Paul Barker]

On 12 February 2014 17:04, Koen Kooi <ko...@dominion.thruhere.net> wrote:
>
> Op 12 feb. 2014, om 15:51 heeft Paul Barker <pa...@paulbarker.me.uk> het volgende geschreven:
>
>> On 12 February 2014 14:28, Koen Kooi <ko...@dominion.thruhere.net> wrote:
>>>
>>> Op 12 feb. 2014, om 15:25 heeft Paul Barker <pa...@paulbarker.me.uk> het volgende geschreven:
>>>
>>>> On 12 February 2014 10:00, Koen Kooi <ko...@dominion.thruhere.net> wrote:
>>>>> Paul,
>>>>>
>>>>> I've been working on using the meta-fsl-arm layer in angstrom and I'm running into some issues with opkg. Meta-fsl-arm defines a custom architecture for their SoC specific things (${ARCH}-mx6). To keep the angstrom feed layout sane I'm copying those into the main armv7a feed, but on every opkg invocation I get a ton of these:
>>>>>
>>>>> Package libgles2-mx6-dev version 1:3.10.9-1.0.0-hfp-r0.0 has no valid architecture, ignoring.

>>>>> <snip>

>>>>>
>>>>> Can the opkg default be changed to hide those until someone actually tries to install one of those packages?
>>>>>
>>>>
>>>> Sadly not, that "ignoring" means the package isn't loaded into the
>>>> in-memory list of available packages. So trying to install any of
>>>> those packages later won't find anything to install. I'm pretty sure
>>>> this is because all the later code assumes that every package has a
>>>> valid architecture.
>>>
>>> So no way of limiting this debug spew? It even triggers on 'opkg update' :(
>>>
>>
>> It could be limited to debugging output but then people may get
>> confused as to why packages in the list aren't available to install.
>>
>> Do the packages in question have an "Architecture" field? Is it just
>> that that architecture isn't defined in the opkg config on a given
>> machine?
>
> Yes, the packaged in question have 'armv7ahf-vfp-neon-mx6' in the architecture field and are present in the 'armv7ahf-vfp-neon' feed. Using non-freescale machines (e.g. beagleboard) will trigger the above spew since it doesn't have 'armv7ahf-vfp-neon-mx6' listed in arch.conf. A similar problem exists for 'core2' where 'core2-emgd' is used for package that depends on the binary only EMGD driver.
>
> I guess it's karmic punishment since I didn't want TI to go the custom arch patch for this situation (SoC specific binary only lib hell) because of the opkg debug spew scaring users. So 4 years later opkg has an actual maintainer so I think we can get this finally fixed :)
>

Ok, the warning message needs improving at least. The packages do have
a valid architecture, just one that doesn't run on the current machine
(and therefore isn't listed in the opkg config on the current
machine).

I'm personally a fan of having one feed per target machine but that's
policy not mechanism. opkg should handle mechanism and leave policy up
to the user where possible.

Let me have a think on this, I'll get back to you in a couple of days.

[Koen Kooi]

As a short term hack I'm using this patch: https://github.com/Angstrom-distribution/oe-core/blob/0ba50f1db5dcbf9733f3691847c247ed5a703392/meta/recipes-devtools/opkg/opkg/0001-pkg_hash-prevent-debug-spew-for-ignored-packages.patch
It's not the right way to fix it, but it does get rid of the debug spew :)

regards,

Koen

[Paul Barker]

Ok I'm going to drop this output to a lower debug level and change the
wording anyway. As stated, it just means that the feed contains
packages which don't run on the target machine. Given the wide variety
of machines in the embedded world, it would simplify things for distro
maintainers to allow one feed to cover multiple machines.

I was cautious at first as the message implied the architecture of a
package was in some way invalid but that's not strictly true.

Cheers,

[Paul Barker]

Sorry it's took so long to get to this, been a busy month!

I've attached a patch which still emits the notice if the package
really does have no valid architecture (meaning no "Architecture:"
field was parsed from the control or list files) but just emits a
debug notice if the architecture is valid but can't be installed on
the current system (which you won't see unless you pass -V3 or greater
to opkg).

Could you take a quick look and maybe try it on your system, check
that the notices do disappear. If it's good I'll merge it into master.

[Koen Kooi]

It looks like this does the right thing, but getting it tested will take a while, I don't have any opkg 0.2.recent systems up yes :(

regards,

Koen

[Paul Barker]

I just grabbed r653 from Subversion which I think is what you're still
using (looking at
https://github.com/Angstrom-distribution/oe-core/blob/0ba50f1db5dcbf9733f3691847c247ed5a703392/meta/recipes-devtools/opkg/opkg_svn.bb).
The patch applies cleanly to that. It's not a very often
changed bit of the code.

[Koen Kooi]

I tested it with opkg_0.1.8+svnr653 and it does the right thing with 'opkg update' and 'opkg upgrade', so it looks good to me!

regards,

Koen

[Paul Barker]

Thanks for the test! I've merged this into the opkg-0.2.x branch so it
should be included in the upcoming v0.2.2 release.