Forums

When trying to install the plugin on a HD51 it gives below error in RC 6.2

opkg install enigma2-plugin-extensions-qthbbtv
qtbase: unsatisfied recommendation for qtbase-qmlplugins
qtdeclarative: unsatisfied recommendation for qtdeclarative-plugins
qtdeclarative: unsatisfied recommendation for qtdeclarative-qmlplugins
qtlocation: unsatisfied recommendation for qtlocation-plugins
qtlocation: unsatisfied recommendation for qtlocation-qmlplugins
qtwebkit: unsatisfied recommendation for qtwebkit-plugins
Collected errors:
 * calculate_dependencies_for: Cannot satisfy the following dependencies for enigma2-plugin-extensions-qthbbtv:
 *      libqt5sensors5 (>= 5.8.0+git0+1220a31e6c) *     libqt5sensors5 (>= 5.8.0+git0+1220a31e6c) *
 * opkg_solver_install: Cannot install package enigma2-plugin-extensions-qthbbtv.

 

It was also mentioned in https://forums.openp...e-2#entry866267 but as this was a thread for another issue, I think it has been overlooked. So I'd thought to make a seperate notification for it.

Thank you for bringing this up again! It's been some time and qt plugins simply deny to work on 6.2 RC whereas they work perfect on 6.1! This completely breaks hbbtv on openatv for hd51.

When I install qtbase from the feed of 6.1 in 6.2rc, the qtstalker works just fine. So it's not like qt plugins simply deny to work on 6.2 RC. You only have to figure out yourself howto install it.

This is not an OpenATV forum. For support on OpenATV you should go to the OpenATV forum.

But I am using OpenPLi, and when I install the plugin from the feed I also get the message.

We don't provide this, zgemma does. So we can't maintain it (properly). 

It might be simply a missing dependency, what happens if you do "opkg install qtsensors" first?

I get below message

opkg install qtsensors
qtsensors: unsatisfied recommendation for qtsensors-plugins
qtsensors: unsatisfied recommendation for qtsensors-qmlplugins
Installing qtsensors (5.8.0+git0+1220a31e6c) on root.
Downloading http://downloads.ope...-neon-vfpv4.ipk.

and then still (also after a reboot)

opkg install enigma2-plugin-extensions-qthbbtv
qtbase: unsatisfied recommendation for qtbase-qmlplugins
qtdeclarative: unsatisfied recommendation for qtdeclarative-plugins
qtdeclarative: unsatisfied recommendation for qtdeclarative-qmlplugins
qtlocation: unsatisfied recommendation for qtlocation-plugins
qtlocation: unsatisfied recommendation for qtlocation-qmlplugins
qtwebkit: unsatisfied recommendation for qtwebkit-plugins
Collected errors:
 * calculate_dependencies_for: Cannot satisfy the following dependencies for enigma2-plugin-extensions-qthbbtv:
 *      libqt5sensors5 (>= 5.8.0+git0+1220a31e6c) *     libqt5sensors5 (>= 5.8.0+git0+1220a31e6c) *
 * opkg_solver_install: Cannot install package enigma2-plugin-extensions-qthbbtv.

And when I do opkg install qtsensors again it says below (so it is installed)
 

Package qtsensors (5.8.0+git0+1220a31e6c-r0.9) installed in root is up to date.

Hmm... the qtsensors package is being built, but it is empty, it contains no libs...

I'm afraid this is above my paygrade...

I may have an idea what could cause this, running a test build now. May take a few hours, my build server isn't the fastest.

As it seems to work on the 6.1 release could you tell me the download path of the ipk for 6.1 (so I can install this one and then try again)

I tried http://downloads.ope...-neon-vfpv4.ipk but that isn't it (probably /openpli-6.1/ is not correct but as all my receivers are running on 6.2 RC there is no easy way of tracking down the right url and I think you can tell me what /openpli-6.1/ should be so I don't have to flash 6.1 to find out).

*** Edit: I now see your reply, I'll wait then and test when it is finished. I already did a opkg remove qtsensors so I can just try to install qthbbtv from the feed and let you know if it works with installing it from the feed.

It's not that simple, 6.1-release doesn't have qtsensors, and that is because it uses an older version of qt5. So I've now downgraded qt5 in 6.2-rc to the level of 6.1-release.

My HD51 build just finish and it has all the missing files even libqt5sensors5.

I still use the original branch and not downgrade to version of Openpli 6.1

I assume the sync with feed cortexa15hf-neon-vfpv4 went wrong in Openpli 6.2

It can happen that a different BSP layer removes QT packages as they do not need it. (Like Dream they split some packages) then maybe the sensor is removed.

It should then add for specified machine which is easy done by add a file called qtsensors_git.bbappend in https://github.com/O.../recipes-qt/qt5 (I see however for this packages no reason why this should been done)

With just one line in the file: PACKAGE_ARCH := "${MACHINE_ARCH}"

No it's not that. The problem is subtle errors, race conditions, in the building process of qt as is provided by the BSP. When I start a complete build there are three possible outcomes:

- all the gfutures machines that use qthbbtv abort building because of errors (dependencies not met)

- all qthbbtv packages are built, but they're empty (like now)

- all qthbbtv packages are built, but they're ok

It seems like the developers are making too much assumptions about packages already being built and installed, which seems ok when you're building for one machine on a dual core processor, but if you're building for > 60 machines in 32 threads, this omission will show sooner or later.

For the develop environment we're moving to Rocko, which is even stricter than Pyro on this point (where Pyro already was a lot more strict, which we're using now for develop). I am foreseeing all hbbtv packages will break, so work for the manufacturers, to resolved these omissions.

I was having similar issues with qtstalker, so I changed the image build so that qtstalker is installed by default (with its dependencies) in the image and so far have not had an issue since...... but then unlike Erik, I am only  building for myself... so can take an aggressive solution.

No it's not that. The problem is subtle errors, race conditions, in the building process of qt as is provided by the BSP.

If that is the case, then I can stop my build. But I want to see what happens if I revert meta-qt5 back to 6.1-release level, which it should have stayed I think.

It still doesn't explain the missing dependency though, if qtsensors is required, then it should be installed with qtwebkit.

You probably mean no root files inside the packages?

This doesn't mean it's empty as it can have depends or recommends.

It's very strange as openpli build machine builds only qtsensors_5.8.0+git0+1220a31e6c-r0.9_cortexa15hf-neon-vfpv4.ipk
My build doesn't even make this file I get the follow files when build for HD51:

libqt5sensors5_5.8.0+git0+1220a31e6c-r0_cortexa15hf-neon-vfpv4.ipk

libqt5sensors-dbg_5.8.0+git0+1220a31e6c-r0_cortexa15hf-neon-vfpv4.ipk

libqt5sensors-dev_5.8.0+git0+1220a31e6c-r0_cortexa15hf-neon-vfpv4.ipk

libqt5sensors-mkspecs_5.8.0+git0+1220a31e6c-r0_cortexa15hf-neon-vfpv4.ipk

libqt5sensors-plugins_5.8.0+git0+1220a31e6c-r0_cortexa15hf-neon-vfpv4.ipk

libqt5sensors-qmlplugins_5.8.0+git0+1220a31e6c-r0_cortexa15hf-neon-vfpv4.ipk

I see in Openpli actually zero libqt5 packages build. So I assume you have from another BSP layer something which force not to build the QT libs.

Does Openpli build QT for Dreambox or any other box then HD51, H7, H9 and e4hd?
I am pretty sure a clean build from only HD51 you will get the qt5 libraries in map cortexa15hf_neon_vfvp4.

What branch are you building? And at what commit hash is the meta-qt5 submodule pinned?

Does Openpli build QT for Dreambox or any other box then HD51, H7, H9 and e4hd?

No, it's only build for the cortexa16 boxes, so these plus the VS1500, the GBQUAD4K and the GBUE4K. I assume these are the only ones that have qthbbtv in OPENPLI_FEATURES in their BSP.

I have build RC and develop branch

QT: c6aa602d0640040b470ee81de39726276ddc0ea3

Different is that I just build the qt plugins direct into the image, so I do not start feed build. Maybe with bitbake version his can have some side effects.

That may explain why you don't have this race condition. OE is littered with it, and as Erik mentioned, they only come to light on massive parallel builds. 

Common issue for example is recipes assume the rootfs is always present, which is not the case as it is by default cleaned after building, so if you run a build that does a feed update but doesn't require the image to be rebuild, there is no rootfs source available during that build run...