**** BEGIN LOGGING AT Fri Mar 18 02:59:58 2016
Mar 18 03:54:12 <amboar> hi
Mar 18 03:54:24 <amboar> is there an easy way to extend the machines supported by the runqemu script?
Mar 18 03:54:32 <amboar> short of patching it (and runqemu-internal)?
Mar 18 03:54:40 <amboar> I've gone the patching route, but was wondering if I'd missed something
**** BEGIN LOGGING AT Fri Mar 18 04:52:37 2016
Mar 18 05:24:22 <vickylinuxer> Hi yocto, the splitted packages should be into RFS by default if it is not dbg / dev / locale.
Mar 18 05:24:32 <vickylinuxer> Am i right?
Mar 18 05:29:23 <AndroUser> Hi..
Mar 18 05:35:00 <AndroUser> How to include the splitted package into rootfs?
Mar 18 05:39:49 <vickylinuxer> Hi Yocto, How to include the splitted packages into Rootfs by default?
Mar 18 10:02:25 <Anticom> Hi all. Could someone elaborate the actual purpose of distros in yocto? I suppose in the end it's about seperation of concerns and usability and stuff. But what does a distro typically provide in yocto?
Mar 18 10:03:14 <boucman_work> Anticom: a distro is where you define "everything-wide" features of your project
Mar 18 10:04:15 <boucman_work> do you use systemd or systemV, do you support USB ? what sound system do you use ? these are typically the kind of decision ubuntu or debian make, but they don't change if you are using kubuntu vs xubuntu or x86 vs arm
Mar 18 10:04:27 <LetoThe2nd> distro is the third axis in the orthogonal space image<->machine<->distro
Mar 18 10:04:28 <Anticom> Well currently we're doing everything in our layer by modifying stuff poky already provides. I've suggested to switch to a custom distro and now i'm curious what i actually have to do
Mar 18 10:04:50 <rburton> give your distro a name, copy the poky.conf to mydistroname.conf
Mar 18 10:04:52 <rburton> done!
Mar 18 10:04:52 <Anticom> I'm currently reading 5.11 in the manual
Mar 18 10:05:23 <boucman_work> the "problem" I usually encounter is that poky is good enough for 90% of usages, so we tend to use it a lot and customize at the image level...
Mar 18 10:05:41 <LetoThe2nd> yeah, a common practise is to just grab poky or something inheriting from it, and then beat it into shape successively.
Mar 18 10:05:44 <Anticom> rburton: i can't even find poky.conf ._. isn't it supposed to be in meta/conf/distro?
Mar 18 10:05:53 <boucman_work> but yeah, even when we do custom distro, we end up copying poky and starting from there...
Mar 18 10:06:07 <LetoThe2nd> but doing that in your own, inheriting distro make it easier to forward-port
Mar 18 10:06:07 <Anticom> boucman_work: that's my plan
Mar 18 10:07:13 <Anticom> boucman_work: and "being just good enough" shouldn't stop you from improving your code base by making it cleaner ;)
Mar 18 10:07:28 <Anticom> it'll pay off some time in the future
Mar 18 10:07:54 <LetoThe2nd> the important point is the orthogonality. make the machine.conf set stuff that is hardware specific. make the image pull in stuff that the specific software project needs. make the distro set the general software platform "architecture"
Mar 18 10:09:02 <Anticom> LetoThe2nd: for example currently i'm removing stuff from DISTRO_FEATURES in our image which is provided by DISTRO_FEATURES_DEFAULT
Mar 18 10:09:15 <Anticom> And i don't think that this is how things should be
Mar 18 10:11:02 <LetoThe2nd> Anticom: well you can always setup everthing from scratch. and OE itself should support a distroless build too.
Mar 18 10:13:19 <Anticom> LetoThe2nd: My idea was to copy poky.conf in it's own layer, rename it and start hacking it
Mar 18 10:14:43 <LetoThe2nd> thats a common technique
Mar 18 10:17:27 <rburton> Anticom: poky is in meta-yocto (or meta-poky if you're tracking master, we finally renamed it)
Mar 18 10:17:40 <Anticom> rburton: found it in meta-yocto :)
Mar 18 10:17:43 <Anticom> but thanks
Mar 18 10:17:44 <rburton> poky the distro actually does very little
Mar 18 10:21:47 <Anticom> I don't need it to do much. Someone told me the other day that setting update channels for example is a things the distro should be responsible for
Mar 18 10:22:00 <Anticom> which makes perfect sense to me
Mar 18 10:22:41 <LetoThe2nd> ok, now its time for you to leave.
Mar 18 10:22:49 <LetoThe2nd> once things tart to make sense, yo're wrong here! ;-(
Mar 18 10:22:50 <Anticom> why?
Mar 18 10:22:55 <LetoThe2nd> *SCNR*
Mar 18 10:24:53 <Anticom> what's wrong about reflecting what someone told me and comming to a conclusion that he or she might be right which what he or she said?
Mar 18 10:25:03 <LetoThe2nd> sorry, that was a joke. nevermind.
Mar 18 10:25:13 <Anticom> pff nah, now i'm leaving ;
Mar 18 10:25:14 <Anticom> ;)*
Mar 18 10:25:19 <LetoThe2nd> just like "EDV -> Ende Der Vernunft"
Mar 18 10:25:42 <Anticom> LetoThe2nd: i forgett that you're speaking german way too often...
Mar 18 10:26:20 <Anticom> quick question: Is it normal to get a bunch of "NOTE: Stamp xyz is not reachable, removing related manifests" when switching the distro?
Mar 18 10:26:52 <rburton> yes
Mar 18 10:27:12 <rburton> it will need to rebuild a fairly good chunk of stuff if the distro config changes
Mar 18 10:27:16 <rburton> (even if thats just the name)
Mar 18 10:28:15 <Anticom> rburton: i don't mind. More time to drink coffee http://img1.joyreactor.com/pics/post/auto-9gag-1701645.jpeg
Mar 18 10:33:15 <Anticom> LetoThe2nd: Also i was wondering, how "architecture" was fitting in that orthogonal construct? i guess it's part of 'machine'? But how do both differ?
Mar 18 10:33:48 <boucman_work> is there anything that DOESN'T need to be rebuilt when switching distro ?
Mar 18 10:34:06 <Anticom> boucman_work: BB started with recipe #160
Mar 18 10:34:18 <Anticom> So i guess there is a very small ammount, that doesn't need to be rebuild
Mar 18 10:34:25 <boucman_work> mkay
Mar 18 10:34:30 <LetoThe2nd> Anticom: ach is part of the machine. for example both imx6 and omap4 are arm A9, but not the same machine - usually
Mar 18 10:35:07 <Anticom> LetoThe2nd: so TL;DR; arch is the bare cpu and machine all the gpio stuff that's build arround it?
Mar 18 10:35:25 <LetoThe2nd> Anticom: simplified, yes.
Mar 18 10:35:38 <Anticom> hm now i really have to leave :(
Mar 18 10:35:42 <Anticom> no more questions to ask...
Mar 18 10:36:14 <LetoThe2nd> hehe
Mar 18 10:36:25 <LetoThe2nd> have a cookie, then.
Mar 18 10:36:40 <Anticom> 1up
Mar 18 10:44:53 <boucman_work> rburton: yesterday you mentionned a script you use to build poky.git from various other git... is the manifest you use available somewhere (mainnly out of curiosity)
Mar 18 10:44:56 <boucman_work> ?
Mar 18 10:52:18 <rburton> boucman_work: i think the actual config file isn't in git
Mar 18 10:53:01 <boucman_work> ok... that would be usefull to have... at least to know what is actually contained in git.poky
Mar 18 10:53:15 <rburton> bitbake + oe-core + meta-yocto + yocto-docs
Mar 18 10:53:35 <boucman_work> yeah, but renamed... thus confusion
Mar 18 10:53:51 <rburton> what's renamed?
Mar 18 10:54:03 <boucman_work> (and it's meta-poky now :P )
Mar 18 10:54:08 <rburton> the *repo* is meta-yocto
Mar 18 10:54:23 <boucman_work> right
Mar 18 10:54:28 <rburton> i was listing repos
Mar 18 10:55:19 <boucman_work> my bad
Mar 18 11:08:20 <Anticom> Concerning RCONFLICTS, RDEPENDS, RRECOMMENDS and RREPLACES: I know i can supply some version information. However is it possible to limit the version in both directions? like (>= v2.0 && < v3.0)
Mar 18 11:35:18 <aratiu> does anyone know how I can specify a file with whitespace in its name in LIC_FILES_CHKSUM?
Mar 18 11:37:10 <Anticom> aratiu: why would you do that?
Mar 18 11:37:43 <aratiu> LIC_FILES_CHKSUM = "file://../PT Free Font License_eng_.txt;md5=(...)"
Mar 18 11:37:59 <aratiu> the original file has spaces in its name...
Mar 18 11:38:45 <Anticom> aratiu: well if you don't want to rename the license file try "file://../PT\ Free\ Font\ License_eng_.txt;md5=(...)"
Mar 18 11:38:53 <Anticom> dunno whether that works or not
Mar 18 11:39:04 <Anticom> but that's how linux typically handles whitespaces afaik
Mar 18 11:39:15 <rburton> depending how much of URI parsing that  line goes though, %20 instead of space might work
Mar 18 11:39:44 <Anticom> I'm not an expert in licensing stuff but does it actually matter, what the file name of the file containing the license is?
Mar 18 11:39:53 <Anticom> i suppose important is the content not the actual file name
Mar 18 11:40:01 <Anticom> i'd probably just rename the damn thing ;)
Mar 18 11:40:11 <rburton> that would mean renaming a file in an upstream tarball right?
Mar 18 11:40:24 <Anticom> rburton: or patching it during build
Mar 18 11:40:40 <rburton> %20 should work
Mar 18 11:40:44 <aratiu> tried escaping but bitbake gives expansion errors, and with %20 it tries to search literally the file with %20 in filename
Mar 18 11:41:05 <rburton> hm
Mar 18 11:41:15 <Anticom> aratiu: have you tried my suggestion?
Mar 18 11:41:21 <aratiu> ah sorry %20 works :D
Mar 18 11:41:24 <Anticom> lol
Mar 18 11:41:34 <aratiu> thank you very much!
Mar 18 11:41:47 <rburton> remember its a uri so usual uri rules apply
Mar 18 11:41:49 <Anticom> rburton: 1 - Anticom: 0
Mar 18 11:41:51 <Anticom> :(
Mar 18 13:57:53 <igor3> hi
Mar 18 13:58:06 <igor3> someone can help me with a problem?
Mar 18 13:58:19 <rburton> ask away, don't ask to ask
Mar 18 13:58:29 <igor3> ok
Mar 18 13:59:19 <igor3> I made a recipe that rprovides, rconflicts and rreplaces initscripts
Mar 18 13:59:51 <igor3> then I put on my layer.conf the PREFERRED_PROVIDER_initscripts = "initscripts"
Mar 18 14:00:34 <igor3> So I installed my package that rreplaces the initscripts on my image
Mar 18 14:01:27 <igor3> but there is another image that I did not installed this package, but this image is installing my recipe instead initscripts
Mar 18 14:02:06 <igor3> I ran bitbake -g and the second image does not depends on my package
Mar 18 14:04:23 <boucman_work> igor3: layer.conf influences all recipes that include that layer. you probably don't want to add  PREFERRED_PROVIDER there
Mar 18 14:04:28 <igor3> I tryied to see the -DDD -v logs, but I did not see anything that would make it happens
Mar 18 14:04:42 <boucman_work> you should either add it in your image's recipe or add a condition on your image name for that variable
Mar 18 14:05:23 <boucman_work> you can try bitbake -e <the image that bugs> into a pager to see where the variable PREFERRED_PROVIDER is manipulated
Mar 18 14:05:34 <igor3> but I want everybody to use the preferred_provider unless my image
Mar 18 14:05:44 <igor3> hummm
Mar 18 14:05:46 <igor3> nice
Mar 18 14:06:21 <boucman_work> i'm not 100% sure what you want to do...
Mar 18 14:06:33 <igor3> let me try to explain
Mar 18 14:06:55 <igor3> I have a layer that produces 3 images
Mar 18 14:07:19 <igor3> I want to change the initscripts only for one image
Mar 18 14:07:57 <igor3> but all images are using the changed initscripts instead default initscripts
Mar 18 14:08:12 <igor3> I made the samething with base-files
Mar 18 14:08:16 <igor3> and it worked
Mar 18 14:08:24 <igor3> but with initscripts it is not working
Mar 18 14:08:50 <boucman_work> well, I would put the PREFERRED_PR in the image that needs it then...
Mar 18 14:09:00 <igor3> humm...
Mar 18 14:09:03 <igor3> intersting
Mar 18 14:09:04 <boucman_work> i'm not sure about base-files, though, i'd have to look at the specifics...
Mar 18 14:09:09 <igor3> I did not know about that
Mar 18 14:10:05 <boucman_work> another method would be to set PREFERED_PROVIDER_initscripts_pn-<the image that needs it> = "your recipe"  in your layer.conf
Mar 18 14:10:21 <boucman_work> but since the change is logically part of the image, putting it in the image makes more sense
Mar 18 14:10:27 <igor3> I made a recipe called something-base-files.bb that RREPLACES, RPROVIDES and RCONFLICTS with base-files, then I put on my layer.conf that the preferred_pr is base-files, so I installed something-base-files on my image.
Mar 18 14:10:54 <igor3> That tip is nice
Mar 18 14:10:58 <igor3> I will try that
Mar 18 14:11:05 <igor3> thank you very much sir
Mar 18 14:26:34 <rburton> JaMa: your grub docs bug is a good one - i can replicate outside of oe which makes me wonder how it builds for me in oe…
Mar 18 14:26:39 <rburton> the fix is trivial though
Mar 18 15:22:09 <JaMa> rburton: cool that someone likes bugs reported by me
Mar 18 15:26:46 <rburton> haha
Mar 18 15:27:03 <rburton> usually yours are a pain ;)
Mar 18 15:28:55 <JaMa> and more to come as nobody seems to read the world/dependencies reports on ML
Mar 18 15:29:15 <rburton> i do skim it to see if anything in oe-core is breaking unexpectedly
Mar 18 15:29:33 <rburton> do you know why your builds hit that? as i said, the tarballs ship the generated documentation
Mar 18 15:31:21 <JaMa> no
Mar 18 15:32:42 <JaMa> and builders are already running another builds so I cannot check log.do_configure in wiped out tmpfsi
Mar 18 15:32:45 <JaMa> or re-run it
Mar 18 16:00:36 <kergoth> i skim the world builds too, just have too much crap on my todo already to take on anything else. i have fond memories of when i had enough spare time to fix random issues with recipes i don't use..
Mar 18 16:00:42 <kergoth> heh
Mar 18 16:31:07 <rburton> JaMa: getting a bit confused with the comments on 9201, are you saying that bill's patch should replace yours?
Mar 18 16:31:33 <rburton> if not, can you re-test with bills patch?
Mar 18 17:05:36 <JaMa> rburton: I was saying that I've already tried that and for whatever reason it didn't work for me
Mar 18 17:07:07 <JaMa> rburton: but if it works for Bill then feel free to merge it
Mar 18 17:45:03 <bottazzini> There is a flag in my CFLAGS that I'd like to exclude, is it possible ?
Mar 18 17:45:45 <Ulfalizer> CFLAGS_remove = "--option"
Mar 18 17:46:04 <Ulfalizer> might be cleaner ways to handle it depending on the circumstances though
Mar 18 17:46:56 <bottazzini> Ulfalizer, thanks I was looking everywhere for this info
Mar 18 17:47:52 <Ulfalizer> _remove should be documented in the bitbake manual
Mar 18 17:51:16 <bottazzini> Ulfalizer, Yes it contains i just looked for wrong keywords
Mar 18 17:51:28 <Ulfalizer> ok, np :)
Mar 18 17:51:40 <bottazzini> ;)
Mar 18 18:40:37 <otavio> rburton: I sent an U-Boot bump, for last release. Could you please queue it for MUT?
Mar 18 18:55:32 <riz__> I am doing a build with meta-qt5 and I keep getting the following error: http://pastebin.com/YsgSuLnc
Mar 18 18:55:38 <riz__> I am having trouble finding a fix
Mar 18 18:55:51 <riz__> Any ideas on what might need to be done?
Mar 18 23:58:43 <kergoth> Hmm, it'd be nice if we had a -S dumpsig, as a convenience. possibly only if a task is provided, and only for that task, not its deps, but still
Mar 19 00:03:12 <kergoth> Hmm. afaict only *tasks* run prefuncs/postfuncs, yet the dependency code includes prefuncs/postfuncs in function checksums, not only tasks
Mar 19 00:23:48 <kergoth> err.. I just noticed we include variable flags for variables we depend on in the checksum (minus excludes), but we don't actually include flags we explicitly use!
Mar 19 00:46:38 <kergoth> WIP: https://github.com/MentorEmbedded/poky/compare/master...kergoth:bitbake-track-var-flag-refs, also WIP: https://github.com/MentorEmbedded/poky/compare/master...kergoth:task-level-exports
Mar 19 00:46:42 <kergoth> hrm
Mar 19 00:50:58 <kergoth> of course the flag thing doesn't actually affect much in practice, since most flags are used to adjust behavior in anonymous python and whatnot, or either the varname or flag isn't a fixed string, but still
**** ENDING LOGGING AT Sat Mar 19 02:59:58 2016