**** BEGIN LOGGING AT Thu Mar 31 02:59:58 2016 **** BEGIN LOGGING AT Thu Mar 31 03:29:41 2016 Mar 31 06:49:08 good morning Mar 31 07:28:00 mood groaning mckoan Mar 31 07:35:19 hi all.. is there a way to set options for stripping? Mar 31 09:43:31 in your local.conf set export STRIP = "${HOST_PREFIX}strip " Mar 31 09:45:55 Hi all. What exactly is determining the architecture of a package? I've got "all", "", "cortexa9hf_vfp_neon" and "cortexa9hf_vfp_neon_mx6qdl" and i'm confused why that is Mar 31 09:51:16 it says where the packages can run Mar 31 09:51:30 all means it can run on all kind of machines Mar 31 09:51:56 cortexa9 can run on SOCs based on cortecxa9 Mar 31 09:52:12 your-machine are limited to just your machines Mar 31 09:52:48 x6qdl seems FSL innovation so ask them Mar 31 09:53:29 khem: no offense but i wasn't asking what it meant but why certain packages are deployed for certain architectures. Shouldn't all of my packages being build for one arch? Mar 31 09:53:59 I don't get, why that is, what's causing it and how to track down where it's set / determined Mar 31 09:54:28 Anticom: feeds are prepared for multiple machine scenario Mar 31 09:55:05 the same structure scales to all kind of machines and shares the packages across them as much as it can Mar 31 09:55:12 khem: Well I've got MACHINE = "xy" in my local.conf. Why is bitbake still building for other machines then? Mar 31 09:55:23 like what variable in a recipe etc. is instructing bb to do so Mar 31 09:55:27 Anticom: usually only the kernel is really hw dependent. so only that is supposed to be in the feed for your specific machine. Mar 31 09:55:51 Anticom: the rest of the userland only is limited by the arch, so it can be safely shared actross multiple machines. Mar 31 09:55:56 LetoThe2nd: And that's done using COMPATIBLE_MACHINES? Mar 31 09:56:18 Anticom: i don't know what triggers it, i only know what it means :) Mar 31 09:56:22 LetoThe2nd: But still i don't know how to take control over it Mar 31 09:56:29 hm Mar 31 09:57:01 i've never had the need to tinker with that. because "it just works"(TM) Mar 31 09:57:04 taking control ? Mar 31 09:57:17 its a wrong thing to do Mar 31 09:57:34 whats wrong that you want to take control Mar 31 09:58:36 khem: e.g. how would i control what recipes are installed just by changing MACHINE but not the image target? Mar 31 09:58:39 is that even possible? Mar 31 09:59:34 well whats the use case? Mar 31 10:00:13 in the trivial meaning, add some trailing selectors to the IMAGE_INSTALL in your image recipe Mar 31 10:00:32 you can select for specific machines, arches, whatever that way. Mar 31 10:00:43 images are generic Mar 31 10:00:59 khem: ... unless you de-genericize them Mar 31 10:01:00 if you want to exclude a package then do so in image recipe Mar 31 10:01:27 yes you can for your own peril Mar 31 10:01:44 Tharr be drrrragons! Mar 31 10:01:57 there are several ways to add/remove packages per machine Mar 31 10:02:19 you can use RECOMMENDS and BAD_RECOMMENDATIONS e.g. Mar 31 10:02:32 in machine config data Mar 31 10:02:43 distro is (or should be) generic too Mar 31 10:02:56 LetoThe2nd: It's not **the** usecase. Afterall I'm just trying to get a deeper understanding. I've been thrown into an existing messy project and trying my best to clean up what i've found ;) Mar 31 10:03:22 Anticom: well then, this is one pf the parts best left as-is. it works. Mar 31 10:03:45 (unless it doesn't) Mar 31 10:04:12 mborzecki: it obviously does, because otherwise the use case would have been "make it work" Mar 31 10:05:24 LetoThe2nd: Strongly disagree with that oppinion. Just because it currently works doesn't mean that you shouldn't improve what you found. That's guaranteed massive and time consuming maintanance lateron Mar 31 10:06:04 LetoThe2nd: or it just 'sort of' works, depending on how we grade 'works' in this context :) Mar 31 10:06:37 Anticom: Feel free to disagree. But if "improvement" means "hackily work around system inherent design decisions, just because i think i know better", then i guess your argument just fails in the long run. Mar 31 10:07:12 LetoThe2nd: No it's more about "fixing inconsistencies and hax due to no one ever worked with yocto before" Mar 31 10:07:24 *in our dev team Mar 31 10:07:45 Anticom: you mean, "worked with OE before" Mar 31 10:08:11 yea Mar 31 10:08:12 Hi. I've enabled Storage=persistent in journald.conf but var/log is symlinked like this ----------> /var/log -> volatile/log Mar 31 10:08:22 rtrt: --> #systemd Mar 31 10:08:24 Is this a bug? Mar 31 10:11:23 Anticom: if you want to improve your setup, make machine, distro and image orthogonal. thats a widely accepted best practise for maintenance :-) Mar 31 10:13:53 LetoThe2nd: That's one of the things i'm working on :) Mar 31 10:15:43 rtrt: IIRC persistent means that journal logs to /var/log/journal, not a bug Mar 31 10:16:48 rtrt: you may need to adjust tmpfiles to make it non-volatile, see /usr/lib/tmpfiles.d or /etc/tmpfiles.d Mar 31 10:16:57 @mborzecki But it's a symlinked folder to volatile which is destroyed during reboot Mar 31 10:18:59 rtrt: systemd-tmpfiles creates the link, that's why you need adjust its config to not touch /var/log or just make sure that it links /var/log/journal to a nonvolatile location Mar 31 10:20:30 btw. it should be possible to configure journal storage location, so maybe that's the easiest way? Mar 31 10:23:26 @mborzecki Oh. Will try both. I could see 00-create-volatile.conf in /etc/tmpfiles.d which might be responsible for this. I'm not sure if I should edit this Mar 31 10:25:17 hi i want to build a 64 bit toolchain from a build which is for 32 bit platform Mar 31 14:52:52 Quick question. The lib files that are built into my target's /usr/lib will be located at "/poky-build/tmp/sysroots/intel-corei7-64/usr/lib", correct? Mar 31 14:54:23 nope :P Mar 31 14:54:51 well, they might be there too, but I don't think it will always be the case Mar 31 14:57:00 well except if your target arch is intel-core7-64 ;-) then its very well possible ;-) Mar 31 14:58:47 It is my target Mar 31 14:59:00 So is there a central place that shows the root of the target? Mar 31 14:59:07 no. Mar 31 14:59:31 I am asking because certain drivers that I see in usr/lib/dri are not on my actual targetr Mar 31 14:59:32 the place you named correlates the most with it, but you should not rely on it being a 100% equivalent. Mar 31 14:59:38 actually, the entire dri folder is missing Mar 31 15:00:16 specifically i965_dri.so and swrast_dri.so Mar 31 15:01:31 like i said, they don't have to correlate. if you need access to the targets filesystem, have the image created as ext and loopmount it. or tar.gz and unpack it. Mar 31 15:03:07 closest thing is probably tmp/work/-///rootfs/ Mar 31 15:03:17 but there was some drawback on that too. Mar 31 15:04:53 If I would like to just add the i965 driver prior to build how would that be done? Mar 31 15:05:08 have your recipe install it properly? Mar 31 15:05:11 thats the way. Mar 31 15:05:34 Would in be done in the intel-corei7-64.conf? Because I believe I see it there Mar 31 15:05:48 why would a driver file be installed in a machine.conf? Mar 31 15:06:03 I figured that is where it would be included Mar 31 15:06:11 judging by the name, it sounds a lot like mesa. Mar 31 15:06:28 i'd start there. maybe you're just missing some distro feature? opengl? Mar 31 15:06:37 I have opengl Mar 31 15:06:46 (just geussing) Mar 31 15:07:14 in any case 1)find out which package builds the file 2) modify the recipe, or its variable to properly install them. Mar 31 15:08:41 I In this case would I alter mesa.inc's PACKAGECONFIG variable? Mar 31 15:08:49 Am I on the right track? Mar 31 15:09:07 maybe. i'm not familiar with mesa. Mar 31 15:09:43 OK. That sheds more light on it. Thanks. Mar 31 15:28:43 has anyone built qtdeclarative lately (5.6-rc)? I'm getting examples/quick/quickwidgets/qquickviewcomparison/mainwindow.cpp:180:14: error: 'QCoreApplication' has not been declared Mar 31 15:37:52 denix: builds fine here with almost default configs Mar 31 15:38:24 JaMa: hmm, strange. thanks, will keep digging Mar 31 16:51:31 edbart: ping Mar 31 16:57:09 I have fixed the android-tools recipe from meta-shr, but I see it being useful for more than android, I would like to propose to move it to more common place may be oe-core is right place Mar 31 16:57:32 the native version could be used for using sparse image generation Mar 31 17:30:15 git ls-remote can now also tell you a remote repository's default branch: $ git ls-remote --symref origin HEAD Mar 31 17:30:15 nice Mar 31 17:30:40 kergoth: that's awesome, know what version git that is? Mar 31 17:30:59 reading the release notes for 2.8 Mar 31 17:31:04 ah, perfect Mar 31 17:43:18 khem: what was broken in current version? Mar 31 19:32:31 What's the correct process for patch submission for changes intended specifically for 2.2, not 2.1, given it's not yet branched? RFC for 2.2, [PATCH for 2.2], ..? Mar 31 19:33:00 don't know the correct process.. but RFC it.. and then submit it after branching Mar 31 19:33:09 but -I- ... Mar 31 19:35:03 i feel like someone should be collecting these things into a branch, and then merging that to master-next/mut after 2.2 is branched, but i don't know if that's being done or if it's much less formal and patch driven Mar 31 19:35:06 * kergoth shrugs Mar 31 19:47:01 bluelightning: have you given any thought to making a few of the hardcoded bits in devtool controllable from the metadata? Specifically 1) extra source prep, as is done for the kernel, and 2) extra externalsrc logic, as is done for the kernel (.config bits) Mar 31 19:47:51 kergoth: probably not enough, but it does sound sensible Mar 31 19:47:59 (not enough thought, I mean) Mar 31 19:49:59 for 1) i was thinking either we could do an extra parse after writing the bbappend that enables externalsrc, then examine SRCTREECOVEREDTASKS, and if we haven't run any of those yet, run them. Then any recipes/classes with extra source prep could add them there (which they probably want to anyway) and devtool would then pick that up or 2) have a task similar to do_image_complete. a 'we know all the sources are ready to go at this point', which is likely Mar 31 19:49:59 just before do_configure but after do_unpack, anything between do_unpack and do_patch, and everything between do_patch and do_configure..' Mar 31 19:50:10 not sure if that makes sense or not, but.. Mar 31 19:50:21 i'll see about opening a bug in the bts for tracking purposes Mar 31 19:51:10 i was intending to add a source preparation hook for recipes to use so they stop adding tasks and mucking with prefuncs/postfuncs, but then i realized integrating with devtool extraction might be non-trivial :) Mar 31 20:05:14 Hmm, the uninative shim was fetched, but uninative wasn't enabled. wonder why Mar 31 20:11:15 oh, nevermind, i see, it was fetched and enabled, just did so after the build configuration summary was displayed, so the NATIVELSBSTRING shown there wasn't correct Mar 31 20:12:01 its shown correctly in the second build Mar 31 20:18:32 man, it's the worst when -S printdiff shows you nothing but a list of fetch/unpack tasks Mar 31 20:18:37 i hate it when that happens Mar 31 20:19:20 wonder if my sstate cleaning is running into the issue with removal of intermediates due to lack of regular access, as was recently discussed on the list Mar 31 20:26:45 Yes, that's something we've run into as well Mar 31 20:27:19 Our plan to address the issue was to just set a size we want to keep and then periodically delete stuff that hasn't been referenced in a while Mar 31 20:27:24 No idea if that's going to work, though. **** ENDING LOGGING AT Fri Apr 01 02:59:58 2016