**** BEGIN LOGGING AT Wed Dec 05 03:00:01 2018 Dec 05 08:41:33 gah, green selftests but eclipse failed Dec 05 08:47:32 good morning Dec 05 12:13:34 So I'm trying a core-image-minimal build of poky-tiny, and I'm spending a lot of time and space on native deps that I never intend to use, like 2.7 gigabytes worth of qemu(-helper) for a bunch of architectures I do not care about? Dec 05 12:13:49 According to recipe-depends.dot, most of these are a direct dependency of core-image-minimal Dec 05 12:14:03 I just can't see where it pulls these deps or why, let alone how to disable it Dec 05 12:19:20 DuClare, which machine ? Dec 05 12:20:48 Whatever the default is Dec 05 12:20:48 you can restrtict the architectures with QEMU_TARGETS variable, but it doesn't really have much time and space Dec 05 12:20:57 Why is qemu built at all? Dec 05 12:21:17 some postinst scripts are executed in qemu Dec 05 12:21:21 I believe qemu is used, as an example, for files that go into the target root fs, that are created by target programs Dec 05 12:21:32 so they cant run on the host Dec 05 12:22:09 also, the qemu* machines inherit qemu.inc, which pulls in qemu-native, for booting the resulting image in qemu Dec 05 12:25:04 Huh. I'm surprised you'd need to run target binaries to finish a cross build Dec 05 12:26:38 cache files for speeding up things, on a read-only rootfs for instance Dec 05 12:28:22 nobody wrote cross tools to generate e.g. fontcache, gio-module-cache, gobject-introspection, gtk-immodules-cache Dec 05 12:28:29 My plan was to build something that doesn't really need such things.. basically just bootloader + kernel + busybox + custom application in initramfs Dec 05 12:29:34 than start with initramfs image instead of core-image-minimal Dec 05 12:31:58 Well I checked out core-image-minimal-initramfs but from what I can tell, it's pulling the same deps Dec 05 12:32:23 Same for core-image-tiny-initramfs Dec 05 12:36:16 Hmm Dec 05 12:38:14 Well. It is smaller and quicker, though it still pulls qemu Dec 05 12:38:26 I wonder if that's because of MACHINE Dec 05 13:12:11 building qemu-native really isn't that time consuming Dec 05 13:12:20 you'll spend longer chipping away at removing it Dec 05 13:14:41 i believe a non-qemu minimal image is buildable without building qemu-native though, so presumably something you're building needs it Dec 05 13:15:02 note that both systemd and eudev need it to build the hwdb Dec 05 13:15:48 of course sstate means you built qemu-native once and it won't be built again unless it changes Dec 05 13:16:29 Hi, folks! Dec 05 13:16:42 I have a newbie question Dec 05 13:17:15 Can I use more than one bbappend file for one recipe Dec 05 13:17:17 ? Dec 05 13:18:06 yes Dec 05 13:18:43 ok. Does layer priority affects th eorder? Dec 05 13:18:50 *the order Dec 05 13:18:52 hm probably Dec 05 13:18:58 easy to inspect with bitbake-layers Dec 05 13:19:09 ok. It's good idea Dec 05 13:19:43 good news, actually Dec 05 13:19:46 thanks! Dec 05 13:20:52 I just fooled myself that I've heard the opposite information before. Like bbappend files override another ones. Dec 05 13:21:05 oh that's definitely wrong Dec 05 13:21:15 Glad to hear I was wrong Dec 05 13:21:18 they all pile up Dec 05 13:22:09 may be it worked that way I thought early... Dec 05 13:30:14 rburton: BTW, as it was already mentioned a couple of times now: my don't start your project on raspi submission was actually accepted! Dec 05 13:38:47 LetoThe2nd: nice! :) Dec 05 13:39:44 RP: :-) Dec 05 13:42:02 LetoThe2nd, what did you submit? Dec 05 13:43:37 Crofton: to a german iot conf. basically "whats on the menu besides raspberry pie", and the abstract pointing out that often the "lets just start quickly" approach using raspi+armbian backfires badly Dec 05 13:44:08 excellent talk! Dec 05 13:44:27 Be sure to focus on the postitive Dec 05 13:45:33 i'll focus on metal. Dec 05 13:49:55 You would Dec 05 13:50:19 LetoThe2nd: nice Dec 05 13:51:01 actually, i expect the audience to not even be properly aware of no-OS/RTOS/runtime environments other than armbian Dec 05 13:52:04 LetoThe2nd: gold, platinum, cobalt, so many to choose from ;-) Dec 05 13:52:09 :-) Dec 05 15:21:07 I'm running into an issue in my do_rootfs step: "nothing provides xf86-video-imx-vivante needed by packagegroup-core-x11-xserver-1.0-r40.var_som_mx6" Dec 05 15:21:36 the oe-pkgdata-util claims that it's provided by imx-gpu-viv, so I added that to my local.conf, but I'm still getting the same error. Dec 05 15:22:07 cdgarren: IIRC we've had about the same topic just a couple of days back Dec 05 15:22:26 seomthing changed in the DEPENDS/REPENDS across layers, so might start checking there Dec 05 15:22:38 (sorry don't remember the actual outcome) Dec 05 15:22:55 No problem. Thanks for the pointer. Dec 05 15:38:02 LetoThe2nd: Any chance you remember anything else about that fix? I'm not figuring anything out yet. Dec 05 15:38:58 Or does anyone else have advice on how to track this down? Dec 05 15:45:58 https://twitter.com/0xdea/status/1070308598146850818 <-- hey so systemd is really good and carefully written Dec 05 15:46:24 https://github.com/systemd/systemd/issues/11026 <-- the actual issue Dec 05 15:46:46 oof Dec 05 15:50:35 not actually a systemd thing, https://gitlab.freedesktop.org/polkit/polkit/issues/74#note_84732 Dec 05 15:51:34 Ok, I have another issue in trying to get this building. The do_prepare_sysroot step fails trying to copy a file to a recipe-sysroot because the file already exists. I seem to be able to fix it by removing the file it complains about it, but I'm a littel confused about why this file isn't cleaned up if it shouldn't be there? Dec 05 15:52:13 cdgarren: two recipes shouldn't be providing the same files Dec 05 15:54:46 How can I remove a package from an image, even if it breaks rdepends? Dec 05 15:55:38 rburton: Makes sense. How can I tell which recipes are providing the file? It looks like all of the failures were complaining about recipe-sysroot/usr/lib/libwayland-egl.so.1.0.0 Dec 05 15:56:14 $ oe-pkgdata-util find-path /usr/lib/libwayland-egl.so.\* Dec 05 15:56:15 wayland: /usr/lib/libwayland-egl.so.1 Dec 05 15:56:16 wayland: /usr/lib/libwayland-egl.so.1.0.0 Dec 05 15:56:43 looks like your driver conflicts with upstream wayland Dec 05 15:56:53 so you'll need to figure out what bit of the bsp is broken Dec 05 15:57:10 should the driver not be shipping that? should the bsp be removing those bits from wayland? Dec 05 15:58:56 it only says it's coming from the wayland package. Dec 05 16:00:03 Do I even need the wayland package? I'm planning on running chromium-x11, so would the easiest thing to do be remove wayland from my distro_features? Dec 05 16:00:15 that is certainly one option Dec 05 16:00:37 (this is why building your own distro is a good idea: poky turns a fair amount of stuff on for testing) Dec 05 16:00:52 Maybe that's really what I should be doing then. Dec 05 16:00:56 cp poky.conf mydistro.conf, and delete anything you don't want Dec 05 16:01:05 its definitely what you should be doing Dec 05 16:01:16 Alright, I'll start down that path. Thanks for the input. Dec 05 16:01:21 maybe we should have called the poky distro file example.conf Dec 05 16:01:29 dontusethis.conf Dec 05 16:03:33 Since yocto supports having no pkg manager on target, does yocto/bitbake have any functions for collecting an additional set of packages into a .tar.xz or similar for deployment to target? Making an arbitrary image is of course easy, but I'm thinking of an image containing only additional packages to a base image Dec 05 16:08:01 adelcast: any chance of a opkg-utils release soon? Dec 05 16:08:16 adelcast: also we're carrying a patch to change the #! to python3, would you accept that? Dec 05 16:10:19 rburton: yes, I plan to release opkg and opkg-utils, version 0.4 on December 15 Dec 05 16:10:55 around the same time I was planning on creating the recipes Dec 05 16:11:45 we still carry an ugly patch for tar Dec 05 16:14:32 yikes, yeah, that's pretty ugly...its a copy of the one used by dpkg Dec 05 16:15:06 problem being we'll hard-link the package tree for each packaging class, so they'll be running in parallel Dec 05 16:16:49 so, while opkg-build is running we change the build directory links? Dec 05 16:16:55 not sure about the new compressorargs logic in opkg-build. imo, things like -nT to gzip should be handled for you as that's universally good behaviour Dec 05 16:17:14 yeah, opkg-build could be running when do_package_rpm starts and does a hardlink farm of the package tree Dec 05 16:18:11 I see...then its pretty OE specific Dec 05 16:19:24 * rburton looks at the class and wonders if his knowledge is wrong Dec 05 16:21:32 regarding -nT, we could add it as a part of the default options since yeah, the option makes sense. I still want to leave compressorargs since others may want to customize the call with other flafs Dec 05 16:21:36 flags Dec 05 16:22:07 yes, i'm looking at this because i wanted to control how much parallelism xz used Dec 05 16:22:37 as lame people with lame amounts of memory are lamely complaining that do_package_ipk can kill their machine by eating all the ram Dec 05 16:23:00 hehe Dec 05 16:23:27 oh the target of my troll isn't even in this channel :) Dec 05 16:32:30 hm, the patch that was in dpkg has been lost Dec 05 16:32:31 claims to be upstream but it's not Dec 05 16:32:37 rburton, doesn't everyone have at least 128 GB of ram, and 64 cores?! Dec 05 16:32:46 fray: apparently some people do builds on laptops! Dec 05 16:32:47 madness Dec 05 16:33:13 definitely madness.. 256 GB of ram and 96 cores works for me.. Dec 05 16:37:00 adelcast: so dpkg appears to effectively do a find and then tell tar that file list Dec 05 16:37:16 which i have a hunch means the count thing changing isn't an issue Dec 05 16:38:44 some of us are stuck with a IT provided server that MUST RUN VM. Thats even more madness than laptops. Dec 05 16:39:32 Or more specifically, my decent i7 laptop is comparable on compile times as the server... Dec 05 16:39:56 adelcast: that might be a better solution. just tar -T, basically Dec 05 16:41:13 interesting...yeah, the patch is gone Dec 05 16:41:25 Our IT want to outsource building to the cloud, Azure specifically, and have challenged our Yocto team to get it up and running.... and are set back when I say how much tmp disk and memory is needed Dec 05 16:41:44 ok, I can take a look to do something similar before 0.4 Dec 05 16:42:06 sveinse: using rm_work will save you a load of disk space Dec 05 16:42:35 the time overhead is pretty much insignificant Dec 05 16:43:04 rburton: yeah sure. And its tmp, so the transferrable file artifacts is much much less than that Dec 05 16:43:21 I'll look to drop that patch, then I'll also add -nT as a default, I agree its sane to be on the list of recommended defaults, if someone doesn't like it, they can still use compressorargs Dec 05 16:44:57 adelcast: yeah, ideally the class passes "use threads" but then users can tweak if it required Dec 05 16:45:02 adelcast: thanks Dec 05 16:46:04 right, and for opkg-build use outside OE, still make sense to use as much as you can Dec 05 16:46:11 np Dec 05 16:51:42 sveinse: with rm_work its also about removing IO load Dec 05 16:57:03 have a big enough commit timeout and you'll be deleting stuff before its on disk Dec 05 16:59:47 or build in tmpfs to make sure that it won't even try to hit disk Dec 05 17:01:14 but even with tmpfs I'm waiting for the build to finish for last 4 hours.. Dec 05 17:30:33 New news from stackoverflow: When using the meta-updater layer dtoverlays will not work Dec 05 18:30:43 New news from stackoverflow: Is it possible to use Embedded OS prepared for i.MX6solo over i.MX6UL...? Dec 05 19:16:31 haven't seen the stackoverflow bot, that's super cool Dec 05 19:31:20 adelcast, It has been around a while :) Dec 05 19:31:35 yeah this is for oldies like us of the project who just dont look at anything besides IRC Dec 05 19:31:59 I believe we are called "coumudgeons" Dec 05 19:32:30 any term you come up with will have negative connotations in my mind Dec 05 19:33:20 :), I think we should adopt modern communication methods Dec 05 19:33:40 like have a discussion over twitter threads :) Dec 05 19:34:07 make patch as a facebook post Dec 05 19:34:17 hehehe, yes, a while back I used to check for opkg questions on stackoverflow, but wouldn't check it very often Dec 05 19:34:50 adelcast, I think you ca set up notification Dec 05 19:35:14 yeah, love those technical twitter discussion getting to the bottom of it in < 280 characters Dec 05 19:41:29 khem: hahaha Dec 05 21:17:35 khem: speak for yourself, we're not all 'oldies' :) Dec 05 21:19:46 RP: oldies in technological age Dec 05 21:20:15 fact is you are included however you dissect the pie :) Dec 05 21:24:17 when building the cross-tools is there a way to include specific development libraries, e.g., sqlite? Dec 05 21:25:25 libraries for what target ? cross, native, target ? Dec 05 21:26:34 i want to cross-build an app under x86 linux that targets my freescale i.mx6 arm Dec 05 21:27:05 and be able to cross-link that app with sqlite Dec 05 21:29:20 am i not being clear? Dec 05 21:29:21 yes, DEPENDS += "sqlite3" in recipe will help Dec 05 21:29:43 cross-link ? Dec 05 21:30:02 what does cross link mean here ? Dec 05 21:30:36 link (as in ld or g++) on one machine for which the output is targetting another machine Dec 05 21:31:05 but i don't mean via bitbaking a recipe. Dec 05 21:31:39 the app i'm building may not even have a recipe Dec 05 21:31:55 i just want to build it, on my x86, for the arm, e.g., using my own makefile etc. Dec 05 21:32:42 actually we already have a cross-development toolchain, but it lacks some of the libraries we use Dec 05 21:34:49 i can build one application 4 different ways: 1) on the x86 linux targeting the x86, 2) on the x86 linux desktop targeting the arm, 3) on the arm targetting the arm (native), or 4) bitbaking in yocto Dec 05 21:34:55 khem: sad but true in those terms Dec 05 21:35:18 khem: I can be in denial though ;-) Dec 05 21:36:51 khem: what was the conclusion on the waf patch btw? Dec 05 21:38:17 khem: i think i am referring to the ADP: https://www.yoctoproject.org/docs/1.6.1/adt-manual/adt-manual.html#the-cross-development-toolchain Dec 05 21:38:22 ADT Dec 05 21:39:12 i didn't build the toolchain, so I'm not sure how it was done. Dec 05 21:46:08 RP: waf is good to go, I fixed the offending recipe Dec 05 21:46:48 RP: I think the number of recipes which needs to be forwarded ported for this change in waf is not many Dec 05 21:47:47 yates: OK, so as I understand you want to link your app with sqlite3 so you need sqlite3 on target along with app righ t? Dec 05 21:48:28 yates: its possible that your SDK does not include sqlite3 so you have to rebuild your SDK to include sqlite3 in SDK Dec 05 21:48:36 other better option is to use eSDK Dec 05 21:49:00 where you dont need to do much accept adding DEPENDS += "sqlite3" in your app recipe Dec 05 21:57:34 khem: thanks, will merge then Dec 05 22:39:34 JPEW: FWIW I put a subset of your patches into -next and builds were fine Dec 05 22:39:51 JPEW: I didn't include the fork one Dec 05 23:05:40 don't you mean hug? Dec 05 23:27:10 yates: sound a lot like you just want to build a new toolchain. if you've an image that you want to be able to compile for outside of yocto, then bitbake myimage -c populate_sdk Dec 05 23:27:32 some people still ship the tarball built by the meta-toolchain recipe, but that's basically just the compiler Dec 05 23:27:39 so of limited use Dec 06 01:39:22 How can I change the compilation optimization option of a package? say for example, opencv Dec 06 01:39:35 I would like to use -Ofast Dec 06 01:39:42 or -O3 **** ENDING LOGGING AT Thu Dec 06 03:00:01 2018