**** BEGIN LOGGING AT Tue Dec 04 03:00:16 2018 Dec 04 12:33:21 Hi All, I have machine configuration set in my local.conf as *MACHINE="colibri-imx7"* and I want to compile the same build tree for *colibri-imx6*, so I have used *MACHINE="colibri-imx6 bitbake core-image-minimal*. I have some custom recipes with *file://* referring the local path with *files//*. In this case, bitbake fetch2 still uses *MACHINE* from local.conf instead of the environment/CLI. Should fetch2 refer environment variable or Dec 04 12:33:21 local.conf overrides it? Dec 04 12:48:34 pn, use #MACHINE ?= Dec 04 12:48:42 in local.conf Dec 04 12:48:59 see examples Dec 04 12:49:57 ant_home: No, I have used MACHINE = "colibri-imx7" in local.conf. Dec 04 12:50:08 then it wins Dec 04 12:50:16 use ?= Dec 04 12:50:52 and even, from local.comf Dec 04 12:50:53 # This sets the default machine to be qemux86 if no other machine is selected: Dec 04 12:50:53 #MACHINE ??= "qemuppc" Dec 04 12:51:11 you see? ?= or ??= Dec 04 12:51:12 ant_home: got it. Thanks. Do you mind sharing the difference between ?= and ??= Dec 04 12:51:32 yw Dec 04 12:51:33 one needs more memory to store an additional "?" Dec 04 12:51:38 Dec 04 12:52:06 I never give MAHINE as arg Dec 04 12:52:15 personal choices ;) Dec 04 12:53:44 pn: https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#setting-a-default-value Dec 04 12:54:19 pn: https://www.yoctoproject.org/docs/2.5/bitbake-user-manual/bitbake-user-manual.html#setting-a-default-value Dec 04 12:54:25 ^ 2.5 is newer Dec 04 12:54:53 heh, google always gives me the old link Dec 04 12:55:38 ant_home Thanks Dec 04 13:00:03 after years we got good docs :) Dec 04 13:00:29 worth a read Dec 04 13:05:13 hello, I am trying to submit my mksh recipe to meta-openembedded. As far as I understand subscribing to the openembedded-devel mailing list and posting a patch there should be enough? Dec 04 13:05:27 eduardas_m: yep Dec 04 13:06:44 LetoThe2nd: I did a git send-email 0001-Add-MirBSD-Korn-Shell-recipe.patch --to=openembedded-devel@lists.openembedded.org , but patch did not appear on the list... how long does it take to process? Dec 04 13:07:12 I thought perhaps there are some special condictions or I am just doing it completely wrong Dec 04 13:07:56 eduardas_m: AFAIK first-time posters must be acked manually, but that might be also wrong Dec 04 13:08:02 posting a patch to the toybox mailing list is almost instantaneous in my experience so I expected this to be similar Dec 04 13:08:21 LetoThe2nd: yeah, I am a first-time poster Dec 04 13:08:47 LetoThe2nd: who is responsible for the ACKing? Dec 04 13:31:01 well, I have abued enough of the courtesy of tg, I'll give at least a build-test ;) Dec 04 13:31:26 just send th epatch with git Dec 04 13:31:43 (sorry for the typos, crappy bt kb) Dec 04 13:34:41 eduardas_m, the patch does appear on the ML as last msg Dec 04 13:35:38 ant_home: are tou the mailing list administrator? if no, who is then? Dec 04 13:36:12 someone actually authorized the post? it took 35 minutes from initial git send-email Dec 04 13:36:20 nope but the patch is there Dec 04 13:36:54 yes, I see... got a Thunderbird notification a second ago Dec 04 13:37:12 I see there isn't any Subject, nor Signed-off-by Dec 04 13:37:20 pls check the format Dec 04 13:37:39 as it is cannot be accepted w/out manual editing Dec 04 13:38:30 ant_home: I am new to this, so I hope people are at least a bit forgiving Dec 04 13:39:59 you started with the right foot with git-send-email ;) Dec 04 14:10:38 ant_home: I intend to fix the signed-off thing, add an "mksh:" prefix to the commit message and "meta-openembedded" to the e-mail subject, then re-submit Dec 04 14:10:52 ant_home: did I still overlook something? Dec 04 14:11:13 II do not believe this requires a PATCHv2 increment Dec 04 14:11:35 as the recipe itself did not change Dec 04 14:14:51 sorry, I can not test it right now Dec 04 14:15:05 but pls send a v2, v1 will be archived Dec 04 14:15:14 (marked as superseeded) Dec 04 14:15:36 you can do that: pls log in in patchwork Dec 04 14:18:16 ant_home: sent without the v2... hope this is still usable... if something is so wrong that the patch can not be used, I will fix it after feedback on the mailing list Dec 04 14:18:36 ant_home: read your comment after sending already Dec 04 14:19:07 ant_home: I am not aware what patchwork is or how it is used in an OE context Dec 04 14:19:10 np, just hide the first in patchwork Dec 04 14:19:32 (me later, you, someone) Dec 04 14:19:59 actually I cannot do it Dec 04 14:20:25 need an adm or the creator Dec 04 14:21:42 https://patchwork.openembedded.org/project/oe/patches/ Dec 04 14:22:05 this is what the poor adm whu pulls will see Dec 04 14:23:58 ant_home: what state do I change the old patch to? Dec 04 14:24:33 ant_home: Not Applicable? Dec 04 14:37:17 superseeded Dec 04 14:37:22 then archive Dec 04 14:38:52 ant_home: both at the same when updating patch status? Dec 04 14:39:43 yes Dec 04 14:40:25 ant_home: done, thank you a lot for guiding me through this Dec 04 14:40:31 yw Dec 04 15:29:16 does toybox in meta-openembedded have a designated maintainer? Dec 04 15:30:08 I have done some work to make the latest version (git master) work decently on the systems I work on Dec 04 15:30:32 do a git log on it and get an idea who cares Dec 04 15:30:38 would like to talk about upstreaming some changes and whether I do things appropriately Dec 04 15:33:15 Crofton: apparently, not so many people... I just thought the component might have a designated maintainer, but as far as I understand only Khem Raj has the responsibility to maintain everything under meta-oe? Dec 04 15:35:21 meta-oe is tragically undermanned all around Dec 04 15:35:38 and has been since its inception, really. nature of the beast, there's a lot of recipes in there :) Dec 04 15:36:32 he may actually use it Dec 04 15:36:57 he tends to fix compile fails Dec 04 15:37:41 eduardas_m, sounds like you are volunteering to keep track of toybox :) Dec 04 15:42:34 indeed Dec 04 15:43:43 Crofton: I actually would, the only problem is that my Linux experience is about two years and it would be difficult without consulting more experienced people Dec 04 15:44:22 eduardas_m: if you show interest and energy, we will make sure you get all the mentoring and assistance you need Dec 04 15:44:25 you care that is important, and you can ask questions and I'm sure khem will review the patches Dec 04 15:47:32 ok, will try to submit some slight changes first then... Dec 04 15:48:33 the thing that baffles me about toybox the most is this relatively recent patch for changing up paths: http://cgit.openembedded.org/meta-openembedded/commit/meta-oe/recipes-core/toybox?id=cdd3e9ab99d4ffda673b564ba802b6bd2d40eabf Dec 04 15:48:51 I kinda get by without such a fix Dec 04 15:49:05 using my own toybox recipe Dec 04 16:01:05 I have also asked toybox maintainer Rob Landley to make some minor changes in toybox for better compatibility with Yocto-based distros: https://github.com/landley/toybox/commit/3d4219014ae5f5a6553423994ff5ccd1d490a6fc Dec 04 16:01:17 https://github.com/landley/toybox/commit/42f8b18bc27b0143edee8fd598eee853d6ca47f9 Dec 04 16:02:14 at my workplace we also make use of toybox mdev implementation which currently is very limited and actually wrong and broken compared to the one of busybox Dec 04 16:02:41 currently looking at how to get that a tleast slightly fixed Dec 04 16:03:33 I would like to eventually see toybox supported in Yocto and OE just as well as busybox is Dec 04 16:05:37 really, a good mdev implementation is pretty much the missing piece for a good functional rootfs applicable to most usecases Dec 04 16:05:57 toybox init has pending status, but is actually good enough Dec 04 16:06:05 so is getty Dec 04 16:22:46 first change submitted... I do not know if it would be good to submit a huge radical recipe change right away? http://lists.openembedded.org/pipermail/openembedded-devel/2018-December/197773.html Dec 04 16:24:32 small steps are usually best Dec 04 16:27:07 just wondering, are other people using usrmerge actively for their distros? Dec 04 16:27:56 there might be some other recipes (besides toybox) that get broken with that enabled because they do not use variables and hardcode paths into recipes Dec 04 22:16:11 khem, hi Dec 04 22:16:53 about mips little endian, I used these to change qemumips Dec 04 22:17:10 for qemumips DEFAULTTUNE = "mips32r2el" Dec 04 22:17:25 for qemumips64 +DEFAULTTUNE = "mips64el" Dec 04 22:17:48 here any variant like mips64r6el gives packaging issues Dec 04 22:21:09 building kodi right now for "mips64el-oe-linux-musl" Dec 04 22:26:59 ouch Dec 04 22:27:02 ERROR: libdrm-2.4.96-r0 do_configure: meson failed Dec 04 22:27:14 | ERROR: Unknown CPU family 'mips64el' Dec 04 22:27:27 another bad recipe... Dec 04 22:28:46 I know I am on the dark side of the moon with mips 64b le Dec 04 22:35:29 yay, i finally have a (work) use case for this again... Dec 04 22:36:08 just not sure i have a happy dance for that right now Dec 04 22:37:34 oh yeah, i found it: https://www.i-programmer.info/programming/theory/3531-sorting-algorithms-as-dances.html Dec 04 22:38:00 * nerdboy does the bubble-sort dance Dec 04 22:42:45 doh ./build-aux/config.sub: | mips64 | mips64el \ Dec 04 22:42:51 wtf... Dec 04 22:45:37 ant_home: the meson thing is an easy fix in meson.bbclass Dec 04 22:46:22 I am learning all the new mips* variants listed in the config.guess :p Dec 04 22:47:21 it's evilish Dec 04 22:48:24 rburton, btw, your patch for multithreading xz on do_package_x regularly break my builds Dec 04 22:48:59 I give to tmpfs 80& of my 16GB ram and use rm_work but with 8 threads I risk Dec 04 22:48:59 ant_home: too much parallism? Dec 04 22:49:11 yes, each thread uses ram Dec 04 22:49:23 sounds like you need more ram! :) Dec 04 22:49:27 heh Dec 04 22:49:47 it did not happen before for normal images, now building beasts I often see OOM Dec 04 22:49:50 16gb with 80% for tmpfs doesn't leave you with a huge amount for actual use Dec 04 22:50:05 if you can replicate, try hacking it down to 8 and seeing if that solves it Dec 04 22:50:17 shouldn't be that tricky to make it respect BB_NUM_THREADS Dec 04 22:50:30 right but my left hand has the TV remote and the right one the beer so I dont waste CPU cycles :p Dec 04 22:50:37 hm no, 0 is 'number of cores', so that's the same thing Dec 04 22:50:51 strong priorities Dec 04 22:50:55 I have 8 threads Dec 04 22:51:07 4 cores + hyper Dec 04 22:51:08 back to 'get more ram' ;) Dec 04 22:51:19 heh, it's a Thinkpad...no way Dec 04 22:51:44 you really are limiting your system to 3gb if the tmpfs is filling up, which isn't a lot! Dec 04 22:51:45 I just blank your patch :D Dec 04 22:52:33 tmpfs /tmp tmpfs defaults,noatime,nodiratime,mode=1777,size=85% 0 0 Dec 04 22:52:53 TMPDIR is there Dec 04 22:52:55 ant_home: shouldn't be that hard to expose the threads count as an option in opkg-build, so then we can have a variable in package_ipk which defaults to 0 but you can change to eg 2 Dec 04 22:53:28 tmpfs on /data/poky-tmp type tmpfs (rw,relatime,size=31457280k,uid=1000,gid=1000) Dec 04 22:53:40 but MemTotal: 65914540 kB Dec 04 22:53:43 I tried to extend your patch adding an option to limit th eoptimization level (saves ram) but had unclear results Dec 04 22:53:55 it is o6 as default iirc Dec 04 22:53:57 well resetting it to 1 would effectively revert it Dec 04 22:54:10 pretty sure its 1 out of the box Dec 04 22:54:17 as the improvement from threading more was huge here Dec 04 22:54:36 - elif [ $compressor = "xz" ] ; then Dec 04 22:54:36 + elif [ $compressor = "xaz" ] ; then Dec 04 22:54:44 sorry Dec 04 22:55:01 * ant_home feels guilty Dec 04 22:55:23 it does speed-up the packaging of kernel modules, sure Dec 04 23:03:00 khem, heh, it is a can of worms...I fixed mason.bbclass and now Dec 04 23:03:00 | cat: /oe/meta-openembedded/meta-networking/recipes-support/libtalloc/../../files/waf-cross-answers/cross-answers-mips64el.txt: No such file or directory Dec 04 23:03:35 we lack an autobuilder :/ Dec 04 23:03:39 ant_home: meson is a new beast Dec 04 23:03:56 it is a one-liner Dec 04 23:04:01 and its written by gnome folks who know not much about cross compiling Dec 04 23:04:10 elif arch == 'mips64el': Dec 04 23:04:10 return 'mips64' Dec 04 23:04:32 like klibc it seems losing the endianess...but it is not Dec 04 23:05:20 now what is that .txt file... Dec 04 23:05:53 khem, about kodi textrel...I suspect it comes from ffmpeg Dec 04 23:06:03 which recipe masks the textrels... :) Dec 04 23:07:47 btw seems scanelf is not available for mips64? I installed pax-utils-native but is not in the dev shell Dec 04 23:08:46 acually I inbstalled -native as well, I'd need the -cross I bet Dec 04 23:18:50 khem, these libtalloc cross-answers are the same for mips and mipsel, I'll just copy mips64->mips64el Dec 04 23:20:49 yes, it did it Dec 04 23:56:01 khem, samba fails because cmocka.h redefines uintptr_t Dec 04 23:56:37 which guard to add? to build I just remove the block Dec 05 00:10:12 khem, in perspective we should log the compiler warning and output colored, like Gentoo Dec 05 00:10:29 did not know samba has so bad headers Dec 05 00:10:39 well, it's old Dec 05 00:11:24 it also saves time while tesing new flags Dec 05 00:11:47 *testing Dec 05 00:25:24 gn Dec 05 01:11:22 perils of working with another gentoo dev... arguments about using the Right Tool for embedded devices... Dec 05 01:14:16 heh Dec 05 01:14:41 and 'right' is a perspective Dec 05 02:21:45 lol Dec 05 02:55:30 hopefully i get to learn som new embedded tricks now... Dec 05 02:56:21 * nerdboy finishing his Year of x86 work Dec 05 02:57:12 well, "year without really touching embedded stuff" **** ENDING LOGGING AT Wed Dec 05 03:00:01 2018