**** BEGIN LOGGING AT Tue Jan 24 02:59:57 2012 Jan 24 09:28:41 morning all Jan 24 10:14:49 hello all, can anyone help me to get started writing a bitbake file? Jan 24 10:24:15 you mean a recipe Jan 24 10:24:39 and I think the don't ask to ask rule apply here: ask your questions directly Jan 24 10:24:56 i do... Jan 24 10:26:25 im not sure where to start, is there a main document somewhere i can read first? Jan 24 10:26:37 or a tutorial? Jan 24 12:43:32 JaMa: Out of interest have you noticed any better sstate reuse for your armv7 builds with recent changes? Jan 24 12:44:28 RP__: not yet.. buildhost still building changes from yesterday Jan 24 12:44:58 JaMa: ok, there were a couple more fixes this morning but these might well explain the issues you were reporting Jan 24 12:45:18 JaMa: Its also possible there are some more but if so I'd like to track them down Jan 24 12:45:46 but it all seems about gcc & co, can it change reexecuting do_package too? Jan 24 12:46:07 JaMa: I'm hoping so Jan 24 12:46:22 JaMa: To save me digging though my email, what are two machines which show this problem? Jan 24 12:46:36 ok, I'll report in 2-3 days Jan 24 12:46:52 even qemux86-64 and qemux86-64copy were reexecuting do_package Jan 24 12:47:32 do_install only once, but do_package once for every machine Jan 24 12:47:59 JaMa: right, but you changed mtune there Jan 24 12:48:02 which is understandable for do_populate_sysroot, but not so much for do_package (which packages same results of do_install) Jan 24 12:48:13 not between qemux86-64 and qemux86-64copy Jan 24 12:48:36 and it does this even without that qemux86-64core (where was mtune changed) Jan 24 12:49:49 and I wouldn't complain if changing mtune reexecuted do_compile + all later tasks depending ond do_compile Jan 24 12:50:04 JaMa: If you enable basichash, it will do exactly that Jan 24 12:50:26 JaMa: I hadn't realised you have both "core" and "copy" in there :( Jan 24 12:50:39 JaMa: "copy" should work, I'll check though Jan 24 12:50:59 ah sorry, I should have use better names or compres that bug report somehow :/ Jan 24 12:51:25 but it's not easy to do so as every information could be usefull and it's not clear why it's happening Jan 24 12:51:32 JaMa: This does explain why I was getting confused though Jan 24 12:52:25 it should be clear from http://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/qemu-tests&id=dac0796e7de216ac6a5ce84090d0eef8ebd1ad63 Jan 24 12:53:28 RP__: hi, a silly question while you're there. Is it envisageable to use $D in pkg_postinst? How is it decided if this has to be run on device or on rootfs image? Some exit status? Jan 24 12:53:56 ant_work: If $D is set, you're in do_rootfs Jan 24 12:54:12 ant_work: exit 1 if $D is set to run on the target device Jan 24 12:54:25 ok, I wasn't too wrong ;) Jan 24 12:55:21 ant_work: we prefer not to need to run on target if at all possible Jan 24 12:55:48 I'm thinking about my tzdata patch. For the update this is what we want Jan 24 12:56:15 ant_work: see this thread http://permalink.gmane.org/gmane.comp.handhelds.openembedded.core/11855 Jan 24 12:56:56 JaMa: I just tested the copy and I think it should work with master Jan 24 12:57:41 RP__: ok, I'll try to reproduce my tests here later Jan 24 12:57:48 JaMa: ok, this check "if [ -n "$D" ]; then " is for code which could run bot on do_rootfs and on device later on pacjkage_update Jan 24 12:58:57 ant_work: I meant mostly the discussion about importance of exit code here Jan 24 12:59:08 precious link, thx Jan 24 13:00:21 then I need to fix the tzdata pacth Jan 24 13:05:16 JaMa: I have found a problem Jan 24 13:05:29 JaMa: will reply to the bug about how to better reproduce this Jan 24 13:07:42 RP__: great! thanks Jan 24 13:09:12 JaMa: I'm not saying this is the problem but its certainly an issue Jan 24 13:12:35 btw those do_package sigdata files were different only in do_install checksum (according to bitbake-diffsigs) Jan 24 13:14:00 JaMa: The problem is the shadow recipe is machine specific Jan 24 13:14:27 ah :/ Jan 24 13:15:35 so do_package is looking at "machine specific" passwd/shadow, but then putting .ipk files to "architecture specific" feed, right? Jan 24 13:15:46 JaMa: summary, we need to move securetty to its own recipe Jan 24 13:16:07 or make it part of something else which is already machine specific Jan 24 13:18:10 * JaMa didn't get it how is securetty related to this, but belives to RP__ :) Jan 24 13:19:35 JaMa: securetty has elements added to it based on the SERIAL_CONSOLE value which is machine specific Jan 24 13:20:01 * RP__ has excluded shadow and there are further issues but its a smaller list Jan 24 13:20:32 ah that's only reason for shadow being machine specific.. Jan 24 13:20:49 JaMa: right Jan 24 13:21:04 somehow gcc-cross is depending on the MACHINE variable? :/ Jan 24 13:21:54 * JaMa somehow messed shadow itself with base-passwd Jan 24 13:23:16 gah, Khem broke gcc-cross :) Jan 24 13:24:25 with machine specific --sysroot? Jan 24 13:24:41 JaMa: no, in the gcc test code he added he references MACHINE_ARCH Jan 24 13:24:59 a s/MACHINE/PACKAGE/ might well fix this Jan 24 13:26:15 yes, that reduces it to some netbase problem, opkg and sysvinit Jan 24 13:26:36 which I suspect is because some of those have machine specific packages in them Jan 24 13:27:16 JaMa: certainly you'd be less upset if its only those three rebuilding, right? :) Jan 24 13:28:15 hehe, maybe I'll build everything in time then :) Jan 24 13:28:28 that would make me much more happy, yes ;) Jan 24 13:29:52 opkg rebuilds since it depends on opkg-config-base Jan 24 13:30:17 so its all machine specific bits at this point Jan 24 13:30:30 so we need to fix the gcc issue and the shadow one Jan 24 13:30:44 * JaMa added patch for gcc-cross Jan 24 13:30:55 some creative task blacklisting could likely fix the rest Jan 24 13:32:15 * RP__ gets some food and will think about this before sending out some patches Jan 24 13:32:37 thanks a lot! Jan 24 15:32:20 I am writing a recipe and it executes fetch, unpack, patch, configure, compile. I fail compile because of libtool version mismatch, google says, I should fetch, unpack, patch, reconf, configure, compile. How do I do that? Jan 24 15:32:58 how do I tell a recipe to run autoreconf before configure? Jan 24 15:38:58 autif: it already does. if you inherit autotools, it runs autoreconf Jan 24 15:39:09 read autotools.bbclass Jan 24 15:42:53 kergoth` - I do not see a log.do_autoreconf or equivalent in the work/mono-2.6.7/temp directory are those logs somewhere? Jan 24 15:45:49 halstead|away: are you really away? Jan 24 15:47:31 halstead|away: never mind Jan 24 15:49:15 grep'ed autoreconf in recipes, found python and pm-utils doing "autooreconf —force —install" in do_configure_prepend(), seems to work Jan 24 16:11:57 autif: i didn't say it was a different task. Jan 24 16:12:04 do_configure is what does it Jan 24 16:23:18 RP__: I'm running qemux86-64copy build after building qemux86-64 from scratch and do_package are still reexecuted (ie glib/udev now) Jan 24 16:27:32 RP__: but it's much better now Jan 24 16:57:36 JaMa: right, I have most of these tracked down Jan 24 16:57:59 JaMa: still figuring out the best fixes but will send something out in the next hour or so I hope Jan 24 17:03:25 RP__: I'm starting new build on that buildhost with more armv7a machines, so we'll see tomorrow Jan 24 17:19:53 RP__: btw: few days ago I switched my builds from that dev-python/pysqlite to "native" sqlite support and unfortunately also futures module at the same time and since then I got bitbake stuck during parsing recipes (it never happen before) Jan 24 17:24:15 JaMa: ouch. You should probably talk to kergoth` Jan 24 17:24:32 JaMa: I have also seen one hang here too but didn't know if it was something else I was doing Jan 24 17:25:34 ok I can switch back to dev-python/pysqlite easily and see if it gets better or not Jan 24 17:40:22 hmm, that's interesting. what do you mean by 'native' sqlite support? Jan 24 17:41:13 RP__: I agree with that plan with closing #1916 Jan 24 17:41:21 JaMa: cool :) Jan 24 17:42:51 kergoth`: seen this one? http://lists.linuxtogo.org/pipermail/bitbake-devel/2012-January/001791.html Jan 24 17:43:01 kergoth`: that's what I mean by 'native' Jan 24 17:43:41 RP__: I am trying to write/test a staticdev QA Test, I should be able to do a bitbake -c package_qa world, correct? Jan 24 17:43:52 sgw: no Jan 24 17:44:01 sgw: package, not package_qa Jan 24 17:44:13 RP__: ah, ok Jan 24 17:44:56 kergoth`: any chance you read my work dir archive email yet? I want to get that to a broader audience if you are OK with it Jan 24 17:45:06 kergoth`: not sure if this is better way to show it, but switched like this http://git.shr-project.org/git/?p=shr-chroot.git;a=commit;h=6d5d93a50da180a68793110349164f11a83b7140 Jan 24 17:47:43 JaMa: its odd that you would have an issue, given i do all my builds on machines with python's built in sqlite support enabled. would be hard to fix without a reproduction environment Jan 24 17:47:59 sgw: I think it's still sitting in my inbox waiting for me to find the time, will try to look at it today Jan 24 17:49:05 kergoth`: and you get some hangs during parsing or not? Jan 24 17:49:30 nope Jan 24 17:49:38 if i did, i would have fixed it already Jan 24 17:49:53 kergoth`: I mean, if switching to futures was in order to get rid of hangs, then maybe hangs are caused by "built in" sqlite support Jan 24 17:50:26 we've been using the built in sqlite stuff for years Jan 24 17:50:36 i doubt it just keeled over recently Jan 24 17:50:39 but perhaps Jan 24 17:51:07 JaMa: I've only seen an odd one :/ Jan 24 17:51:31 the only hang i knew of was the parse error one. *shrug* Jan 24 17:51:39 OK, I'll let you know if hangs became more often or something (I got 3 in last 5 days since that switch on 2 different machines - but both using that shr-chroot) Jan 24 17:51:42 and even that I never hit in the past, only recently Jan 24 17:51:53 kergoth`: I've only seen this once, just after I switched to the futures stuff. I couldn't reproduce Jan 24 17:52:01 interesting Jan 24 17:52:31 I'll switch back to pysqlite to eliminate this difference too Jan 24 17:53:28 JaMa: If you attach strace to the "hung" bitbake, is it doing anything? Like timing out after 30s on sqlite or anything? Jan 24 17:54:57 RP__: I'll try when I get another "hung" bitbake, but it was hanging like this for maybe 5 hours or so (last line "Parsing recipes...") Jan 24 17:55:32 and it was on same metadata (for cycle for 6 machines, 4 built fine and it was haning on 5th) Jan 24 17:56:30 and killing that process and starting again finished 5th and 6th machine fine Jan 24 17:56:56 JaMa: we did change the sqlite3 timeout code to be more reliable. I'm wondering if its something to do with that Jan 24 17:57:24 I'd expect to see some activity if that were the case Jan 24 18:03:15 RP__: still getting the multiple patching issue with latest master + basichash change! Jan 24 18:05:50 who should initialize runtime_script_required in classes/rootfs_ipk.bbclass: if [ $runtime_script_required -eq 0 ]; then ? Jan 24 18:06:42 it's only plase where this variable is used and results in run.do_rootfs.6328: line 235: [: -eq: unary operator expected Jan 24 18:08:17 hmm added by pb in 87780fc09b066525e47d0f50ee5497db54d304cd will ask him Jan 24 18:49:15 RP__: btw, what git version are you using? your securetty patch cannot apply again because of "a/dev/null" instead of "/dev/null" Jan 24 20:45:33 I want to copy a build machine directory (tmp/sysroots/i686-linux/etc/mono) to my recipe's build directory (presumably tmp/work/core2-poky-linux/mono-2.10/image/etc/). How do I do this in the recipe? Presumably do_install_append(), but what are the variables for build system's sysroot and image? Jan 24 20:47:05 autif, if i were you i'd just make a tarball of whatever it is you want, and treat that as just another "source" for a bb recipe Jan 24 20:48:32 autif, that way it's clearly reproducible, rather than pulling in a snapshot of random files from the host Jan 24 20:49:13 the files in tmp/sysroots/i686-linux/etc/mono are generated, I can not make a tarball of this before hand, or is that not what you intented Jan 24 20:49:34 ah hm...yeah i misunderstood Jan 24 20:52:40 so, it seems like ${D} Is some variable for destination - presumably its tmp/work/core2-poky-linux/mono-2.10/image Jan 24 20:53:02 what is the variable for tmp/sysroots/i686-linux Jan 24 20:53:05 ? Jan 24 20:53:43 read bitbake.conf Jan 24 20:54:53 got it. Thank! kergoth Jan 24 21:58:06 sgw: try with the patches on the mailing list too :/ Jan 24 21:58:14 sgw: it has to be close to working... Jan 24 21:59:54 RP__: I hope so, will keep trying! Jan 24 22:50:41 * RP__ wonders how he ended up involved with rights of way issues. Pages upon pages of legal stuff :/ Jan 24 22:51:08 Well, are you for or against? Jan 24 22:52:02 seebs: I'm for them with vehicle rights where they can be proved but policy is against that Jan 24 22:52:34 That stuff gets so crazy so quickly. Jan 24 22:53:04 When we got our house, we had to do a bunch of extra paperwork to establish that we understood that the city had the right to build a residential sewer line to connect our house to the sewer network. Jan 24 22:53:37 Because, you know. What if they decided that they didn't want to use the perfectly good existing one, or rebuild where it was already, but instead build one that wouldn't go anywhere useful? THEY HAVE TO BE ABLE TO DO THAT. Jan 24 22:54:07 I just spent a substantial hunk of time, plus hundreds of $, getting approval to build a greenhouse AFTER the planning people originally said it was okay, too. :P Jan 24 22:57:33 seebs: Its a crazy world Jan 24 22:57:53 ....all because domes are not allowed by the city code, but basically all other roof types were... Jan 24 22:58:28 seebs: There is legislation here basically extinguishing claims for access by vehicle on routes after a magic date Jan 24 22:58:28 * fray realized today his passport expires next week.. d'oh.. and I have to go to Canada in 2 weeks.. Jan 24 22:58:38 time for the "quick" passport refresh Jan 24 22:58:41 Many claims were deliberately delayed until after said magic date :( Jan 24 22:58:43 Domes aren't disallowed, they just weren't mentioned, so no one could figure out how high it is. Jan 24 22:59:06 RP__ here in the US, claims are based on file, not processing date.. Jan 24 22:59:14 (done specifically to avoid gov't delays) Jan 24 22:59:23 fray: if only it were that simple Jan 24 22:59:58 and now they're throwing out claims made before the deadline on technicality grounds. Obviously they cannot be resubmitted Jan 24 23:00:07 ugh Jan 24 23:01:03 You mention X, everyone has easy access to copies of X but you didn't include it. Claim invalid. Jan 25 01:28:27 hm, so where's this systemd integration that other people want removed? i see references to it in the poky git logs, but i only see a sysvinit recipe **** ENDING LOGGING AT Wed Jan 25 02:59:56 2012