**** BEGIN LOGGING AT Mon Jan 16 02:59:57 2012 Jan 16 09:53:09 morning all Jan 16 16:23:56 gm all Jan 16 16:40:17 hey (hopefully a quick question)... I'm working on adding a really simple package to my build. It only requires the libc to exist, so I assume I watn DEPENDS = "virtual/libc"? But I also want it to build as a native/nativesdk package. For that do I need to have a DEPENDS_virtclass-native = "" or? Jan 16 16:40:37 I did a quick grep and didn't see a lot of things in the system have a hard dependency on virtual/libc -- so I'm wondeirng if I'm doing this wrong Jan 16 16:41:57 fray: I think we have logic in base.bbclass to add that dependency already Jan 16 16:42:21 ok, so then if I had a package that ddin't have a dependency on the libc -- what would I do to specify that? Jan 16 16:42:24 DEPENDS = "" ? Jan 16 16:44:42 fray: I think you may have to set INHIBIT_DEFAULT_DEPS = "1" Jan 16 16:44:52 and then fully specify the dependencies in DEPENDS Jan 16 16:44:54 ahhh.. ok.. thats what I was missing.. Jan 16 16:45:02 ok, I get it now.. I knew I was missing something minor Jan 16 17:00:45 im having an issue with SSTATEPOSTINST Jan 16 17:01:02 i *think* it's getting executing before the sstate_unpack_package is finished executing Jan 16 17:01:12 which is causing the task to fail Jan 16 17:03:32 master seems to be broken. building from scratch, there seems to be a circular dependency chain once the initial (pseudo) build stage completes Jan 16 17:03:51 what is the dep chain repoted? Jan 16 17:03:58 (/data/poky_builds/poky/meta/recipes-gnome/gtk+/gtk+_2.24.8.bb, do_compile) (dependent Tasks ['gtk+, do_configure']) Jan 16 17:04:09 Hmm Jan 16 17:04:14 fray, I'll pastebin the whole thing, one sec Jan 16 17:04:56 http://pastebin.com/zSHPtaRC Jan 16 17:05:47 dollars to donuts its the most recent commit Jan 16 17:06:20 odd Jan 16 17:07:07 confirmed - it's that commit Jan 16 17:07:25 which adds gtk+ to DEPENDS of gconf Jan 16 17:07:33 RP__, ^^ Jan 16 17:07:49 zenlinux: rats. Someone would hope the author tested that :/ Jan 16 17:24:30 RP__: did you see my issue above? Jan 16 17:54:57 msm: I saw the comment, I haven't looked into it Jan 16 18:02:30 zenlinux: fix pushed for that Jan 16 18:02:39 thanks RP__ Jan 16 18:48:38 RP__: if you care to look at the log: Jan 16 18:48:38 https://gist.github.com/1622285 Jan 16 18:49:22 its hard to reproduce, i was thinking about adding a lock around SSTATEPOSTINSTFUNC and sstate_unpack_package Jan 16 18:49:36 and rerunning on our build machine which is seeing hte issues Jan 16 18:49:45 this takes like 12 hours to get to the point... Jan 16 19:08:11 otavio: you around? I seem to have misplaced the information you gave me about the tools that can monitor upstreams like sourceforge Jan 16 19:14:58 ok.. I have a Makefile that is doing: Jan 16 19:15:05 PYLIBVER ?= $(shell python -c 'import sys;print "python%d.%d" % sys.version_info[0:2]') Jan 16 19:15:05 PYINC ?= /usr/include/$(PYLIBVER) Jan 16 19:15:05 PYLIB ?= /usr/lib/$(PYLIBVER) Jan 16 19:15:05 PYTHONLIBDIR ?= $(LIBDIR)/$(PYLIBVER) Jan 16 19:15:13 what is the correct way to do that in a recipe? Jan 16 19:15:31 I was looking for an example and didn't directly see one Jan 16 20:00:13 msm: still there? Jan 16 20:00:25 msm: I'm looking at the code but I can't see a race there :/ Jan 16 20:04:17 fray: export PYLIB = "xxx" Jan 16 20:04:35 telling me to do that, or is there a value already set? Jan 16 20:04:57 RP__: i dont think it's a race anymore Jan 16 20:05:03 fray: I doubt we have such an export unless its from one of the python classes Jan 16 20:05:13 RP__: i think its a subtle issue Jan 16 20:05:25 ok.. thats what I thought.. what I'm going to have to do is ensure python-native has been built.. adn then just execute the command to get the version value.. Jan 16 20:05:26 fray: There is some global python X.Y version variable Jan 16 20:05:41 with sstate Jan 16 20:05:48 shadow-sysroot sstate package is not getting created Jan 16 20:06:02 therefore the sstate-postfunc can't run and won't work Jan 16 20:06:18 shadow-sysroot is just a package with /etc/login.defs Jan 16 20:06:30 AFAICT that file is actually included in the shadow recipe Jan 16 20:06:36 fray: FWIW you can do PYTHON = "python${@sys.version_info[0:2]}" Jan 16 20:06:47 RP, something that bitbake/classes are storing to say what version of python we use? or pulling from the in memory python? Jan 16 20:07:07 problem with that is the running version of python may be different from targeted version of python Jan 16 20:07:22 i.e. python 2.7 is the default now.. but I'm still running w/ 2.6 on my host.. Jan 16 20:07:37 fray: See default-versions.inc PYTHON_BASEVERSION ?= "2.7" Jan 16 20:08:07 fray: We ended up hardcoding that for various reasons (see the git logs for that change) Jan 16 20:08:28 fray: "hardcoding" meaning specify the python version explicitly Jan 16 20:09:34 so I can just do PYLIBVER = "python$PYTHON_BASEVERSION" Jan 16 20:09:44 and get a reasonable result? Jan 16 20:09:47 msm: ah, because we don't include ${sysconf} in the default staging? Jan 16 20:09:56 fray: yes Jan 16 20:10:04 fray: missing {} Jan 16 20:10:07 RP__: that could be it, which would explain why useradd stuff is failing too Jan 16 20:10:23 RP__: where do we specific sysconf in staging? Jan 16 20:10:56 of course Jan 16 20:11:51 msm: Try adding sysroot_stage_all() { Jan 16 20:11:51 sysroot_stage_dir ${D}${sysconfdir} ${SYSROOT_DESTDIR}${sysconfdir} Jan 16 20:11:51 } Jan 16 20:12:16 RP__: k, i'll report back in a bit Jan 16 20:12:42 msm: I'm curious why our tests don't show this up Jan 16 20:13:04 RP__: im on josh's edison 1.1.1 Jan 16 20:13:06 if that helps Jan 16 20:13:13 explain anything Jan 16 20:14:20 also, i've got meta-oe enabled currently too Jan 16 20:15:02 msm: tbh, the shadow_sysroot_sstate_postinst() in that recipe just looks wrong Jan 16 20:15:12 msm: should be replaced with the above code Jan 16 20:16:02 * RP__ remembers some long conversations about that function :/ Jan 16 20:16:10 zenlinux: ^^^ Jan 16 20:16:22 zenlinux: You might remember more about this than I do? Jan 16 20:24:20 RP__: above code? Jan 16 20:26:31 RP__: as in it can be dropped completly? Jan 16 20:27:35 msm: the function I mentioned can be replaced with the one line function I mention above Jan 16 20:28:04 right the sstate-postinc-shadow-sysroot ? Jan 16 20:28:12 postinst* Jan 16 20:31:17 ok.. what is the variable to get the path to the sysroot so I can choose include files? Jan 16 20:35:04 fray: SYSROOT_INCDIR? Jan 16 20:35:16 thank you.. I'm not sure why I couldn't find it Jan 16 20:37:54 why is my grep not finding any instances of SYSROOT_INCDIR? Jan 16 20:39:45 STAGING_INCDIR? Jan 16 20:41:03 ya thats it.. Jan 16 20:41:13 STAGING always throws me because I think it's the temporary directory in work Jan 16 20:47:46 all the variables always throw me Jan 16 20:47:47 =) Jan 16 21:20:05 heh, we should probably work on transitioning to more consistent terminology Jan 16 21:32:12 ugh Jan 16 21:32:30 my tmp/work/ppce500v2-fsl-linux-gnuspe/shadow-sysroot-4.1.4.3-r1/temp/log.do_populate_sysroot_setscene Jan 16 21:32:37 has the following error: Jan 16 21:32:45 install: cannot stat `/local/home/mattsm/git/poky/build_mpc8572ds_release/tmp/work/ppce500v2-fsl-linux-gnuspe/shadow-sysroot-4.1.4.3-r1/image/etc/login.defs': No such file or directory Jan 16 21:33:03 except that file exists (after i check on the bitbake command at least) Jan 16 21:34:04 msm, it's a race condition Jan 16 21:34:12 we have a bug filed for that, one sec Jan 16 21:34:22 hmm Jan 16 21:34:27 http://bugzilla.pokylinux.org/show_bug.cgi?id=1721 Jan 16 21:34:54 I've been so buried in other things I have yet to get to the bottom of it. This week I'm hopeful to. Jan 16 21:35:08 that would be the one Jan 16 21:36:46 this is also affecting 1.1.1 =) Jan 16 21:37:10 yep :( Jan 16 21:37:45 do you have any idea about what's causing it? i have time to look at it Jan 16 21:38:17 my first thought was the sstate extraction was occurring asynchronously Jan 16 21:40:21 hmm Jan 16 21:40:39 that bug explains the useradd recipes Jan 16 21:40:44 but shadow-sysroot doesnt have useradd Jan 16 21:40:56 unless i've overlooked it Jan 16 21:41:02 (fyi im seeing all the errors) Jan 16 21:41:52 it seems like it has to be something occuring out of sync Jan 16 21:41:56 shadow-sysroot is a good baseline Jan 16 21:41:59 its so simple Jan 16 21:42:08 its just installing one file Jan 16 21:42:19 and so copying the one file from sstate-cache should be trivial Jan 16 21:43:39 and why don't other packages like base-passwd fail this way - it's doing almost the exact same thing Jan 16 21:44:32 msm, RP__ noted something about the need to declare dependencies between setscene tasks, which BitBake currently does not support. So something will need to be added to provide that. Jan 16 21:46:19 zenlinux: well my observation is different - shadow-sysroot is so simple Jan 16 21:46:28 it should not depend on any other setscene tasks except it's own Jan 16 21:47:48 (the useradd ones might be different) Jan 16 21:51:44 also I think the fix RP mentioned earlier may remove the need for the sstatepostinstfuncs Jan 16 21:53:35 msm, have you had a chance to test that? Jan 16 21:54:01 that would likely be the first thing I'd try, but I won't have time to sit down with this until tomorrow Jan 16 21:54:33 ill have to go through an remove the useradd sstatepostinstfunc Jan 16 21:54:40 not sure all what it's doing Jan 16 21:55:20 im sure the thing will build problem is testing the permutations w/ sstate cache Jan 16 21:55:38 sstatepostinstfunc's are typically used when a recipe needs to do something other than just deploy static files (e.g, dynamically run a command which changes files, such as useradd/groupadd) Jan 16 21:56:02 is useradd sstatepostinstfunc doing more? Jan 16 21:56:55 I'm pretty sure that's all it's intended to do Jan 16 21:57:36 ok, but why do we need to run groupadd? won't we have the files we need to deploy in sstate-cache? (im not sure all of what groupadd does) Jan 16 21:58:14 a recipe could specify that it uses groups without needing to create user accounts Jan 16 21:58:58 also, we need to be mindful of the order we perform the addition of users vs. groups - new groups must be created first Jan 16 22:00:17 zenlinux: right, but that information will be encoded in the sstate-cache hash Jan 16 22:00:29 so if you change it it will rebuild all the packages sstate-cache Jan 16 22:00:55 and consequently, you just need to copy /etc/group and /etc/passwd from the sstate-cache - you don't need to rerun anything after the inial pass Jan 16 22:01:00 initial* Jan 16 22:01:20 (maybe) Jan 16 22:02:51 copying the group and passwd files from where? I'm missing some context here Jan 16 22:03:14 Are you talking about the base-passwd recipe or a recipe which inherits useradd? Jan 16 22:04:51 I ask because recipes which inherit useradd do not create static group and passwd files to be copied - they need to run dynamic commands to modify pre-existing group and passwd files Jan 16 22:06:42 The big pain here is that we need to modify group and passwd files in the sysroot, so pseudo can use them when generating the rootfs Jan 16 22:07:23 ok, i think im following Jan 16 22:07:39 so the pristine files are packaged in sstate-cache Jan 16 22:07:45 and modified after installation Jan 16 22:07:50 exactly Jan 16 22:07:52 this still does not explain why shadow-sysroot is failing Jan 16 22:08:03 its just copying one file Jan 16 22:08:16 not executing anything Jan 16 22:08:24 not depending on other files from other recipes Jan 16 22:08:39 see the comment in shadow_sysroot_sstate_postinst Jan 16 22:08:55 Staging does not copy ${sysconfdir} files into the target sysroot, so we need to do so manually. Jan 16 22:09:36 zenlinux: its not the copying that's the problem Jan 16 22:09:42 its the source file that's present Jan 16 22:10:43 I think I need some time to get my head back in the game - would it be alright to ping me tomorrow and we can discuss this further? Jan 16 22:11:02 I agree the issue is urgent and I'd like to resolve it asap. Jan 16 22:12:02 yep Jan 16 22:12:12 tomorrow is good Jan 16 22:12:31 cool. I need some time to re-absorb some of my own code, and tweak a couple of things to test some theories. :) Jan 16 22:35:42 zeddii: you still around? I am getting a kernel failure on the mpc build, check out: http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/225/steps/shell_31/logs/stdio (Look for ERROR) Jan 16 22:43:34 ya.. I think I found a bug in the RPM processing.. it doesn't seem to be able to deal with filenames w/ spaces in them.. :P Jan 16 22:43:45 'er.. s/ya/ha Jan 16 23:26:45 halstead1away: Are you here? Jan 16 23:26:57 sgw, Yes. Jan 16 23:27:27 That's odd my nick wasn't showing as away. There must be something up with my irc proxy. Jan 16 23:27:34 I guess when I see halstead1away, I thought you where not on line! Can we sync in 30 minutes or so? Jan 16 23:27:45 halstead: ping Jan 16 23:27:59 halstead: Say at 4:00pm! Jan 16 23:28:39 I moved my irc proxy to a new server this weekend. I think I have it fixed now. Jan 16 23:28:49 scottrif, pong Jan 16 23:29:29 halstead: I am trying to log into the server that holds the published docs with 'ssh rifenbark@www.yoctoproject.org' I keep getting a permission denied (publickey) error. Jan 16 23:32:10 scottrif, try ssh srifenbark@www.yoctoproject.org Jan 16 23:34:03 halstead: prompts me for a password to unlock the private key for scott.m.rifenbark@intel.com. Not sure what password it is looking for. My Linux login password is not working Jan 16 23:35:17 scottrif, It would be the password you selected when you generated that key. It is separate from your login. Jan 16 23:37:26 halstead: That password has been cremated and buried.... Is there a way to find it out? Jan 16 23:39:39 scottrif, No. Consider that key lost forever. You can generate a new one and I'll install it for you. Jan 16 23:39:44 halstead: nevermind.... I found it Jan 16 23:40:14 Great. All is well? Jan 16 23:40:33 halstead: yes - all is well... Thanks Michael! Jan 16 23:41:09 scottrif: wasn't it mom's birthday ? :p Jan 16 23:41:44 ant__: ??? Don't follow Jan 16 23:42:36 that's the typical password for signing certs (bad habits...) Jan 16 23:43:01 ant__: ahhh.... I did not know that. Jan 16 23:43:54 i fact I've been slowly overwhelmed by passwords in the years Jan 16 23:44:59 ant__: I can relate... It seems I have way too many Jan 16 23:55:05 halstead: I forgot I have a 4:00, let's make it 4:30 Ok? Jan 17 00:02:21 sgw, Sure. **** ENDING LOGGING AT Tue Jan 17 02:59:57 2012