**** BEGIN LOGGING AT Thu Mar 22 03:00:03 2018 **** BEGIN LOGGING AT Thu Mar 22 03:33:06 2018 Mar 22 06:39:45 Hi Guys, has any one got icecc working with poky 2.4.2? Mar 22 06:40:27 I've got cluster with ~100 cores and im pretty keen on using it if possible Mar 22 08:59:28 Hi all, i would like to know what is the best way to disable kernel driver autoloading in yocto ? module_autoload_mymod -= "mymod" doesn't work :( Mar 22 10:10:13 pinksnake KERNEL_MODULE_AUTOLOAD_remove = "mymod" Mar 22 10:31:17 @nayfe thx for tips i'm going to try :) Mar 22 10:40:16 @nayfe it's building, little question : is it alos possible to use module_conf_mymodule = "blacklist mymodule" ? Mar 22 10:44:40 pinksnake: don't know, maybe read https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#migration-1.7-kernel-module-autoloading Mar 22 10:48:40 @nayfe yes my question is based on that ;) thx for answer Mar 22 10:56:39 pinksnake: i think best is to update Yocto version but just in case, some hints here https://www.yoctoproject.org/irc/%23yocto.2014-04-10.log.html Mar 22 11:38:52 rburton: for the records, after the qemu tweaks you suggested, build time decreased by ~2m20 Mar 22 11:38:58 rburton: thanks for the suggestions Mar 22 11:39:34 lucaceresoli: of couse qemu-native should only rarely be rebuilt so its quite a niche optimisation Mar 22 11:40:37 rburton: it's built 3 times per day on our CI server ;) Mar 22 11:40:45 lucaceresoli: why don't you use sstate? Mar 22 11:40:46 rburton: but who cares, it's done overnight! Mar 22 11:41:31 rburton: of course I use sstate for regular development, but for CI we want to have something rebuilt from zero Mar 22 11:41:44 ouch, that's a slow CI cyce Mar 22 11:43:03 rburton: we also have a hourly CI job that uses sstate and takes minutes. OTOH the nightly is a wipe-all-and-rebuild-all thing. Mar 22 11:43:21 fair enough Mar 22 11:46:21 Are there any (defacto) pratices regarding layer priority values? Mar 22 13:25:47 Hi, i add "cups" package to configure a printer in yocto. After starting kernel, i don't have cups as a service on my embedded device. i read the content of cups recipe (https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-extended/cups/cups.inc) a,d i see in the do_install task that if we are not using sysvint it remove the script. but i use systinit on my distro and i verify in my bitbake environment variable which contains Mar 22 13:26:06 how can i avtivate the cups service? Mar 22 14:20:20 New news from stackoverflow: Installing cups on embedded linux using yocto Mar 22 15:20:33 New news from stackoverflow: do_compile error while running bitbake on poky Mar 22 16:01:46 vladzouth: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#new-recipe-enabling-system-services Mar 22 16:31:38 Hello all! What is the proper etiquette for asking questions about here? Mar 22 16:32:44 Eternal_Intern: ask them Mar 22 16:35:21 I'm having trouble using the Wic tools to create a partitioned image that can run on my QEMU. I provide a kickstart file and specify "wic" and "wic.vmdk" in the image recipe, and am able to successfully build the images. The "ext4" version runs fine, but the "wic" or "wic.vmdk" version both give "attempting to execute out of memory" errors. I've checked that it's running the correct machine (ARM), so it might be an issue with Mar 22 16:36:44 Has anyone here created a partitioned image with Wic that they can run on their QEMU instead of using a .direct file to write to an external device? Mar 22 16:44:47 I inserted intentional errors into the "rootfs" and "bootimg-pcbios" plugins to try and force it to fail uding "do_image_wic" during the bitbake process, but the failures never happened when placed in the actual "do_install_disks" or "do_prepare_partition" functions, so maybe those aren't ever being called for some reason? Mar 22 17:35:39 I have a native tool recipe that ouptuts a file that errors with "accessing a corrupted shared library" Mar 22 17:36:38 The executable works fine in the image output folder, but after it's copied over to recipe-sysroot-native, it no longer works Mar 22 17:36:52 otavio: you are *so* replying to the [meta-chicken] post on oe-core@ Mar 22 17:44:30 It seems to me that something is happening in the do_populate_sysroot that is breaking the executable. I tried setting the INHIBIT_PACKAGE_STRIP flag, but that didn't help Mar 22 17:45:07 nathani_: that inhibits stripping for the binary packages, you want INHIBIT_SYSROOT_STRIP to test instead Mar 22 17:45:22 of course natives aren't packaged, so the other var probably didn't change anything Mar 22 17:59:48 kergoth: First of all, thanks for responding. Perhaps I am misunderstanding the order of operations. Without the flag I have correct files in ./build and ./image, but broken files in ./sysroot-destdir Mar 22 18:00:11 with the INHIBIT_SYSROOT_STRIP set, I have working file in ./build, but the others are now broken Mar 22 18:00:48 sounds like it isn't the split that's the problem, in that case Mar 22 18:01:36 indeed, do you have any pointers of where to look next, I am unfamiliar with this error, and google isn't providing much insight Mar 22 18:04:14 "Accessing a corrupted shared library" Mar 22 18:39:54 sorry to say i can't say i've ever run into that one. afaik only the stripping and then debug splitting processes really modify the elf binaries, and i don't know if the latter even occurs for native recipes.. Mar 22 18:54:54 rburton RP1 , i launched a Rocko build. you can kill it you need the AB Mar 22 18:55:39 * armpit what came first, meta-chicken or meta-egg ? Mar 22 19:12:40 armpit: good question! Mar 22 19:35:39 rburton: I think you got it right; the end user was using the wrong package Mar 22 19:35:53 rburton: meta-chicken has not been updated to RSS Mar 22 22:16:52 kergoth: Hello, man! I finally finished working the meta-external-toolchain. tested it with external and internally built ones. got SDK working with my toolchain. As promised here is the repo: Mar 22 22:16:52 https://github.com/fancer/meta-external-toolchain Mar 22 22:18:09 I made it public, so you can freely download it from there. Could you test it with your toolchain, since I've introduced some alterations in the files set there? Mar 22 22:19:13 It shouldn't break your setup, but just to make sure it's better test it. Mar 22 22:19:41 fancer: congrats, yeah, i'll review and test on my end Mar 22 22:19:55 If you get any question about the changes, just ask them either here or right on the commit Mar 22 22:20:03 at the github page Mar 22 22:20:08 thanks.) Mar 22 22:24:56 will do. no problem, thanks for your work on this, both for the work itself and the motivation for me to help support it. been on the back burner for a while now Mar 22 22:28:26 Always welcome. It would be great to merge our changes, so they would at least work for both of our toolchains. Mar 22 22:30:12 yep, that's the plan, meta-external-toolchain should provide as generic and functional an implementation as possible, so the only thing that has to be maintained in separate layers above that is workarounds and the like for specifics Mar 22 22:32:31 So if you in doubt of changes I've made, just ask. I am not a pro of python and yocto, so some of my solutions might not be that optimized.) Mar 22 22:34:26 Regarding the generic part. I suppose it's very hard to reach, since all the toolchains can be configured in a many variaty of ways. Mar 22 22:36:36 Although, I discovered a thing, which might help to at least minimize the search paths. gcc got a special key: -print-search-dirs. So together with -print-sysroot they can be used to at cover all the necessary paths in the external-toolchain layer. Mar 22 22:38:08 yeah, i've thought about that, it's a good idea. someday i want to try to extract info about the external multilib configuration to either adjust or compare to the yocto multilib configuration, too. and also potentially use the search path info to make sure dirs like libdir/etc are set the same as the external toolchain, to avoid issues like glibc looking for locales in the wrong place Mar 22 22:38:21 low priority, though Mar 22 22:40:44 yeah, same here. My next task is to create a custom binary image generator in yocto. Already found a template in the oe-core. Mar 22 23:03:33 fancer: ah, glibc-external-locale simplifies matters since we aren't pointlessly copying the files into the internal sysroot path first, eh? Mar 22 23:04:26 yeah, it does a bit.) Mar 22 23:05:57 Although I couldn't generate the locales using qemu, only by localedef-cross. Mar 22 23:06:29 the qemu based approach obviously requires that the qemu user mode args are defined for the machine in question, which isn't always the case Mar 22 23:06:32 i got error like: kernel is too old. somethin.) Mar 22 23:07:21 yeah, I haven't tested it, so it was not surprising when it dumped the error.) Mar 22 23:07:46 One more thing about the localedef-cross. Mar 22 23:08:09 It fails to compile the old locale files like ones in my glibc Mar 22 23:08:28 the change sseem sane for the most part. i'm assuming you fleshed out the files in libc.headers to grab individual files rather than subdirs to avoid conflicts betwen linux-libc-headers and glibc? i actually intentionally left out linux-libc-headers, as overriding it is almost always wrong, and is always recommended against by the community. meta-sourcery has it, though, since people insist on asking for it anyway, not knowing any better Mar 22 23:08:39 s/change sse/changes se/ Mar 22 23:09:41 i'll see about breaking these up into individual commits with you set as the commit author and include both our signoffs, if that's okay with you. i see this being 5-10 commits once broken up by logical change Mar 22 23:11:29 I dumped all the header files from my kernel (4.4.10), since it easier. Then moved them from the lib directory and got fresh set of glibc headers mixed with some small number of ncurses files. Mar 22 23:11:54 linux-libc-headers got one mixed directory with glibc Mar 22 23:12:03 it's usr/include/scsi Mar 22 23:12:14 ah Mar 22 23:12:20 Some file there belong to glibc, some of them are from linux Mar 22 23:13:16 I'm torn between what's The Right Thing and what's practical when it comes to linux-libc-headers. The main reason to split them out is to allow the user to switch to a different set of linux libc headers, which they shoudln't be doing anyway.. Mar 22 23:13:39 Regarding the commits and authorship. Fine with me. Mar 22 23:14:29 k, thanks. i'll first verify it doesn't cause problems with the sourcery toolchain on my end, then will work on rebasing and breaking up the changes Mar 22 23:14:32 Yeah, I've split it since, it is a logical recipe. And some other recipes DEPEND of it direcly. Mar 22 23:15:10 glibc ends up packaging and including those files, the oe-core recipe only provides them to glibc, so keeping it combined makes sense from a packaging perspective Mar 22 23:15:26 it's debatable. i'll leave off merging that until the rest is sorted Mar 22 23:15:34 ok Mar 22 23:19:22 hmm, the extraction of ct-ng metadata, i.e. in strace-external, could probably be done in a more generic way, and override the versions of all the packages based on it. i.e. create a tcmode-crosstool-ng and write an event handler to extract all the versioning info up front and then in the tcmode set the versions with recipe overrides Mar 22 23:20:40 yeah. I forgot about the strace at all.) Mar 22 23:21:37 might add an example of how to do that in the layer, since making use of available metadata that was shipped with the external toolchain sounds like a somewhat common thing to want/need to do Mar 22 23:23:05 yeah, it would be good to have it there as an example. It don't have much free time left for new updates. Mar 22 23:23:11 * kergoth nods Mar 22 23:26:15 I unpicked the rest of the packages from glibc, so there wouldn't be perl runtime dependency just due to one small glibc-mtrace script. Mar 22 23:27:26 ah, makes sense Mar 22 23:27:34 thanks for the background, that helps Mar 22 23:27:55 If user need glibc-mtrace, then one should state it explicitly and get the perl built as well. Mar 22 23:27:56 ok Mar 22 23:28:03 Unrelated: https://github.com/MentorEmbedded/meta-mentor/commit/1090dff7 - anyone have any thoughts on this, conceptually? Mar 22 23:28:37 kergoth: is there an easy way to use shallow clone just for one recipe ? Mar 22 23:28:42 kergoth: e.g. gcc Mar 22 23:29:27 currently we don't support shallow clones at all, only shallow mirrors, as clone —depth= isn't usable unlses we know the distance between branch HEAD and SRCREV, or unless SRCREV is AUTOREV. but yes, that support can be controlled per recipe Mar 22 23:30:37 though i suppose one could add a new variable to allow use of clone with —shallow-since= instead, since that wouldn't move when HEAD changes Mar 22 23:30:50 assuming one has a git that has that, anyway Mar 22 23:31:04 the bitbake commits on shallow have the details on the variables available and their semantics and syntax Mar 22 23:31:12 yeah --shallow-since is exactly what would be good in my case Mar 22 23:32:29 probably a worthwhile enhancement to git.py all around, i'd suggest opening a tracking issue for that feature Mar 23 02:52:50 New news from stackoverflow: unable to launch weston on linux yocto from ssh **** ENDING LOGGING AT Fri Mar 23 03:00:03 2018