**** BEGIN LOGGING AT Thu Mar 10 02:59:58 2016 Mar 10 11:48:23 epic: http://www.oeclassic.com/ Mar 10 11:49:21 hi all Mar 10 11:49:41 is it safe to build core-mage-weston when we have X11 in distro features Mar 10 11:50:34 Noor: i guess it won't hurt you physically, e.g. i'd call it safe. Mar 10 11:51:42 doesn't recipe will be build with x11 configurations Mar 10 11:51:52 LetoThe2nd: ^ Mar 10 11:54:33 Noor: yes Mar 10 11:54:49 as in, you can build -weston with x11 distro feature Mar 10 11:55:04 obviously it won't have x11 in as you built an image with weston in Mar 10 12:04:05 RDEPENDS are package names and there is no automatic building of th erecipe that creates those packages? Mar 10 12:04:13 asking for a friend Mar 10 12:05:43 Crofton|work: it will build required providers for those packages Mar 10 12:05:47 or fail trying Mar 10 12:05:50 heh Mar 10 12:05:57 ok, I can never remeber Mar 10 12:30:08 JaMa: oh no...linux-yocto again :/ Mar 10 12:30:28 funny it breaks on x86 Mar 10 12:33:15 JaMa: fwiw I could lead Bruce to repeat a build failure of linux-yocto enabling rm_work Mar 10 12:33:42 Hello all. Is there a way to convert a variable's expansion to uppercase letters? My use case is that some of my recipes have upper-case letters in them, but to appease the packager, I have to make the recipe known using lower-case letters. Towards the end of the installation though, I need to call some scripts in the resulting installation folders which are upper-case versions of ${PN}. Mar 10 12:37:46 beat sense inot upstream sources? Mar 10 12:38:02 I think I've seen people use sed in cases like this Mar 10 12:38:10 but I can't recall where Mar 10 12:43:29 eengie: why not rename the recipes? Mar 10 12:43:45 eengie: IIRC there is even sanity check for them now to force them to be all lowercase Mar 10 12:43:46 JaMa: Because the packager pukes on the upper-case letters. Mar 10 12:44:07 HMM 13:46:29 < JaMa> eengie: why not rename the recipes? TO BE LOWERCASE? Mar 10 12:44:31 ant_work: I'm tempted to drop meta-initramfs from world build Mar 10 12:44:40 JaMa: Exactly. I've made the recipe lower-case letters, but the code that is being compiled is written to install itself into upper-case directories. Mar 10 12:44:51 JaMa; that was oe-core, not meta-initramfs :) Mar 10 12:45:16 ant_work: are you sure it's not caused by the kexecboot bits? Mar 10 12:45:17 I have a similar issue with uhd source tarballs using underscores in the version name Mar 10 12:45:17 JaMa: post-install, I need to call some scripts in those upper-case directories, so I'm looking for a way to convert ${PN} to upper-case so that I can make a generic class handling this post-install routine. Mar 10 12:45:18 madness Mar 10 12:46:13 JaMa: I don't think so, I guess something is not staged right aftern wiping tmpdir Mar 10 12:46:35 eengie: so your packagemanager has issues with uppercase letters in directory names not package names? Mar 10 12:46:40 CroftonIwork: I feel your pain. I'm actually using uhd right now with a REDHAWK Device that installs itself as USRP_UHD. Mar 10 12:47:40 JaMa: no, it's having issues with upper-case letters in the package names, hence I renamed my recipes so that the packages would be lower-case letters. The issue is that now ${PN} is lower-case, but for the sake of writing a generic class to handle this type of recipe, I need to convert ${PN} to uppercase. Mar 10 12:48:28 JaMa: anyway it can be something happening during concurrent build of linux-yocto and linux-yocto-tiny-kexecboot Mar 10 12:49:21 I usually got failure in do_kernel_metadata but Bruce got lately an error during do_kernel_checkout Mar 10 12:49:35 imagine... Mar 10 12:50:29 unfortunately linux-yocto had weekly changes lately, I hope to be able to debug in the next days when commits will stop Mar 10 12:51:19 neverthless it is rare that your autobuilder registered failures for qemux86 only Mar 10 12:51:40 I'd expect all archs to fail Mar 10 12:56:34 JaMa: probably the key is, linux-yocto-tiny contains Mar 10 12:56:34 COMPATIBLE_MACHINE = "(qemux86)" Mar 10 13:04:00 sometimes it's qemux86-64 as well Mar 10 13:04:14 see http://www.openembedded.org/wiki/Bitbake_World_Status Mar 10 13:04:38 it's almost always there for one of qemux86* or both Mar 10 13:06:19 and yes the COMPATIBLE_MACHINE contains the breakage only for x86* Mar 10 13:07:58 JaMa: that recipe was meant to be used with specific .bbappend in the bsp layer, not by qemu directly Mar 10 13:08:25 if it does indeed harm I will happily collapse it in meta-handheld Mar 10 13:08:41 let see what me and Bruce sort out Mar 10 13:10:00 ok thanks Mar 10 13:10:50 JaMa: besides that, in meta handheld I had to revert back to plain linux-yocto & defconfigs, back to popular demand (the few kernel devs didn't want to learn that) Mar 10 13:11:03 err.. plain linux-kexecboot :) Mar 10 13:13:53 ant_work: https://github.com/shr-project/jenkins-jobs/commit/c168b7824c2c68bd5894532fc122929d2d9df9a7 Mar 10 13:14:55 right Mar 10 13:14:59 ant_work: I've already dropped meta-handheld from world buidls a while ago Mar 10 13:15:12 oh, that build just fine Mar 10 13:15:36 if you still care about those MACHINEs then you should check thread about thumb1 in oe-core ML Mar 10 13:16:00 anyway, I hope to be wrong but I suspect the underlying issue might be that, as it is now, it is impossible to build two different kernels Mar 10 13:16:26 yes, e.g. linux-yocto-rt is blacklisted unless specified in PREFERRED_PROVIDER Mar 10 13:16:32 I've seen, we have all on arm iirc. I built armv5 last night Mar 10 13:16:35 unfortunately we cannot do the same for tiny-kexecboot Mar 10 13:16:50 as people using that will expect 2 separate kernels to be built Mar 10 13:17:48 fwiw I do build linux-handheld_4.4 and linux-kexecboot_3.2 right now (meta-handheld) Mar 10 13:18:16 but don't try with one -yocto Mar 10 13:18:54 hmm my buildhistory is quite big Mar 10 13:18:56 Receiving objects: 0% (44126/16145615), 5.86 MiB | 280.00 KiB/s Mar 10 13:20:13 github doesn't like that Mar 10 13:57:10 JaMa: my repo is 4.6gb, how big is yours? :) Mar 10 13:59:43 Is there a way to re-use a file (like a patch, etc.) between recipes? Mar 10 14:03:36 put the recipes in the same folder and have FILESEXTRAPATH search the same folder? Mar 10 14:03:45 rburton: this one is around 4GB (new clone around 2GB) Mar 10 14:03:56 rburton: the busy one has 17GB Mar 10 14:04:02 luckily not hosted on github Mar 10 14:04:45 JaMa: i suspected your busy machines would have a somewhat hefty buildhistory! Mar 10 14:05:10 eengie: two recipes in the same directory will share a files/ or ${PN}/ folder for patches Mar 10 14:05:20 and I have couple cron jobs prunning older branches and running git gc on it every week :) Mar 10 14:06:13 CroftonIwork: Something like /recipes-top which contains ./first ./second, etc. as well as a ./files, then use FILESEXTRAPATHS_append+="${THISDIR}/../files" in the "first" and "second" recipes? Mar 10 14:07:30 that would work if it would be madness to put the first.bb and second.bb into the same directory Mar 10 14:08:41 Well first and second are otherwise independent products. It just happens that their init script (in this case) can be made generic enough to be shared between the recipes. The other patches, etc., are very specific to the build environments of first and second, if that makes sense. Mar 10 14:09:01 So rather than have a folder full of patches all mixed together for first and second, I was trying to keep them neatly separate. Mar 10 14:12:12 CroftonIwork: Thanks for the suggestion! Mar 10 16:13:54 So does anyone have any ideas/opinions on whether wic should support Flattened Image Trees? curious if I should look into implementing it in wic or as a seperate piece of the build process. Mar 10 16:33:40 hmm Mar 10 16:33:53 isn't there a fit-image bbclass Mar 10 16:34:15 seems like the kernel recipe should make the appropraites fitimage, then tell wic where to put it? Mar 10 16:35:08 and a good question for the architecture list :) Mar 10 16:48:48 Crofton|work: there is a fit-image class, but it can only currently handle kernel, dtb, rootfs. I will post a query to the oe-architecture list with some better details :) Mar 10 16:49:43 I assume you can have an fpga image payload? Mar 10 16:50:02 Crofton|work: not yet but that is the idea yep Mar 10 16:51:03 also u-boot scripts, specific configuration names, re-writing dtb chosen properties (via a source plugin for example), etc. Mar 10 17:04:34 nrossi, outside of oe you can stick fpga in there as 'firmware' **** ENDING LOGGING AT Thu Mar 10 17:12:40 2016 **** BEGIN LOGGING AT Thu Mar 10 17:14:17 2016 Mar 10 17:25:13 any good examples of recipes that install init.d scripts and systemd and select between them? Mar 10 17:25:51 select? install both, inherit both classes, let the classes to their job Mar 10 17:26:50 heh Mar 10 17:26:53 oh, does that actually work? nice Mar 10 17:26:55 you trsust classes? Mar 10 17:27:09 WE'LL NO SOON ENOUGH :) Mar 10 17:27:13 oops :) Mar 10 17:27:57 I have systemd setup now and still installing the init script Mar 10 17:29:47 if you have a init script installed but no sysvinit in distro features then they'll be deleted Mar 10 17:30:25 just remember to ensure the units and the init scripts have the same basename so if you have sysv+systemd features enabled - and so both scripts in the image - systemd doesn't run both Mar 10 18:11:45 rburton, bencoh seems to ahve down the right thing at least for systemd case **** BEGIN LOGGING AT Thu Mar 10 22:35:18 2016 Mar 10 23:15:42 how does one modify the system.conf in systemd recipe / bbappend? Mar 10 23:25:06 patching system.conf in a bbappend? Mar 10 23:47:24 fischerm: I think so yes Mar 10 23:47:47 fischerm: probably easier to just replace it rather than patching it Mar 10 23:48:05 hrm **** ENDING LOGGING AT Fri Mar 11 02:59:58 2016