**** BEGIN LOGGING AT Tue May 26 02:59:58 2015
May 26 08:22:23 <bluelightning> morning all
May 26 08:25:38 <parrot> bluelightning: good afternoon
May 26 10:49:29 <[w00t]> Hi, I would like to create a recipe for setting up a virtual environment and installing python packages in this environment using pip, is this possible? I would like to do it when building and not while running as some packages require gcc which won't be available in the target.
May 26 10:53:34 <rburton> [w00t]: that's what virtualenv is for, right?  run virtualenv in the recipe's build step, package the results
May 26 10:54:02 <rburton> you'll end up with symlinks to python that you'll need to fix up or at least check
May 26 10:55:02 <[w00t]> rburton: Ok, thanks. I'm still a bit confused when it comes to recipes
May 26 11:27:42 <Valentin_> hi all!
May 26 11:28:14 <Valentin_> somebody here works with edison?
May 26 11:28:53 <blitz00> Hi. Is someone familiar with changes in make > 3.81? I'm trying to understand why a projects fails to build (it can't find a headers) with make 4 but it builds just fine with make 3.81. Looking at the makefile, I can see that the include path is actually wrong so it's actually correct that make4 fails, but somehow make 3.81 figures out the correct path and I can't understand why....
May 26 11:42:36 <LetoThe2nd> whats the most elegant way if i want to replace linux-yocto with my own tree for the qemuarm target?
May 26 11:42:57 <LetoThe2nd> creating a linux-yocto-custom recipe
May 26 11:42:57 <LetoThe2nd> ?
May 26 11:43:53 <Crofton|work> liekly
May 26 11:44:50 <LetoThe2nd> hmhm
May 26 11:55:23 <ericbutters> WARNING: busybox: alternative target (/etc/syslog.conf or /etc/syslog.conf.busybox) does not exist, skipping... WARNING: busybox: NOT adding alternative provide /etc/syslog.conf: /etc/syslog.conf.busybox does not exist WARNING: alt_link == alt_target: /etc/syslog.conf == /etc/syslog.conf
May 26 11:55:30 <ericbutters> why? how to fix?
May 26 12:55:11 <jaeckel> is there some howto on implementing your own packaging format in yocto?
May 26 13:14:08 <ncgs> Does anybody know what package provides qmake tool for ontarget app preparing?
May 26 13:20:59 <bluelightning> ncgs: qt4 or qt5? embedded or x11?
May 26 13:21:22 <ncgs> hi! qt5,   embedded
May 26 13:24:19 <bluelightning> ncgs: I think qtbase-tools
May 26 13:26:34 <ncgs> There is not such package, there is qttolls, but the package doesn't include qmake
May 26 13:27:08 <ncgs> That's why I'm asking)))
May 26 13:27:08 <bluelightning> ncgs: when you say there is no such package, how are you determining that?
May 26 13:28:15 <ncgs> bitbake qtbase-tools -> ERROR: Nothing PROVIDES 'qtbase-tools'. Close matches: qttools, alsa-tools
May 26 13:29:20 <bluelightning> ncgs: qtbase-tools is a package; what bitbake expects on the command line is a recipe, not a package
May 26 13:29:59 <bluelightning> you can either "bitbake qtbase" (since qtbase is the recipe that produces the qtbase-tools package), or, perhaps more appropriately, add qtbase-tools to your image
May 26 13:32:48 <ncgs> Thank you. you are right, I've just checked tpm package and see qmake inside. Thanks.
May 26 13:35:29 <bluelightning> ncgs: no problem
May 26 14:39:50 <pokynewb> hi, can anyone help with a poky-daisy busybox configuration question?  I'm creating a busybox_%.bbappend with a custom defconfig fragment in order to set a few CONFIG_<prop> values to "n", but the .config ends up with all of my properties saying "is not set" instead of "=n"
May 26 14:40:27 <pokynewb> how can I get my CONFIG_* properties to be set to "=n" instead of "is not set"?
May 26 14:42:07 <bluelightning> pokynewb: "is not set" is the way that the option being disabled is recorded in kconfig
May 26 14:42:58 <bluelightning> so unless something else is happening it sounds like it is working as expected
May 26 14:43:02 <pokynewb> the problem is that when my property "is not set", the functionality is still being compiled into busybox
May 26 14:43:40 <pokynewb> if I "bitbake -c configure busybox", then manually set the property "=n", then it is compiled out
May 26 14:44:49 <pokynewb> the "<property> is not set" behaves differently than the "<property>=n"
May 26 14:45:29 <bluelightning> pokynewb: I'm not sure what's going on then, but AFAIK "is not set" is the expected way of something being turned off in kconfig, if busybox's build is interpreting it differently then it's probably not correct
May 26 14:47:19 <pokynewb> ok, I'll have to look more into the "is not set" behavior, but I find it strange that if I explicitly set some "CONFIG_<prop>=n", then it ends up as "# CONFIG_<prop> is not set" instead of the value that I explicitly told it to use ("n")
May 26 14:48:27 <pokynewb> and ultimately I would not care if the "# CONFIG_<prop> is not set" resulted in that component being excluded from busybox; but that's not what I'm seeing
May 26 14:48:27 <bluelightning> pokynewb: all I know is, if I run "make menuconfig" in the kernel, and turn an option off, I get "is not set" - I do not get "=n"
May 26 14:49:07 <bluelightning> so =n may not even be expected as a legal value
May 26 14:49:17 <pokynewb> the related problem might be that the default value for that CONFIG_<prop> is "y", so if it "is not set", then it ends up as "y"
May 26 14:50:05 <pokynewb> the "=n" is a valid value, but I can only get it to stick if I go through the "do_configure" step, manually update the defconfig file to "=n", then finish building busybox
May 26 14:50:13 <pokynewb> that results in the component being excluded
May 26 14:51:54 <pokynewb> maybe I'll patch the Config.in file to set the default to "n", that way "is not set" will result in "n" instead of "y"...?
May 26 14:52:13 <bluelightning> pokynewb: what makes you say "n" is a valid value?
May 26 14:52:37 <pokynewb> because "n" works exactly as I need it to
May 26 14:52:37 <bluelightning> pokynewb: if you look at various defconfigs for busybox around the place, none of them have =n for any values
May 26 14:53:08 <pokynewb> I know, but setting it to "=n" is the only way that I can get the component to be compiled out/omitted
May 26 14:53:49 <pokynewb> Is there some other way to get a component out of busybox?
May 26 14:55:37 <bluelightning> I'm no busybox expert by any means, but it seems to me if a value is at "is not set" in the final config (as in the .config that appears in the build directory for busybox) and the feature is still being enabled, then there is a bug in how that option is being handled within busybox's build scripts
May 26 14:56:35 <bluelightning> silly question, but just to be sure, are you looking at that final .config in order to determine the value that's actually going into busybox's build process?
May 26 14:57:04 <pokynewb> Yep, I'm looking at the final .config
May 26 14:57:12 <pokynewb> I think that if a property "is not set", then the default value will be applied.  In my specific case, I'm trying to disable udhcp
May 26 14:57:30 <bluelightning> ok - perhaps you could pastebin your config fragment so I could try it here?
May 26 14:57:53 <pokynewb> If I look at the <busybox_src>/networking/udhcp/Config.src, the default value for that property is "y"
May 26 14:58:11 <pokynewb> so when it "is not set", then it results in "y"
May 26 14:59:28 <bluelightning> I don't think that's how it's supposed to work
May 26 14:59:42 <pokynewb> my config fragment is literally 2 lines:
May 26 14:59:54 <pokynewb> CONFIG_UDHCPD=n
May 26 14:59:54 <pokynewb> CONFIG_UDHCPC=n
May 26 15:00:32 <pokynewb> if I don't include my config fragment, the .config ends up with those 2 properties as "=y"
May 26 15:01:01 <pokynewb> if I DO include my config fragment, then they end up as "is not set", but the UDCHP daemon and client are still included in the busybox build
May 26 15:02:27 <bluelightning> ok, let me try something here
May 26 15:02:49 <bluelightning> in these circumstances I tend to hope that someone who knows better than I do pipes up with the solution
May 26 15:03:52 <abelloni> VARIABLE=n is not a valid kconfig statement
May 26 15:04:01 <bluelightning> that's what I'd assumed
May 26 15:04:52 <pokynewb> then how do I get a component to be excluded from the busybox build? "# CONFIG_<prop> is not set" does not result in the component being excluded if the default value is "y"
May 26 15:05:29 <pokynewb> it the default value is "n" and the "# CONFIG_<prop> is not set", then I believe that the component is excluded
May 26 15:06:51 <pokynewb> *if, not "it"
May 26 15:07:07 <abelloni> # CONFIG_<prop> is not set is the correct way to unselect
May 26 15:07:27 <pokynewb> but if the default value is specified as "y", then "is not set" results in "y"....?
May 26 15:07:43 <abelloni> no, it results in # CONFIG_<prop> is not set
May 26 15:07:54 <pokynewb> which results in the component being compiled into busybox
May 26 15:07:56 <pokynewb> try it
May 26 15:08:12 <bluelightning> I am, right now ;)
May 26 15:08:15 <pokynewb> add a config fragment that disables CONFIG_UDHCPD and CONFIG_UDHCPC
May 26 15:10:06 <pokynewb> if you end up with a "/etc/udhcpc.d" directory, then it still compiled udhcpc into busybox
May 26 15:12:51 <abelloni> /etc/udhcpc.d is probably not coming from busybox
May 26 15:12:59 <pokynewb> yes it is
May 26 15:13:27 <pokynewb> because if I explicitly set CONFIG_UDHCPC=n in the .config, then it is not in my build
May 26 15:13:36 <bluelightning> the code in our recipe that writes files into that directory only writes them if CONFIG_UDHCPC=y is not found in the .config file - but you said that wasn't the case...
May 26 15:14:10 <pokynewb> not sure that I understood that last statement
May 26 15:14:12 <abelloni> pokynewb: it may be coming from your recipe but not from busybox
May 26 15:14:20 <bluelightning> hmm let me rephrase
May 26 15:14:30 <bluelightning> the code in our recipe that writes files into that directory only writes them if CONFIG_UDHCPC=y *is* found in the .config file - but you said that wasn't the case...
May 26 15:14:44 <bluelightning> (sorry)
May 26 15:15:12 <pokynewb> I think it also depends on the default value specified for the CONFIG_UDHCPC property
May 26 15:15:53 <abelloni> because at one point, if you don't explicitely set it, it ends up in you .config
May 26 15:16:05 <abelloni> the best would be to check you .config
May 26 15:16:15 <abelloni> you probably have a mistake in your fragments
May 26 15:16:45 <pokynewb> but I cannot figure out any way to explictly UNSET it.  If I unset it in my defconfig fragment, then it falls back to the default value, which in this case is "y
May 26 15:16:51 <bluelightning> ok, so I just tried with master - I very definitely do not get /etc/udhcpc.d if I have both of those options turned off via a config fragment with two "is not set" comments in it
May 26 15:17:04 <bluelightning> I am just trying the default build for comparison
May 26 15:17:08 <pokynewb> ah
May 26 15:17:18 <bluelightning> right, and now I do get that dir
May 26 15:17:23 <bluelightning> so it appears to be working here
May 26 15:17:31 <pokynewb> are you on daisy branch?
May 26 15:17:40 <bluelightning> no, but I can quickly run that same test on daisy
May 26 15:17:52 <kergoth> pktdans: afaik you want `# CONFIG_FOO is not set`, not `CONFIG_FOO=n`
May 26 15:17:58 <kergoth> at least, that's how kconfig typically works
May 26 15:18:02 * kergoth shrugs
May 26 15:19:03 <pokynewb> ok, if bluelightning was able to get UDHCPC compiled out of busybox with the "# CONFIG_UDHCPC is not set" in the .config file, then it must be working properly and I have something else going on
May 26 15:19:32 <abelloni> do you correctly have a space between # and CONFIG?
May 26 15:19:52 <pokynewb> I think so, but let me check
May 26 15:21:06 <pokynewb> yes, there is a space between "#" and "CONFIG"
May 26 15:22:13 <pokynewb> the defconfig file in the busybox source dir is getting updated properly with my "CONFIG_UDHCPC=n", and the resulting .config says "# CONFIG_UDHCPC is not set"
May 26 15:22:33 <pokynewb> so I think that the configuration stuff is being processed correctly
May 26 15:22:51 <pokynewb> I just need to figure out why I'm still getting UDHCPC in my build if it "is not set"
May 26 15:23:40 <bluelightning> yep, just confirmed, same thing works on daisy also
May 26 15:24:42 <bluelightning> pokynewb: here is what I used in my fragment: http://pastebin.com/Lk3esjWB
May 26 15:25:28 <pokynewb> ok, thanks for verifying.  I'll keep working at it
May 26 15:26:35 <bluelightning> I think the conclusion is you definitely shouldn't be using =n
May 26 15:26:56 <pokynewb> ok, I'll switch to "is not set" in my defconfig fragment
May 26 15:28:00 <bluelightning> FWIW, I had noticed a while ago that you don't seem to get a warning on invalid values in config fragments, that ought to be fixed
May 26 15:31:11 <pokynewb> holy crap, it looks like it's working for me now
May 26 15:31:20 <pokynewb> thanks for the assistance everyone!
May 26 15:31:36 <joseppc> any experiences in building yocto on fedora 22? (or gcc 5 in general)
May 26 18:29:58 <WarheadsSE> All, is this still an issue? http://patchwork.openembedded.org/patch/6181/ --- git/svn w/ SRCREV being a tag vs the hash value
May 26 20:14:54 <raffo> Hello, anyone available to talk to a bitbake newbie?
May 26 21:37:28 <bltzfsck> can anybody point me to a good primer on using /sys/class/gpio?
May 26 21:38:56 <bltzfsck> i have a bash script that blinks an led over wifi, but the nomenclature is pretty obscure to me
May 26 22:24:06 <abelloni> bltzfsck: it actually depends on the SoC
May 26 22:35:28 <k_j> hello
May 26 22:35:58 <k_j> can yocto be used to build a complete cross-compilation toolchain?
May 26 22:36:14 <k_j> i don't need a whole system
May 26 22:37:59 <neverpanic> yes, I think it can
May 26 22:44:48 <Marex> k_j: yeah, bitbake meta-toolchain
May 26 22:45:06 <Marex> k_j: it would spit out tmp/deploy/sdk/ where the whole toolchain installer is present
May 26 22:45:30 <k_j> Marex, i could build a complete toolchain (gcc hopefully) for every target i like?
May 26 22:47:23 <k_j> Marex, i am completely new to yocto, but my understaning is that building a toolchain for cross-compiling for a specific arch is as easy as modifying some configuration file and invoke the building. is this right?
May 26 22:47:55 <Marex> k_j: for ones which are supported
May 26 22:47:59 <Marex> k_j: unless you add your own
May 26 22:48:03 <k_j> is armv7 supported?
May 26 22:58:38 <Marex> k_j: yeah
May 26 22:58:48 <k_j> thx
May 26 22:58:48 <Marex> k_j: if you mean armv7a, then sure
May 26 22:59:02 <Marex> k_j: you might want to take a simple peek at how beagleboard is built
May 26 22:59:09 <Marex> k_j: that's armv7a and it's supported by stock yocto
May 26 23:04:21 <k_j> thx
May 27 00:57:36 <bltzfsck> abelloni: you still there?  i had to step away.  im running yocto on an edison
May 27 01:07:31 <Marex> bltzfsck: you still need the help about GPIO or something ?
May 27 01:07:56 <Marex> bltzfsck: did you read for example https://www.kernel.org/doc/Documentation/gpio/sysfs.txt ? :)
May 27 01:17:50 <Marex> bltzfsck: btw he's French, I doubt he'd be around now (it's 2 or 3 am in there now)
**** ENDING LOGGING AT Wed May 27 02:59:59 2015