**** BEGIN LOGGING AT Fri Jun 17 02:59:56 2011
Jun 17 09:01:12 <bluelightning> morning all
Jun 17 15:38:02 <nitink> Good Morning All !
Jun 17 15:39:14 <bluelightning> hi nitink
Jun 17 15:39:36 <nitink> hi bluelightning
Jun 17 20:27:38 <jefferai> yocto is very gentoo-like
Jun 17 20:27:48 <jefferai> I could swear that it's very nearly using ebuilds
Jun 17 20:27:51 <jefferai> :-)
Jun 17 20:28:37 <GNUtoo> ah?
Jun 17 20:29:07 <GNUtoo> some people tend to confuse recipes with ebuilds
Jun 17 20:29:21 <GNUtoo> that create special do_patch(){
Jun 17 20:29:24 <GNUtoo> for instance
Jun 17 20:29:29 <GNUtoo> I saw recipes like that
Jun 17 20:29:43 <GNUtoo> theses were external recipes tough
Jun 17 20:30:26 <ant__> well, bitbake was inspired by portage afaik
Jun 17 20:30:34 <ant__> you'd ask kergoth
Jun 17 20:30:35 <GNUtoo> ok
Jun 17 20:31:28 <ant__> big difference OE is crosscompiling
Jun 17 20:31:38 <GNUtoo> portage can cross compile too
Jun 17 20:31:53 <ant__> sure, I was there ;)
Jun 17 20:32:00 <GNUtoo> last time I tried(some years ago, I don't use gentoo anymore) it was awfull tough
Jun 17 20:32:21 <GNUtoo> I couldn't cross compile weechat
Jun 17 20:32:51 <GNUtoo> btw there is license filtering in yocto, right?
Jun 17 20:32:52 <ant__> I'm still very happy user, I even share SRCDIR for building
Jun 17 20:33:04 <ant__> but not for cross
Jun 17 20:33:10 <GNUtoo> I quited for 2 reasons:
Jun 17 20:33:33 <GNUtoo> * ) I had to cross compile, I couldn't afford spending time compiling
Jun 17 20:33:46 <GNUtoo> * ) no separations between free and non-free
Jun 17 20:34:26 <GNUtoo> but it was well made....lot of choice was put on the hand of the user
Jun 17 20:34:30 <pidge> GNUtoo: license filtering == INCOMPATIBLE_LICENSE iirc
Jun 17 20:34:49 <GNUtoo> pidge, ok, is there COMPATIBLE_LICENSE?
Jun 17 20:34:50 <fray> ya, you set a text string and say "if you see this, ignore that package"
Jun 17 20:35:06 <pidge> GNUtoo: hrmmm.... I don't think so.
Jun 17 20:35:16 <GNUtoo> how to filter out non-free stuff?
Jun 17 20:35:27 <pidge> GNUtoo: INCOMPATIBLE_LICENSE
Jun 17 20:35:32 <fray> the problem with compatible_license is that starts leading into judgement calls, which under American law is tricky for any non-lawyer to do
Jun 17 20:35:42 <GNUtoo> lol
Jun 17 20:35:53 <GNUtoo> ah lawyers vocabulary.....
Jun 17 20:36:00 <fray> incompatible_license on the other hand is just string matching.. you see this string.. you ignore that package..  and we're consistent, within Yocto/oe-core, on the strings we use
Jun 17 20:36:14 <pidge> fray: wellllll
Jun 17 20:36:31 <fray> pidge, I know.. I'm being a bit simplistic here..
Jun 17 20:37:32 <pidge> fray: we're *mostly* consistent. this is why we have the SPDXLICENSEMAP, to weed out the inconsistencies.
Jun 17 20:37:51 <GNUtoo> let's say I want to filter all proprietary software, so I add a string containing most of the proprietary license(TI-EULA for instance) or the sgx license, but what if I miss a license, for instance someone add a new package with a new license
Jun 17 20:37:59 <fray> yup.. and SPDX should start to help over the next few months on getting more consistentcy and a better chance that the value(s) are correct
Jun 17 20:38:30 <pidge> GNUtoo: you'd verify licenses in tmp/deploy/licenses/common-licenses
Jun 17 20:38:37 <GNUtoo> ok
Jun 17 20:38:41 <GNUtoo> good idea
Jun 17 20:38:49 <pidge> and tmp/deploy/licenses/${PN}
Jun 17 20:38:56 <GNUtoo> I think I'll have to work on getting something better than that tough
Jun 17 20:39:08 <GNUtoo> since skipping at build time is better
Jun 17 20:39:15 <GNUtoo> anyway should I set $BUILDDIR ?
Jun 17 20:39:19 <pidge> if we have a generic of the license and it's in the image we dump it in common-licenses
Jun 17 20:39:34 <fray> GNUtoo use the ./oe-init-build-env (or ./poky-init-buildenv) scripting
Jun 17 20:39:44 <fray> that will setup the build directory and your envrionment..
Jun 17 20:39:44 * pidge just happens to be revamping some of this now.
Jun 17 20:39:58 <fray> if you don't want to, then you should familiarize yourself with what that script does and set that manually
Jun 17 20:39:59 <GNUtoo> fray, that's incompatible with my manual setup
Jun 17 20:40:10 <GNUtoo> I've most of it setup manually
Jun 17 20:40:26 <GNUtoo> thanks to kergoth's help
Jun 17 20:42:11 <fray> be sure to use the bitbake wrapper script and don't call bitbake/bin/bitbake..
Jun 17 20:42:15 <GNUtoo> is BUILDDIR the same as the old TMPDIR
Jun 17 20:42:22 <fray> otherwise you won't get pseudo control and you'll have permissions, owners and groups issues
Jun 17 20:42:25 <GNUtoo> I've the wrapper script
Jun 17 20:42:31 <GNUtoo> yes I was told taht
Jun 17 20:42:37 <GNUtoo> it's in the path
Jun 17 20:42:47 <fray> scripts/oe-buildenv-internal is the place where everything is defined
Jun 17 20:42:54 <GNUtoo> ok
Jun 17 20:43:13 <fray> Note, OEROOT is "temporary".. it's unset adter it's used..
Jun 17 20:43:28 <fray> the vale of OEROOT is the directory that contains the "scripts" directory..
Jun 17 20:43:43 <fray> I believe BBPATH is unset as well in the nromal case
Jun 17 20:44:24 <GNUtoo> yes
Jun 17 20:44:34 <fray> so oe-buildenv-internal sets up PATH, BUILDDIR to the build working directory, and BB_ENV_EXTRAWHITE
Jun 17 20:44:38 <fray> so that is likely all you need
Jun 17 20:44:57 <fray> the build directory is the directory in which your conf, tmp, sstate, etc all reside
Jun 17 20:45:06 <fray> 'er.. local project conf that is
Jun 17 20:45:24 <GNUtoo> ok
Jun 17 20:47:13 <GNUtoo> thanks a lot
Jun 17 20:48:37 <GNUtoo> <fray> incompatible_license on the other hand is just string matching.
Jun 17 20:48:41 <GNUtoo> is it a regexp
Jun 17 20:49:00 <GNUtoo> because if so I could match for not free licenses
Jun 17 20:53:42 <GNUtoo> nothing fills my tmpdir....
Jun 17 20:54:30 <GNUtoo> I've renamed TMPDIR to BUILDDIR
Jun 17 20:55:26 <GNUtoo> it is gone to TOPDIR
Jun 17 22:35:52 <dvhart> does anyone know the magic bitbake incantation to regenerate an image rootfs in tmp/deploy/images ?
Jun 17 22:36:18 <dvhart> rebuilding core-image-sato doesn't work, nor does cleanall'ing several of the task-base and similar
Jun 17 22:58:49 <incandescant> bitbake my-image-name -c rootfs -f ??
Jun 17 23:14:03 <dvhart> incandescant, nope :(
Jun 17 23:14:12 <dvhart> you'd think though wouldn't you?
Jun 17 23:18:36 <incandescant> I would
Jun 17 23:24:37 <ReaperOfSouls> incandescant: do you need the -c rootfs -f? Images used to never leave stamps for rootfs, so it would always rebuild. Did that change?
Jun 17 23:25:22 <incandescant> ReaperOfSouls: what you're saying sounds right but dvhart is clearly having problems :-/
Jun 17 23:25:27 <dvhart> it runs the rootfs task without -f
Jun 17 23:25:48 <dvhart> but that doesn't put the tar.bz2 image in tmp/deploy/images
Jun 17 23:25:50 <incandescant> oh, so what's going wrong?
Jun 17 23:25:58 <dvhart> ^
Jun 17 23:26:25 <dvhart> after running I would see the same old timestamp on the core-image-sato-beagleboard.tar.bz2 file
Jun 17 23:26:37 <dvhart> and after removing that file it never got regenerated
Jun 17 23:28:08 <ReaperOfSouls> incandescant: right.
Jun 17 23:30:39 <dvhart> there are two things I know how to do really well. 1) break hardware. 2) break bitbake
Jun 17 23:31:18 <Crofton> good skills
Jun 17 23:31:25 <dvhart> ;)
Jun 17 23:32:06 <dvhart> I've only sacrificed one beagleboard to the hardware gods over the course of the bsp update though
Jun 17 23:32:10 <dvhart> not too bad
Jun 17 23:38:37 <Jefro> dvhart define "sacrifice"
Jun 17 23:38:52 <dvhart> Jefro, it just stopped working out of the blue
Jun 17 23:39:13 <Jefro> I had a rev C do that, turned out I broke the power input
Jun 17 23:39:23 <dvhart> and, not having time to dink with it incandescant was kind (naive ?) enough to lend me his so I could finish
Jun 17 23:39:42 <dvhart> in this case it just started to refuse to read anything off the MMC
Jun 17 23:40:00 <Jefro> ah, the mmc readers occasionally get borked
Jun 17 23:40:15 <Jefro> you can send it back to the beagle repair shop
Jun 17 23:40:33 <dvhart> that's the plan, just as soon as I get the third and final pull request out
Jun 17 23:40:39 <dvhart> must... finish... before... weekend...
Jun 17 23:41:00 * dvhart needs to do something really nice for his build box
Jun 17 23:41:06 <dvhart> she's saved me this week :)
Jun 17 23:41:26 <Jefro> let me know if I can help with beagles, I have a few here that are doing nothing
Jun 17 23:41:40 <dvhart> Jefro, which revs?
Jun 17 23:41:52 <dvhart> I'd like to see testing on an xMrC
Jun 17 23:42:09 <dvhart> but that Robert has agreed to do that once I get bits into master
Jun 17 23:42:17 <Jefro> I have a rev C4 and a few xMs, will check the revs
Jun 17 23:43:27 <Jefro> highest I have is xMrB
Jun 17 23:44:54 <dvhart> Jefro, the B would be worth testing
Jun 17 23:45:02 <dvhart> Monday probably, I think the bits will be in by then
Jun 17 23:45:24 <Jefro> sounds like a plan
Jun 17 23:55:01 <pidge> interesting. has anyone else run into the parsing hang?
Jun 17 23:55:16 <dvhart> pidge, what are you seeing?
Jun 17 23:55:22 <dvhart> any new screen sessions listed?
Jun 17 23:55:30 <pidge> on the autobuilder
Jun 17 23:55:37 <pidge> it sits @ 98%
Jun 17 23:55:47 <pidge> like... for 5 minutes at this point
Jun 17 23:55:55 <dvhart> load?
Jun 17 23:55:58 <pidge> which is why all my internal sanity tests are failing
Jun 17 23:56:20 <pidge> 0.00
Jun 17 23:56:30 <dvhart> screen -ls
Jun 17 23:56:31 <dvhart>  ?
Jun 17 23:56:49 <dvhart> any disconnected that you don't recognize?
Jun 17 23:58:30 <pidge> dvhart: no screen sessions. vnc session however
Jun 17 23:58:40 <dvhart> hrm
Jun 17 23:59:08 <dvhart> sometimes bitbake will open something in screen that is blocking a build, but I haven't seen it during parse
Jun 17 23:59:13 <dvhart> was worth checking
Jun 17 23:59:22 <pidge> yeah. incandescant is looking at it too
Jun 17 23:59:30 <dvhart> check your python tasks and their wchan
Jun 17 23:59:35 <pidge> i thought it was an AB thing
Jun 18 00:01:10 <pidge> they all go defun at the hang
**** ENDING LOGGING AT Sat Jun 18 02:59:56 2011