**** BEGIN LOGGING AT Wed Apr 20 02:59:58 2016 Apr 20 03:22:01 hmm Apr 20 03:22:03 -ENOPIDGE Apr 20 03:22:05 -ENOSWOLD Apr 20 03:26:24 Folks around? Apr 20 03:26:59 I'm trying to bring XFCE back into a distro that has been gutted off its graphics stack Apr 20 03:27:24 I added meta-xfce to bblayers.conf Apr 20 03:27:34 I added meta-gnome to bblayers.conf Apr 20 03:27:48 I added xfdesktop to local.conf install packages and this is what I see Apr 20 03:27:50 ERROR: Nothing RPROVIDES 'xfdesktop' Apr 20 03:28:10 So my question now is: Is there a way to use bitbake to tell me what layers are missing? Apr 20 03:28:57 make sure your BBLAYERS is correct Apr 20 03:29:45 if meta-xfce was in bblayers, then xfdesktop would be available Apr 20 03:36:41 It is not Apr 20 03:37:25 And my suspicion is that meta-xfce requires something else that is blacklisted, but doesn't tell me what it is Apr 20 03:37:35 I mean it is :) Apr 20 03:37:37 sorry Apr 20 03:37:40 Reverse logic Apr 20 03:38:51 I wish every meta-layer would explicitly state what layers are required or derive this information from packages it depends on and state this information when you try to build to make it clear that is needed Apr 20 03:38:54 This is fucked up Apr 20 03:43:09 For every layer there should be requirements which other layers it depends upon to build stuff. Whether or not they are blacklisted should be stated and inform the user trying to build things that a package inside a layer can't be build and why Apr 20 03:44:10 ulf`: what exactly is it saying? beyond "Nothing RPROVIDES" Apr 20 03:44:21 kergoth, so back to my question. Is there a way to help me out and find out which layer is missing that results in bitbake claiming the xfdesktop recipe is not available? Apr 20 03:44:40 bluelightning, ERROR: Nothing RPROVIDES 'xfdesktop' (but /data/ostro-os/meta-ostro/recipes-image/images/ostro-image-noswupd.bb RDEPENDS on or otherwise requires it) Apr 20 03:44:40 ERROR: xfdesktop was skipped: not supported by ostro Apr 20 03:45:27 oh, well that's it then Apr 20 03:45:37 this isn't a case of a layer being missing Apr 20 03:45:56 Yes it's not supported Apr 20 03:46:01 But WHY is it not supported Apr 20 03:46:53 this will be whitelist.bbclass in action Apr 20 06:48:47 Hi Apr 20 06:50:18 good morning Apr 20 07:53:19 Hi everyone i build an image yocto for dart 6 ul and i want to boot on emmc, what can i do, how can i flash on emmmc Apr 20 08:24:06 Hey guys, is it possible to have an image that generates two images? one is the rootfs and another is a data parition that is mounted on rootfs? That data partition will have packages installed on it too. Apr 20 08:44:18 ftonello: you can have two images, one of which contains the other Apr 20 08:47:24 JaMa, I went further in the investigation and sent an email yesterday on the mailing list. Apr 20 08:48:06 JaMa, the problem might comes from Qt mainstream. Apr 20 09:33:35 hi .. i am using parts from meta-arago and put them in my own meta-layer to get my 3d hw support up .. but this solution ( from TI) uses its own libgbm , so i ve to "hack" this out of mesa.inc Apr 20 09:34:12 would it be now the best way to "overlay" mesa totally in my own meta-layer or is there any other way ? Apr 20 09:34:24 i basicly need a different mesa.inc Apr 20 09:34:57 do you need meta-arago's libgdm? Apr 20 09:35:35 you can remove mesa entirely, just set the preferred providers to point at something that isn't mesa Apr 20 09:36:26 basically if a bsp provides a gl stack then you don't need mesa Apr 20 09:37:26 ok , it felt that some other recipes did pull in mesa Apr 20 09:38:10 so ur saying that my PREFFERRED_PROVIDERS are missing some things to point yet again to my 3d instead of mesa .. Apr 20 09:38:13 will check thx Apr 20 09:40:39 PROVIDES = "virtual/libgl virtual/mesa" is what mesa.inc also sets .. so i should set a my 3d stuff to also provide virtual/mesa ? Apr 20 09:41:18 if it has the same api Apr 20 09:41:24 try and find out what is pulling in mesa Apr 20 09:41:30 ok thx Apr 20 09:41:33 nothing should be explicitly depending on mesa without very good reason Apr 20 09:41:38 virtual/libgl is "the GL api" Apr 20 09:41:49 virtual/mesa is "libgbm etc" Apr 20 09:42:26 ie mesa-gl is an alternative build of mesa that just builds the big-GL stack for people who really want it in software-only mode but have a BSP which only supports GLES Apr 20 09:42:51 i see Apr 20 09:42:57 which is basicly my case Apr 20 09:44:03 i got PREFERRED_PROVIDER for virtual/egl libgles1 libgles2 .. so i should also set virtual/gl to my 3d , right Apr 20 09:44:11 then see what still pulls in mesa Apr 20 09:47:15 if your 3d recipe doesn't support big-GL then don't add virtual/libgl Apr 20 09:58:52 rburton: how would you do that? Apr 20 10:08:58 hmm mesa-gl has this PROVIDES = "virtual/libgl virtual/mesa" is this correct ? Apr 20 10:09:14 should it have only virtual/libgl ? Apr 20 10:10:50 this is on fido branches .. btw Apr 20 10:13:46 rburton: What I want to do is to have two partitions (rootfs and data) where the image creates both and isntall packages on data partition. Is that possible? Apr 20 10:14:21 The interesting part is that rootfs, which contains the rpm db, will know that packages were installed in that data partitions (which is mounted in /data). Apr 20 10:54:44 damn .. something keeps pulling mesa Apr 20 10:56:41 rob_w: bitbake -g then look in the dot files to find what it is, maybe ? Apr 20 10:59:27 i am trying but i cant figure it out Apr 20 11:11:38 xserver-xorg seems to be my culprit Apr 20 11:11:44 it pulls virtual/libgl Apr 20 11:15:46 rob_w: I imagine that is conditional on opengl being in DISTRO_FEATURES Apr 20 11:19:43 bluelightning: Hi, do you know if it is possible to build an image and output two partitions (rootfs + data)? with packages installed on both. Apr 20 11:21:05 ftonello: ftonello: you can do that with two images and combine them with wic - but you cannot have dependencies satisfied across the two partitions if that's what you're looking to do Apr 20 11:22:21 bluelightning: That's exactly what I am looking for. Apr 20 11:22:23 :( Apr 20 11:22:46 hmm, in that case you'd have to do some custom mangling Apr 20 11:23:05 I am trying a hack where I move files around on a ROOTFS_POSTINSTALL_COMMAND and on the IMAGE_CMD I generate this partition. Apr 20 11:23:10 Is that something possible? Apr 20 11:23:19 theoretically, certainly Apr 20 11:23:45 bluelightning: Great. I think to enable this as a feature on OE it will be really nice. Apr 20 11:23:58 once upon a time opkg (well, ipkg at the time) had support for splitting packages across partitions, I don't know if that still works or if it would even help here (since it was more for runtime than this) Apr 20 11:24:24 I can work on that later. I see that image.py only deals with rootfs images, which in theory should be generic. Apr 20 11:25:33 bluelightning: The only problem with rpm or others, is that on build-time I want the package db to contain packages as installed in a different partition. Apr 20 11:26:13 The package manager doesn't know it is in fact a different partition, and will not even know that because that partition is mounted via fstab Apr 20 11:28:33 Hi everyone i want to boot on emmc on yocto on dart_6ul som module what can i do Apr 20 11:37:34 Hi everyone i want to boot on emmc on yocto on dart_6ul som module what can i do Apr 20 11:42:43 LinuxMice: my hint would be, to stop repeating yourself and instead read the documentation of your board on how to store your software in the ROM Apr 20 11:43:34 LetoThe2nd: sorry for this, but i dont understand doc on varwiki web page Apr 20 11:43:52 LinuxMice: then repeating still wont help you... Apr 20 11:44:09 LinuxMice: maybe contact the support of whoever sold the board to you? Apr 20 11:44:32 LinuxMice: getting software into rom is certainly not part of the yocto project, but of the specific board. Apr 20 11:46:12 LetoThe2nd: okey Leto my apologies again. i think maybe you know, how can i do this, Apr 20 11:51:54 bluelightning: how do i debug DISTRO_FEATURES ? Apr 20 11:52:13 rob_w, you need to be more specific Apr 20 11:52:17 rob_w: bitbake -e | less Apr 20 12:03:37 joshuagl: ping Apr 20 12:04:05 trip_stealth: shouldn't you be sleeping? Apr 20 12:04:47 i wish Apr 20 12:05:03 been banging my head on this recipe all night Apr 20 12:05:41 joshuagl: it just occurred to me you'd probably be able to just look at the recipe and know what's wrong. Apr 20 12:06:39 error during do_package while linking to a file that's already been linked Apr 20 12:07:51 it creates a link for ./usr/lib/java/mraa.jar then later, it creates one for ./usr/lib/../lib/java/mraa.jar Apr 20 12:08:38 i suspected the error was this line: https://github.com/tripzero/meta-intel-iot-middleware/blob/master/recipes-devtools/mraa/mraa.inc#L38 Apr 20 12:08:42 urgh, jar? Apr 20 12:08:58 but removing that line in mraa.inc does nothing to change the outcome Apr 20 12:09:27 pastebin of the error? Apr 20 12:09:55 joshuagl: http://paste.ubuntu.com/15946475/ Apr 20 12:10:53 that sure looks like it's trying to link to itself Apr 20 12:11:31 Does anyone know of any way to hide the matchbox mouse cursor. I have hiden it in my GUI application, but the the cursor seems to be overridden and still appears... Apr 20 12:12:00 riz__: iirc, there's an option you pass to the matchbox-desktop command Apr 20 12:12:15 but it's been a long time since I played with matchbox... Apr 20 12:12:44 That would be during run time correct? I was wondering if there was a way to make that the default during build. Apr 20 12:13:47 riz__: bbappend with a patch to matchbox-session or whatever calls matchbox-desktop? Apr 20 12:14:24 I heard of "-nocursor" but I ma not sure of its use Apr 20 12:14:25 joshuagl: looks like it's trying to link to a fifle it already linked to? Apr 20 12:16:28 trip_stealth: it links that file to that location at line 107, then tries again at 123 Apr 20 12:17:00 (and files because the target exists) Apr 20 12:18:18 trip_stealth: are you building for x86_64 target? Apr 20 12:18:46 joshuagl: ack. yes. so i think that silly append in the recipe is causing it. removing it changes nothing... almost as if it wasn't picking up my changes Apr 20 12:18:52 that line you identified does look, strange Apr 20 12:19:18 trip_stealth: tried the -c cleansstate hammer? sure you're using the same version of the layer you're editing? Apr 20 12:19:24 (you did say you've been up all night) Apr 20 12:19:32 zomg... Apr 20 12:19:43 it's my bblayers Apr 20 12:19:54 pointing to the wrong layer! Apr 20 12:20:02 yeah, been there "enjoyed" that Apr 20 12:20:39 * trip_stealth crosses fingers Apr 20 12:29:55 trip_stealth: and? Apr 20 12:33:45 joshuagl: looks good. not done building everything, but it seems past that error. Apr 20 12:33:57 I told you all you'd have to to was look at it and the error would disappear Apr 20 12:35:20 trip_stealth: I wish that super power worked on my own code Apr 20 12:35:39 trip_stealth: ooi why aren't using CMake for mosquitto? I vaguely recall fixing their CMake support when I wrote a recipe for it some time back Apr 20 12:37:04 joshuagl: not using cmake for the recipe? Or in the project? Apr 20 12:37:17 trip_stealth: recipe Apr 20 12:37:28 POKY_DEFAULT_DISTRO_FEATURES sets opengl which seems to be my mesa issue ,.. how do i "override" that legally ? Apr 20 12:37:32 no clue. seems like we should Apr 20 12:37:37 trip_stealth: agreed :-) Apr 20 12:38:03 rob_w: POKY_DEFAULT_DISTRO_FEATURES_remove = "opengl" ? Apr 20 12:39:16 joshuagl: i may play around with that recipe after fixing mraa (and maybe others) Apr 20 12:39:34 trip_stealth: hmm feels working .. thx Apr 20 12:39:42 * rob_w off to a full rebuild Apr 20 13:56:16 How do I add files to FILES_ with spaces? Apr 20 13:58:20 files don't have spaces in, you heathen Apr 20 13:58:32 next you'll be suggesting that path separators are \ Apr 20 13:58:43 (url encode them i expect) Apr 20 14:01:25 file://my%20file, at a guess Apr 20 14:02:00 rburton: The problem is non-unix people love to use spaces in files. Apr 20 14:02:17 rburton: not in SRC_URI, but in FILES_${PN} for example. Apr 20 14:02:30 You have to discovery how to cheat the split python function Apr 20 14:06:38 gar, not reading right today Apr 20 14:06:41 globs? Apr 20 14:16:20 rburton: html encoding didn't work. I will actually change the application, it's easier. Apr 20 14:16:36 yeah in files, that won't work Apr 20 14:16:38 try a glob Apr 20 14:16:52 ${datadir}file*with*spaces Apr 20 14:37:27 rburton: ok, will try. Apr 20 14:46:32 after changing PACKAGE_CLASSES to "package_deb", my /etc directory on my target rootfs is missing a lot of files including inittab. I'm bamboozled. Apr 20 14:49:19 also, I've got a "WARNING: Debian package install does not support BAD_RECOMMENDATIONS" which I don't really understand Apr 20 14:52:36 karobar: package_deb is definitely the least-supported option, use opkg or rpm if you can Apr 20 14:54:40 thanks. I was having issues with smart, though, that's why I tried switching (smart issues here http://stackoverflow.com/questions/36703804/smart-cant-install-no-package-provides-shared-object-file if you're interested) Apr 20 15:08:42 rburton: it worked! thanks :) Apr 20 15:14:35 What is the "You need to update bblayers.conf manually for this version transition" message for? Apr 20 15:14:53 Just trying the latest Release. Apr 20 15:19:26 Not release though but krogoth. Apr 20 15:29:51 What is this REQUIRED_POKY_BBLAYERS_CONF_VERSION for? Apr 20 15:32:14 Just setting it makes the job... It seems to be the minimum version of POKY_BBLAYERS_CONF_VERSION for the transition. Apr 20 15:37:52 It's used to trigger the automatic transitioning of files from meta-yocto to meta-poky and to know what needs to be done. Apr 20 15:48:17 * kergoth yawns Apr 20 16:00:56 hello. What problems should I expect if I'm trying to build a kernel with EXTERNALSRC_pm-linux-mymachine = /path/to/my/kernel ? Apr 20 17:10:35 someone should really untangle the vm/live image fstypes. hdddirect isn't vm specific, hddimg is used by wic, not just live, etc Apr 20 17:11:02 inconsistent behaviors between the multiple efi bits.. Apr 20 17:11:17 image-vm is only syslinux, whereas live/hddimg is grub or syslinux.. Apr 20 17:11:25 confusing mess Apr 20 17:14:00 also, wic only needs the bits in the HDDDIR, not the actual hddimg file, so using the wic image type ends up with some pointless redundant work there, afaict Apr 20 17:14:08 unless i'm missing something Apr 20 17:14:43 initrd support is consistent across the board, and afaict none of the 'hdd' style images support using the kernel with a bundled initrd, they all grab the non-bundled kernel image from DEPLOY_DIR_IMAGE Apr 20 17:16:07 s/cons/incons/ Apr 20 17:58:12 What is mini-x-session? I see it under recipes-graphics. Is that just an x terminal? Apr 20 18:37:34 anybody have tips for avoiding build host contamination? I'm running cmake then oe_make and have all sorts of problems Apr 20 19:08:00 karobar: that was extremely vague. Apr 20 19:12:55 well i'm just looking for general answers or ways to diagnose how to solve it myself. My problems are that I have links which are created by make which point to my build host Apr 20 19:13:43 sounds like you'll have to patch the makefiles to behave. Apr 20 19:13:55 there's no process you can follow, it's always case-by-case Apr 20 19:14:24 okay thanks Apr 20 20:19:25 Who is the person I can talk about issues in meta-intel? Apr 20 20:20:13 otavio: sgw_ Apr 20 20:20:20 (or file a bug, or mail the list) Apr 20 20:20:29 sgw_: you there? Apr 20 20:21:35 sgw_: we are using the core2 machine. It has two issues: hard dependency on meta-yocto-bsp, due gma500 bbappend file, however this is not noted in layer dependencies. Another issue is that it is lacking overlayfs support. Apr 20 20:22:12 sgw_: this for 4.4 kernel. 4.1 seems to boot file in live CD Apr 20 20:22:15 ah yes we ran into the gma500 thing too, i think i ended up bbmasking it Apr 20 20:22:38 I'm working with intel-corei7-64 here lately Apr 20 20:22:38 kergoth: I will mask it as well but the layer need to fix it or depend on bsp Apr 20 20:22:42 agreed. Apr 20 20:23:24 kergoth: up to now I cannot; I have a funky 32bit app needing to run and qt5 is not multilib friendly Apr 20 20:23:33 aside: that change to make it so BBMASK is a space separated list of patterns is so helpful. i cringe at the lack of spaces in paths support, but being able to use += is so so handy Apr 20 20:26:15 there's a bug for the gma500 thing, masking is a good workaround Apr 20 20:26:26 i really hope we can fix it before release Apr 20 20:26:56 otavio: re overlayfs, ping zeddii. there were changes in that recently, but i can't remember what was going on. Apr 20 20:29:20 zeddii: ^ Apr 20 20:30:38 Is there anyway disable sleep/hibernate/power management? I would like my screen to always be on. Apr 20 21:07:41 Where is the package libglfw3 coming from if I generate an image Apr 20 21:07:59 I search for glfw on layers.openembedded.org and find nothing Apr 20 21:08:50 oe-pkgdata-util lookup-recipe libglfw3 Apr 20 21:09:28 Can't be found Apr 20 21:10:00 In an environment where you can run bitbake (ideally the one you used to build the image) Apr 20 21:41:29 How do I properly file issues for poky (jethro) builds on aarch64 ? Apr 20 21:41:42 Here: https://bugzilla.yoctoproject.org/ ? Apr 20 21:42:37 a fix for binutils in poky would go under Build System & Metadata -> Meta-yocto ? Apr 20 21:50:12 gtristan: binutils bugs would typically go under the OE-Core category Apr 20 21:51:42 (unless you are using a vendor specific toolchain, like meta-linaro, for example) Apr 20 21:56:14 billr, alright gotcha thanks Apr 20 21:57:51 you're welcome Apr 20 23:03:13 So when building meta/recipes-core/glibc/cross-localedef-native_2.22.bb... I need to conditionally pass --build=arm-64-linux in do_configure() Apr 20 23:03:23 What would be the correct yocto way of doing that ? Apr 20 23:04:15 Is there a way I can conditionalize the do_configure() function to give it the extra flag only if ARCH=aarch64 ? Apr 20 23:07:05 that sounds like a terrible idea. BUILD_SYS is already set appropriately based on uname -s, overriding that for just one recipe sounds really wrong. if you want to change it, do it across the board and just override BUILD_ARCH to arm-64 Apr 20 23:07:23 erm, not -s, but you get the point Apr 20 23:10:00 kergoth, it looks like yocto glibc is still at 2.22, my guess is that glibc configure scripts only learn about aarch64 in 2.23 Apr 20 23:10:55 I am finding that I need to patch many config.sub & config.guess alot just to recognize the aarch64 in the triple Apr 20 23:11:42 we update the config.sub/config.guess in the recipes we build, generally. you shoul djust need to patch the ones in the gnu-config recipe and the automake recipe Apr 20 23:11:54 or update them to newer versions, presumably Apr 20 23:12:29 no well, the config.sub & config.guess patches are admittedly not in bitbake recipies or yocto Apr 20 23:12:36 gnu-config is a script/recipe used to update them in recipes that don't re-run autoconf/autoreconf Apr 20 23:12:44 whereas automake does the job for the others Apr 20 23:12:51 just pointing out it seems to be a trend that aarch64 is unrecognized in older tarballs/packages Apr 20 23:13:01 like i said, what's in the individual recipe tarball doesn't matter Apr 20 23:13:44 don't fix it on a per-recipe basis, fix it in gnu-config and automake and that'll fix all the recipe. if it fails to fix any recipe, then those recipes need fixing to either run gnu-configize or autoreconf Apr 20 23:13:48 kergoth, so you think that maybe I can avoid upgrading glibc by applying this magick gnu-config script to the glibc recipies ? Apr 20 23:13:54 if I understand right ? Apr 20 23:14:09 it's already done Apr 20 23:14:14 our glibc recipe runs gnu-configize Apr 20 23:14:21 hmm Apr 20 23:14:27 all you have to do is patch its config.guess/config.sub files nad call it a day Apr 20 23:14:33 as i said earlier Apr 20 23:15:04 well, the main glibc recipe does, not sure about localedef specifically. might need adding there depending on how that recipe works Apr 20 23:15:21 maybe that Apr 20 23:16:21 your best bet is to first make sure the files in gnu-config and automake have the updates you need, then fix any remaining recipes to use gnu-config if needed on a case by case basis at that point Apr 20 23:16:24 IMO anyway Apr 20 23:19:04 Ok Apr 20 23:19:08 upon further inspection Apr 20 23:19:13 On an unrelated note, anyone have any thoughts on adding plugin support to bitbake-layers? Apr 20 23:19:28 it looks like maybe I can just pass --build=${BUILD_SYS} in the localedef part... since it's not specified at all Apr 20 23:19:56 and maybe I also need to do the gnu-configurize in the ${S}/localedef directory Apr 20 23:19:59 autotools.bbclass passes it already Apr 20 23:20:04 for any autotools based recipe Apr 20 23:20:13 see autotools.bbclass Apr 20 23:20:19 specifically CONFIGUREOPTS Apr 20 23:20:57 kergoth, even if cross-localedef-native_2.22.bb invokes configure directly in it's do_configure() function ? Apr 20 23:21:21 ah, if it's not using oe_runconf, then yeah, that'd need to be taken care of directly Apr 20 23:22:00 i'd question why it's not using oe_runconf in that case, but yes, that could explain it. of course, updating config.guess should make it unnecessary, one would hope Apr 20 23:22:10 well, it is glibc after all Apr 20 23:22:32 if anything needs coaxing and special casing, it must be glibc ;-) Apr 20 23:24:03 will be a while until I can test this... have another test build running :-/ **** ENDING LOGGING AT Thu Apr 21 02:59:58 2016