**** BEGIN LOGGING AT Thu Mar 07 02:59:57 2019 Mar 07 07:40:00 Installing kernel-devsrc as part of my sdk ends up with a dead link to /lib/modules/ - shouldn't it be pointing to the /lib/modules in the sdksysroot path? Mar 07 08:23:48 in bitbake.conf I can see exports of AR, AS, RANLIB, STRIP etc. Is there a special reason why the SIZE export is missing? Mar 07 08:25:01 Tamis: we've never seen anything need/use it? Mar 07 08:29:08 RP: I have some Makefiles that they use it. They don't do anything they just print a nice table... So I guess if we put it there with a patch wouldn't be a problem. It will complete also the list Mar 07 08:31:47 Tamis: just do it in your recipe. Changing bitbake.conf changes shell environment globally and we need probably reduce what we have there, not add to it if we can help it Mar 07 08:32:07 Tamis: I doubt it would break anything but its not something I'm keen to see upstream Mar 07 08:33:45 RP: ok ty Mar 07 12:37:57 Hi, I'm trying to build my custom image based on a demo image. I keep getting the error : amixer: Unable to find simple control 'Speaker',0 in my custom image. I can see that the alsa libs are installed and there were no specific sound recipes that i could see in the old image, but now I'm unable to get the sound to work Mar 07 12:59:38 The image recipes are similiar : https://pastebin.com/FQ5RpaVn but something must be missing Mar 07 13:17:43 hey guys! is there a reason why I can't find a ready yocto recipe for electron? Noone does kiosk applications with Electron or something? meta-electron seems to be gone from OSSystems github... Mar 07 13:22:55 luneff: it might also be that just nobody shared. so, be the first to improve the situation! Mar 07 13:23:08 luneff: we have support for chromium and webkit, though Mar 07 13:24:52 yes, I saw meta-browser etc, but I wondered with there's anything related to electron other than this https://github.com/vulcanoio/meta-electron :-) it's 4 year old Mar 07 13:25:26 maybe indeed I'll have to be the first one :-D I just need underlying Chromium to be properly hw accelerated on a RPi3 :-) Mar 07 14:21:23 I'm using the exact same zImage so as long as the same sound recipes are installed I don't see how it can work in one image but not the other Mar 07 14:22:37 hi, in a kernel .bb i have a LIC_FILES_CHKSUM but also in included linux.inc ... is this correct ? Also, is sufficient to midify the LIC_FILES_CHKSUM in the .bb recipe ? Mar 07 14:44:17 This commit breaks mosquitto for thud: http://cgit.openembedded.org/meta-openembedded/commit/meta-networking/recipes-connectivity/mosquitto/mosquitto_1.5.1.bb?h=thud&id=a483d344d9fb42709c09b523c1768f4142ab9da4 Mar 07 14:44:30 as PACKAGECONFIG_CONFARGS is not passed to EXTRA_OEMAKE Mar 07 14:45:56 so I don't know what'a the right tactic, should this patch be backported to thud? http://cgit.openembedded.org/meta-openembedded/commit/meta-networking/recipes-connectivity/mosquitto?id=e39709e381f4a1229584a3c47e219536a35b78e2 Mar 07 14:46:29 yes Mar 07 14:50:43 should I send an email to request so? Mar 07 14:58:31 dkc: yes please Mar 07 14:59:07 Not sure if it's ok, about my issue above, i removed LIC_FILES_CHKSUM from the linux.inc, while i am leaving it into the linux_X.X.bb only. Seems to build fine. Mar 07 14:59:22 okay, I have plenty of meetings today but I'll do it later today Mar 07 15:11:34 Hey all. I'm having some problems with the instructions with auto-update-helper Mar 07 15:11:37 https://git.yoctoproject.org/cgit/cgit.cgi/auto-upgrade-helper/about/ Mar 07 15:11:54 I've followed the directions, but I'm pretty new to yocto, so I haven't been able to get it to properly run. Mar 07 15:13:04 I ran ". ./oe-init-build-env build-auh" from a fresh clone of yocto Mar 07 15:13:24 where does it expect the auto upgrade helper sources to be? Mar 07 15:13:33 I don't see a bitbake target for it either Mar 07 15:18:25 could someone please point me to the doc for pkgconfig? i'm not seeing it in a google search Mar 07 15:19:21 when building an autotools-based recipe, how do i see the ./configure options that are being used in the actual ./configure command? Mar 07 15:20:04 yates: try pkg-config ? Mar 07 15:20:30 yates: look at the files in ${WORKDIR}/temp e.g. run.do_configure Mar 07 15:20:41 RP: ok thanks (twice) Mar 07 15:21:21 hi there, what might be the Right Way™ of having conditional SRC_URI (a different git branch) depending on the image being built ? Mar 07 15:21:47 meego: images are constructed from packages. at the time the package is built, we have no idea what images it'll be installed into Mar 07 15:22:22 so you could change it via local.conf between the two builds, to make it rebuild with the new rev, or use two recipes/packages and select between them Mar 07 15:22:42 meego: perhaps having a bbappend in your image layer to modify the SRC_URI? Mar 07 15:24:07 unlikely the images are in separate layers, and violates the convention where layer inclusion shouldn't change the build without opting in Mar 07 15:28:16 How can I query what versions of a package are available? Mar 07 15:29:07 package, or recipe? bitbake -s is probably sufficient Mar 07 15:29:07 thanks for the help. i've considered the .bbappend path. Won't there be a naming issue ? Let's say my debug image has IMAGE_INSTALL_append += "packageX-dbg", and i create a "packageX-dbg.bbapend" file. That bbappend can't modify the packageX build process, can it ? Mar 07 15:29:20 meego: bbappends apply to recipes, not packages Mar 07 15:29:29 Looking at it Mar 07 15:29:32 Thank you. Mar 07 15:29:41 Still quite new to this Mar 07 15:29:53 jonmason, zeddii: FWIW KMACHINE_qemuarm = "qemuarma15" works locally for me Mar 07 15:30:19 kergoth - bitbake -s ran fast enough that it's obviously looking at a local copy Mar 07 15:30:32 Striking7: as opposed to what? Mar 07 15:30:47 bitbake builds from local recipes, that's what it is Mar 07 15:30:51 is there a utility to run the same type of lookups remotely? For instance, to see if a CVE has been patched yet according to version numbers? Mar 07 15:31:05 RP: cool! Mar 07 15:31:19 devtool has a subcommand to check for new upstream versions, but you can't build them without using it to first upgrade the recipe Mar 07 15:31:21 Sure - I understand: bitbake is a local deal. Not a problem. That package info has to be grabbed by some utility though Mar 07 15:31:31 Ok, good to know Mar 07 15:31:32 where did you put it? in the linux-yocto_4.19.bb? Mar 07 15:31:39 no, it doesn't. determining what upstream versions are available used to be entirely manual Mar 07 15:31:49 jonmason: linux-yocto_5.0.bb Mar 07 15:31:53 the fact that we have such a tool now is a convenience Mar 07 15:32:24 I agree. I'm trying to figure out how best to use it. Mar 07 15:32:26 the kernel part works fine here as well. Mar 07 15:32:33 RP: weird, I wonder why it wasn't working for me. Anyway, ship it ;-) Mar 07 15:33:28 Thanks for the tip about devtool Mar 07 15:34:31 kergoth: OK. If i understand correctly, there is no way to conditionally load a bbappend from an image bb file. Because of the layer separation you mentioned. Is that right ? Mar 07 15:35:01 appending an image isn't going to magically change a different recipe Mar 07 15:35:05 one recipe can't change how another recipe builds Mar 07 15:35:34 yates was proposing changing the recipe configuration based on inclusion of a layer, not changing the image Mar 07 15:35:36 afaict anyway Mar 07 15:35:54 i'd suggest just changing ther ecipe's SRCREV from local.conf when you switch image builds Mar 07 15:36:21 bitbake picks a single provider of a package to build, builds it one way, and then that package is available to install in any and all images Mar 07 15:36:30 an image can't change another reicpe/package Mar 07 15:36:42 kergoth: ok understood Mar 07 15:37:07 i'll take the local.conf path. Thank you both for your help. Mar 07 15:37:17 you could use a second recipe, and switch versions/providers to select it, or change how the one recipe builds via configuration Mar 07 15:37:27 in either case you're having to change providers in the config, so it doesn't matter either way Mar 07 15:39:19 @#!@! gmail, RP it filed your follow up from this morning as spam. Mar 07 15:39:27 I’m shocked I even bothered to check the spam folder Mar 07 15:39:36 * zeddii clicks ‘not spam’ Mar 07 15:39:51 * kergoth giving serious thought to ditching gmail at some point Mar 07 15:40:35 please take my suggestion with a grain of salt. kergoth has two orders of magnitude more experience with yocto than i Mar 07 15:41:25 only 2? Mar 07 15:41:29 it's a valid suggestion, my objections are more to do with conventions and "best practices" .. i hate that term, but drawing a blank Mar 07 15:42:16 Crofton: the order of magnitude estimate is an order of magnitude. could be 20... Mar 07 15:42:45 idiomatic. that's the word i was looking for. oe allows you a hell of a lot of flexibility, so a certain amount of thought as to the cleanest most maintainable approach is useful Mar 07 15:42:55 will my .bbappend for a recipe in my layer get utilized when devtool building Mar 07 15:42:56 ? Mar 07 15:43:08 devtool build just runs bitbake Mar 07 15:43:31 if the layer is included, and the bbappend matches the patterns in BBFILES, and its filename matches the recipe, it'll be applied whether you're using devtool or not Mar 07 15:43:50 kergoth: aha. that was going to be antoher question: difference between "devtool build within context of a devtool modify, that is Mar 07 15:45:06 Is there a way to roll a package back to a previous version using bitbake, devtool, and the like? Mar 07 15:45:27 looks like it just bitbakes the populate_sysroot packagedata tasks for you, optionally temporarily disabling parallel make during the build Mar 07 15:45:29 https://github.com/openembedded/openembedded-core/blob/master/scripts/lib/devtool/build.py Mar 07 15:45:30 Striking7: seems like a git/svn function, Mar 07 15:45:41 https://github.com/openembedded/openembedded-core/blob/master/scripts/lib/devtool/build.py#L57-L73 Mar 07 15:45:50 https://github.com/openembedded/openembedded-core/blob/master/scripts/lib/devtool/build.py#L49-L51 Mar 07 15:45:50 Reading your links - thanks for the info Mar 07 15:46:05 those 3 links were for yates Mar 07 15:46:25 to "roll back" a version you need to change/rename the recipe to the old version, and adjust patches appropriately Mar 07 15:46:34 Oh, came in kind of handy for me anyway :-) Mar 07 15:46:37 if we already had a recipe for the old version at some point, as yates says, use git to resurrect the old version Mar 07 15:46:53 ok. Mar 07 15:47:06 bitbake only builds the verisons of the recipes we have in the layers, not arbitrary versions Mar 07 15:47:39 devtool assists with upgrades to newer upstream versions, but you'll have to fix patches, if we'd already built the old version, it makes more sense to pull it out of source control than to re-do the work Mar 07 15:47:51 Makes sense. Mar 07 15:48:15 back to the .bbappend question, i have a .bbappend in a layer which should be selected for matchbox-wm which is simply this: https://paste.fedoraproject.org/paste/jrnTHd6sigstMaPuPqlQsg Mar 07 15:48:31 I don't mind doing it that way, I'm just trying to figure out all the data that's available to me here. For instance, one thing we would really like is a list of available package versions Mar 07 15:48:51 yet the ./configure option --enable-composite" is not being specified Mar 07 15:48:56 I can get the list of latest packages, but not info about previous versions for a single package. Mar 07 15:49:09 †he only list you can get is what recipes you have right now, or what upstream upgrades are available. by policy we don't keep old versions around in our layers, it's a maintenance nightmare to keep everything building going forward Mar 07 15:49:27 Of course, I understand completely Mar 07 15:49:52 *if* the recipe name includes the version, i.e. for non-git recipes, you could use git to extract a list of the files we've removed from history Mar 07 15:50:37 Striking7: https://github.com/kergoth/dotfiles/blob/master/git/scripts/git-attic Mar 07 15:50:46 So really all the remote access these tools do is git? Mar 07 15:50:51 here is my latest log.do_configure: https://paste.fedoraproject.org/paste/gus2ueMRZMOi0ZACyE1GFw Mar 07 15:50:59 it's just not ther.e Mar 07 15:51:00 via http://chneukirchen.org/dotfiles/bin/git-attic Mar 07 15:51:02 there Mar 07 15:51:18 Striking7: no, devtool's upgrade checking uses patterns and remote urls to check for remote version availability Mar 07 15:51:20 Thanks kergoth Mar 07 15:51:24 but other than that,e verything is local Mar 07 15:51:29 i need "Building with Composite manager" to be "yes" Mar 07 15:51:57 yates: make sure your append is in an included layer (see conf/bblayers.conf in BBLAYERS) and in the correct path to be included (see BBFILES in /conf/layer.conf) Mar 07 15:52:01 kergoth: perfect! I'll dive into its source to see where all that comes from. That looks like the right direction for me Mar 07 15:52:03 and the filename has to match the recipe Mar 07 15:52:48 i'm using matchbox-wm_%.bbappend - wouldn't that work ? Mar 07 15:52:50 bitbake/oe is designed to be self-contained and independent of host and target distro and machine, we've never designed or implemented a protocol to access metadata anywhere but in the local layers Mar 07 15:53:19 yates: also, use bitbake-layers show-appends, way quicker way to check if it's being applied Mar 07 15:53:32 matchbox-wm_1.2.1.bb is the recipe Mar 07 15:53:33 ok Mar 07 15:53:44 that filename is fine, yeah, so check layer inclusion and its location within the layer Mar 07 15:53:56 you can't just drop a bbappend wherever you want, it has to match the wildcards in BBFILES in the layer it's in Mar 07 15:54:15 i.e. /recipes-*/*/*.bbappend, or whatever Mar 07 15:54:19 ok Mar 07 15:54:23 let me check.. Mar 07 15:56:02 Striking7: https://gist.github.com/5f34aff94cce3b0d66b5ffc4b1b24959 if you want to pursue the scm history route. Mar 07 15:59:08 kergoth you are a life saver Mar 07 16:00:31 np. that attic script is handy, particularly since it includes the last commit where the file existed, so you can look at the recipe with git show, or use checkout to resurrect it Mar 07 16:00:55 veeeeery cool Mar 07 16:01:08 This is all still a bit over my head - I just started this job Tuesday. Mar 07 16:01:28 So the terminology (recipe vs. package, layers, etc) is all still soft and squishy in the brain Mar 07 16:01:45 no worries, we all have to start somewhere, and oe/yocto is complex (of necessity, due to the flexibility), with a fairly steep learning curve Mar 07 16:01:58 once you grasp the big picture it starts to come together in your head, i think Mar 07 16:02:11 but some learn best bottup-up, others top-down, so depends on the person Mar 07 16:06:24 Totally understand - I usually do a little of each Mar 07 16:06:50 lets you use your right brained creativity in "reverse engineering" from top down, lets you use left brain methodical tendencies for bottom up Mar 07 16:13:29 i am confused about how layers are configured. is it via sources/poky//conf/bblayers.conf? but i also have a sources//conf/layer.conf? Mar 07 16:15:09 if is in the build bblayers.conf, does its layer.conf get appended? Mar 07 16:15:39 or some other means... Mar 07 16:16:59 bitbake-layers show-appends is NOT showing my .bbappend file Mar 07 16:17:24 am i even making sense? Mar 07 16:19:03 Anyone knows where devtool checks for upstream updates? Mar 07 16:19:30 know* Mar 07 16:30:25 my sources//conf/layer.conf does not specify layers but it does specify BBILES, how layers are to be searched I guess. Mar 07 16:32:36 so if the sources/poky//conf/bblayers.conf contains source/ as a layer, does that layer's /conf/layer.conf get applied (e.g., the BBIILES)? Mar 07 16:34:03 ..the BBFILES Mar 07 16:45:19 nm - got it. Mar 07 16:49:35 yocto schoolboy mistake... it was in //matchbox-wm_%.bbappend instead of //matchbox-wm/matchbox-wm_%.bbappend Mar 07 16:49:50 s/mega/meta/ Mar 07 16:56:33 figured, you're not the first one to put it in the wrong spot. been there myself Mar 07 16:59:19 would be nice if bitbake-layers show-appends took a recipe as a final argument, so you don't have to grep through ALL appends to fihd the one... Mar 07 16:59:38 not a bad idea, maybe submit a bug to bugzilla? Mar 07 17:00:02 debatable whether it should accept layer or recipe as first argument, so probably use an option. -r RECIPE or something Mar 07 17:01:10 kergoth: good idea. just to complete, was i right on the application of the BBFILES in layer.conf? Mar 07 17:01:42 yes, bblayers lists layers to process, conf/layer.conf is parsed in each layer to construct a final BBPATH and BBFILES, and bitbake uses those to do the actual parsing Mar 07 17:02:12 ack - good. Mar 07 17:02:45 then BBFILE_COLLECTIONS/BBFILE_PATTERN_/BBFILE_PRIORITY_ controls layer priority. when the same recipe exists in multiple layers with different versions, the higher priority layer recipe is used, even if it's the older one, unless PREFERRED_VERSION selects explicitly Mar 07 17:08:23 ok Mar 07 17:09:10 I'd highly suggest both of you to read http://www.aosabook.org/en/yocto.html Mar 07 17:09:33 it covers this, and isn't particularly long Mar 07 17:17:56 i'm getting errors in the build and having a hard time parsing. could someone please have a look? https://paste.fedoraproject.org/paste/D1eOHqORDezbOZVkp5vbTg Mar 07 17:19:24 do i need a DEPENDS on glibc? Mar 07 17:19:26 jonmason: we're missing a patch I think to replace qemuarm with the a15 one? Mar 07 17:19:38 zeddii: how dare it! :) Mar 07 17:20:18 Thanks Kergoth - reading Mar 07 17:27:16 RP: I’ve reproduced the perf 4.19 issue, looking at a fix now. Mar 07 17:27:49 and I’m randomly throwing configs at qemuarm64 to see if I can get a framebuffer to activate. but it is nearly random ;) Mar 07 17:28:09 RP: I thought you didn't want to remove it for legacy reasons Mar 07 17:31:00 jonmason: no, I want to switch it over and leave armarmv5 for legacy Mar 07 17:41:48 ah, ok. I can push that patch then....when I get home on Monday. Is that long of a delay okay? Mar 07 17:45:06 jonmason: It'll be my turn to travel Mar 07 17:46:00 jonmason: I'll take what I can get, when I can get it. I might sort something before then, we'll see. I know I'm running out of time to do everything before my travel now Mar 07 17:58:53 In SCaLE now, and for some reason my dyndns isn't working :( Mar 07 18:05:00 jonmason: right, no problem. I think the M3 build is going to be a bit rocky timing wise... Mar 07 18:15:43 anyone here using cve-check-tool? Mar 07 18:21:07 and now oe-selftest for devtool is failing due to a lack of git user name/email configuration Mar 07 18:21:12 despite it being configured Mar 07 18:29:09 is there a way to require a busybox version with FEATURE_FANCY_HEAD enabled for a recipe (ptest actually)? Mar 07 18:30:08 head is missing the -c option... and end-up screwing a basic bash randomstring generator. We can change it upstream but if I can add a dependancy for a *fancy* head utils in yocto, I would prefer that Mar 07 18:32:32 nope, not possible. you'd have to change the busybox configuration at a configuration or busybox recipe level Mar 07 18:32:48 you could always depend on the real tool, not busybox, for head Mar 07 18:32:51 i.e. coreutils i'm guessing? Mar 07 18:33:40 yeah Mar 07 18:34:09 does oe-core have the recipe for the "real" tool... Mar 07 18:35:29 nevermind, did a quick grep. got my answer Mar 07 18:35:31 thanks Mar 07 18:57:05 does bitbake dump the screen output to a file? Mar 07 19:22:55 tmp/log/ Mar 07 19:36:40 is there a better display system than matchbox? namely, something with a decent compositor? Mar 07 19:48:11 or... does anyone know how to make --enable-composite work? Mar 07 19:48:20 in the matchbox-wm recipe? Mar 07 19:49:47 has anyone gotten this to work? Mar 07 19:50:19 i'm reading some nasty stuff that it won't work with compositing enabled: http://lists.busybox.net/pipermail/buildroot/2015-June/129897.html Mar 07 19:52:08 rburton: any thoughts? Mar 07 19:58:21 yates: Would weston work? Mar 07 20:00:11 So I like devtool so far - its "upgrade" command takes a preferred version as a param, and it can downgrade or upgrade pretty seamlessly. Mar 07 20:00:25 What I'd like is to get a list of versions of a package that are available and present that to the user Mar 07 20:00:36 (or rather, long term, to another component in the system) Mar 07 20:01:18 Anyone know if devtool has a way of doing that already? I know it's using SRC_URI and scraping latest_version from there, but I wasn't sure if it stored all the versions available as well Mar 07 20:01:29 JPEW: icecc in my env did not solve the world hunger Mar 07 20:01:53 JPEW: I have 16Core+16GB+300GB-SSD Mar 07 20:01:57 khem - that's the worst: I hate it when my code fails to solve world hunger Mar 07 20:02:10 khem: Too bad. It is a bit twiddly.... for example, we are all running a patched version of icecc Mar 07 20:02:10 and I add another box with same spec and build times are same or worse Mar 07 20:02:47 I guess n/w is my bottleneck Mar 07 20:02:55 I need 10G backhaul Mar 07 20:03:09 That would be nice. What do you have now? Mar 07 20:03:18 or maybe even thats not enough to beat SSDs Mar 07 20:03:51 JPEW: this is some cloud that someone else manages I have asked them the question Mar 07 20:04:20 khem: Could be the SSDs. I still have spinny drives Mar 07 20:04:32 JPEW:I am doing another experiment where I will have 4 8 core machines as slaves and then do -j30 to build chromium-x11 Mar 07 20:05:08 yeah SSDs are the biggest improvement for OE builds I agree Mar 07 20:05:23 JPEW: it looks like that is for wayland Mar 07 20:05:29 we are using x11 Mar 07 20:05:37 Ah. too bad Mar 07 20:05:59 yates:you can look into westeros which is a light weight wayland compositor Mar 07 20:06:30 https://github.com/rdkcmf/westeros Mar 07 20:06:33 JPEW: have you used wayland/weston on an embedded device with like a smallish LCD display? (ours is 800x480) Mar 07 20:06:51 yates:whats the app ? Mar 07 20:06:57 do you run in kiosk mode ? Mar 07 20:07:14 khem: i don't understrand the question(s) Mar 07 20:07:19 x11+qt5 is decent Mar 07 20:07:30 we are using x11+wxwidgets Mar 07 20:07:32 yates: I've used weston for testing purposes. We have our own proprietary wayland compositor we use in production (not by choice.... I'd rather use weston) Mar 07 20:08:05 weston is pretty configurable with plugin shells and such Mar 07 20:08:24 JPEW: would it be easy to bring weston/wayland in instead of x11/matchbox? Mar 07 20:08:53 weston is heavier, surely thats why we wrote westeros for RDK and its opensource( Apache-2.0) so enjoy and contribure back Mar 07 20:08:56 yates: depends on what applications you want to run on top of it Mar 07 20:09:03 yates: Just getting weston is pretty easy Mar 07 20:09:13 IMAGE_INSTALL += "weston" Mar 07 20:09:31 or base your image on top of core-image-weston Mar 07 20:09:55 Oh, ya that would work :) I didn't even know that was a thing Mar 07 20:10:21 khem: Does core-image-weston default weston to use DRM for hardware accelerated rendering? Mar 07 20:10:33 DRM? Mar 07 20:10:56 We have a browser based UI running on top of wayland+westeros doing full HD video in less than 512M RAM device Mar 07 20:11:11 yates: Direct Rendering Management, basically the kernels GPU API Mar 07 20:11:13 see https://github.com/WebPlatformForEmbedded/meta-wpe Mar 07 20:12:24 yates: AFAIK, weston in OE defaults to using (non-accelerated) framebuffer backend, which might feel pretty slow. If you have a GPU, enabling the DRM backend in weston makes it much better :) Mar 07 20:12:55 holy crap! Mar 07 20:13:04 no, nothing near HD video required in our stuff. Mar 07 20:13:40 but we do want sexy-looking UI with gradients, transparency, etc. Mar 07 20:14:34 yates: sure, are you using OpenGL (or OpenGLES) for that? Mar 07 20:16:18 i don't know... (sheepish look). i'm using wxWidgets wxDC classes and a little of my own, but transparencies don't work because we have no compositor Mar 07 20:16:45 wxDC has a built-in gradient fill Mar 07 20:17:29 perhaps under-the-hood wx uses OpenGL Mar 07 20:17:31 ? Mar 07 20:17:48 yates: Probably not Mar 07 20:19:36 wxwidgets would use opengl if platform enabled it Mar 07 20:20:22 build it with --with-opengl Mar 07 20:20:23 thanks for all the input folks, i'm still parsing/thinking on it. Mar 07 20:20:43 khem: you mean build wxWidgets --with-opengl? Mar 07 20:20:49 yes Mar 07 20:21:18 and ensure that your graphics driver supports openGL and is enabled there too Mar 07 20:21:35 FWIW: My recollection is that wxDC is a simple (non-acclerated) raster bitmap backing, and there are other classes for using OpenGL in wxWidgets, but I could be wrong Mar 07 20:21:48 yes, we already are: https://paste.fedoraproject.org/paste/UC7v7DGyhgPfuYhQYMht8w Mar 07 20:22:04 this is from the wx recipe i wrote a few weeks back. Mar 07 20:22:06 thats possible maybe they rely on GLX Mar 07 20:22:27 libglu is a depends - is that opengl? Mar 07 20:23:28 khem: Very possible. wxWidgets does line to punt the underlying system when possible. My knowledge of X is very weak (more of a Wayland fan), and I'm OK with that :) Mar 07 20:25:07 JPEW: re: raster bitmap, the transparencies work on fedora - exact same code as what i run on matchbox Mar 07 20:25:19 same wx version, 3.0.4 Mar 07 20:25:35 so it's not wx Mar 07 20:26:35 latest fedora uses wayland IIRC Mar 07 20:29:38 khem: Yes it does, running it right now Mar 07 20:31:56 yates: Can you run wxwidgets without a windowing system (e.g. gtk)? Mar 07 20:37:01 it is the gtk-based version of wx, so .. yes? Mar 07 20:37:09 i've never done it, don't really know Mar 07 20:37:46 i'm just trying to determine the quickest way to get our project transparency. Mar 07 20:38:02 if that means switching to weston/wayland, so be it. Mar 07 20:38:24 that will also probably be the time to upgrade morty to something this century.. Mar 07 20:38:51 it seems wayland is the wy of the future. Mar 07 20:39:34 but i do have questions. like can i still run an xterm if x11 is not there? Mar 07 20:40:03 can i run vnc server ? Mar 07 20:40:08 yada yada.. Mar 07 20:40:33 i guess i'm ignorant of the deeps parts of x11 versus wayland Mar 07 20:40:37 deep Mar 07 20:45:43 khem: are you implying that if the graphics driver supported openGL and it is enabled there, that we'd have transparencies with matchbox-wm? Mar 07 20:48:15 matchbox-wm + wxWidgets, that is? Mar 07 20:52:18 yates: those comments are not very accurate. we autoreconf mbwm for a start Mar 07 20:52:50 yates: nobody that i'm aware of has used the compositor since nokia/maemo so who knows if it still *works* Mar 07 20:52:57 yates: ideally, just ditch X entirely and use weston Mar 07 20:53:16 right, coming to the same conclusion Mar 07 20:54:06 x11 is legacy at this point basically Mar 07 20:54:15 if you can use wayland Mar 07 20:55:06 khem/rburton: by "base your image on core-image-weston" do you mean "inherit core-image-weston" instead of "inherit core-image"? Mar 07 20:55:21 no, i mean ditch X entirely and use weston Mar 07 20:55:28 core-image-weston is an example, like core-image-sato Mar 07 20:55:50 enabling compositing in mbwm is most likely trivial though Mar 07 20:56:06 rburton: oh? Mar 07 20:56:38 --enable-composite and come back with patches Mar 07 20:57:48 you mean just rewrite part of the compositor? Mar 07 20:57:50 :) Mar 07 20:58:05 i've already done the --enable-composite Mar 07 20:58:32 that scares me.. but perhaps i'm just a wuss... Mar 07 20:58:38 so voila, you have a compositing window manager Mar 07 20:58:46 no, it won't build. Mar 07 20:58:52 right, so. fix that then :) Mar 07 20:59:13 i am honored that you have so much confidence in my abilities! Mar 07 20:59:20 its just C Mar 07 20:59:28 so is the kernel... Mar 07 20:59:50 honor is hard to earn and easy to loose :) Mar 07 21:00:14 yates: pastebin errors if you actually want a hand Mar 07 21:00:20 ok, thanks much Mar 07 21:00:23 otherwise we're just telling you to fix it and you're saying its broken Mar 07 21:00:56 require recipes-graphics/images/core-image-weston.bb Mar 07 21:01:02 add that in your image recipe Mar 07 21:01:11 is a signed-off-by required for a backport? Mar 07 21:01:14 dkc: yes Mar 07 21:01:24 ok! Mar 07 21:01:44 khem: no need for that really but lets not complicate matters, yates is going to try fixing mbwm first :) Mar 07 21:02:26 :) Mar 07 21:02:44 ok, course laid in, engaging... Mar 07 21:03:32 Chekov: "But Captain (rburton), it will take 13.4 light years at sub-warp!" Mar 07 21:06:12 https://paste.fedoraproject.org/paste/1L0gQixPQo07dBAsLKmBmQ Mar 07 21:06:46 rburton: from this output i'd say the problem is a wrong link order, but how do i change that? a Makefile change? Mar 07 21:12:45 should i try modifying the build/src/Makefile? or is that auto-generated? Mar 07 21:13:28 there is a build/Makefile too Mar 07 21:21:15 zeddii: looks like stap works except for qemuarm Mar 07 21:26:27 yates: I think you're right and its a link order issue Mar 07 21:26:55 yates: you could probably prove easily by hacking Wl,--as-needed out of LDFLAGS Mar 07 21:27:10 yates: not the proper fix but would tell you if there are any other issues lurking Mar 07 21:28:41 * nerdboy finally got his silly internet back again... Mar 07 21:29:15 I'm having a hard time understanding the goal of " Mar 07 21:29:18 PACKAGECONFIG ??=" Mar 07 21:29:40 this https://lists.yoctoproject.org/pipermail/yocto/2013-November/016969.html indicate that it list the "enabled" feature Mar 07 21:30:34 but if I take the lttng-tools recipe which define PACKAGECONFIG ??= "lttng-ust" lttng-ust is not present in the end image. Mar 07 21:31:45 I have to add PACKAGECONFIG += "lttng-ust" to a bbapend (lttng-tools) to see lttng-ust feature used Mar 07 21:33:10 is it because lttng-ust is not part of the "runtime dependencies" and only in the "build dependencies"? Mar 07 21:34:05 Hi, Anyone here using RPI3 with Yocto? I have tried following : https://jumpnowtek.com/rpi/Raspberry-Pi-Systems-with-Yocto.html but I cannot get it generate the bootcode.bin. This whole workflow is very different from other stuff, like imx6 Mar 07 21:36:53 psrcode: PACKAGECONFIG is primarily about build time things Mar 07 21:38:22 psrcode: What would work here is to change the lttng-ust line to PACKAGECONFIG[lttng-ust] = "--with-lttng-ust, --without-lttng-ust, lttng-ust, lttng-ust" Mar 07 21:38:46 psrcode: that 4th position in the PACKAGECONFIG entry adds to RDEPENDS Mar 07 21:39:14 psrcode: so then the lttng-tools package would depend on lttng-ust Mar 07 21:40:11 psrcode: normally we pick up rdepends through dynamic linking analysis but I guess lttng doesn't directly link to ust Mar 07 21:40:37 RP: based on the PACKAGECONFIG ??= line was it the intention to have lttng-ust by default? Mar 07 21:40:45 psrcode: I think so Mar 07 21:40:52 because lttng-tools can be built without lttng-ust Mar 07 21:41:03 if so this solve a big chunk of the ptest suite Mar 07 21:41:35 psrcode: ah, interesting. Yes, its being made configurable and turned on there Mar 07 21:41:38 still we do have a fuckup on our side regarding how we handle ust dependant tests Mar 07 21:42:17 psrcode: I guess we just never realised there wasn't a direct linkage to cause it to be pulled in Mar 07 21:42:31 I'm looking into adding the python agent option on lttng-ust so we can run the python agent test via lttng-tools, otherwise the ptest suite works all green Mar 07 21:43:01 psrcode: sounds great! :) Mar 07 21:43:52 RP: there was a couple missing dep for the tests and 1~2 fuckup on our side. I'll send you a RFC when I'm confident with the work. Mar 07 21:44:23 next step will be to have all this integrated in our CI to track stuff either from scratch or using report from your builder Mar 07 22:02:38 psrcode: FWIW our ptest builds do run lttng-tools-ptest at least on qemux86 Mar 07 22:03:34 psrcode: shows up on a-full builds: https://autobuilder.yocto.io/pub/non-release/20190228-9/testresults/testresult-report.txt Mar 07 22:03:42 lttng-tools | 4431 | 7 | 391 | 549 Mar 07 22:04:26 psrcode: we're actively working on improving our ptest handling and reporting Mar 07 23:03:15 jonmason: with my patch to change qemuarm to your a15 config, I find graphics doesn't work there either with the 5.0 kernel Mar 07 23:04:50 does the qemu command still include the VGA? Mar 07 23:05:43 jonmason: yes Mar 07 23:09:17 Can you send me the patch? I'll look in a VM Mar 07 23:10:02 jonmason: its in master-next Mar 07 23:10:19 yates: add -lm to src/Makefile.am Mar 07 23:10:25 jonmason: it builds on top of you a15 one Mar 07 23:10:30 RP: ok, fetching now Mar 07 23:10:33 yates: presumably guaded by if composite checks Mar 07 23:21:48 * RP -> Zzzz Mar 07 23:25:02 rburton: yes, i just discovered that .. Mar 07 23:26:28 rburton: right now i'm modifying the Makefile in the workspace. how would i get that into the recipe? is src/Makefile.am in the recipe somewhere? Mar 07 23:26:45 yates: no, its upstream. patch it Mar 07 23:27:28 by "upstream" do you mean in the git repo for matchbox-window-manager? Mar 07 23:27:31 yes Mar 07 23:27:38 ah. Mar 07 23:27:46 use devtool modify! Mar 07 23:27:52 literally what its for Mar 07 23:28:15 oh. i thought you met to submit a patch to the git repo Mar 07 23:28:50 that too Mar 07 23:28:56 but you can generate it iwth devtool modify Mar 07 23:29:01 when you have a working patch, send it in Mar 07 23:29:17 how did you know the problem was -lm?!? Mar 07 23:29:21 ok, right Mar 07 23:30:15 | /Storage/production-hardware-revision-A-1.0/sources/poky/build-hw-test-image/tmp/sysroots/x86_64-linux/usr/libexec/arm-fslc-linux-gnueabi/gcc/arm-fslc-linux-gnueabi/6.2.0/ld: composite-engine.o: undefined reference to symbol 'exp@@GLIBC_2.4' Mar 07 23:30:22 exp() is in libm.so Mar 07 23:30:30 RP: are you forcing the kernel to 5.0? Mar 07 23:30:43 ah Mar 07 23:31:11 yates: man exp says "Link with -lm" Mar 07 23:37:24 rburton: src/Makefile.am uses several predefined variables such as LIBMB_LIBS. that is apparently defined in src/Makefile.in. but in src/Makefile.in it is defined as LIBMB_LIBS = @LIBMB_LIBS@. where does "@LIBMB_LIBS@" come from? Mar 07 23:38:01 yates: configure.ac sets LIBMB_LIBS, most likely via a PKG_CHECK call Mar 07 23:38:42 RP: the go 1.9 drop didn't drop the recipe Mar 07 23:39:20 and i should be modifying the git/src/... files with devtool, right? it will generate a .bbappends for those files, right? Mar 07 23:40:01 honestly, don't know the workflow Mar 07 23:40:01 rtm Mar 07 23:40:39 yates: git/src ? Mar 07 23:40:53 yes..? Mar 07 23:41:05 where exactly are the files you are talking about modifying?\ Mar 07 23:41:16 config.ac and/or Makefile.in Mar 07 23:41:23 the path, I mean Mar 07 23:41:45 /sources/poky/build-hw-test-image/tmp/work/armv7at2hf-neon-fslc-linux-gnueabi/matchbox-wm/1.2.1-r0/git/ Mar 07 23:42:10 is that wrong? Mar 07 23:42:11 yes Mar 07 23:42:19 unless you specified that path (unlikely), devtool modify checks out the source to workspace/sources/ Mar 07 23:42:19 there's a source tree in the devtool workspace Mar 07 23:42:32 (read the manual) Mar 07 23:42:32 oh yeah... Mar 07 23:42:43 i knew this already.. Mar 07 23:42:52 no worries :) Mar 07 23:43:10 it's late, i'm tired... Mar 07 23:47:41 is Makefile.in automatically generated from configure.ac? i.e, would it be pointless to modify Makefile.in? Mar 07 23:48:03 RP: ugh, all those warnings for inetutils come from a specific oe-selftest? Mar 07 23:48:31 no, nm, Mar 07 23:48:38 stupid question Mar 07 23:49:00 configure.ac is the right file to modify, no? Mar 07 23:49:04 right Mar 07 23:49:19 makefile.am and configure.ac are the source files Mar 08 00:09:44 yates: comedy, we fixed that back in 2018 Mar 08 00:10:01 yates: there's a patch in matchbox-wm, top commit Mar 08 00:20:15 yates: rburton it seems you need to add -lm to LDFLAGS LIBMB_LIBS does not seem to be right place Mar 08 00:21:16 RP:I sent a v3 of go patches, v2 has some shortcomings that showed up on local world build + Ross's comment Mar 08 01:26:03 RP: it seems kernel 5.0 is crashing Mar 08 01:26:05 http://ix.io/1CQp **** ENDING LOGGING AT Fri Mar 08 02:59:56 2019