**** BEGIN LOGGING AT Tue May 27 02:59:58 2014 May 27 06:56:31 good morning May 27 06:57:14 morning May 27 06:57:17 deja vu :) May 27 06:58:59 anyone got a udev script for automounting sdcard partitions? May 27 06:59:34 tasslehoff: look for 'mount.sh' in the oe metadata May 27 06:59:38 we used to have one May 27 06:59:55 * koen stopped using it years ago, too many bad sideeffects May 27 07:00:27 koen: ah. then I will not go down that road. May 27 07:01:48 tasslehoff: see if udisks works for you May 27 07:09:15 this is exactly the problem I sit with now May 27 07:10:50 koen: if I can sort the /etc/fstab issue I have that will work May 27 07:12:04 with 1.4@beagleboard I could see my rootfs both in / and in /media/mmcblk0p2. I still want it to be like that, because of reasons. May 27 07:16:05 I have a problem with my sdcard partitions & opkg postinst scripts :( May 27 07:16:08 timing issue May 27 07:16:49 mine is create by a systemd mount-datafs.service May 27 07:17:21 sorry that was... datafs.mount May 27 07:18:21 but then that Requires another service... datafs-creation.service... a Type=oneshot that triggers when the partition is not seen May 27 07:20:48 my postinstall scripts need to write to the datafs partition... but it gets stuck with this output -> May 27 07:20:53 [ TIME ] Timed out waiting for device dev-mmcblk0p4.device. May 27 07:20:53 [DEPEND] Dependency failed for "data folder". May 27 07:20:53 [DEPEND] Dependency failed for foobar service. May 27 07:22:31 mmcblk0p4 is created by the type=oneshot service datafs-creation.service... that is not being run... which causes datafs.mount to get stuck May 27 07:24:43 the services are WantedBy=basic.target May 27 07:25:01 I was hoping there is something before that, before the deferred opkg scripts start to run. May 27 07:25:38 Or is there a way to make image baking deferred opkg postinstall scripts run later? (when my partitions are all up) May 27 07:28:09 I was told by khem that some changes were done on how / are mounted. Any idea where I should look for those changes? May 27 07:40:03 mmm May 27 07:40:09 im gonna switch to 1.6 and hope for the best May 27 07:40:31 if you don't see mee for another 3 months... May 27 07:40:37 il see you in hell... haha May 27 07:54:40 I miss systemd :) May 27 07:56:17 ant_work, hi, meta-toolchain was fine. It was the 3.2 kernel which had problems with newer gcc versions optimizing some code differently than expected, taking a couple of kernel commits from the future fixed the problem. JFYI commits are in the second message from here http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/39864 May 27 07:57:15 ao2: I vaguely remember. Though, I've never had issues compiling with oe-built toolchain May 27 07:58:08 maybe I'm confusing the kernel ver. 3.2 was removed long ago and probably 3.10 is immune May 27 07:59:24 yes, I think the compiler+kernel combo in your tests just happened to be always OK May 27 07:59:40 lucky at least once ;) May 27 08:00:30 what about userspace? Did you test any image? May 27 08:01:05 what can we reasonably remove from meta-handheld? May 27 08:01:14 or archive May 27 08:01:22 ant_work, I had an old angstrom rootfs and it worked fine May 27 08:02:28 I see May 27 08:03:56 I'll spend a couple of week-ends looking at ezx stuff in meta-handheld and see if there is anything we can remove. And I'll try to port the kernel to 3.14 or 3.15 and see if openezx-kernel_git.bb can be dropped (i.e. if it's not too many patches for ezx devices) May 27 08:05:22 BTW where do I send meta-handheld patches these days? It's been a while since I tracked OE development, is openembedded-devel@lists.openembedded.org still the place to go? May 27 08:08:49 yes, pls prefix with [meta-handheld] tag May 27 08:10:25 wow May 27 08:10:26 ros May 27 08:10:28 uav May 27 08:10:32 nice toys May 27 08:36:14 Should following http://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html#using-systemd-exclusively be enough to make systemd my init manager? It didn't rebuild much. May 27 08:38:35 systemd is awesome... until is breaks May 27 08:44:36 pompomJuice: I guess. haven't broken for me :) May 27 08:55:19 Well and it does break a lot of things. May 27 08:58:51 morning all May 27 09:03:13 hi bluelightning May 27 09:03:19 hi kroon May 27 09:12:51 late morning May 27 10:02:07 which command could let me re-generate the *Packages*, to update the pacakge list May 27 10:13:06 bitbake package-index May 27 10:14:54 lol this system of mine hacks kernel.bbclass to get the job done... now I must backport this thing every time May 27 10:14:56 magaad May 27 10:18:10 sounds awfull May 27 10:43:05 pompomJuice: well, we're happy to take patches if they're reasonable and then you won't have to keep backporting the changes.. May 27 11:12:56 oh thanks bluelightning, but this is not a patch. It's a hack to enable addition of kernel modules built from ti-sources after the kernel build has completed. (As I cannot find a way to do this legitimately) May 27 11:21:42 pompomJuice: vpss? May 27 11:22:36 I split do_compile into do_compile and do_compile_kernelmodules to build the out-of-tree syslink stuff May 27 11:26:36 ... May 27 11:26:56 I am sure there is a mechanism to do this, it's just I haven' May 27 11:27:11 haven't been told or know where to find docs that explain how it is done May 27 11:27:23 further more May 27 11:27:37 I have a knowlege problem when it comes to kernel configuration... May 27 11:27:50 not sure how the config file points to actual code on disk... May 27 11:28:02 or I have an idea May 27 11:28:06 there is this mapping file May 27 11:28:37 but yea... I don't know how to take the syslink module and create that entry in the mapping file that makes the module appear somewhere in make menuconfig May 27 11:29:38 buit so far porting to 1.6 is going smoothly... my kernel is building May 27 11:30:06 1.4 ->1.5 took 3 months... lets hope I am more lucky this time May 27 11:31:04 we use accurev as source control May 27 11:31:14 so I have to backport accurev inserters into bitbake tooo May 27 11:31:25 accurev fetchers I mean May 27 11:31:51 all this trouble because of syslink... sigh May 27 11:32:03 or ti May 27 11:33:21 how important is it that I understand and implement this new PR service? May 27 11:37:36 it's needed if you have >1 builder and what packages update to work May 27 11:38:09 fastest way is to keep the sqlite3 files in cache/ in sync on all the builders May 27 11:42:05 aah ok May 27 11:42:09 for later then May 27 11:45:41 what is this SRC_uRI checksum... May 27 11:46:22 does bitbake ever care about rebuilding if the source of a Makefile-based recipe has changed? If yes, how does it determine which files it should track for changes? May 27 11:46:38 not if the makefile does not do it May 27 11:47:07 you need to manually nuke the object files and do another -c compile May 27 11:47:21 so, bitbake will always run make, even if it cannot detect that any changes to recipe and/or variables? May 27 11:47:35 yes May 27 11:47:53 for variable changes you need to do a -c cleansstate May 27 11:48:05 it will run -c compile only once May 27 11:48:08 variable changes in the recipy May 27 11:48:13 -c compile -f will always run May 27 11:48:17 (unless it failed) May 27 11:48:44 if you change do_compile or an earlier talks, it will rerun do_compile May 27 11:48:50 if you change the source, it will do nothing May 27 11:48:55 koen, ok, so -c compile outcome is recorded in the cache until it is tainted? and what ways are there to taint the cache, other than -f? May 27 11:49:17 why must I add this to my recipy now? May 27 11:49:18 SRC_URI[sha256sum] = "58a1dd84fdfd06d5652bee24f59521a0b7492bde4abac2932f9ce2dfc716e37a" May 27 11:49:19 -c clean, -c cleansstate May 27 11:49:33 but that's the big hammer, analog to 'make mrproper/distclean' May 27 11:49:58 koen, can you make bitbake go backwards one state? May 27 11:50:01 pompomJuice: how does accurev check accurately? May 27 11:50:09 pompomJuice: if your recipe uses tarballs they need to be checksummed to guard against tampering and corruption May 27 11:50:09 checksums? May 27 11:50:09 like go from compile(done) to configure(pending) May 27 11:50:13 something like that? May 27 11:50:36 ERROR: No checksum specified for /mnt/ssd2/w/setup-scripts/sources/downloads/repo_devbuild.EOS.oe.rowboat-manifest.git_rowboat-ics-impedo-duo.xml_impedo-duo.20140404.tar.gz, please add at least one to the recipe: May 27 11:50:36 SRC_URI[md5sum] = "06f72c1d97189c29d05d53edb14a43ff" May 27 11:50:36 SRC_URI[sha256sum] = "58a1dd84fdfd06d5652bee24f59521a0b7492bde4abac2932f9ce2dfc716e37a" May 27 11:50:52 is this new? May 27 11:51:15 okay. so, if im doing iterative development on a working dir, what should I do? "bitbake -f -c compile " only seems to compile it, but not deploy it. but "bitbake -f " doesn't seem to rebuild everything. So right now, im first doing "bitbake -f -c compile " and then "bitbake " to actually get it to deploy my files May 27 11:51:23 my SRC_URI is full of repo's and patches and things... surely this is overkill? May 27 11:51:26 pompomJuice: 5 years old or so May 27 11:51:32 no May 27 11:51:54 mago_: Go to your ${workdir} May 27 11:51:59 cd ${S} May 27 11:52:06 vim main.cpp May 27 11:52:10 rm main.o May 27 11:52:14 mago_: -c compile -f ; -c package_write (or -c deploy) May 27 11:52:19 ../../temp/run.do_compile May 27 11:52:27 koen, ok, basically the same then. thanks May 27 11:52:54 mago_: I tend to use ' -c clean ; -c package_write' to avoid missing changes May 27 11:53:19 and deal with blowing away unsaved changed every other invocation :) May 27 11:58:10 koen: May 27 11:58:26 my SRC_URI contains a tar.gz, but then also all kinds of other patch files May 27 11:58:48 must I now add name=maintarball and a SRC_URI_maintarball or what? May 27 12:00:07 aah nm May 27 12:00:36 somehow this recipy got away with not specifying the checksums... I thought this was new... just a dorment bug... nm May 27 12:02:13 fixed May 27 12:08:59 or not May 27 12:40:16 hi. how can i build static eglibc (libc.a) with oe? May 27 12:40:16 May 27 12:46:10 dca: eglibc-staticdev May 27 12:46:23 it's already been done May 27 12:52:45 pompomJuice: thanks May 27 12:53:03 np ;) May 27 12:53:34 pompomJuice: but i can't find libc.a or smth May 27 12:53:54 in sdk generated by `bitbake meta-toolchain' May 27 12:54:27 uuuh May 27 12:54:43 not sure just go bitbake eglibc? May 27 12:55:00 dca: meta-toolchain does not include static libs by default; you can add the libc ones with TOOLCHAIN_TARGET_TASK_append = " eglibc-staticdev" May 27 12:55:08 (note leading space in the value!) May 27 12:59:51 so far so good 1.5 -> 1.6 seems to be going smoothly.. May 27 13:04:13 pompomJuice: apart from your syslink issues anything popped up that we didn't cover in the migration section in the manual? May 27 13:10:27 bluelightning: should i add this definition to my image recipe ? May 27 13:10:53 dca: no, it'll need to be in local.conf or a custom distro config May 27 13:11:24 assuming you are producing your SDK with bitbake meta-toolchain rather than bitbake -c populate_sdk , that is May 27 13:11:42 yes May 27 13:12:19 i am using poky May 27 13:25:04 bluelightning: thanks, seems that i have it now May 27 14:15:49 bluelightning: ilo check the migration manual and see how it matches up with my process May 27 14:44:07 bitbake has changed May 27 14:44:24 the FetchMethod interface May 27 14:44:39 nm May 27 14:48:58 url and urldata has been combined? May 27 14:56:09 pompomJuice: http://cgit.openembedded.org/bitbake/commit/?id=6a48474de9505a3700863f31839a7c53c5e18a8d May 27 14:57:13 thanks May 27 14:58:48 woop my accurev fetcher is working again May 27 16:12:30 eglibc-locale.inc contains "LOCALETREESRC = "${STAGING_INCDIR}/eglibc-locale-internal-${MULTIMACH_TARGET_SYS}"". That directory doesn't exist in my build (with SDKMACHINE=...mingw...). Any idea ? May 27 16:22:23 otavio: hello---thanks for your help on the mailing list with the 'eject' recipe May 27 16:23:53 stefan___: the main eglibc recipe writes those files out in do_install_locale May 27 16:24:02 stefan___: then eglibc-locale pulls from there and packages them up May 27 16:34:35 kergoth: oh, interesting. For some reason in my mingw build I had eglibc-locale built but not eglibc. So it appears the eglibc-locale install step was simply tripping over a missing prerequisite. May 27 16:36:33 that shouldn't even be possible, given the dependencies. eglibc-locale depends on virtual/libc, afaik May 27 16:36:49 * kergoth shrugs May 27 16:37:42 and building eglibc fails in configure with "checking sysdep dirs... configure: error: Operating system mingw32 is not supported." May 27 16:39:04 RP: any thoughts on this ? May 27 16:43:56 * kroon wonders when master will switch to gcc 4.9 May 27 16:46:33 ash_charles: worked? May 27 16:46:34 stefan___: don't build the locales May 27 16:46:41 stefan___: they make no sense in a mingw32 context May 27 16:46:55 stefan___: you'll have to stop whatever is pulling them in from pulling them in May 27 16:47:06 ah, good call May 27 16:48:01 OK. Only the locales ? Should anything depend on eglibc on mingw ? (As I just mentioned, eglibc configure itself is bailing out...) May 27 16:48:11 otavio: unfortunately not :(. I don't know enough to patch configure.in properly. May 27 16:51:16 stefan___: well, I don't know what you're doing. No, things shouldn't depend on eglibc or eglibc-locale but something is obviously pulling them in May 27 16:52:04 kroon: soon, there is a PPC bug I'm hoping will get fixed before we switch May 27 16:53:04 RP: OK. Yeah, I may indeed be doing something stupid. I'm simply trying to populate the SDK with some additional tools. They depend on glib as well as a few others, so perhaps one of those is dragging in eglibc. May 27 16:53:42 stefan___: glib itself has some locale dependencies iirc May 27 16:54:04 stefan___: as I said previously, nobody has gone far with the mingw stuff beyond the direct toolchain May 27 16:54:31 stefan___: I personally have little enthusiasm for it either to be quite honest :( May 27 16:54:32 yeah, understood. May 27 16:54:54 heh, if I got to choose, I wouldn't bother about Windows at all. :-) May 27 16:55:19 stefan___: you can try commenting out those dependencies see where it goes... May 27 16:55:44 OK, I'll try to hack my way through this jungle... May 27 16:56:11 * Daemon404 wonders if it wouldnt be saner just to give windows-based devs a vm image to run May 27 16:58:17 that would clearly be easier for us to provide, but it's not always what customers want. May 27 17:06:44 ash_charles: let me check it May 27 17:08:13 ash_charles, you are willing to maintain meta-oe/daisy? May 27 17:14:58 Ich düse mal heim... bbiab May 27 17:15:17 otavio: thanks :) May 27 17:16:03 Crofton|work: I'd be happy to help out but I don't think I'm confident enough to be a maintainer at this point May 27 17:17:07 Crofton|work: I've got auto-builders on meta-oe/daisy so I'm certainly happy to test and add patches May 27 17:17:23 need to talk with JaMa some May 27 17:17:39 basically, we need someone to watch for requests and queue them up May 27 17:38:00 ash_charles: I have done a look at the eject code May 27 17:38:18 ash_charles: and the po Makefile is not generated by Automake/Autoconf May 27 17:38:57 ash_charles: so it seems it'd be better if you hardlink it/copy it May 27 17:39:30 ash_charles: I am not keen to rework it completely May 27 17:39:41 otavio: me neither! May 27 17:39:47 :) May 27 17:39:58 otavio: might the v2 I sent be acceptable then? May 27 17:43:37 ash_charles: acked it May 27 17:43:47 ash_charles: sorry for all the hasle May 27 17:48:09 otavio: thank you for taking the time to review and look into the autotools muck May 27 17:48:38 is there a way to fine-tune the dependency graph generation (as per `bitbake -g`) ? I'm getting images of size 27541 x 12304... An option to only show direct dependencies, or control the shown number of indirect dependencies shown, or something. May 27 17:53:18 ash_charles: you're welcome May 27 17:56:02 stefan___: not really. a better bet is to examine the .dot file with an editor / grep /etc, or use the dependency explorer May 27 17:56:10 stefan___: bitbake -g -u depexp core-image-base May 27 17:56:42 yeah, I have been looking at the dot files already. May 27 17:59:12 kergoth: Some of the eglibc dependencies are dragged in via "RDEPENDS_${PN}-ptest_append_libc-glib = ...". However, I haven't enabled ptest-pkgs in my local.conf. So shouldn't these dependencies be masked ? May 27 17:59:18 the weakness of -g all around is it doesn't retain the *why*, and it shows both direct and indirect May 27 17:59:28 Crofton|work: ash_charles: daisy branch exists, but still nobody sent README file update for it :/ May 27 17:59:32 right, noticed. May 27 17:59:40 stefan___: that isn't about ptest-pkgs, its about ptest in DISTRO_FEATURES May 27 17:59:45 ptest-pkgs is an image feature, it only changes the image May 27 18:00:10 but yes, if ptest isn't in distro features, that dependency shouldnt' be a factor, unless ${PN}-ptest is in PACKAGES whether ptest is enabled or not, but it shoulnd't be May 27 18:00:33 Ah. Where are DISTRO_FEATURES added (or removed) ? May 27 18:00:44 DISTRO_FEATURES is defined by the distro May 27 18:01:10 the mel local.conf includes a snippet to add ptest to distro feautres as well as the bits to add it to imag efeatures, which is why the section of our local.conf includes like 3 commented variables, not just one :P May 27 18:02:19 but if you're concerned that it might be in distro feautres, you should use bitbake -e to examine distro features as well as the comments above it, which will show you not only what it's set to, but every line in every file where it was set that way May 27 18:02:52 JaMa, I saw the branch May 27 18:03:04 basically someone needs to queue backport requests May 27 18:03:11 and you can run builds on e them? May 27 18:03:36 stefan___: bb whatdepends might be useful, but sadly it only shows build deps, not runtime, still :\ May 27 18:04:09 kergoth: bb is your own script you once showed me, yes ? May 27 18:10:10 JaMa, I resent zeroc-ice patch May 27 18:10:19 it should work with curent oe-core now May 27 19:34:26 I'm running "bitbake nativesdk-glib-2.0 -c devshell". This yields a new xterm window, whose first line of output is "cmdModule.c(166):ERROR:11: Usage is 'module command [arguments ...] '" May 27 19:35:01 i.e., it appears the devshell command invoked a no-quite-correct subcommand. ANy idea what's wrong ? May 27 19:36:02 (and after some helpful usage message I further get "bash: module: line 1: syntax error: unexpected end of file". So I'm not entirely sure this shell is now in a useful state.) May 27 19:47:22 bluelightning ping May 27 20:00:21 woglinde: pong May 27 20:05:21 hm nevermind May 27 20:05:31 found something out myself May 27 20:05:59 was about sstate and how I can archive some archiver stuff May 27 20:06:12 when tmp dir is deleted May 27 20:25:41 bluelightning hm ah now I have question is it possible to use sstate on a do_patch[postfuncs] ? May 27 20:27:08 sstate operates on tasks. it runs _setscene to pull from the sstate archives, and it captures the output of the task. if your postfunc runs before the sstate postfunc, then probably its changes would be included May 27 20:27:17 afaik anyway. see sstate.bbclass for details May 27 20:29:04 thanks kergoth May 27 20:29:15 so i have to rewrite it a bit May 27 20:29:42 we still tinkring to get the sources along to the build packages May 27 20:32:46 hm or maybee we live with old class and use cleansstate to regenerate the patched sources May 27 20:32:52 I will ask zecke May 27 20:33:25 in the rare case tmp is delete before its all exported to a repository May 27 20:38:24 archiver already uses sstate well, i'm guessing you need something extra that archiver doesn't provide? May 27 20:39:50 kergoth it must run on edison and dora May 27 20:43:50 edison? good lord May 27 20:44:16 yes ;) May 27 20:44:48 I'm surprised someone would still be using that, but I guess there are good reasons May 27 20:44:59 its working May 27 20:46:50 even dylan seems old nowadays, but edison.. May 27 21:58:20 what package does provide libXmuu.so ? May 27 21:58:46 libxmu ? May 27 22:11:56 why is the only place libXmuu.so reside is in `usr/lib/.debug/libXmuu.so.1.0.0' (in toolchain generated by `bitbake meta-toolchain') ? **** ENDING LOGGING AT Wed May 28 02:59:58 2014