Re: [yocto] QA cycle report for 2.3.3 RC1
On 12/21/2017 08:43 AM, Richard Purdie wrote: On Wed, 2017-12-20 at 20:25 -0800, Cruz, Libertad wrote: Hello All, Enjoy viewing the full Report for 2.3.3 RC1: https://wiki.yoctoproje ct.org/wiki/WW51_-_2017-12-20-_Full_Test_Cycle_-_2.3.3_rc1 === Summary The QA cycle for release 2.3.3 RC1 is complete. There are 4 new bugs from which so far none of them are high. QA has two big concerns: 1. Performance report shows an increase of 30% build time on the eSDK in fedora 23, bug has not been created until further investigation with setup outside of the GDC environment. Could you confirm when the performance test machines were last rebooted? We've had issues before where the benchmarks drift with machine uptime. If the've been running for more than about 3 weeks I'd like to run the benchmarks again after a reboot. It was last week 12/12 -$ who -b system boot 2017-12-12 09:18 -$ uptime -s 2017-12-12 09:19:28 Thanks! Richard -- Saludos José -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] QA cycle report for 2.4.1 RC1
Hello All, Enjoy viewing the full Report for 2.4.1 RC1: https://wiki.yoctoproject.org/wiki/WW51_-_2017-12-21-_Full_Test_Cycle_-_2.4.1_rc1 === Summary The QA cycle for release 2.4.1 RC1 is complete. There are 5 new bugs from which so far none of them are high. QA has 1 concern on the performance testing. Performance report shows an increase of 23% build time on the eSDK in fedora 23, bug has not been created until further investigation with setup outside of the GDC environment. https://wiki.yoctoproject.org/wiki/WW51_-_2017-12-21-_Full_Test_Cycle_-_2.4.1_rc1#Build_Performance_Test === QA-Hints The build is stable enough to be released, provided the performance issue is investigated and root-cause identified. === Bugs New Bugs -12444 [1] [Test Case 1542] test_2_logrotate fails in MinnowMax with core-image-lsb-sdk-genericx86-64 image -12417 [2] Eclipse installer steps only apply to latest Eclipse release -12416 [3] autobuilder.yocto.io directory index does not display the full long filename -12443 [4] [Test Case 312,313] Bitbake failed after using yocto-kernel add patch -12445 [5] [Test Case 309,310,311] Bitbake fails after add layer with yocto-bsp create Full Bug Report: https://wiki.yoctoproject.org/wiki/WW51_-_2017-12-21-_Full_Test_Cycle_-_2.4.1_rc1#Bugs_Found_during_QA_Test Links = 1. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12444 [1] 2. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12417 [2] 3. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12416 [3] 4. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12443 [4] 5. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12445 [5] Regards Ee Peng -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] how to deal with the dependency explosion caused by enabling x11vnc
On 22 December 2017 at 02:53, Davis Roman wrote: > > Hello, > > I'd like to put a vnc server on my target. > > My embedded target has an onboard display and runs an application that > drives the display directly via the framebuffer. ( no xorg onboard ) > > I would like to use x11vnc ( with the --rawfb option ) however I'm > having a hard time justifying the load of dependencies that it brings > along with it. (Almost 100MB.) > > With the --rawfb option, x11vnc does not require a X server ( just > libX11) to be onboard however I'm required to add x11 to > DISTRO_FEATURES otherwise x11vnc won't compile. > > (x11vnc even drags gtk3 along with it which seems unnecessary.) > > My goal is to only add the minimum number of x11vnc depencies. > > Any advice on how to slim this down would be appreciated. >From glancing at https://github.com/LibVNC/x11vnc/blob/master/configure.ac it appears that you can tell it to build without X: If you want to build x11vnc without X support (e.g. for -rawfb use only > or for native Mac OS X), specify the --without-x configure option. I'd use PACKAGECONFIG to respect the x11 DISTRO_FEATURE and enable/disable building with X. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] linux kernel rt
Hi Andreas, On Thu, Dec 21, 2017 at 8:59 PM, Andreas Müller wrote: > On Thu, Dec 21, 2017 at 5:08 PM, Andrei Gherzan wrote: > >> Hi all, >> >> On Thu, Dec 14, 2017 at 12:09 PM, Andreas Müller > > wrote: >> >>> On Thu, Dec 14, 2017 at 11:40 AM, Mirza Krak >>> wrote: >>> 2017-12-14 9:41 GMT+01:00 Andreas Müller : > On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran < sherifomran2...@gmail.com> > wrote: >> >> hey guys, >> >> any body tried the real time kernel? I get an error, it is snot in the >> compatibility list. >> can we skip it? >> >> thanks >> >> -- > > Good news: I use RT kernel only together with VC4 graphics and have lots of > fun on PI2/3. > Bad news: As far as I know it is not in meta-raspberrypi but in my fork [1]. > There were attempts to land the RT-patches in meta-raspberrypi but that was > denied for huge patch size :( If the patch size was the only problem one can pull it by doing the following in the recipe: SRC_URI += " \ https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.9/patc h-4.9.65-rt56.patch.gz;name=rt-patch \ " SRC_URI[rt-patch.md5sum] = "9caa7b541d8c84c2d5c5f58985982e95" SRC_URI[rt-patch.sha256sum] = "47dfb518c78d8cbaafd4ab9130eb26fe0170be9189b580ab26209ef679309539" Note that above sums are "random" and not the for the actually file but are there for reference. That way you do not need to keep a copy of it in meta-raspberrypi. -- >>> Hi Mirza, >>> >>> Problem is that patches need alignments sometimes either caused by >>> Raspberry-Pi-specific adjustments or versions not matching exactly - RT >>> kernel patch updates are less frequent than kernel updates. Anyway: git is >>> very good at maintaining huge text content and this should not be a problem >>> these days. Another discussion about RT kernel was to have an extra kernel >>> for it and I never understood why. To me that seems nothing but an extra >>> maintenance burden. >>> >>> However - just wrote to Paul: I plan to be at FOSDEM and we can discuss >>> there how to get back to one layer only (not mine!) making everybody happy >>> :) >>> >>> >> I remember the discussion. Indeed that was the reason and the >> recommendation was to maintain a separate linux-raspberry fork where >> whoever has interest in this will maintain on top of linux-raspberrypi this >> patch. Obviously that didn't happen but I'd like to see it landing. >> >> Yes that was one of the suggestions which made me say 'Thanks - this is > just additional maintenance burden and will not work for long time - I do > my own'. FWIW: That suggestion came at a time when you (Andrei) seemed > overworked totally (just to mention - PLEASE don't take it as criticism - I > know what I am talking of when it comes to 'overworked'). > You will be suprised but all of us are busy and this is a side project handled as good possible in our spare time. I do agree that there was a time where this project was a little demoted in priority. But even if that is the case, contributions are always welcomed - as you know. > > Why not simply one stable kernel with RT-patches applied if user decides > by an option? That is what I am doing for >1 year now and meta-raspi-light > is the one which caused me least efforts/headaches of all. And yes I know I > made life easy here by removing userland completely and taking care for > RPi2/3 only. > > I will always advocate against forks but definitely that is an option too. What I want to understand is why maintaining it in meta-raspberrypi was painful. Basically, the question is how do you currently maintain, rebase etc the rt patch? I would expect it to happen in a git tree as well. Isn't that the case? -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] linux kernel rt
On Fri, Dec 22, 2017 at 2:25 PM, Andrei Gherzan wrote: > Hi Andreas, > > On Thu, Dec 21, 2017 at 8:59 PM, Andreas Müller > wrote: > >> On Thu, Dec 21, 2017 at 5:08 PM, Andrei Gherzan >> wrote: >> >>> Hi all, >>> >>> On Thu, Dec 14, 2017 at 12:09 PM, Andreas Müller < >>> schnitzelt...@gmail.com> wrote: >>> On Thu, Dec 14, 2017 at 11:40 AM, Mirza Krak wrote: > 2017-12-14 9:41 GMT+01:00 Andreas Müller : > > On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran < > sherifomran2...@gmail.com> > > wrote: > >> > >> hey guys, > >> > >> any body tried the real time kernel? I get an error, it is snot in > the > >> compatibility list. > >> can we skip it? > >> > >> thanks > >> > >> -- > > > > Good news: I use RT kernel only together with VC4 graphics and have > lots of > > fun on PI2/3. > > Bad news: As far as I know it is not in meta-raspberrypi but in my > fork [1]. > > There were attempts to land the RT-patches in meta-raspberrypi but > that was > > denied for huge patch size :( > > If the patch size was the only problem one can pull it by doing the > following in the recipe: > > SRC_URI += " \ > https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.9/patc > h-4.9.65-rt56.patch.gz;name=rt-patch > \ > " > > SRC_URI[rt-patch.md5sum] = "9caa7b541d8c84c2d5c5f58985982e95" > SRC_URI[rt-patch.sha256sum] = > "47dfb518c78d8cbaafd4ab9130eb26fe0170be9189b580ab26209ef679309539" > > Note that above sums are "random" and not the for the actually file > but are there for reference. > > That way you do not need to keep a copy of it in meta-raspberrypi. > > -- > Hi Mirza, Problem is that patches need alignments sometimes either caused by Raspberry-Pi-specific adjustments or versions not matching exactly - RT kernel patch updates are less frequent than kernel updates. Anyway: git is very good at maintaining huge text content and this should not be a problem these days. Another discussion about RT kernel was to have an extra kernel for it and I never understood why. To me that seems nothing but an extra maintenance burden. However - just wrote to Paul: I plan to be at FOSDEM and we can discuss there how to get back to one layer only (not mine!) making everybody happy :) >>> I remember the discussion. Indeed that was the reason and the >>> recommendation was to maintain a separate linux-raspberry fork where >>> whoever has interest in this will maintain on top of linux-raspberrypi this >>> patch. Obviously that didn't happen but I'd like to see it landing. >>> >>> Yes that was one of the suggestions which made me say 'Thanks - this is >> just additional maintenance burden and will not work for long time - I do >> my own'. FWIW: That suggestion came at a time when you (Andrei) seemed >> overworked totally (just to mention - PLEASE don't take it as criticism - I >> know what I am talking of when it comes to 'overworked'). >> > > You will be suprised but all of us are busy and this is a side project > handled as good possible in our spare time. I do agree that there was a > time where this project was a little demoted in priority. But even if that > is the case, contributions are always welcomed - as you know. > > >> >> Why not simply one stable kernel with RT-patches applied if user decides >> by an option? That is what I am doing for >1 year now and meta-raspi-light >> is the one which caused me least efforts/headaches of all. And yes I know I >> made life easy here by removing userland completely and taking care for >> RPi2/3 only. >> >> > I will always advocate against forks but definitely that is an option too. > What I want to understand is why maintaining it in meta-raspberrypi was > painful. Basically, the question is how do you currently maintain, rebase > etc the rt patch? I would expect it to happen in a git tree as well. Isn't > that the case? > > I maintained it this way: * Set new kernel version * Check if there is an update at RT-Kernel. If so update the patch. * Rebuild the kernel. In case a patch does not apply cleanly, I use git inside of oe work-shared folder, check/align for hunks failing and insert them manually into original patch. From my experience there are usually very few hunks to touch so this is no rocket science. What do you think? Some advertisement :) I would stand up to take care for RT and VC4 in the future. This is what I need to build heavy heavy world builds with EGL/GLES and able to mix/produce music.. Andreas -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to config kernel in my own meta layer?
On Thu, Dec 21, 2017 at 11:32 AM, Fan Zhang wrote:
> Greetings,
>
> I have a recipes that requires 128MB of CMA allocation for DMA. I followed
> the instruction in
> http://www.yoctoproject.org/docs/1.6/kernel-dev/kernel-dev.html#changing-the-configuration
> and did the following:
>
> My recipes structure:
>
> meta-mylayer\recipes-my\uio-test\
>
> 1. Then in uio-test folder, I have uio-test.bb that created by recipetool
> (in general) with some modification. uio-test.bb looks like this:
>
> #--
>
> # Recipe created by recipetool
> # This is the basis of a recipe and may need further editing in order to be
> fully functional.
> # (Feel free to remove these comments when editing.)
>
> # Unable to find any files that looked like license statements. Check the
> accompanying
> # documentation and source headers and set LICENSE and LIC_FILES_CHKSUM
> accordingly.
> #
> # NOTE: LICENSE is being set to "CLOSED" to allow you to at least start
> building - if
> # this is not accurate with respect to the licensing of the software being
> built (it
> # will not be in most cases) you must specify the correct value before using
> this
> # recipe for anything other than initial testing/development!
> LICENSE = "CLOSED"
> LIC_FILES_CHKSUM = ""
>
> # No information for SRC_URI yet (only an external source tree was
> specified)
> PV = "2.0.2"
> SRC_URI = "file://src"
>
> # NOTE: this is a Makefile-only piece of software, so we cannot generate
> much of the
> # recipe automatically - you will need to examine the Makefile yourself and
> ensure
> # that the appropriate arguments are passed in.
>
> do_configure () {
> # Specify any needed configure commands here
> :
> }
>
> do_compile () {
> # You will almost certainly need to add additional arguments here
> cd ${WORKDIR}/src
> oe_runmake
> }
>
> FILES_${PN} = "/www/pages /etc/lighttpd.d"
> do_install () {
> # This is a guess; additional arguments may be required
> cd ${WORKDIR}/src
> oe_runmake install 'DESTDIR=${D}'
> }
>
> DEPENDS = "libgcc boost"
> RDEPENDS_${PN} = "libgcc boost-thread boost-system lighttpd
> lighttpd-module-cgi"
> #--
>
> 2. Also in uio-test folder, I have uio-test.bbappend file with these
> contents:
>
> #--
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> SRC_URI += "file://uio-test.cfg"
>
> #--^^^-
>
> 3. In uio-test/files folder, I have uio-test.cfg with the following
> contents:
>
>
> #--
>
> CONFIG_CMA_ALIGNMENT=8
> CONFIG_CMA=y
> CONFIG_CMA_AREAS=7
> CONFIG_DMA_CMA=y
> CONFIG_CMA_SIZE_MBYTES=128
> CONFIG_CMA_SIZE_SEL_MBYTES=y
> CONFIG_DMADEVICES=y
> CONFIG_DMA_ENGINE=y
> CONFIG_DMA_OF=y
> CONFIG_XILINX_DMA_ENGINES=y
> CONFIG_XILINX_DMA=y
> CONFIG_DMA_API_DEBUG=y
> CONFIG_HAS_DMA=y
> CONFIG_NEED_DMA_MAP_STATE=y
> CONFIG_HAVE_DMA_CONTIGUOUS=y
> CONFIG_HAVE_DMA_API_DEBUG=y
> CONFIG_HAVE_GENERIC_DMA_COHERENT=y
> CONFIG_ARM_DMA_MEM_BUFFERABLE=y
> CONFIG_ZONE_DMA_FLAG=0
> #--^^^-
>
> My question: I think the cfg file is being parsed because if I change the
> folder name files to something else, bitbake will complaint about not being
> able to find uio-test.cfg. However, the final .config in built do not have
> the CMA allocated. My meta layer does have a priority higher than the
> upstream layers. What else can cause the problem here? Any suggestions?
> Thanks.
The question is ... which kernel is it ? If the kernel recipe you are
using doesn't
inherit linux-yocto, the fragments won't be applied.
And a second question, what release/branch are you using ?
On that note, I actually have a patch completed to move the core of the fragment
support to kernel.bbclass, so any kernel could use it. So if you
aren't linux-yocto
and would like to test a patch, I could send it along.
Bruce
>
> Fan Zhang
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Python cryptography failing due to undefined symbol: pthread_atfork
I have confirmed that no `-pthread` flags are being set for building python-cryptography. Running the following: bitbake python-cryptography -c do_compile bitbake python-cryptography -c devshell grep pthread ../temp/run.do_compile gives no returns. Also there isn't a mention of it when doing a build in full verbose: bitbake python-cryptography -c cleanall bitbake python-cryptography -vvv | vi - On the target the symbol is identified as missing (NOTYPE): ~# readelf -a /usr/lib/python3.5/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so | grep pthread_atfork 000aebb4 0002d916 R_ARM_JUMP_SLOT pthread_atfork 729: 0 NOTYPE GLOBAL DEFAULT UND pthread_atfork My current goal is to extend the recipe with the `-pthread` so that it's there when the '_openssl' extension is being built. Still open to suggestions. A thing that seems to be underlying my assumption is that the recipe for python-cryptography hasn't actually changed between Morty (where it worked) and Rocko... On Thu, Dec 21, 2017 at 6:17 PM, Alan Martinovic wrote: > Hi there, > just did a migration to Rocko and am witnessing" > > root@device:~# python3 > Python 3.5.3 (default, Dec 20 2017, 02:02:22) > [GCC 7.2.0] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> from cryptography.hazmat.bindings._openssl import ffi, lib > Traceback (most recent call last): > File "", line 1, in > ImportError: > /usr/lib/python3.5/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so: > undefined symbol: pthread_atfork > > > Have tried both the recipe that comes with Rocko > and master of meta-openembedded. > > Seems to be the same bug as this one: > > https://bugs.gentoo.org/630578 > > resolved with this patch: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c824d1c44fcf4556de21d2c8b8ae3732b0fc0c5b > > Can someone provide hints on what would that translate to > for the python cryptography recipe? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] linux kernel rt
On Fri, Dec 22, 2017 at 2:17 PM, Andreas Müller wrote: > On Fri, Dec 22, 2017 at 2:25 PM, Andrei Gherzan wrote: >> >> Hi Andreas, >> >> On Thu, Dec 21, 2017 at 8:59 PM, Andreas Müller >> wrote: >>> >>> >>> Why not simply one stable kernel with RT-patches applied if user decides >>> by an option? That is what I am doing for >1 year now and meta-raspi-light >>> is the one which caused me least efforts/headaches of all. And yes I know I >>> made life easy here by removing userland completely and taking care for >>> RPi2/3 only. >>> >> >> I will always advocate against forks but definitely that is an option too. >> What I want to understand is why maintaining it in meta-raspberrypi was >> painful. Basically, the question is how do you currently maintain, rebase >> etc the rt patch? I would expect it to happen in a git tree as well. Isn't >> that the case? >> > I maintained it this way: > > * Set new kernel version > * Check if there is an update at RT-Kernel. If so update the patch. > * Rebuild the kernel. In case a patch does not apply cleanly, I use git > inside of oe work-shared folder, check/align for hunks failing and insert > them manually into original patch. From my experience there are usually very > few hunks to touch so this is no rocket science. > > What do you think? > So, my thinking was that if you're going through the effort of getting the -rt patches to apply to the rpi kernel, I'd like to see that available to non-OpenEmbedded users. I think a linux-raspberrypi-rt kernel tree would be a useful think to make available as a standalone project, which we can then pull into meta-raspberrypi as a simple recipe. My complaint with having the entire -rt patch in the meta-raspberrypi repo was that it's a huge, un-reviewable blob. Multi-thousand line patches are now less painful with review happening on GitHub now though - they at least don't upset my email workflow anymore :) Could you try handling this in git by merging the -rt kernel branch (https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git/log/?h=v4.9-rt) into the linux-raspberrypi branch regularly instead of by applying the -rt patch manually? Any merge conflicts could be handled cleanly that way and it would give us something we could bisect properly in case of any bugs. The resulting git repository could be published online as something like 'linux-raspberrypi-rt' if this works. This is basically my opinion though, there is no one true Right Way (TM) to do this. If you decide it's still easier for you to handle this as a patch in the meta-raspberrypi layer then I'm happy to support that. -- Paul Barker Togán Labs Ltd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Kernel configuration problem/confusion
I'm trying to add some kernel configuration to a Raspberry pi3 yocto build. I've got the .cfg fragment being read in, but I'm getting warnings that indicate that they are not making the desired changes. The first one is CONFIG_SND_SOC_MAX9768. This is a sound codec and the Kconfig file has it in a long list of select's. the one for the MAX9768 is: select CONFIG_SND_SOC_MAX9768 if I2C I2C is set, but CONFIG_SND_SOC_MAX9768 ends up undefined. the warning I'm getting is: -- CONFIG_SND_SOC_MAX9768 - Config: CONFIG_SND_SOC_MAX9768 From: /home/gwilson/Qt-5.9/Yocto-build-RPi3/build-raspberrypi3/tmp/work-shared/raspberrypi3/kernel-source/.kernel-meta/configs/Scribe.cfg Requested value: CONFIG_SND_SOC_MAX9768=y Actual value: Config 'SND_SOC_MAX9768' has the following conditionals: Dependency values are: SND_SOC_MAX9768 ends up not being selected even though I try to set it ti 'y' The second one is CONFIG_MAX1363, this is an ADC that I'm trying to set, the warning is: -- CONFIG_MAX1363 - Config: CONFIG_MAX1363 From: /home/gwilson/Qt-5.9/Yocto-build-RPi3/build-raspberrypi3/tmp/work-shared/raspberrypi3/kernel-source/.kernel-meta/configs/Scribe.cfg Requested value: CONFIG_MAX1363=y Actual value: # CONFIG_MAX1363 is not set Config 'MAX1363' has the following conditionals: I2C (value: "y") Dependency values are: I2C [y] It ends up being not set. In both cases the value that I'm trying to set is ignored. Any insight would be greatly appreciated. Regards, Greg -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel configuration problem/confusion
On 12/22/2017 3:51 PM, Greg Wilson-Lindberg wrote: I'm trying to add some kernel configuration to a Raspberry pi3 yocto build. I've got the .cfg fragment being read in, but I'm getting warnings that indicate that they are not making the desired changes. The first one is CONFIG_SND_SOC_MAX9768. This is a sound codec and the Kconfig file has it in a long list of select's. the one for the MAX9768 is: select CONFIG_SND_SOC_MAX9768 if I2C I2C is set, but CONFIG_SND_SOC_MAX9768 ends up undefined. the warning I'm getting is: -- CONFIG_SND_SOC_MAX9768 - Config: CONFIG_SND_SOC_MAX9768 From: /home/gwilson/Qt-5.9/Yocto-build-RPi3/build-raspberrypi3/tmp/work-shared/raspberrypi3/kernel-source/.kernel-meta/configs/Scribe.cfg Requested value: CONFIG_SND_SOC_MAX9768=y Actual value: Config 'SND_SOC_MAX9768' has the following conditionals: Dependency values are: SND_SOC_MAX9768 ends up not being selected even though I try to set it ti 'y' The second one is CONFIG_MAX1363, this is an ADC that I'm trying to set, the warning is: -- CONFIG_MAX1363 - Config: CONFIG_MAX1363 From: /home/gwilson/Qt-5.9/Yocto-build-RPi3/build-raspberrypi3/tmp/work-shared/raspberrypi3/kernel-source/.kernel-meta/configs/Scribe.cfg Requested value: CONFIG_MAX1363=y Actual value: # CONFIG_MAX1363 is not set Config 'MAX1363' has the following conditionals: I2C (value: "y") Dependency values are: I2C [y] It ends up being not set. In both cases the value that I'm trying to set is ignored. Any insight would be greatly appreciated. The python library that tries to detangle the Kconfig dependencies isn't perfect (but I do have an update for it pending), so you might not be getting the entire story in that information dumb. Two things to check: - there are no other fragments that are disabling the same option - use menuconfig in the kernel to search the option and see what it reports for the dependencies. There's some constraint or overriding command that is not allowing the option into the final config, we just need to track it down. Bruce Regards, Greg -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel configuration problem/confusion
Hi Bruce, First, thanks for the unbelievably quick response. I searched the Yocto sources and didn't find anything that was trying to manipulate either of the variables except my .cfg. The memuconfig search for MAX9768 results in: Symbol: SND_SOC_MAX9768 [=n] Type : tristate Defined at sound/soc/codecs/Kconfig:917 Depends on: SOUND [=y] && !M68K && !UML && SND [=m] && SND_SOC [=m] Selected by: SND_SOC_ALL_CODECS [=n] && SOUND [=y] && !M68K && !UML && SND [=m] && SND_SOC [=m] && COMPILE_TEST [=n] && I2C [=y] To my (untrained) eye it seems that I need SND_SOC_ALL_CODECS & COMPILE_TEST. I tried setting them but I get a similar error for COMPILE_TEST. A search for it yields: Symbol: COMPILE_TEST [=n] Type : boolean Prompt: Compile also drivers which will not load Location: (1) -> General setup Defined at init/Kconfig:56 Which doesn't seem to suggest that there should be any problems setting it. The search for MAX1363 yields: Symbol: MAX1363 [=n] Type : tristate Prompt: Maxim max1363 ADC driver Location: -> Device Drivers -> Industrial I/O support (IIO [=m]) (1) -> Analog to digital converters Defined at drivers/iio/adc/Kconfig:218 Depends on: IIO [=m] && I2C [=y] Selects: IIO_BUFFER [=y] && IIO_TRIGGERED_BUFFER [=n] Which doesn't seem to me reveal any reason that I shouldn't be able to set it. Regards, Greg From: Bruce Ashfield Sent: Friday, December 22, 2017 12:27:22 PM To: Greg Wilson-Lindberg; yocto@yoctoproject.org Subject: Re: [yocto] Kernel configuration problem/confusion On 12/22/2017 3:51 PM, Greg Wilson-Lindberg wrote: > I'm trying to add some kernel configuration to a Raspberry pi3 yocto > build. I've got the .cfg fragment being read in, but I'm getting > warnings that indicate that they are not making the desired changes. > > > The first one is CONFIG_SND_SOC_MAX9768. This is a sound codec and the > Kconfig file has it in a long list of select's. the one for the MAX9768 is: > > select CONFIG_SND_SOC_MAX9768 if I2C > > I2C is set, but CONFIG_SND_SOC_MAX9768 ends up undefined. the warning > I'm getting is: > > -- CONFIG_SND_SOC_MAX9768 - > Config: CONFIG_SND_SOC_MAX9768 > From: > /home/gwilson/Qt-5.9/Yocto-build-RPi3/build-raspberrypi3/tmp/work-shared/raspberrypi3/kernel-source/.kernel-meta/configs/Scribe.cfg > Requested value: CONFIG_SND_SOC_MAX9768=y > Actual value: > > Config 'SND_SOC_MAX9768' has the following conditionals: > Dependency values are: > > SND_SOC_MAX9768 ends up not being selected even though I try to set it > ti 'y' > > > The second one is CONFIG_MAX1363, this is an ADC that I'm trying to set, > the warning is: > > -- CONFIG_MAX1363 - > Config: CONFIG_MAX1363 > From: > /home/gwilson/Qt-5.9/Yocto-build-RPi3/build-raspberrypi3/tmp/work-shared/raspberrypi3/kernel-source/.kernel-meta/configs/Scribe.cfg > Requested value: CONFIG_MAX1363=y > Actual value: # CONFIG_MAX1363 is not set > > Config 'MAX1363' has the following conditionals: >I2C (value: "y") > Dependency values are: >I2C [y] > > It ends up being not set. In both cases the value that I'm trying to set > is ignored. Any insight would be greatly appreciated. The python library that tries to detangle the Kconfig dependencies isn't perfect (but I do have an update for it pending), so you might not be getting the entire story in that information dumb. Two things to check: - there are no other fragments that are disabling the same option - use menuconfig in the kernel to search the option and see what it reports for the dependencies. There's some constraint or overriding command that is not allowing the option into the final config, we just need to track it down. Bruce > > > Regards, > > Greg > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] linux kernel rt
On Fri, Dec 22, 2017 at 7:57 PM, Paul Barker wrote: > On Fri, Dec 22, 2017 at 2:17 PM, Andreas Müller > wrote: > > On Fri, Dec 22, 2017 at 2:25 PM, Andrei Gherzan > wrote: > >> > >> Hi Andreas, > >> > >> On Thu, Dec 21, 2017 at 8:59 PM, Andreas Müller < > schnitzelt...@gmail.com> > >> wrote: > >>> > >>> > >>> Why not simply one stable kernel with RT-patches applied if user > decides > >>> by an option? That is what I am doing for >1 year now and > meta-raspi-light > >>> is the one which caused me least efforts/headaches of all. And yes I > know I > >>> made life easy here by removing userland completely and taking care for > >>> RPi2/3 only. > >>> > >> > >> I will always advocate against forks but definitely that is an option > too. > >> What I want to understand is why maintaining it in meta-raspberrypi was > >> painful. Basically, the question is how do you currently maintain, > rebase > >> etc the rt patch? I would expect it to happen in a git tree as well. > Isn't > >> that the case? > >> > > I maintained it this way: > > > > * Set new kernel version > > * Check if there is an update at RT-Kernel. If so update the patch. > > * Rebuild the kernel. In case a patch does not apply cleanly, I use git > > inside of oe work-shared folder, check/align for hunks failing and insert > > them manually into original patch. From my experience there are usually > very > > few hunks to touch so this is no rocket science. > > > > What do you think? > > > > So, my thinking was that if you're going through the effort of getting > the -rt patches to apply to the rpi kernel, I'd like to see that > available to non-OpenEmbedded users. I think a linux-raspberrypi-rt > kernel tree would be a useful think to make available as a standalone > project, which we can then pull into meta-raspberrypi as a simple > recipe. > > My complaint with having the entire -rt patch in the meta-raspberrypi > repo was that it's a huge, un-reviewable blob. Multi-thousand line > patches are now less painful with review happening on GitHub now > though - they at least don't upset my email workflow anymore :) > > Could you try handling this in git by merging the -rt kernel branch > (https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-st > able-rt.git/log/?h=v4.9-rt) > into the linux-raspberrypi branch regularly instead of by applying the > -rt patch manually? Any merge conflicts could be handled cleanly that > way and it would give us something we could bisect properly in case of > any bugs. The resulting git repository could be published online as > something like 'linux-raspberrypi-rt' if this works. > > This is basically my opinion though, there is no one true Right Way > (TM) to do this. If you decide it's still easier for you to handle > this as a patch in the meta-raspberrypi layer then I'm happy to > support that. > > Good suggestion - but: 1. you overestimate the RT-patching process / errors caused by RT 2. I would like to keep RT and non-RT kernel versions in sync 3. I see more efforts which don't buy me anything personally My dislike (3.) might be increased by the fact that I * (try to) maintain >400 recipes and contribute to others more or less for 'fun' and due to that I am not keen on some extra duty * am an old man afraid of changing bad habits :) However: there is no time pressure on this matter and I am looking forward to discuss this with you (and others) at FOSDEM. I am sure we'll find a solution/compromise there. Andreas -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [eclipse-poky][neon][PATCH] Update setup.sh to Neon.3 (4.6.3) release
org.eclipse.tm.terminal* are now available on MAIN_SITE
Signed-off-by: Tim Orling
---
scripts/setup.sh | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/scripts/setup.sh b/scripts/setup.sh
index 0764021b66c..4f7dc2b0a78 100755
--- a/scripts/setup.sh
+++ b/scripts/setup.sh
@@ -23,7 +23,7 @@ while getopts ":h" opt; do
esac
done
-err_exit()
+err_exit()
{
echo "[FAILED $1]$2"
exit $1
@@ -35,7 +35,7 @@ case ${uname_s}${uname_m} in
Linuxppc*) ep_arch=linux-gtk-ppc
cdt_arch=linux.ppc
;;
- Linuxx86_64*) ep_arch=linux-gtk-x86_64
+ Linuxx86_64*) ep_arch=linux-gtk-x86_64
cdt_arch=linux.x86_64
;;
Linuxi*86) ep_arch=linux-gtk
@@ -92,12 +92,12 @@ fi
# prepare the base Eclipse installation in folder "eclipse"
ep_rel="R-"
-ep_ver="4.6.2"
-ep_date="-201611241400"
+ep_ver="4.6.3"
+ep_date="-201703010400"
P2_disabled=false
P2_no_dropins=false
-if [ ! -f eclipse/plugins/org.eclipse.swt_3.105.2.v20161122-0613.jar ]; then
+if [ ! -f eclipse/plugins/org.eclipse.swt_3.105.3.v20170228-0512.jar ]; then
pushd .
@@ -130,7 +130,7 @@ if [ ! -f
eclipse/plugins/org.eclipse.swt_3.105.2.v20161122-0613.jar ]; then
popd
if [ ! -d eclipse -o -h eclipse ]; then
-if [ -e eclipse ]; then
+if [ -e eclipse ]; then
rm eclipse
fi
ln -s eclipse-${ep_ver}-${ep_arch}/eclipse eclipse
@@ -150,7 +150,7 @@ if [ ! -f eclipse/startup.jar ]; then
LAUNCHER="`ls org.eclipse.equinox.launcher_*.jar | sort | tail -1`"
if [ "x${LAUNCHER}" != "x" ]; then
-echo "eclipse LAUNCHER=${LAUNCHER}"
+echo "eclipse LAUNCHER=${LAUNCHER}"
ln -s plugins/${LAUNCHER} ../startup.jar
else
echo "Eclipse: NO startup.jar LAUNCHER FOUND!"
@@ -261,24 +261,24 @@
UPDATE_SITE="http://download.eclipse.org/eclipse/updates/4.6";
#CDT related
echo -e "\nPlease wait. Installing CDT.SDK.FEATURE.GROUP"
-CDTFEAT="9.2.0"
+CDTFEAT="9.2.1"
update_feature_remote ${MAIN_SITE} org.eclipse.cdt.sdk.feature.group ${CDTFEAT}
echo -e "\nPlease wait. Installing CDT.LAUNCH.REMOTE.FEATURE.GROUP"
-CDTREMOTEVER="9.2.0"
+CDTREMOTEVER="9.2.1"
update_feature_remote ${MAIN_SITE} org.eclipse.cdt.launch.remote.feature.group
${CDTREMOTEVER}
#TM Terminal (was RSE) related
echo -e "\nPlease wait. Installing TM.TERMINAL.FEATURE.FEATURE.GROUP"
-TMTERMVER="4.1.0"
-update_feature_remote ${TM_TERMINAL_SITE}
org.eclipse.tm.terminal.feature.feature.group ${TMTERMVER}
+TMTERMVER="4.2.0"
+update_feature_remote ${MAIN_SITE}
org.eclipse.tm.terminal.feature.feature.group ${TMTERMVER}
echo -e "\nPlease wait. Installing TM.TERMINAL.VIEW.RSE.FEATURE.GROUP"
-TMTERMVIEWRSEVER="4.1.0"
-update_feature_remote ${TM_TERMINAL_SITE}
org.eclipse.tm.terminal.view.rse.feature.feature.group ${TMTERMVIEWRSEVER}
+TMTERMVIEWRSEVER="4.2.0"
+update_feature_remote ${MAIN_SITE}
org.eclipse.tm.terminal.view.rse.feature.feature.group ${TMTERMVIEWRSEVER}
echo -e "\nPlease wait. Installing TM.TERMINAL.CONTROL.FEATURE.GROUP"
-TMCONTROLVER="4.1.0"
+TMCONTROLVER="4.2.0"
update_feature_remote ${MAIN_SITE}
org.eclipse.tm.terminal.control.feature.feature.group ${TMCONTROLVER}
#RSE_SDK
@@ -293,11 +293,11 @@ update_feature_remote ${TM_SITE}
org.eclipse.rse.terminals.feature.group ${RSETE
#AUTOTOOLS
echo -e "\nPlease wait. Installing AUTOTOOLS.FEATURE.GROUP"
-ATVER="9.2.0"
+ATVER="9.2.1"
update_feature_remote ${MAIN_SITE} org.eclipse.cdt.autotools.feature.group
${ATVER}
#Lttng2
-TMF_CTF_REL="2.2.0"
+TMF_CTF_REL="2.3.0"
echo -e "\nPlease wait. Installing TRACECOMPASS.LTTNG2.UST.FEATURE.GROUP"
update_feature_remote ${MAIN_SITE}
org.eclipse.tracecompass.lttng2.ust.feature.group ${TMF_CTF_REL}
--
2.13.6
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Python cryptography failing due to undefined symbol: pthread_atfork
My hunch (not tested) is that the recipe needs -pthread added to LDSHARED:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/distutils.bbclass#n82
So try a python3-cryptography_%.bbappend file with “export
LDSHARED="${CCLD} -shared -pthread” in your own layer
Or try adding that line to python-cryptography.inc and then submit a patch
if it works.
On Fri, Dec 22, 2017 at 9:10 AM Alan Martinovic
wrote:
> I have confirmed that no `-pthread` flags are being set for building
> python-cryptography.
>
> Running the following:
>
> bitbake python-cryptography -c do_compile
> bitbake python-cryptography -c devshell
> grep pthread ../temp/run.do_compile
>
> gives no returns.
> Also there isn't a mention of it when doing a build in full
> verbose:
>
> bitbake python-cryptography -c cleanall
> bitbake python-cryptography -vvv | vi -
>
>
> On the target the symbol is identified as missing (NOTYPE):
>
> ~# readelf -a
> /usr/lib/python3.5/site-packages/cryptography/hazmat/bindings/_
> openssl.abi3.so
> | grep pthread_atfork
> 000aebb4 0002d916 R_ARM_JUMP_SLOT pthread_atfork
>729: 0 NOTYPE GLOBAL DEFAULT UND pthread_atfork
>
>
> My current goal is to extend the recipe with the `-pthread` so that
> it's there when
> the '_openssl' extension is being built.
> Still open to suggestions.
>
>
> A thing that seems to be underlying my assumption is that the recipe
> for python-cryptography
> hasn't actually changed between Morty (where it worked) and Rocko...
>
> On Thu, Dec 21, 2017 at 6:17 PM, Alan Martinovic
> wrote:
> > Hi there,
> > just did a migration to Rocko and am witnessing"
> >
> > root@device:~# python3
> > Python 3.5.3 (default, Dec 20 2017, 02:02:22)
> > [GCC 7.2.0] on linux
> > Type "help", "copyright", "credits" or "license" for more
> information.
> > >>> from cryptography.hazmat.bindings._openssl import ffi, lib
> > Traceback (most recent call last):
> > File "", line 1, in
> > ImportError:
> > /usr/lib/python3.5/site-packages/cryptography/hazmat/bindings/_
> openssl.abi3.so:
> > undefined symbol: pthread_atfork
> >
> >
> > Have tried both the recipe that comes with Rocko
> > and master of meta-openembedded.
> >
> > Seems to be the same bug as this one:
> >
> > https://bugs.gentoo.org/630578
> >
> > resolved with this patch:
> >
> >
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c824d1c44fcf4556de21d2c8b8ae3732b0fc0c5b
> >
> > Can someone provide hints on what would that translate to
> > for the python cryptography recipe?
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [eclipse-poky][neon][PATCH] Update setup.sh to Neon.3 (4.6.3) release
Also fixed some white space errors...
On Fri, Dec 22, 2017 at 6:27 PM Tim Orling
wrote:
> org.eclipse.tm.terminal* are now available on MAIN_SITE
>
> Signed-off-by: Tim Orling
> ---
> scripts/setup.sh | 32
> 1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/scripts/setup.sh b/scripts/setup.sh
> index 0764021b66c..4f7dc2b0a78 100755
> --- a/scripts/setup.sh
> +++ b/scripts/setup.sh
> @@ -23,7 +23,7 @@ while getopts ":h" opt; do
>esac
> done
>
> -err_exit()
> +err_exit()
> {
>echo "[FAILED $1]$2"
>exit $1
> @@ -35,7 +35,7 @@ case ${uname_s}${uname_m} in
>Linuxppc*) ep_arch=linux-gtk-ppc
> cdt_arch=linux.ppc
> ;;
> - Linuxx86_64*) ep_arch=linux-gtk-x86_64
> + Linuxx86_64*) ep_arch=linux-gtk-x86_64
> cdt_arch=linux.x86_64
> ;;
>Linuxi*86) ep_arch=linux-gtk
> @@ -92,12 +92,12 @@ fi
>
> # prepare the base Eclipse installation in folder "eclipse"
> ep_rel="R-"
> -ep_ver="4.6.2"
> -ep_date="-201611241400"
> +ep_ver="4.6.3"
> +ep_date="-201703010400"
> P2_disabled=false
> P2_no_dropins=false
>
> -if [ ! -f eclipse/plugins/org.eclipse.swt_3.105.2.v20161122-0613.jar ];
> then
> +if [ ! -f eclipse/plugins/org.eclipse.swt_3.105.3.v20170228-0512.jar ];
> then
>
>pushd .
>
> @@ -130,7 +130,7 @@ if [ ! -f
> eclipse/plugins/org.eclipse.swt_3.105.2.v20161122-0613.jar ]; then
>popd
>
>if [ ! -d eclipse -o -h eclipse ]; then
> -if [ -e eclipse ]; then
> +if [ -e eclipse ]; then
>rm eclipse
> fi
> ln -s eclipse-${ep_ver}-${ep_arch}/eclipse eclipse
> @@ -150,7 +150,7 @@ if [ ! -f eclipse/startup.jar ]; then
>LAUNCHER="`ls org.eclipse.equinox.launcher_*.jar | sort | tail -1`"
>
>if [ "x${LAUNCHER}" != "x" ]; then
> -echo "eclipse LAUNCHER=${LAUNCHER}"
> +echo "eclipse LAUNCHER=${LAUNCHER}"
> ln -s plugins/${LAUNCHER} ../startup.jar
>else
> echo "Eclipse: NO startup.jar LAUNCHER FOUND!"
> @@ -261,24 +261,24 @@ UPDATE_SITE="
> http://download.eclipse.org/eclipse/updates/4.6";
>
> #CDT related
> echo -e "\nPlease wait. Installing CDT.SDK.FEATURE.GROUP"
> -CDTFEAT="9.2.0"
> +CDTFEAT="9.2.1"
> update_feature_remote ${MAIN_SITE} org.eclipse.cdt.sdk.feature.group
> ${CDTFEAT}
>
> echo -e "\nPlease wait. Installing CDT.LAUNCH.REMOTE.FEATURE.GROUP"
> -CDTREMOTEVER="9.2.0"
> +CDTREMOTEVER="9.2.1"
> update_feature_remote ${MAIN_SITE}
> org.eclipse.cdt.launch.remote.feature.group ${CDTREMOTEVER}
>
> #TM Terminal (was RSE) related
> echo -e "\nPlease wait. Installing TM.TERMINAL.FEATURE.FEATURE.GROUP"
> -TMTERMVER="4.1.0"
> -update_feature_remote ${TM_TERMINAL_SITE}
> org.eclipse.tm.terminal.feature.feature.group ${TMTERMVER}
> +TMTERMVER="4.2.0"
> +update_feature_remote ${MAIN_SITE}
> org.eclipse.tm.terminal.feature.feature.group ${TMTERMVER}
>
> echo -e "\nPlease wait. Installing TM.TERMINAL.VIEW.RSE.FEATURE.GROUP"
> -TMTERMVIEWRSEVER="4.1.0"
> -update_feature_remote ${TM_TERMINAL_SITE}
> org.eclipse.tm.terminal.view.rse.feature.feature.group ${TMTERMVIEWRSEVER}
> +TMTERMVIEWRSEVER="4.2.0"
> +update_feature_remote ${MAIN_SITE}
> org.eclipse.tm.terminal.view.rse.feature.feature.group ${TMTERMVIEWRSEVER}
>
> echo -e "\nPlease wait. Installing TM.TERMINAL.CONTROL.FEATURE.GROUP"
> -TMCONTROLVER="4.1.0"
> +TMCONTROLVER="4.2.0"
> update_feature_remote ${MAIN_SITE}
> org.eclipse.tm.terminal.control.feature.feature.group ${TMCONTROLVER}
>
> #RSE_SDK
> @@ -293,11 +293,11 @@ update_feature_remote ${TM_SITE}
> org.eclipse.rse.terminals.feature.group ${RSETE
>
> #AUTOTOOLS
> echo -e "\nPlease wait. Installing AUTOTOOLS.FEATURE.GROUP"
> -ATVER="9.2.0"
> +ATVER="9.2.1"
> update_feature_remote ${MAIN_SITE}
> org.eclipse.cdt.autotools.feature.group ${ATVER}
>
> #Lttng2
> -TMF_CTF_REL="2.2.0"
> +TMF_CTF_REL="2.3.0"
> echo -e "\nPlease wait. Installing TRACECOMPASS.LTTNG2.UST.FEATURE.GROUP"
> update_feature_remote ${MAIN_SITE}
> org.eclipse.tracecompass.lttng2.ust.feature.group ${TMF_CTF_REL}
>
> --
> 2.13.6
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
