[yocto] x86 testing
I'm trying to track down some recent changes in the X server (using the latest Poky/Yocto master). I've had failures on a number of the embedded targets I work with, so I thought I'd give it a go on platforms with a larger base - x86 machines. It used to be that I could run qemu and it would pop up a separate window that emulated a display+keyboard+mouse. That doesn't seem to be the same now, or at least I don't see how to make it work. Advice on this would be great as I need to test the "native" X setup, not VNC connections. I'd also be happy to try this on real hardware, e.g. my wife's laptop, but I need some way to do that non-destructively. Again, pointers would be greatly appreciated. Once I get this figured out, I'll disappear back down my embedded rabbit hole... Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] "external"/"internal" SDK
Hi, On 2017-01-18 04:54, Joshua Watt wrote: external SDK: everything the same as above, but for some packages there should be only libraries - no header files. Is there a reason why you want the libraries without the headers? It doesn't seem particularly useful to be able to link a program against a library, but not have the header to use its API (especially in an SDK, where the point is to build program against the libraries). I think they are worried about revealing their "internal" API since they don't want their customers to access it directly. As an alternative, there might be a way to completely exclude those particular packages from the external SDK instead of removing the header files (see below)? I'll try to clarify this with them. ... Hopefully it will at least give a place to start. Certainly. This gives me some more ideas how other people would do it. Thanks! Joshua Watt -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 0/2] Drop kernel versions 4.7 and 4.8
Hi Gary, You get this because the patch to the latest 4.7 version have not been merged... 4.7 has been stable for some time now, unlike 4.8 - and 4.9 will probably have some similar issues, basically the downstream is heavily rebasing, so revisions numbers are not reliable anymore. I'm OK to remove 4.7, since I've branched it - and mine is working fine :) I have no problem removing 4.8, since I moved from 4.7 to 4.9. But I believe we might also want to remove 4.1, because it's really very old, and select the next non-LTS version instead. That would make it 4.4, 4.9 and next-kernel. Cheers, Herve -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Gary Thomas Sent: lundi 16 janvier 2017 15:48 To: yocto@yoctoproject.org Subject: Re: [yocto] [meta-raspberrypi][PATCH 0/2] Drop kernel versions 4.7 and 4.8 On 2017-01-16 08:26, Paul Barker wrote: > As discussed recently on the list, we can just keep LTS versions now > that v4.9 is available. > > I'm sending these so anyone who still needs v4.7 or v4.8 can shout > 'stop!' before we remove them. > > Paul Barker (2): > linux-raspberrypi: Drop v4.7 > linux-raspberrypi: Drop v4.8 > > .../0001-fix-dtbo-rules.patch | 44 -- > recipes-kernel/linux/linux-raspberrypi_4.7.bb | 9 - > recipes-kernel/linux/linux-raspberrypi_4.8.bb | 8 > 3 files changed, 61 deletions(-) > delete mode 100644 > recipes-kernel/linux/linux-raspberrypi-4.7/0001-fix-dtbo-rules.patch > delete mode 100644 recipes-kernel/linux/linux-raspberrypi_4.7.bb > delete mode 100644 recipes-kernel/linux/linux-raspberrypi_4.8.bb > +1 at least for 4.7 given that with today's repo I get this: ERROR: linux-raspberrypi-1_4.7.7+gitAUTOINC+c2cbd9c611-r0 do_kernel_version_sanity_check: Package Version (4.7.7+gitAUTOINC+c2cbd9c611) does not match of kernel being built (4.7.10). Please update the PV variable to match the kernel source. ERROR: linux-raspberrypi-1_4.7.7+gitAUTOINC+c2cbd9c611-r0 do_kernel_version_sanity_check: Function failed: do_kernel_version_sanity_check (log file is located at /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspb errypi/1_4.7.7+gitAUTOINC+c2cbd9c611-r0/temp/log.do_kernel_version_sanity_ch eck.27925) ERROR: Logfile of failure stored in: /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspb errypi/1_4.7.7+gitAUTOINC+c2cbd9c611-r0/temp/log.do_kernel_version_sanity_ch eck.27925 ERROR: Task (/local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspbe rrypi_4.7.bb:do_kernel_version_sanity_check) failed with exit code '1' -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ 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] [meta-raspberrypi][PATCH 0/2] Drop kernel versions 4.7 and 4.8
Hi Gary, I believe that we will see for 4.9 the same issues we had with 4.8, heavy rebasing from the downstream. I'm currently working with the upstream - plus patches - and I plan to have a yocto build that would take the upstream source and add some patches, instead of taking the downstream as a reference. Is this an approach that could be interesting to people using yocto and RaspberryPi? Any thoughts on that? Or another solution to remove the dependency to the downstream and its constant rebasing? Cheers, Herve -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Gary Thomas Sent: lundi 16 janvier 2017 15:52 To: yocto@yoctoproject.org Subject: Re: [yocto] [meta-raspberrypi][PATCH 0/2] Drop kernel versions 4.7 and 4.8 On 2017-01-16 15:48, Gary Thomas wrote: > On 2017-01-16 08:26, Paul Barker wrote: >> As discussed recently on the list, we can just keep LTS versions now >> that v4.9 is available. >> >> I'm sending these so anyone who still needs v4.7 or v4.8 can shout >> 'stop!' before we remove them. >> >> Paul Barker (2): >> linux-raspberrypi: Drop v4.7 >> linux-raspberrypi: Drop v4.8 >> >> .../0001-fix-dtbo-rules.patch | 44 -- >> recipes-kernel/linux/linux-raspberrypi_4.7.bb | 9 - >> recipes-kernel/linux/linux-raspberrypi_4.8.bb | 8 >> 3 files changed, 61 deletions(-) >> delete mode 100644 >> recipes-kernel/linux/linux-raspberrypi-4.7/0001-fix-dtbo-rules.patch >> delete mode 100644 recipes-kernel/linux/linux-raspberrypi_4.7.bb >> delete mode 100644 recipes-kernel/linux/linux-raspberrypi_4.8.bb >> > > +1 at least for 4.7 given that with today's repo I get this: > > ERROR: linux-raspberrypi-1_4.7.7+gitAUTOINC+c2cbd9c611-r0 > do_kernel_version_sanity_check: Package Version > (4.7.7+gitAUTOINC+c2cbd9c611) does not match of kernel being built > (4.7.10). Please update the PV variable to match the kernel source. > ERROR: linux-raspberrypi-1_4.7.7+gitAUTOINC+c2cbd9c611-r0 do_kernel_version_sanity_check: Function failed: > do_kernel_version_sanity_check (log file is located at > /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux > -raspberrypi/1_4.7.7+gitAUTOINC+c2cbd9c611-r0/temp/log.do_kernel_versi > on_sanity_check.27925) > > ERROR: Logfile of failure stored in: > /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux > -raspberrypi/1_4.7.7+gitAUTOINC+c2cbd9c611-r0/temp/log.do_kernel_versi > on_sanity_check.27925 > > ERROR: Task > (/local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux- > raspberrypi_4.7.bb:do_kernel_version_sanity_check) > failed with exit code '1' > However, there is this error when I tried to switch to 4.9: ERROR: linux-raspberrypi-1_4.9.2+gitAUTOINC+4052b0da7d-r0 do_fetch: Fetcher failure: Unable to find revision 4052b0da7dbab0df22ca8733cf50b3e573e221e0 in branch rpi-4.9.y even from upstream ERROR: linux-raspberrypi-1_4.9.2+gitAUTOINC+4052b0da7d-r0 do_fetch: Fetcher failure for URL: 'git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.9.y'. Unable to fetch URL from any source. ERROR: linux-raspberrypi-1_4.9.2+gitAUTOINC+4052b0da7d-r0 do_fetch: Function failed: base_do_fetch ERROR: Logfile of failure stored in: /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspb errypi/1_4.9.2+gitAUTOINC+4052b0da7d-r0/temp/log.do_fetch.13098 ERROR: Task (/local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspbe rrypi_4.9.bb:do_fetch) failed with exit code '1' Using meta-raspberrypi:e1f69daa805cb02ddd123ae2d4d48035cb5b41d0 -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ 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] "external"/"internal" SDK
external SDK: everything the same as above, but for some packages there should be only libraries - no header files. Is there a reason why you want the libraries without the headers? It doesn't seem particularly useful to be able to link a program against a library, but not have the header to use its API (especially in an SDK, where the point is to build program against the libraries). If you are just worried about including the source code in the external SDK, you might be able to get by with simply removing "dbg-pkgs" from SDKIMAGE_FEATURES. This would still include the development headers for the libraries (i.e. the API), but would remove the source code for debugging (I think, I haven't actually tried it). As an alternative, there might be a way to completely exclude those particular packages from the external SDK instead of removing the header files (see below)? I guess I'm not the first one who needs something like this. How would you do something like this the "Yocto way"? We have to do something similar to this where I work. We actually accomplish this by having multiple "image" recipes dedicated to the SDK(s) that are distinct from our actual main image that goes on our final product. This allows us to add whatever we want to the SDK image, but keep our final image paired down to only what is necessary. For example, our (internal) SDK image has many libraries included in it that aren't going to necessarily be used by our final product, but we may want to use in the future. Having a separate SDK image allows us to (more or less) start using the library without having to go through the hassle of updating and re-releasing the SDK to add support (granted, we *do* have to install the new library on our product before it works, but that is generally easier in our particular work flow). To reduce duplicate maintenance, between the internal SDK and our product image, we make judicious use of bitbake include files to make sure that they both get all the packages that should be common. Using a external SDK is a similar exercise, except we are much more careful about what libraries end up on that one. We make sure that none of our "special sauce" (i.e. proprietary) libraries end up there if we can help it. This might work for you if you can pare down what packages are including to keep the libraries you don't want from getting included in the SDK. Finally, failing all that, you can probably create an external SDK image but remove "dev-pkgs" and "dbg-pkgs" from SDKIMAGE_FEATURES. This would create an SDK that isn't very exciting because you wouldn't have the headers for *any* libraries, but you could manually add the ones you did want back into the image by including the corresponding "-dev" package in IMAGE_INSTALL. It would be a lot of manual work, but you could probably get exactly what you wanted. Not sure if its the "Yocto way", but it works well enough for us. Hopefully it will at least give a place to start. Joshua Watt -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Openembedded layer index stopped updating
On Tue, Jan 17, 2017 at 11:21 PM, Paul Eggleton wrote: > On Fri, 13 Jan 2017 11:02:20 Andreas Müller wrote: >> On Fri, Jan 13, 2017 at 9:55 AM, Paul Eggleton >> wrote: >> > On Fri, 13 Jan 2017 08:56:47 Andreas Müller wrote: >> >> again me... sorry but I use index regularly to check if somebody else >> >> already created a recipe I am interested in. >> >> >> >> I think it was caused by maintenance changes. >> > >> > You're right, we have just done an upgrade and as a result we are >> > currently dealing with an issue updating the index, as yet I don't know >> > what has caused it exactly because we aren't actually seeing any errors - >> > the update process only manages to update some of the layers before it >> > stalls and then eventually gets killed. We're working on it, apologies for >> > the inconvenience. >> >> Thanks and there is no inconvenience - was just a ping > > FYI everything should be back to a working state now. I'll send a separate > email describing recent enhancements. > > Cheers, > Paul > Thanks a lot! Andreas -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Openembedded layer index stopped updating
On Fri, 13 Jan 2017 11:02:20 Andreas Müller wrote: > On Fri, Jan 13, 2017 at 9:55 AM, Paul Eggleton > wrote: > > On Fri, 13 Jan 2017 08:56:47 Andreas Müller wrote: > >> again me... sorry but I use index regularly to check if somebody else > >> already created a recipe I am interested in. > >> > >> I think it was caused by maintenance changes. > > > > You're right, we have just done an upgrade and as a result we are > > currently dealing with an issue updating the index, as yet I don't know > > what has caused it exactly because we aren't actually seeing any errors - > > the update process only manages to update some of the layers before it > > stalls and then eventually gets killed. We're working on it, apologies for > > the inconvenience. > > Thanks and there is no inconvenience - was just a ping FYI everything should be back to a working state now. I'll send a separate email describing recent enhancements. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [layerindex-web][PATCH] restviews: hide unpublished layers
Layers that aren't published shouldn't be visible via the API. (We don't need to apply that filter to recipes, machines or distros though since a layer's content won't automatically be indexed unless it has been published). Signed-off-by: Paul Eggleton --- layerindex/restviews.py | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/layerindex/restviews.py b/layerindex/restviews.py index 57f1552..b0c8a7a 100644 --- a/layerindex/restviews.py +++ b/layerindex/restviews.py @@ -5,7 +5,7 @@ from layerindex.querysethelper import params_to_queryset, get_search_tuple class ParametricSearchableModelViewSet(viewsets.ModelViewSet): def get_queryset(self): model = self.__class__.serializer_class.Meta.model -qs = model.objects.all() +qs = self.queryset (filter_string, search_term, ordering_string) = get_search_tuple(self.request, model) return params_to_queryset(model, qs, filter_string, search_term, ordering_string) @@ -22,7 +22,7 @@ class LayerItemSerializer(serializers.ModelSerializer): model = LayerItem class LayerItemViewSet(ParametricSearchableModelViewSet): -queryset = LayerItem.objects.all() +queryset = LayerItem.objects.filter(status='P') serializer_class = LayerItemSerializer class LayerBranchSerializer(serializers.ModelSerializer): @@ -30,7 +30,7 @@ class LayerBranchSerializer(serializers.ModelSerializer): model = LayerBranch class LayerBranchViewSet(ParametricSearchableModelViewSet): -queryset = LayerBranch.objects.all() +queryset = LayerBranch.objects.filter(layer__status='P') serializer_class = LayerBranchSerializer class LayerDependencySerializer(serializers.ModelSerializer): @@ -38,7 +38,7 @@ class LayerDependencySerializer(serializers.ModelSerializer): model = LayerDependency class LayerDependencyViewSet(ParametricSearchableModelViewSet): -queryset = LayerDependency.objects.all() +queryset = LayerDependency.objects.filter(layerbranch__layer__status='P') serializer_class = LayerDependencySerializer class RecipeSerializer(serializers.ModelSerializer): -- 2.5.5 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Openembedded-architecture] Patchwork and incoming patch testing
Paul, That is some impressive work by the team! Thank you all for the hard work and bringing the plan to fruition - I'm sure this framework will benefit our entire Community and will improve and streamline the workflow! -- Denys On Wed, Jan 18, 2017 at 07:05:58AM +1300, Paul Eggleton wrote: > Hi all, > > As some of you are aware some of my colleagues and I have been working on > improving how incoming patches are handled - initially for OE-Core but we > hope > to arrive at something that will be useful for other layers as well. The aim > was to do so without adversely affecting existing workflows, so that means > building on top of the things we already have. It's taken a bit longer than > we'd originally planned - we embarked on this a little over a year ago [1] - > but now I am happy to be able to show some meaningful progress. > > A few months ago we upgraded OE's patchwork instance [2], moving not just to > a > later version but to a fork of patchwork where a bunch of new functionality > was being developed for freedesktop.org [3], notably support for capturing > and > presenting patch series instead of just individual patches. There were some > teething problems but we've now resolved most of them. Unfortunately work on > said freedesktop.org fork appears to have stalled so for now we have forked > it > ourselves [4]; long term we'll have to see if we can merge back with > patchwork > upstream - at least for small fixes we'll try to push those back up > independent of any wholesale merge. In any event we are now finally in the > position where our patchwork instance can be relied upon to collect emails, > and the UI is much improved. This should give us a bit more visibility into > where patches are at in the process, although we are still working on a few > places where patch series status needs to be updated (e.g. when a patch goes > into testing). > > On top of patchwork we have built a simple smoke-testing framework called > "patchtest" [5] along with a suite of corresponding tests for OE [6]. These > tests are fairly simplistic at this point but check the basics such as > whether > a patch has been properly signed off, etc. We should soon start seeing > replies > sent to the mailing list and to submitters with results if there are any > failures, saving us from noticing and pointing out some of the more obvious > classes of mistakes. The tests are easy to run locally without the rest of > the > infrastructure and can be extended without difficulty, and I expect we'll > continue to work on those as time progresses. Contributions would be very > welcome. > > My sincere thanks to José Lamego, Leonardo Sandoval, Daniela Plascencia, > Belen Barros Pena, Michael Halstead, Damien Lespiau, Patrick Ohly and others > that have been part of implementing this, and to everyone else who has put up > with the delays. > > Please let us know if you have issues with any part of this process or > suggestions on how to improve it. We're tracking improvements in the Yocto > Project bugzilla [7] so you can see what's being worked on there if you're > interested. > > Cheers, > Paul > > [1] Earlier announcement: > > https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg72952.html > > [2] OE's patchwork instance: > http://patchwork.openembedded.org > > [3] Freedesktop.org patchwork fork: > https://github.com/dlespiau/patchwork > > [4] Our patchwork fork: > http://git.yoctoproject.org/cgit/cgit.cgi/patchwork/ > > [5] Patchtest main repository: > http://git.yoctoproject.org/cgit/cgit.cgi/patchtest/ > > [6] OE test suite for patchtest: > http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe/ > > [7] Yocto Project bugzilla area for patchwork/patchtest: > > https://bugzilla.yoctoproject.org/describecomponents.cgi?product=Patchwork%2FPatchtest > > -- > > Paul Eggleton > Intel Open Source Technology Centre > ___ > Openembedded-architecture mailing list > openembedded-architect...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Patchwork and incoming patch testing
Hi all, As some of you are aware some of my colleagues and I have been working on improving how incoming patches are handled - initially for OE-Core but we hope to arrive at something that will be useful for other layers as well. The aim was to do so without adversely affecting existing workflows, so that means building on top of the things we already have. It's taken a bit longer than we'd originally planned - we embarked on this a little over a year ago [1] - but now I am happy to be able to show some meaningful progress. A few months ago we upgraded OE's patchwork instance [2], moving not just to a later version but to a fork of patchwork where a bunch of new functionality was being developed for freedesktop.org [3], notably support for capturing and presenting patch series instead of just individual patches. There were some teething problems but we've now resolved most of them. Unfortunately work on said freedesktop.org fork appears to have stalled so for now we have forked it ourselves [4]; long term we'll have to see if we can merge back with patchwork upstream - at least for small fixes we'll try to push those back up independent of any wholesale merge. In any event we are now finally in the position where our patchwork instance can be relied upon to collect emails, and the UI is much improved. This should give us a bit more visibility into where patches are at in the process, although we are still working on a few places where patch series status needs to be updated (e.g. when a patch goes into testing). On top of patchwork we have built a simple smoke-testing framework called "patchtest" [5] along with a suite of corresponding tests for OE [6]. These tests are fairly simplistic at this point but check the basics such as whether a patch has been properly signed off, etc. We should soon start seeing replies sent to the mailing list and to submitters with results if there are any failures, saving us from noticing and pointing out some of the more obvious classes of mistakes. The tests are easy to run locally without the rest of the infrastructure and can be extended without difficulty, and I expect we'll continue to work on those as time progresses. Contributions would be very welcome. My sincere thanks to José Lamego, Leonardo Sandoval, Daniela Plascencia, Belen Barros Pena, Michael Halstead, Damien Lespiau, Patrick Ohly and others that have been part of implementing this, and to everyone else who has put up with the delays. Please let us know if you have issues with any part of this process or suggestions on how to improve it. We're tracking improvements in the Yocto Project bugzilla [7] so you can see what's being worked on there if you're interested. Cheers, Paul [1] Earlier announcement: https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg72952.html [2] OE's patchwork instance: http://patchwork.openembedded.org [3] Freedesktop.org patchwork fork: https://github.com/dlespiau/patchwork [4] Our patchwork fork: http://git.yoctoproject.org/cgit/cgit.cgi/patchwork/ [5] Patchtest main repository: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest/ [6] OE test suite for patchtest: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe/ [7] Yocto Project bugzilla area for patchwork/patchtest: https://bugzilla.yoctoproject.org/describecomponents.cgi?product=Patchwork%2FPatchtest -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-swupd][PATCH] swupd-image.bbclass: do_swupd_update() depends on time-native
On Tue, 2017-01-17 at 17:42 +0100, Patrick Ohly wrote: > On Tue, 2017-01-17 at 15:59 +, André Draszik wrote: > > The shell script uses time, which is either a bash built-in, or > > a GNU utility. Not all build machines will have either bash or > > GNU time available out of the box. Make sure it is available. > > Good catch. I'm just wondering whether it wouldn't be simpler to remove > the usage of "time" instead, or make it optional? > > The "time" utility was useful while working on performance of the code, I thought the same, and was contemplating removing its use... > but now that this is done, it's merely nice to have when one can get it ...but I was curious as well, so I left it in and added the dependency. > for free, which isn't the case when time-native has to be compiled > first. It's a one-time host-depend, which should also be satisfied from sstate after that, so I thought it'd be OK to keep it. I have no preference either way. Cheers, Andre' -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-swupd][PATCH] swupd-image.bbclass: do_swupd_update() depends on time-native
On Tue, 2017-01-17 at 15:59 +, André Draszik wrote: > The shell script uses time, which is either a bash built-in, or > a GNU utility. Not all build machines will have either bash or > GNU time available out of the box. Make sure it is available. Good catch. I'm just wondering whether it wouldn't be simpler to remove the usage of "time" instead, or make it optional? The "time" utility was useful while working on performance of the code, but now that this is done, it's merely nice to have when one can get it for free, which isn't the case when time-native has to be compiled first. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Project Status WW03’17
Current Dev Position: YP 2.3 M2 Next Deadline: YP 2.3 M2 by Jan 23, 2017 SWAT team rotation: Armin -> Saul on Jan. 13, 2017. SWAT team rotation: Saul -> Paul on Jan. 20, 2017. https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: ·The 2.2.1 release has been held up by a bug in eSDK which we’re having trouble tracking down, it is fixed in master but we’re not sure where/how. We’ll rebuild and submit to QA once we find it. ·The M2 deadline is at the end of the week. The oeqa patchset should be posted imminently once the final bugs that testing has discovered are fixed. There is an update about recipe specific sysroot that will be sent to the openembedded-architecture list shortly but good progress is also being made there with a handful of test cases showing issues that still need to be resolved. We don’t yet have performance data on the sysroot changes which is one potential problem still to be determined. ·We continue to struggle with stabilizing patches coming in from the mailing list and whilst patches are merging, its taking longer to review and test them that we’d like and the flow is slower than it would ideally be. ·One particular challenge we’re facing is the length of time oe-selftest takes to run. A bitbake change from Jianxun Zhang has sped up the bitbake -S based sstate tests significantly which is a start at improving its speed, we also found an issue that slowed down test case loading but there are many more things which can be done to speed this up and it's an area we’ll need to focus on if we want to improve overall patch throughput. Proposed upcoming dot releases: YP 2.2.1 Release by Jan. 20, 2017 (Will be late) YP 2.1.3 Cut off May 8, 2017 YP 2.1.3 Release by May 19, 2017 YP 2.2.2 Cut off May 22, 2017 YP 2.2.2 Release by June 2, 2017 Key YP 2.3 Dates: YP 2.3 M2 Cutoff is Jan. 23, 2017 YP 2.3 M2 Release is Feb. 3, 2017 YP 2.3 M3 Cutoff is Feb 27, 2017 YP 2.3 M3 Release is Mar. 10, 2017 YP 2.3 M4 Cutoff is April 3, 2017 YP 2.3 M4 Release is April 28, 2017 Tracking Metrics: WDD 2624 (last week 2632) (https://wiki.yoctoproject.org/charts/combo.html) Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.3_Status https://wiki.yoctoproject.org/wiki/Yocto_2.3_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.3_Features [If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!] Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 • Work Telephone:(503) 712-0534 •Cell: (208) 244-4460 • Email:stephen.k.jol...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-swupd][PATCH] swupd-image.bbclass: do_swupd_update() depends on time-native
From: André Draszik The shell script uses time, which is either a bash built-in, or a GNU utility. Not all build machines will have either bash or GNU time available out of the box. Make sure it is available. Note that this needs the patch to OE-core to enable the time-native BBCLASSEXTEND to be applied before this here can go in. Signed-off-by: André Draszik --- classes/swupd-image.bbclass | 1 + 1 file changed, 1 insertion(+) diff --git a/classes/swupd-image.bbclass b/classes/swupd-image.bbclass index 5ba9cfb..60f7edb 100644 --- a/classes/swupd-image.bbclass +++ b/classes/swupd-image.bbclass @@ -563,6 +563,7 @@ SWUPDDEPENDS = "\ virtual/fakeroot-native:do_populate_sysroot \ rsync-native:do_populate_sysroot \ bsdiff-native:do_populate_sysroot \ +time-native:do_populate_sysroot \ " # We don't know exactly which formats will be in use during -- 2.11.0 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] "external"/"internal" SDK
Hi, A client would like to dish out an SDK to their customers, but only with a subset of header files compared to those they use internally. internal SDK: As it is right now when you build an sdk with e.g. bitbake whatever -c populate_sdk external SDK: everything the same as above, but for some packages there should be only libraries - no header files. I guess I'm not the first one who needs something like this. How would you do something like this the "Yocto way"? Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] kernel-fit: Change FIT (kernel+initrd) symlinks to fitImage-*
On 11 January 2017 at 20:55, Rick Altherr wrote: > KERNEL_IMAGETYPE only provides the first image type specified in > KERNEL_IMAGETYPES which can provide surprising results. Since this > class is solely for FIT images, just hardcode the names to fitImage-*. > Nathan sent the identical patch earlier, so I merged his. Expect this in master shortly. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to change toochains to gcc 4.9.3
On 2017-01-17 11:41, Richard Zhang wrote: Hi when I want to change gcc version to 4.9.3. I just change gcc & libgcc,but gcc-truntime still 5.3. Is there a rapid method to change everything I need? Of course you'll need the correct recipes, but just add these lines to local.conf: GCCVERSION ?= "4.9.%" SDKGCCVERSION ?= "4.9.%" -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to change toochains to gcc 4.9.3
Hi when I want to change gcc version to 4.9.3. I just change gcc & libgcc,but gcc-truntime still 5.3. Is there a rapid method to change everything I need? Regards Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH v2] linux-raspberrypi-rt: add
On Tue, 17 Jan 2017 08:51:10 +0100 Andreas Müller wrote: > On Tue, Jan 17, 2017 at 1:12 AM, Trevor Woerner wrote: > > Hi Paul, > > > > On Thu 2017-01-05 @ 09:59:16 PM, Paul Barker wrote: > >> Also, are you thinking of moving the -rt recipe to the 4.9 series when > >> upstream linux-raspberrypi declares that stable? > > > > I just want to confirm that 4.9 is going to be the next stable series? How > > do > > we know 4.8 isn't going to be the next stable after 4.4? > > -- > Upstream 4.8 is already marked as EOL > > Andreas https://plus.google.com/+gregkroahhartman/posts/DjCWwSo7kqY is official enough for me. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
