**** BEGIN LOGGING AT Fri Apr 06 03:00:01 2018 Apr 06 05:44:35 hi Apr 06 05:47:26 I want to ask a question,Is there a build suitable for orange pi plus 2e device? Apr 06 05:56:45 New news from stackoverflow: Yocto Project usb sensor access Apr 06 07:43:09 Hello ! Apr 06 10:10:22 Hi, is there a way to remove any program from busybox package in yocto? i would like to remove unzip program from busybox. Apr 06 10:12:12 vladzouth: change the busybox configuration in recipe directly or from your own layers with bbappends Apr 06 10:18:50 mcfrisk: how can i do that in the recipe, there is no where into the recipe file where unzip is referenced Apr 06 10:27:36 New news from stackoverflow: toaster yocto build UI Apr 06 10:29:01 mcfrisk: found!!! there is a menuconfig with allow to configure applet that you want into the final busybox package: bitbake -c menuconfig busybox Apr 06 12:05:08 Hi guys. We are currently developing a new iteration of our operating system: Apr 06 12:05:20 The old iteration was a openembedded classic and angström based os (I'll call 'classic' from now). Apr 06 12:05:30 The new iteration is openembedded core and yocto based (which I'll call 'core' from now on). Apr 06 12:05:37 Both are running fine, but the /proc/loadavg on core is around 0.22 while on classic it's around 0.05. Apr 06 12:06:32 I can't seem to find a cause for this. I set up OProfile on both and it says both idle around 93 percent of the time Apr 06 12:06:55 What could be the cause of this difference? Which metric should I trust more here? Apr 06 12:07:40 The classic kernel version is 2.6.35.14 and the core kernel version is 4.9.28 Apr 06 12:07:46 JPEW, RP: patches submitted Apr 06 12:10:35 load average in this case is meaningless.. and with the kernels so different in age, even more so Apr 06 12:10:48 you need to actually benchmark performance and not use those meaningless figures Apr 06 12:13:20 Well it seems kinda scary to me that the new OS runs >4x heavier than the old one. Apr 06 12:13:43 the number is meaningless.. seriously.. the way it's calculated has changed many times over the years as requirements and implementation has changed.. Apr 06 12:13:46 So you suggest I just need to create a heavy load and see how well it holds up? Apr 06 12:14:31 you are trying to compare something that is 8 years old vs something that is 2 years old.. Apr 06 12:14:52 it's just different.. you have to actually run benchmarks on your new device to see if it meets your needs.. Apr 06 12:15:12 if the old one works but the new one doesn't.. then start investigating.. otherwise you are wasting your time chasing meaningless numbers. Apr 06 12:15:40 bogomips, load average, etc are all meaningless without context.. and only the context of actual benchmarks matters Apr 06 12:16:34 Alright, noted. Thanks!\ Apr 06 12:17:05 at a minimum you can use something like lmbench, or netperf, or iobench or... to give you enough confidence that the system is performing properly.. Apr 06 12:17:23 but you need to choose a benchmark based on the context of what your application(s) are trying to do Apr 06 12:18:14 on an identical CPU -- I would expect some minor loss in overall performance since 2.6 to 4.9 4.9 is just more complex... but I would expect it to be minor.. in the 5% range maybe Apr 06 12:21:50 I ran some floating point bench before and noticed around 7.8% loss in speed, (which wass entirey attributed to libm v2.10 -> v2.24 btw) so you're dangerously close :') Apr 06 12:41:17 Renault: not seeing the patches as yet :/ Apr 06 12:43:27 there are not in poky archives Apr 06 12:43:36 do I have to subscribe to the list for that? Apr 06 12:45:21 Renault: yes, but the patches need to be sent to oe-core Apr 06 12:48:39 ok Apr 06 12:53:38 Hi there, is there someone who can help me setting up a mirror for yocto builds ? I have a particular environment so that it seems that it is not as easy as adding SOURCE_MIRROR_RUL and INHERIT += "own-mirrors" Apr 06 12:54:42 RP: done, thanks Apr 06 13:17:27 Renault: thanks Apr 06 13:18:35 patchtest failed because the cover letter does not provide Signed-off-by flag (but real patches it is the case), I don't have to send another patchset for that? Apr 06 13:19:18 Renault: there is no Sob line in the perl patch Apr 06 13:19:56 Renault: I'm busy debating the way way to handle this. Do we want to split xcrypt for both glibc on target and nativesdk in sumo? :/ Apr 06 13:20:19 Renault: or do we merge this after sumo releases, make a new uninative release and then backport the uninative to sumo and others? Apr 06 13:20:31 or do we just patch nativesdk-glibc Apr 06 13:20:51 this patch concerned only class_sdk normally Apr 06 13:21:12 Renault: libc_baselibs_remove_class_sdk = "${base_libdir}/libcrypt*.so.* ${base_libdir}/libcrypt-*.so" - that is an invalid override Apr 06 13:21:24 ah? Apr 06 13:21:27 it would be class-nativesdk but its clearly not being used Apr 06 13:21:58 Renault: also, the way you've applied this, it would apply on target as well? Apr 06 13:22:09 and then nothing has dependencies on libxcrypto :/ Apr 06 13:22:45 the patches prove the uninative solution works but merging the patches is going to need a bit more work :/ Apr 06 13:22:49 for me the idea was to apply this only on nativesdk Apr 06 13:23:05 for other targets, it should be normal glibc with libcrypt Apr 06 13:23:09 When is the target release date for sumo (before or after F28?) Apr 06 13:23:13 so no need to add dependencies for the moment Apr 06 13:23:57 (F28 release date should be 1st or 8th of May, normally) Apr 06 13:24:31 Renault: you're right, it does only patch nativesdk Apr 06 13:24:40 Renault: I was misreading it, sorry, long day Apr 06 13:24:47 no problem ;) Apr 06 13:25:07 trouble is f28 will release whilst sumo is in active use. We'll have to deal with this sooner or later Apr 06 13:25:56 Renault: it may be enough to add an RDEPENDS_${PN}_append_class-nativesdk = " libxcrypto" Apr 06 13:26:17 and maybe also excluding libxcrypto from parsing in the target case, make it nativesdk only Apr 06 13:26:21 on glibc-package.inc? Apr 06 13:26:29 or libxcrypt? Apr 06 13:26:35 Renault: yes, in glibc Apr 06 13:26:39 Sure. It seems like we could probably do the "safer" option of just splitting the nativesdk for now and split the target later (after sumo releases)? Apr 06 13:27:13 JPEW: yes Apr 06 13:27:17 for the target, it should not be better to wait upstream merging? Apr 06 13:27:45 Renault: we need to wait at least until the next release cycle, yes Apr 06 13:28:31 ok, so, I have to add your line and fix libc_baselibs_remove_class_sdk = "${base_libdir}/libcrypt*.so.* ${base_libdir}/libcrypt-*.so", that's it? I have to rebuild everything to check again? Apr 06 13:28:49 (in that case, should be done this week-end, not today) Apr 06 13:29:12 Renault: we need to make libxcypto raise SkipRecipe in the target case so its nativesdk only Apr 06 13:29:26 Renault: I can take a look at this later on and then run wider testing Apr 06 13:30:00 so, you want to make these changes and test it yourself, I can wait your results? Apr 06 13:34:55 Can somebody tell me how I can disable 'libgomp' from gcc-runtime ? I see it's in PACKAGES , but I cannot find how to remove it. Apr 06 13:54:51 oh nm I found it ! Apr 06 14:45:51 hello guys. I have built an image for the rpi3, at the very first boot I want to launch a script to extend the fs on the 2nd partition prior having it mounted. Doeas anyone have a suggestion ? Apr 06 14:52:22 fberg: You might be able to use something like: https://superuser.com/questions/660309/live-resize-of-a-gpt-partition-on-linux Apr 06 14:52:36 if i don't have a backlight listed in the device tree when i compile, will i not be able to use it on the device? Apr 06 14:52:59 Something similar might work with MBR and fdisk. I have never tried tough Apr 06 15:11:07 where can i find the kernel for the build that i'm doing? Apr 06 15:11:19 like the actual source that will be compiled into the kernel Apr 06 15:13:15 hey Apr 06 15:14:18 hello derRichard Apr 06 15:15:16 i tried to build a minimal yocto distro to run on freescale with vivante gpu support. but in the resultung image no vivante files are included. but they are build. at least i can see libVIVANTE.so in my build dir. yoco version (and of all layers is rocko) Apr 06 15:15:31 AbleBacon: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#maintaining-open-source-license-compliance-during-your-products-lifecycle should give you that, if you're only looking for it to distribute it Apr 06 15:15:37 after some research i found this howto: http://twoerner.blogspot.co.at/2017/06/gpu-support-with-openembedded_9.html Apr 06 15:15:46 i did the same, but still no vivante stuff in my rootfs Apr 06 15:16:17 i need the kernel source location so that i can add stuff to it, neverpanic. i need drivers Apr 06 15:16:20 what kind of stupid mistake did i? :D Apr 06 15:17:49 AbleBacon: sounds like the kernel development manual would be your resource of choice then: https://www.yoctoproject.org/docs/2.4.2/kernel-dev/kernel-dev.html#kernel-dev-intro Apr 06 15:18:02 ok, thanks Apr 06 15:21:45 anyone else seeing do_rootfs failing with latest oe-core with something like this: Apr 06 15:21:48 ERROR: Cannot get the installed packages list. Command '/OE/build/oe-core/tmp-glibc/work/raspberrypi3_64-oe-linux/core-image-sato/1.0-r0/recipe-sysroot-native/usr/bin/opkg -f /OE/build/oe-core/tmp-glibc/work/raspberrypi3_64-oe-linux/core-image-sato/1.0-r0/opkg.conf -o /OE/build/oe-core/tmp-glibc/work/raspberrypi3_64-oe-linux/core-image-sato/1.0-r0/rootfs --force_postinstall --prefer-arch-to-version status' Apr 06 15:21:54 returned 0 and stderr: Apr 06 15:21:56 31947: new pid: 31947 [sh] Apr 06 15:21:59 31947: new pid: 31947 [opkg] Apr 06 15:22:30 running the command manually works Apr 06 15:23:43 JaMa: hmm, no :/ Apr 06 15:25:41 JaMa: and so much for my TMPDIR theory on morty. Those changes did pass on the autobuilder :/ Apr 06 15:27:35 I'm trying to revert last 5 package_manager.py changes to narrow down the do_rootfs issue in master a bit Apr 06 15:28:25 RP: yeah :/ will try to debug morty issue a bit more Apr 06 15:29:09 I've retriggered all failed builds after removing the TMPDIRs again, lets see if it will be reproducible again Apr 06 15:29:46 it might be something in sstate which was reused in the first build after the change Apr 06 15:30:06 bbl Apr 06 15:31:15 when i want to create my own image, is it okay to just edit conf/local.conf and play with CORE_IMAGE_EXTRA_INSTALL or do i have to define my own image? Apr 06 15:32:39 RP Q regarding package master-next build failure. Who has to fix the issue? gtk_ fails to build do to update of atk, both are updates Apr 06 15:32:53 is it Fifo ? Apr 06 15:33:32 cage fight? Apr 06 15:34:00 armpit: well, the gtk issue got fixed by Anuj who sent a patch for atk Apr 06 15:34:13 armpit: there is a new x32 failure which maxin is going to look at I think Apr 06 15:34:18 k Apr 06 15:34:22 armpit: I also fixed libxcalibrate for you Apr 06 15:34:26 by deleting it Apr 06 15:36:19 cool. seems i am slow to the game :/ Apr 06 15:36:49 armpit: it all changed overnight even for me Apr 06 15:37:04 armpit: I'm rebuilding -next now so we'll see what issues that shows up Apr 06 15:37:11 k Apr 06 15:40:30 derRichard: that depends. either will get the packages you want into the image, but your own image recipe is far easier to maintain in the long term, and would apply to any build directories you add that layer to, rather than just that one. you can easily forget about changes you have living in local.conf Apr 06 15:42:40 kergoth: yeah, i know and understand that local.conf is volatile. i'm currently trying to understand why my rootfs contains no vivante drivers. CORE_IMAGE_EXTRA_INSTALL contains imx-gpu-viv Apr 06 15:42:56 and i see them built, but they don't get installed Apr 06 15:43:34 MACHINE is imx6qdlsabresd, so imxgpu3d should be selected too Apr 06 15:43:39 make sure the image you're using inherits core-image, for one Apr 06 15:43:46 and doesn't override that varaible Apr 06 15:43:54 iirc core-image-minimal doesn't always obey vars like that, for example Apr 06 15:43:56 well, i run bitbake core-image-x11 Apr 06 16:58:57 New news from stackoverflow: systemd ignores services from overlayFS Apr 06 17:08:45 JPEW: sadly building libxcrypt is a bit tricky, those patches don't work :( Apr 06 17:15:38 JPEW: I've put some details on the list but this looks like it might take a little more work Apr 06 17:23:09 hi Apr 06 17:23:44 Do yocto and orangepi plus 2e compatible configs? Apr 06 17:29:25 gah, now the glibc macro caching results are wrong :( Apr 06 17:37:06 seems like meta-intel master needs to bump its layerseries from rocko to sumo Apr 06 17:37:17 meta-dpdk as well Apr 06 17:37:56 i think adding the warnings and errors was a bit premature if even meta-intel is behind Apr 06 17:38:08 RP: Tricky. I haven't gotten around to to building an SDKs yet... I ran into an Icecream bug Apr 06 17:39:10 JPEW: note this is builds with the patchset applied Apr 06 17:39:42 kergoth: my reasoning was that its simple to fix Apr 06 17:40:00 and it really does cause users problems not knowing what works with what Apr 06 17:40:14 it is, but the average user likely doesn't want to have to modify layers they don't maintain to be able to continue to build what built fine last week Apr 06 17:40:16 RP: Renault's patchsets? Yes I have those in my tree (or some version of them...) Apr 06 17:40:21 at least get the main layers fixed first Apr 06 17:41:14 kergoth: The change from rocko -> sumo had to happen regardless and the fatal code was already there Apr 06 17:41:28 RP: I *think* the new uninative is going to work just fine.... it's more of a matter of getting those patches to applied so that everything else still works Apr 06 17:41:35 JPEW: agreed Apr 06 17:41:38 * RP -> food Apr 06 17:42:15 not that hard to at least submit patches to the most popular layers and make the change a couple days layer. seems like the obvious path to me, but *shrug*, whatever, will fix it locally for now like everyone else Apr 06 21:42:20 fancer: fyi, https://git.yoctoproject.org/cgit/cgit.cgi/meta-external-toolchain/log/?h=fancer-integrate finally got around to finishing breaking it up into individual commits. still need to rebase, clean up a bit, and adjust authorship and signoffs, and determine which to merge **** ENDING LOGGING AT Sat Apr 07 03:00:00 2018