**** BEGIN LOGGING AT Fri Feb 15 02:59:58 2013 Feb 15 07:11:10 hey guys, where can i read about the differences between meta-toolchain, meta-toolchain-sdk, adt-installer and meta-ide-support? Feb 15 07:42:47 gbrennon: look at poky manual Feb 15 07:43:07 meta-toolchain is basic SDK Feb 15 07:43:27 adt-installer is bunch of scripts to install SDK Feb 15 07:43:58 ide-support is necessary tools to run QEMU to do nfs mounted rootfs Feb 15 07:51:25 khem, hmm so using meta-toolchain or meta-toolchain-sdk i'll generate my cross compiling stuff, right? like gcc for arm. in the yocto manual doesn't say anything about qt, only about the simple C/C++ development. how can i build my qt tools for arm? Feb 15 07:51:59 gbrennon: yes those are basic C/C++ SDKs Feb 15 07:52:04 should i add some kind of "qt-4-tools" package and then the meta-toolchain will create my stuff? Feb 15 07:52:10 for QT there is a separate SDK target Feb 15 07:52:40 where could i find about the SDK for qt? Feb 15 07:53:35 meta-toolchain-qt or meta-toolchain-qte Feb 15 07:53:51 the recipes are under recipes-qt/meta/ Feb 15 07:54:10 okok Feb 15 07:54:12 thank you! Feb 15 07:55:11 Q: rpm-postinsts, it seems there's only a sysvinit script to run them. Does systemd run it through some compat package/script? Feb 15 07:55:53 i'm "new" to embedded o.s. stuff and i'm reading documentation and asking here in the channel everyday :D Feb 15 07:56:11 khem where are u from and how into yocto project are u? Feb 15 08:21:22 good morning **** ENDING LOGGING AT Fri Feb 15 08:38:45 2013 **** BEGIN LOGGING AT Fri Feb 15 08:40:19 2013 Feb 15 11:46:13 JaMa: found out why that patch gives mixed results - its the code parser cache getting in the way Feb 15 12:36:31 Anyone has a second to fix dropbear? Currently /etc/init.d/dropbear restart will kill the client sessions as well Feb 15 12:36:40 this means opkg upgrade on a device might not finish Feb 15 12:37:30 OE-classic is using a PIDFILE to resolve it Feb 15 12:37:41 I am currently on the road.. does someone have time to look at it? Feb 15 12:40:34 http://git.openembedded.org/openembedded/commit/recipes/dropbear/dropbear/init?id=6adaccf00601e1bc3ce1ede5417eabcdf1671768 would be the 'fix' Feb 15 13:58:00 hi Feb 15 13:59:13 anybody to tell me how to tell in a recipe how to install files in /home/root ? tried ${D}/home/root, but failed Feb 15 14:17:30 frs: failed how? Feb 15 14:17:47 frs: the above is a good start, you'd also have to package it up Feb 15 14:27:14 now i get WARNING: QA Issue: initscripts: Files/directories were installed but not shipped Feb 15 14:28:20 First issue was /home/root non existing, it is fixed Feb 15 14:29:21 RP: by packaging, you mean state things like FILE_ ... ? Feb 15 14:30:03 I don't really need to put things in a package, installation in rootfs is enough Feb 15 14:32:18 frs: we build the rootfs from packages so you need to package it Feb 15 14:32:29 ok Feb 15 14:32:37 thx Feb 15 14:44:58 <_Lucretia_> anyone seen this before for the meta-ti omap-sgx-modules? http://pastebin.com/F9unrEgC Feb 15 15:17:54 <_Lucretia_> when using quilt should I be using the one installed by yocto or a native one on my os? Feb 15 15:23:30 _Lucretia_: either is probably fine for quilt Feb 15 15:24:33 <_Lucretia_> well, the doc just shows quilt commands, yet the my install doesn't find it, which makes me think I should be using the system one as there doesn't seem to be "target specific" commands to use it within yocto Feb 15 15:24:51 <_Lucretia_> the doc could do with more explanation Feb 15 15:26:10 <_Lucretia_> I mean there is some set up involved in quilt afaik and I would expect the yocto tree to sort that out when I enter it Feb 15 15:31:44 _Lucretia_: That is a good point, we don't add the tools to PATH by default Feb 15 15:32:52 _Lucretia_: Can you open an enhancement bug for that please in the bugzilla? Feb 15 15:45:12 RP: thoughts on adding a logging Filter() after the fork in fork_off_task to add various attributes to the log events, e.g. taskid/taskname/filename? was thinking it would give us reliable association of log messages to the task they came from Feb 15 15:47:33 kergoth: We do already inject pid information into the log events (see self.pid = worker_pid in event.py) Feb 15 15:48:23 kergoth: I think the main reason we didn't do id/fllename/taskname was just the overhead of the repetitive data over IPC Feb 15 15:48:50 kergoth: the clients have lookup tables in the uihelper for that Feb 15 15:49:18 Ah, right, forgot about that. Okay, so we could just enhance the ui to make that association user-visible if appropriate Feb 15 15:49:21 okay, thanks Feb 15 15:49:48 kergoth: yes, the data is there, would just need to display it Feb 15 15:50:27 I do think having the useful bits as attributes of the message would be handy for formatting rather than having to do it programmatically, but if we wanted that we could add it from the ui end of the ipc connection based on the pid Feb 15 15:50:38 * kergoth scratches that off his list then Feb 15 15:51:12 kergoth: agreed Feb 15 15:55:08 i wish python string formatting had really simple conditionals. it'd be nice to be able to have a format string that was like %(%(foo)s:) and have the : only show if foo is defined, or so Feb 15 16:17:10 Q: how to get debug output from do_rootfs? I've messed up something but can't find any logs. Feb 15 16:18:06 the log is in the same place all task logs are :) buried under tmp/work/*/*/temp/log.do_configure Feb 15 16:18:12 s/configure/rootfs/ Feb 15 16:18:21 <_Lucretia_> anyone know where cpu_is_omap3530 is actually defined? Feb 15 16:19:30 mcfrisk: use sub-bb and you can do "bb log core-image-sato rootfs" to read it Feb 15 16:19:34 * rburton hugs sub-bb Feb 15 16:25:59 older version, don't seem to have sub-bb. Also log.do_rootfs is not created. All I have is "Function failed: do_rootfs" from bitbake. Feb 15 16:28:52 mcfrisk: its a separate tool Feb 15 16:28:56 mcfrisk: try the cooker log Feb 15 16:29:10 tmp/log/cooker/ Feb 15 16:30:29 found a "set +x" in do_rootfs, maybe -x helps. Feb 15 16:37:28 nope, "set -x" in rootfs_rpm_do_rootfs did not help. cooker log is same as bitbake output. Hmm. Feb 15 16:46:58 hello i am trying to write a recipe can anyone tell me how i can use install rather then cp ??? SUMMARY = "copy the os-release file" Feb 15 16:46:58 LICENSE = "TPLINO" Feb 15 16:46:58 SRC_URI = "file://os-release" Feb 15 16:46:58 LICENSE="CLOSED" Feb 15 16:46:58 do_install() { Feb 15 16:46:59 mkdir -p ${D}${sysconfdir} Feb 15 16:47:01 cp ${WORKDIR}/os-release ${D}${sysconfdir} Feb 15 16:47:03 } Feb 15 16:49:37 wfailla: change "cp" to "install" Feb 15 16:52:26 rburton, what about the mkdir should i use install -d Feb 15 16:53:00 you can Feb 15 16:53:05 they both do the same thing at the end of the day Feb 15 16:54:42 rburton, and a nother thing when i add IMAGE_INSTALL += "os-release" to my local config the img turns out to be total junk the number of tasks drops and nothing seems to work , did i use IMAGE_INSTALL correctly Feb 15 16:56:38 i add IMAGE_INSTALL += "os-release" to my local config the img turns out to be total junk the number of tasks drops and nothing seems to work , did i use IMAGE_INSTALL correctly Feb 15 16:57:13 it drops round about 1000 tasks Feb 15 16:57:51 your image recipe probably does something funky Feb 15 16:58:02 if you image inherits core-image, use CORE_IMAGE_EXTRA_INSTALL Feb 15 16:58:39 i will try that because my image recipe dose that Feb 15 16:59:24 that's the preferred way of extending anything using core-image Feb 15 17:01:22 ? += ? Feb 15 17:03:11 rburton, i don't whant to speak to soon but it looks promesing Feb 15 17:07:13 rburton, win THX ... BIG THX Feb 15 17:11:51 wfailla: np Feb 15 17:19:17 rburton: in regard to systemd.. did you work on/fix the running of postinst? Feb 15 17:22:24 zecke: in what sense? Feb 15 17:23:18 postinst? fwiw, I'm trying to hack do_rootfs to create a systemd service for running /etc/rpm-postinsts Feb 15 17:24:21 <_Lucretia_> I want to get sgx compiled for overo on yocto, but it's not compatible with 3.5, has anyone done this? Feb 15 17:25:52 rburton: nevermind. I thought update-modules (or such was not ran).. but it is that my ifplugd is not running Feb 15 17:30:18 zecke: you went offline but I fixed the dropbear issue Feb 15 17:31:57 RP: thanks! I went through the digest and couldn't find a patch in the oe-core archive so I sent the email. I have now pulled and see that your cherry-picked the change. Thank you! Feb 15 17:32:08 hey guys, someone ever used qt with yocto? after bitbake meta-toolchain-qte what should i do to cross compile my applications from qt? Feb 15 17:32:46 rburton: my next issue for systemd is the watchdog. Somehow my opkg foo is very weak.. I wanted to have systemd RPROVIDE, PROVIDE, RRCONFLICT, RREPLACE the watchdog package.. but it doesn't really work Feb 15 17:33:09 gbrennon: I am sure there are docs on yocto wiki or manual on how to install the SDK Feb 15 17:33:48 zecke: are you suffixing those vars with _${PN} Feb 15 17:36:32 khem: I did. maybe I was missing PROVIDE.. this way watchdog might not be built at all Feb 15 17:48:24 zecke: yes systemd has to PROVIDE it Feb 15 17:48:57 that way DEPENDs will resolve to systemd and not watchdog Feb 15 17:52:17 fray: around ? Feb 15 20:54:23 halstead: ping Feb 15 20:54:52 halstead: Is my dev cluster up and running. I've got fresh ab code I want to try out. Feb 15 21:45:07 Hi all, I have a few custom image targets that pull in different packages. There's a post-image creation step I want to be able to conditionally to for all of these. I know one option would be to introduce a corresponding task for each and include the post-processing in each. Is there a better way? Feb 15 21:48:01 basically I want to covert the generated rootfs into a different image format Feb 15 21:49:57 pidge, Yep, the core of it is unchanged. The extra workers aren't added yet. Feb 15 22:22:03 anybody know why meta/conf/bitbake.conf has ALLOW_EMPTY_${PN}-dev and ALLOW_EMPTY_${PN}-dbg equal to "1"? Feb 15 22:23:08 any reason setting it to zero globally would be a bad idea? Feb 15 22:26:10 RP added those two lines in 50bbb774 but the commit comment doesn't hint as to why Feb 15 22:40:07 evanp: The reason why is the dependencies of those packages are as important as the contents Feb 15 22:40:29 evanp: so it depends if you care about the -dev and -dbg dependency chains being valid Feb 15 22:49:29 RP: why would having the dependency chains valid matter? won't a -dev and -dbg that's empty always be a leaf node on the dependency DAG? or am I missing something? Feb 15 22:50:37 evanp: the idea was that if X links against Y and you're debugging X, you'd also want the symbols for Y Feb 15 22:50:48 ditto development headers Feb 15 22:51:17 evanp: If you don't have these empty packages, the chains get truncated Feb 15 22:51:46 Whether this is the best idea in the world remains to be seen. People have very different views of what a -dev or -dbg package should do :/ Feb 15 23:03:25 RP: I'm still not following.... if foo links libbar which links libbaz, the goal is for foo-$X to pull in libbar-$X, which will pull in libbaz-$X, where $X is -dev and -dbg.... But if libbar-$X is empty, doesn't that necessarily mean libbaz-$X is empty too? Feb 15 23:06:00 or is the issue that I'm assuming people put headers in -dev and debug sections in -dbg, but some people like putting them in the main package, and it is that scenario that makes chain truncation a problem? Feb 15 23:50:29 I think I found a block of characters which is a valid shell script, but which causes bitbake to get weird finalize errors parsing. Feb 15 23:51:05 Is it a bug if I can find valid sh that bitbake won't accept, or is it just a known limitation? Feb 15 23:54:29 Seems that foo & isn't acceptable to bitbake. I found a trivial workaround. Feb 15 23:54:44 foo & trap "kill $!" 0 Feb 15 23:59:36 for opkg, http://www.gumstix.net/feeds returns a 404 error ... has it changed recently ? Feb 16 00:07:59 nm Feb 16 00:51:46 anyone remember the sdk target to maek an sdk for an image Feb 16 00:52:15 meta-toolchain maybe? Feb 16 00:54:03 bitbake -c populate_sdk image I think **** ENDING LOGGING AT Sat Feb 16 01:22:36 2013 **** BEGIN LOGGING AT Sat Feb 16 03:02:18 2013 Feb 16 09:03:02 rburton: ping? one more systemd issue. :) Feb 16 09:58:48 zecke: not really here, feel free to mail / file bugs Feb 16 10:15:44 rburton: I will wait. :) Feb 16 10:19:04 zecke: i won't really be here until monday Feb 16 10:19:23 this machine was only on as its the one with the tv-fetching tools Feb 16 10:19:33 now, to walk the dog and take the kids to the farm Feb 16 10:20:09 rburton: no rush. I have plenty of other things to do Feb 16 21:20:09 Hey, folks. Anyone want to be guinea pigs for some pseudo changes? Feb 16 21:21:28 Quick summary: First, switch to an in-memory DB, flushed to disk on server exit. This helps some for some common use cases, mostly only when disk load is high. Feb 16 21:22:05 Second, and this is RP's idea: Add an option under which pseudo intercepts fsync(), fdatasync(), and the like, and just drops them. Feb 16 21:22:37 Thing being, if you're using RPM or SMART, there is a db-5.3 database which is spamming fdatasync() during fs assembly... Feb 16 21:23:07 And on a lot of Linuxes, fdatasync() has in practice the side-effect of flushing ALL writes to that filesystem that preceeded the last write to a given file. Feb 16 21:23:42 Basically, the net result is a 40x speed improvement in rootfs assembly, for the "install all these RPMs" phase. Yes. 40x. Feb 16 21:24:06 I go from 10-12 packages installed per 10 seconds to 400 on my workstation. Feb 16 21:24:53 And the thing is, these are perhaps sort of intrusive changes, and might be risky. But I think the performance win may be of enough interest for me to bother pitching it to people. :) Feb 16 21:26:47 wow, nice Feb 16 21:26:50 that's impressive Feb 16 21:27:22 What offends me about it is.... Feb 16 21:27:40 I've been REALLY upset about rootfs assembly performance, and I assumed it was pseudo's fault. Feb 16 21:28:00 So I spent significant time on the memory DB thing, which really does help performance noticably under load for most use cases. Feb 16 21:28:23 And then I went and tested filesystem assembly, and got changes in runtime on the order of 1-2 seconds out of 15 minutes. Feb 16 21:28:49 So I've spent the last year feeling vaguely stressed because of this horrible performance problem in pseudo, and it wasn't even actually in pseudo. Feb 16 21:29:24 And I was having a heck of a time fixing it in other packages, and worried about the implications of breaking fsync() in them, and so on. Feb 16 21:29:59 Luckily, RP saved the day by pointing me at the fsync() patches to pseudo he'd done, which allow me to solve the problem in a more elegant way. Feb 16 21:30:48 Instead of breaking the semantics of db5, I change the semantics of "tasks run under pseudo", because there really is a strong logical implication that "run under pseudo" implies "working on a filesystem you can recreate cheaply if something goes wrong". Feb 16 21:32:26 I'll probably be sending out patches to pseudo to the oe-core list. Normally I wouldn't send pseudo patches there, just the upgrade-patch, but in this case, I would really like it if people who are perhaps more careful than me were to review the changes. :) Feb 16 21:33:52 I also have a patch which I find really useful locally, which might be worth trying to make more generally available, which adds timestamps at fixed intervals to a shell task. Feb 16 21:34:21 Which is INSANELY useful if you are trying to discern where the wall-clock time is going during a longish task like do_rootfs. Feb 16 21:34:49 oooh. Feb 16 21:35:01 Well, there's a test result. Feb 16 21:35:23 Making pseudo suppress fsync in general, rather than just suppressing it in db and rpm, also improves build speed further. Feb 16 21:36:09 On my workstation, build time from scratch for our "standard" filesystem goes from 83 minutes (original) to 70 (no fsyncs in RPM/db) to 64 or so (pseudo suppressing fsync). Feb 16 21:52:24 seebs: great work! Feb 16 21:52:36 hahahah I just... man. Feb 16 21:52:53 So I have this problem, which is that my workstation slows down HORRIBLY during builds. Feb 16 21:53:03 Like, it'll take vi 5 seconds to save a file. Feb 16 21:53:07 ouch Feb 16 21:53:09 GUESS WHO CALLS FSYNC. Feb 16 21:53:41 I'm doing some editing for another possible change. Now that I realize this, I'm going to do my editing in a pseudo session. Feb 16 22:00:36 seebs: fyi, you can control fsync behavior in vim with the 'fsync' option for regular files, and 'swapsync' for swap files (highly recommend disabling the latter if you have swap files enabled at the least) Feb 16 22:00:46 Oh, very helpful. Feb 16 22:01:14 I dare say that MAY even be a tiny bit more convenient than writing a shared library to intercept and discard the calls. Feb 16 22:04:02 heh Feb 16 22:10:27 Okay, having pseudo suppress fsyncs trimmed the build time for three simultaneous builds further. With fsyncs, 78 minutes. With fsyncs removed from RPM/db, 33-34 minutes. With pseudo suppressing them in general, 28 minutes. Feb 16 22:31:36 seebs: we used to set a flag for the rpm db creation to disable fsyncs, but that's no longer being used; I wonder if we should have taken that out Feb 16 22:31:55 (unless it never worked in the first place) Feb 16 22:32:00 It probably didn't work, I think. Feb 16 22:32:15 Because so far as I can tell, that affects the code actually in RPM, but not the libdb code. Feb 16 22:32:23 ah, ok Feb 16 22:32:42 Or at least. I set that flag unconditionally and commented out every fsync in RPM, and libdb was still fsyncing. :) Feb 16 22:51:34 Okay, that may have been easier than I thought. Feb 16 22:52:45 I may have the guts of a patch to make pseudo not wait for responses it doesn't need. Feb 16 22:54:17 seebs: did my patches work as they were? I'm curious if I was benchmarking the right thing Feb 16 22:54:50 I didn't check, but I think they would have. They looked right; only big change I made was to move the immediate-return into the outer wrapper. Feb 16 22:58:46 woah Feb 16 22:58:47 okay Feb 16 22:58:54 If this works... Feb 16 22:59:26 Test case: "tar xf doc.tar; rm -rf usr", where doc.tar is a tarball of 28k files, /usr/share/doc. Feb 16 23:00:02 First trial on my workstation: With the fsync and memory DB patches, runtime around 12 seconds for untar, 5 for rm. Feb 16 23:00:23 With the fsync and memory patches, and the "no waits for responses from most operations", about 3 seconds for untar, 5 for rm. Feb 16 23:00:34 (MAY_UNLINK really does need a response.) Feb 16 23:02:37 seebs: I like the sound of these :) Feb 16 23:03:05 And it should coredump if I screwed it up. Feb 16 23:03:26 PSEUDO_MSG_FASTOP yields a null pointer as its response. Feb 16 23:03:41 So if any code IS trying to read the results, it'll core dump rather than failing silently. Feb 16 23:07:41 ... although fstat was checking for a msg before checking its contents, so it did indeed fail silently. Hmm. Feb 16 23:13:26 Still pretty slow compared to unwrapped code (1.1 seconds, 0.7 respectively), but definitely faster than it used to be. Feb 17 02:30:53 Sent the actual pseudo patches to the oe-core list in case people want to look at 'em. PSEUDO_1_5 branch should be in the git repo. **** ENDING LOGGING AT Sun Feb 17 02:59:57 2013