**** BEGIN LOGGING AT Mon Apr 15 02:59:57 2013 Apr 15 07:47:38 good morning Apr 15 07:49:37 morning all, hi apelete Apr 15 07:50:16 morning! Apr 15 07:57:39 hi silvio__, afournier1 Apr 15 07:58:09 hi afournier1 Apr 15 08:08:43 morning all Apr 15 08:11:29 hi bluelightning Apr 15 08:13:01 hi apelete Apr 15 08:31:06 hi bluelightning Apr 15 08:33:41 I have trouble with cache, can I safing removing only dir "out-eglibc/cache/*"? Apr 15 08:36:18 silvio__: first, what is the problem? Apr 15 08:37:30 bluelightning, incorrect exiting , and "bitbake.lock" to remove :), I think solved, sorry Apr 15 08:37:51 silvio__: bitbake.lock does not need to be removed Apr 15 08:38:08 bluelightning, ERROR: Only one copy of bitbake should be run against a build directory Apr 15 08:38:14 if it's complaining about another instance running it's because there is another instance running Apr 15 08:38:42 it doesn't just look for that file, it looks at running processes Apr 15 08:40:37 bluelightning, u right, thanks Apr 15 09:26:57 hi all Apr 15 09:27:36 hi pb_ Apr 15 09:28:00 morning bluelightning Apr 15 09:28:01 hi pb Apr 15 09:28:05 hi silvio_ Apr 15 09:28:10 _ Apr 15 09:28:41 ___ Apr 15 09:29:12 ah, you win Apr 15 09:30:08 pb_: is there still a pb on freenode? or did you prefer pb_ anyway? Apr 15 09:30:57 I sort of got used to my underscore. I'm not actually sure whether there still is a pb or not, let me see. Apr 15 09:31:06 *** pb Nickname is already in use. Apr 15 09:31:08 apparently there is Apr 15 09:44:24 so I am moving over to danny and I am starting to see AUTOINC a lot when building code pulled from git, should this not be a number based on when there is a change in AUTOREV? Apr 15 09:46:55 OWayne_: it now gets set at packaging time, so it's expected that you see it as AUTOINC in the logs Apr 15 09:49:40 but just as well to check :) Apr 15 09:53:19 bluelighting: would you expect the work folder to have AUTOINC in its name? Apr 15 09:54:20 hmmm, so my kernel image has the title uImage-3.3+gitrAUTOINC+ followed by the hash Apr 15 09:58:38 OWayne_: yes that would be expected Apr 15 09:58:56 OWayne_: are you using SRCREV in PV or SRCPV ? Apr 15 09:59:15 SRCPV Apr 15 09:59:32 SRCREV = AUTOREV Apr 15 09:59:38 ok Apr 15 10:00:27 I was just expecting to see a number that would increase as the SCM changed Apr 15 10:00:51 it should be when it gets to the packaging stage Apr 15 10:01:21 OWayne_: so the file in tmp/deploy/images/ has AUTOINC in its name then? Apr 15 10:02:00 that is correct Apr 15 10:02:25 bluelightning: yes in deploy, I see the same with meta-handheld kernels Apr 15 10:02:35 ok I think that is a bug Apr 15 10:05:23 hm.. anything news. I've been told it was expected, even with local PRServer Apr 15 10:05:30 or not..? Apr 15 10:06:16 PN is already embarrasingly long for linux-yocto recipes :) Apr 15 10:06:48 ant_work: up to the point of packaging, yes... but the deployed kernel probably shouldn't have this in it Apr 15 10:07:52 hmm; well linux-yocto for qemuarm is no different Apr 15 10:08:04 maybe it is expected but I don't think it's really desirable Apr 15 10:11:32 so this is correct behaviour? Apr 15 10:13:40 OWayne_: I don't know about correct, but it is what I'm seeing here for a vanilla build Apr 15 10:14:29 ok, talking to Richard, it is a bug Apr 15 10:14:32 agreed, it's OK in workdir, but deploy should expand it Apr 15 10:22:42 bug filed: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4293 Apr 15 10:26:07 JaMa: about MMC bug...he, again my bad Apr 15 10:26:10 Yes, you forgot this patch. Apr 15 10:26:10 http://comments.gmane.org/gmane.linux.kernel.mmc/18242 Apr 15 10:26:21 (c/o dromede) Apr 15 10:27:13 OK I'll retest when there is option to enable debug output :) Apr 15 10:27:35 there is, see my mail :) Apr 15 10:27:35 I have some trouble with "http://cgit.openembedded.org/openembedded/plain/recipes/xmlrpc-c/", i try to use it in oe-core, but I have an error of "mkdir: cannot create directory `/usr/include/xmlrpc-c': Permission denied" during do_install, I m doing something wrong? Apr 15 10:41:46 ant_work: will it enable early printk etc? or is it really enough? Apr 15 10:44:39 spitz out of drawer again :) Apr 15 10:47:18 spitz++ Apr 15 10:47:26 ant_work: with boot.cfg modified I still get only "Uncompressing Linux... done, booting the kernel." and hang Apr 15 10:47:51 if it's just uSD issue then I should get a bit more output Apr 15 10:48:05 meta-qt5-- back to it Apr 15 11:09:46 ant_work: kexecboot-klibc just failed again with | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/qemuarm/lib/klibc/include/limits.h:43:26: fatal error: linux/limits.h: No such file or directory Apr 15 11:10:48 Running task 19862 of 25944 Apr 15 12:02:42 I'm trying to incorporate a systemd service file in my recipe but I keep receiving this error message: | SYSTEMD_SERVICE_hiawatha value hiawatha.service does not exist Apr 15 12:03:21 recipe: http://pastebin.com/Lr5ciaMP Apr 15 12:19:26 ah ok, it seems I had to install the .service file manually Apr 15 12:20:22 I was under the impression the systemd class wuld automatically install the service file if systemd was set a distro feature Apr 15 12:23:22 jackmitchell: old systemd.bbclass did.. read "[OE-core] RFE: make the init manager an image feature (again)" for details Apr 15 12:23:45 jackmitchell: and please check/ack my patches to meta-networking about systemd from weekend Apr 15 12:24:20 I would like to push them soonish "Running task 22568 of 25944" Apr 15 12:27:19 JaMa: which meta-networking patches? I currently don't use anything from there... Apr 15 12:28:34 I didn't use the old systemd class, so I cannot check upgrade paths if that's what you mean Apr 15 12:28:37 http://patchwork.openembedded.org/user/bundle/79/?q=meta-networking&archive=both Apr 15 12:29:33 but nevermind, I mixed up you with Joe MacDonald Apr 15 12:29:45 JaMa: I was thinking that may have been the case ;) Apr 15 12:30:05 not sure why I remember only the initials :) Apr 15 12:30:42 i have some doubt why before it doesn't works but I solved so: Apr 15 12:31:09 "http://cgit.openembedded.org/openembedded/plain/recipes/xmlrpc-c/" Apr 15 12:33:14 after: http://paste.ubuntu.com/5710234/ Apr 15 12:36:43 since when it has closed license? Apr 15 12:37:12 just add correct license and LIC_FILES_CHKSUM Apr 15 12:39:28 now I adjust it, the trouble was with the do_intall task Apr 15 21:14:59 Is patchwork searchable ? Apr 15 21:16:55 yes Apr 15 21:17:02 klick on filter Apr 15 21:18:04 woglinde, ah thanks, tiny little button that one :-D Apr 15 21:24:26 so I guess maybe I should stick with gtk2 for this embedded application im doing, for now.. gtk3 doesnt seem mature enough for the OE ? Apr 15 21:43:00 evening all Apr 15 21:43:09 hi pb_ Apr 15 21:43:31 hi rp Apr 15 21:44:39 hi pb Apr 15 21:44:42 hi rp Apr 15 21:45:30 hi woglinde Apr 15 21:54:19 woglinde, can you help with Linuxtag? Apr 15 22:22:26 it must be weird bug day... Apr 15 22:24:53 crofton max 1 day Apr 15 22:34:21 can I set a package's FILES_ value with a python block? Apr 15 22:34:51 I added a task after do_install and before do_package that sets the value of FILES_ , but apparently, what I add gets ignored Apr 15 23:17:28 is that dos1 guy dos'ing us? Apr 15 23:19:06 oops, sorry :D Apr 15 23:19:53 was playing with display manager settings and forgot to disable autolaunch of irc client ;) Apr 15 23:21:38 pretty bad pun too... Apr 16 01:16:39 i'm working on new recipe, and using the -c devshell to assist setting up the do_compile(). one thing i'm noticing is that the devshell doesn't seem to carry the same environment variables that are set for a particular recipe (e.g. bitbake --environment zlib). I'm guessing it would be easy enough to dump the environment and source it within the devshell, but was wondering if perhaps I'm just missing something? a number of recipes i've looke Apr 16 01:16:39 d at are using variables in their do_compile() that aren't otherwise defined when using devshell **** ENDING LOGGING AT Tue Apr 16 02:59:58 2013