[meta-ti] State of dylan branch in meta-ti

[Volker Vogelhuber]

On 25.10.2013 13:27, Dmytriyenko, Denys wrote:
>> On 25.10.2013 13:11, Dmytriyenko, Denys wrote:
>>>> On 25.10.2013 12:58, Dmytriyenko, Denys wrote:
>>>>> On 25.10.2013 12:30, Denys Dmytriyenko wrote:
>>>>>>>> On Fri, Oct 25, 2013 at 12:12:35PM +0200, Volker Vogelhuber wrote:
>>>>>>>>> I just checked out the dylan branch of the yocto core and the
>>>>>>>>> meta-ti repository.
>>>>>>>>> It seems like the state of the meta-ti branch is not yet consistent
>>>>>>>>> to work out of the box.
>>>>>>>>>
>>>>>>>>> I currently had to remove the update-modules part from the ti
>>>>>>>>> recipes and had to add
>>>>>>>>> RPROVIDES_${PN} += "kernel-module-dsplinkk" to the ti-dsplink.inc
>>>>>>>>>
>>>>>>>>> Did I miss something or the dylan branch just not yet in a consistent state?
>>>>>>>> It's in great shape - better than ever! What you don't mention is what
>>>>>>>> platform you are using. You do mention dsplink though, but that is long since
>>>>>>>> unsupported. As a matter of fact, most of the old DSP related recipes are not
>>>>>>>> supported [1]. The new replacements are not ready yet. Other than that, it
>>>>>>>> provides great BSP support for platforms listed in the conf/ directory.
>>>>>>>>
>>>>>>>> [1]http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-ti/README?h=dylan
>>>>>>
>>>>>> Thanks for the link, actually I did not read that notice yet indeed.
>>>>>> I'm currently using a TAO-3530 board from technexion.
>>>>>> We used to work with the denzil branch for some time, but after 
>>>>>> updating to ubuntu
>>>>>> 13.10 there were a lot of errors that I tried to fix with the 
>>>>>> dylan branch. And indeed after
>>>>>> patching some small problems (next to the patches for the meta-ti 
>>>>>> branch), it does create
>>>>>> a rootfs image at least, but have to flash it and test if it has 
>>>>>> some additional problems.
>>>>>>
>>>>>> I only wonder why the problem with the kernel-module- package 
>>>>>> name does only occure with the
>>>>>> dsplink and not with the e.g. libgles modules as they seem to 
>>>>>> provide wrong package names as well.
>>>>>
>>>>>
>>>>> What do you mean by the wrong package name?
>>>> In the hello-mod_0.1bb script under meta-skeleton within the dylan 
>>>> branch of the yocto repository
>>>> there is the following notice:
>>>>
>>>> # Kernel module packages MUST begin with 'kernel-module-', otherwise
>>>> # multilib image generation can fail.
>>>> #
>>>> # The following line is only necessary if the recipe name does not 
>>>> begin
>>>> # with kernel-module-.
>>>> #
>>>> PKG_${PN} = "kernel-module-${PN}"
>>>>
>>>> I guess because there is a new bbclass within dylan called 
>>>> kernel-module-split.bbclass
>>>> that has the following lines adding dependencies automatically.
>>>>
>>>> ...
>>>>     if modules:
>>>>         metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE', True)
>>>>         d.appendVar('RDEPENDS_' + metapkg, ' '+' '.join(modules))
>>>>
>>>> the do_split_packages method called before that code gets executed 
>>>> seems to automatcally create
>>>> a list with kernel modules that all start with kernel-module-%s. I 
>>>> did not check what modules this method recognized. Maybe 
>>>> dsplinkk.ko was the only one and that's why the other modules did not
>>>> cause an error. Actually I did not spent to much time digging into 
>>>> the reason for introducing this bbclass at all.
>>>>
>>>> So to answer your question, all the module recipes within the 
>>>> meta-ti repository don't seem to be named with a "kernel-module-" 
>>>> prefix, but only the dsplinkk.ko module result in an error.
>>>>
>>> Because they don't have to be called that. The only extra thing the 
>>> new class does is sets up the dependencies. So even when a custom 
>>> module name is used, it will work fine.
>>
>> Well then I don't understand why compiling the dsplink module causes 
>> an error during creation of the
>> RootFS when not adding the RPROVIDES_${PN} += 
>> "kernel-module-dsplinkk" to ti-dsplink.inc
>>
>> Error log follows:
>>
>>  Some packages could not be installed. This may mean that you have
>> | requested an impossible situation or if you are using the unstable
>> | distribution that some required packages have not yet been created
>> | or been moved out of Incoming.
>> | The following information may help to resolve the situation:
>> |
>> | The following packages have unmet dependencies:
>> |  ti-dsplink : Depends: kernel-module-dsplinkk but it is not installable
>> | E: Unable to correct problems, you have held broken packages.
>>
>> Or is that error by design to avoid people using the dsplink module 
>> within dylan?
>> As mentioned, I did not test the resulting firmware image yet, so 
>> maybe there is indeed a problem with the modules, although I can't 
>> imagine why it shouldn't work as the used kernel is still the same.
>>
> FILES_ti-dsplink-module is causing the problem...

Removing this line (as it seems to be done in 
http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/recipes-bsp/ti-ocf-crypto-module/ti-ocf-crypto-module_1.0.bb?id=f3c7afb5a3f762894fb0476081d862cb3d54e2dd) 
results in the following error message:

Package ti-dsplink-module is not available, but is referred to by 
another package.
| This may mean that the package is missing, has been obsoleted, or
| is only available from another source
|
| E: Package 'ti-dsplink-module' has no installation candidate


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-ti/attachments/20131025/5a56d485/attachment.html>