**** BEGIN LOGGING AT Tue Apr 16 02:59:58 2013
Apr 16 06:24:42 <mattnie> Good morining! I am searching for a Howto compile Kernel and U-Boot with FDT support. But I do not found anything. (First question where I enable/disable FDT in u -boot?) Regards MaTT
Apr 16 07:05:05 <mckoan> good morning
Apr 16 07:05:24 <erbo> good morning
Apr 16 07:05:32 <mattnie> good morning mckoan
Apr 16 07:46:39 <ericbutters> hello.. how to get lxde in yocto? is there a meta-lxde?
Apr 16 07:50:13 <mckoan> ericbutters: AFAIK no
Apr 16 07:51:37 <ericbutters> what about xfce?
Apr 16 07:51:50 <ericbutters> is there only matchbox?
Apr 16 07:52:50 <mckoan> ericbutters: http://layers.openembedded.org/layerindex/
Apr 16 07:53:31 <mckoan> ericbutters: http://layers.openembedded.org/layerindex/layer/meta-xfce/
Apr 16 07:54:12 <ericbutters> mckoan perfect!
Apr 16 07:54:16 <ericbutters> thank you
Apr 16 08:02:48 <mckoan> ericbutters: yw
Apr 16 08:13:55 <david-e_> to compile a 3rd party (ugly) package I had to pass $(STAGING_DIR_TARGET)/usr/lib/powerpc-poky-linux-gnuspe/4.7.2  ... is there an appropriate variable I can use to avoid specifying that?
Apr 16 08:14:35 <david-e_> btw, it is needed for gcc to locate libgcc.a
Apr 16 08:38:28 <RP> david-e_: Can't the toolchain find that as needed?
Apr 16 08:39:07 <RP> david-e_: ${STAGING_LIBDIR}/${TARGET_SYS}/4.7.2 is a bit neater
Apr 16 08:39:22 <david-e_> RP: didn't dig too deep: I got "ld: cannot find libgcc.a"
Apr 16 08:39:36 <RP> david-e_: ld *should* be able to find that :/
Apr 16 08:39:37 <david-e_> RP: looks better, thanx
Apr 16 08:40:09 <RP> david-e_: there is something broken in the compiler/linker for it to be saying that, default search paths must be broken somehow
Apr 16 08:40:23 <RP> david-e_: a good place to start looking would be to strace it, see where it is looking
Apr 16 08:41:00 <david-e_> RP: I wouldn't blame it on the toolchain, the package is huge and really ugly
Apr 16 08:41:08 <david-e_> will try to strace that later on
Apr 16 08:41:28 <RP> david-e_: It could be you're missing the --sysroot option to ld
Apr 16 08:41:54 <david-e_> RP: I guess that is missing: thanx for the tip
Apr 16 08:50:37 <bluelightning> morning all
Apr 16 08:52:55 <mattnie> morning bluelightning
Apr 16 08:54:44 <RP> hi bluelightning
Apr 16 09:06:05 <bluelightning> hi mattnie, RP
Apr 16 09:06:17 <khem> new busybox mount is now useless with systemd
Apr 16 09:06:19 <khem> hmm
Apr 16 09:06:40 <bluelightning> if what koen says is true so was the old one...
Apr 16 09:06:41 <khem> cant mount loop devices
Apr 16 09:06:53 <khem> I am on dylan
Apr 16 09:07:04 <khem> have a initrd with busybox in it
Apr 16 09:07:48 <khem> use to work
Apr 16 09:07:58 <khem> a month or so ago
Apr 16 09:08:14 <rburton> khem: didn't think we'd touched busybox mount since before then
Apr 16 09:08:20 <ant_work> khem: hmm.. iirc the one from klibc is ok
Apr 16 09:09:32 <ant_work> but I can't guarantee I was running systemd ...
Apr 16 09:09:34 <rburton> khem: any errors?  saul did patch the automoutning behaviour recently
Apr 16 09:10:08 <khem> rburton: hang on
Apr 16 09:10:25 <khem> yes I was nearing to that commit
Apr 16 09:10:38 <khem> mount: mounting /dev/loop0 on /media/isolinux failed: No such device
Apr 16 09:11:04 <khem> sh-4.2# ls /media/isolinux/ -ld
Apr 16 09:11:04 <khem> drwxr-xr-x    2 root     root             0 Apr 16 09:10 /media/isolinux/
Apr 16 09:11:24 <khem> sh-4.2# ls /dev/loop0 -ld
Apr 16 09:11:24 <khem> brw-rw----    1 root     disk        7,   0 Apr 16 09:10 /dev/loop0
Apr 16 09:11:52 <khem> sh-4.2# ls -ltr /tmp/junos.img
Apr 16 09:11:52 <khem> -rw-r--r--    1 root     root     1841299456 Apr 16 09:10 /tmp/junos.img
Apr 16 09:11:59 <khem> so all artifacts are there
Apr 16 09:13:08 <khem> mount -o rw,loop,noatime,nodiratime /tmp/junos.img /media/isolinux
Apr 16 09:13:17 <khem> is what the cmd is
Apr 16 09:14:33 <khem> aha btw. /bin/mount.util-linux -o rw,loop,noatime,nodiratime /tmp/junos.img /media/isolinux works
Apr 16 09:14:42 <khem> so someone botched up busybox
Apr 16 09:15:43 <rburton> khem: if you could try reverting saul's patch and my backport from upstream that would be great
Apr 16 09:16:34 * khem looks at Sauls patch and thats definitely it
Apr 16 09:17:04 <khem> bb_perror_msg_and_die will die on first fail
Apr 16 09:17:31 <rburton> khem: please file bug and mail list
Apr 16 09:17:49 <khem> is bug report still needed
Apr 16 09:18:04 <khem> after spending 3 hrs to wreslte with it :)
Apr 16 09:18:14 <rburton> khem: bugs don't get lost as easily as mail
Apr 16 09:22:29 <khem> probably I should find some time to test patches atelast to the packages that affect me
Apr 16 09:24:02 <khem> rburton: your patch does not impact me
Apr 16 09:24:07 <khem> so no point in testing it
Apr 16 09:24:21 <khem> but revert of that fail_on_no_media.patch
Apr 16 09:24:24 <khem> I will test
Apr 16 09:24:33 <rburton> thanks
Apr 16 09:25:00 <khem> and your patch does not fix koen reported issue either
Apr 16 09:25:10 <khem> so i would advise to hold off
Apr 16 09:25:30 <rburton> my mega-patch is being held off
Apr 16 09:25:46 <khem> good
Apr 16 09:26:05 <khem> known bugs are better than unkown ones
Apr 16 09:27:47 <khem> this freaking box takes 10 mins to reboot
Apr 16 09:28:24 <rburton> ouch
Apr 16 09:29:20 <khem> OK confirmed its that patch
Apr 16 09:29:28 <khem> let me capture it in  a bug and sleep
Apr 16 10:01:56 <ericbutters> why there is no meta-lxde?
Apr 16 10:02:07 <david-e_> would it be possible from within a package recipe to reference another package variable (i.e. EXTRA_OEMAKE of package B from A.bb)
Apr 16 10:02:55 <bluelightning> david-e_: no, you'd need to set a variable globally and have both recipes read from that
Apr 16 10:03:11 <david-e_> bluelightning: great, thanx
Apr 16 10:03:50 <bluelightning> ericbutters: there is https://github.com/adam-lee/meta-lxde but it doesn't look like it's being kept up-to-date and the author hasn't bothered to get it listed in the index
Apr 16 10:05:48 <david-e_> bluelightning: of course I guess that applies also to build directories (${S} of another package)
Apr 16 10:06:11 <bluelightning> david-e_: you definitely want to avoid that
Apr 16 10:06:32 <bluelightning> david-e_: if you were to enable rm_work for example the work directory will be gone by the time the second recipe tries to look at it
Apr 16 10:06:57 <bluelightning> david-e_: the solution is to stage whatever files from the first recipe that the second recipe needs and then the second recipe can find them in the sysroot
Apr 16 10:08:16 <bluelightning> (and "stage" these days just means you need to install them into ${D} within do_install; the staging code should automatically pick up files installed to standard locations and stage them)
Apr 16 10:08:45 <bluelightning> if you need to stage files in non-standard locations that's also possible, we have examples of how to do that
Apr 16 10:09:44 <david-e_> bluelightning: I did not think about rm_work. Unfortunately I have to package a couple of 3rd party packages with sick dependencies (to compile B you need to unpack it inside A)
Apr 16 10:09:46 <ericbutters> bluelightning thank you, i already tried that one and that is not really working.. bitbake warns with: WARNING: task-lxde-base: task.bbclass is deprecated, please inherit packagegroup instead
Apr 16 10:10:27 <ericbutters> i think lxde is really good for embedded.. wondering why yocto does not have it
Apr 16 10:10:56 <rburton> ericbutters: because nobody's packaged it.  feel free to update that meta-lxde
Apr 16 10:11:16 <bluelightning> david-e_: that's probably a case where you need to just do that inside one recipe I suspect then
Apr 16 10:11:34 <ericbutters> rburton if i find time i will do that..
Apr 16 10:11:40 <david-e_> bluelightning: indeed
Apr 16 10:17:29 <ericbutters> so what do most of yocto users when building a desktop device? they put meta-openembedded and use meta-xfce or meta-gpe? is there a roadmap for yocto?
Apr 16 10:18:13 <bluelightning> I suspect a lot of users aren't building devices that need a traditional desktop UI
Apr 16 10:19:59 <rburton> i'd expect a desktop UI to be a rather small use-case
Apr 16 10:20:03 <ericbutters> i understand and i agree..
Apr 16 10:20:19 <rburton> sato is "good enough" that it's been deployed in several commercial products
Apr 16 10:28:41 <ericbutters> bluelightning, rburton is there a roadmap for yocto?
Apr 16 10:29:03 <bluelightning> ericbutters: I don't think we have anything beyond the next release no
Apr 16 10:30:34 <ericbutters> okay
Apr 16 10:30:46 <rburton> ericbutters: if there's anything you want, feel free to suggest it
Apr 16 10:33:41 <ericbutters> i think you guys do a great job..
Apr 16 14:24:49 <rburton> JaMa: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/dbus <-- can you pre-review this quickly?
Apr 16 14:26:57 <JaMa> it's not entirely quiet when testing with wrong user, but otherwise looks ok to me
Apr 16 14:27:00 <JaMa> martin@jama ~ $ killall -q -HUP dbus-daemon
Apr 16 14:27:03 <JaMa> dbus-daemon(1811): Operation not permitted
Apr 16 14:27:13 <rburton> what.
Apr 16 14:27:25 <rburton> oh, right, well, you'll be root doing the postinsts.
Apr 16 14:27:42 * rburton sends
Apr 16 14:27:45 <JaMa> yes not an issue for package manager upgrades
Apr 16 14:27:57 <JaMa> I assume that killall from busybox does the same
Apr 16 14:28:22 <rburton> i got the syntax from busybox
Apr 16 14:29:55 <rburton> jama: your patch to dbus to work around this was talking about udev
Apr 16 14:32:59 <rburton> JaMa: was that some meta-oe thin?
Apr 16 14:35:22 <JaMa> which patch do you mean?
Apr 16 14:35:48 <rburton> " fixes udev configure in run-postinsts failing with:
Apr 16 14:35:50 <rburton>   update-rc.d: /etc/init.d/dbus-1: file does not exist
Apr 16 14:35:52 <rburton>   because dbus-udev is installed only with sysvinit in features
Apr 16 14:35:54 <rburton>   but update-rc.d was always called from PN postinst"
Apr 16 14:35:56 <rburton> is what you said
Apr 16 14:37:20 <JaMa> ah sorry it looks like copy&paste from http://git.openembedded.org/openembedded-core/commit/?id=b1dca3a693bb439181a155c5248a2c6a900f729d
Apr 16 14:37:50 <JaMa> but it was different issue then this with reload
Apr 16 14:38:01 <rburton> that makes more sense
Apr 16 14:38:20 <JaMa> there is also issue with prerm, seen that on ML?
Apr 16 14:39:00 <rburton> i know of koen's mentionof systemctl --system daemon-reload
Apr 16 14:39:21 <JaMa> no prerm without sysvinit in DISTRO_FEATURES
Apr 16 14:39:29 <JaMa> in "[PATCH 1/2] systemd: set INHIBIT_UPDATERCD_BBCLASS without sysvinit in features" thread
Apr 16 14:39:47 <JaMa> http://lists.linuxtogo.org/pipermail/openembedded-core/2013-April/038052.html
Apr 16 14:39:50 <JaMa> brb
Apr 16 14:49:29 <rburton> JaMa: surely that stops if we merge that inhibiting patch?
Apr 16 14:50:08 <rburton> oh, its's merged already, so the prerm postinst from update-rcd won't exist
Apr 16 14:50:44 * rburton checks
Apr 16 14:53:35 <waynr> hmm is it a problem for multiple layers to share the same BBPRIORITY?
Apr 16 14:55:05 <rburton> i wonder if the TI UK bridge is back up
Apr 16 15:00:45 <Song_Liu> YPTM: Welcome to the technical team meeting. Please let me know who's on the bridge. Thanks!
Apr 16 15:00:50 <scottrif> YPTM: Scott Rifenbark joined the call
Apr 16 15:00:59 <Zagor> YPTM: Björn Stenberg is here
Apr 16 15:01:01 <tomz1> YPTM: Tom on the call
Apr 16 15:01:11 <Corneliu> YPTM: Corneliu joined
Apr 16 15:01:22 <strassek> YPTM: Kevin Strasser is here
Apr 16 15:01:32 <scottrif> scott R also
Apr 16 15:01:47 <scottrif> nope
Apr 16 15:01:50 <scottrif> you skipped me
Apr 16 15:01:51 <scottrif> :)
Apr 16 15:02:03 <jmpdelos> YPTM: Polk joined
Apr 16 15:02:22 <jzhang-laptop> YPTM: Jessica's on the call
Apr 16 15:02:46 <belen> YPTM: Belen's on the call
Apr 16 15:03:04 <RP> Song_Liu: YPTM, Richard is here
Apr 16 15:03:10 * rburton lost the new UK number
Apr 16 15:03:19 <rburton> RP, what's the new uk number that works?
Apr 16 15:03:25 <RP> rburton: 01908355599
Apr 16 15:03:28 <rburton> thanks
Apr 16 15:03:30 <cristianiorga> YPTM: cristian joined
Apr 16 15:03:58 <rburton> YPTM: ross joined
Apr 16 15:04:15 <Song_Liu> YPTM: Any opens?
Apr 16 15:04:27 <bluelightning_> YPTM: Paul Eggleton has joined
Apr 16 15:06:32 <nitink> YPTM: nitin is joining the bridge
Apr 16 15:08:45 <Corneliu> here is a preliminary report: https://wiki.yoctoproject.org/wiki/1.4_QA_Status
Apr 16 15:17:33 <JaMa> rburton: not sure why I've seen those issues with prerm, because as you say they shoudn't be there but were
Apr 16 15:18:31 <rburton> JaMa: i've just done a build of dbus without sysvinit, and there was no prerm
Apr 16 15:18:44 <JaMa> rburton: maybe it from upgrading from package without update-rc.d inhibited to one with inhibited
Apr 16 15:19:02 <rburton> that would mean opkg was running the old prerm *after* doing the file extraction
Apr 16 15:19:07 <rburton> which is wrong
Apr 16 15:19:23 <rburton> but hey, isn't that the motto of opkg? :)
Apr 16 15:19:32 <rburton> "opkg - doing dpkg wrong since 1989"
Apr 16 15:20:20 <darknighte> YPTM: Sean Hudson joining late...
Apr 16 15:20:25 <darknighte> Song_Liu: ^
Apr 16 15:21:10 <fray> YPTM: Mark joining late..
Apr 16 15:21:47 * zedii joins into the YPTM: joining late
Apr 16 15:22:00 * darknighte laughs at not being the last one in
Apr 16 15:22:41 <darknighte> don't forget Bruce...
Apr 16 15:22:46 <zedii> darknighte, we just make an entrance
Apr 16 15:22:53 <darknighte> heh… extra attention...
Apr 16 15:26:03 <belen> https://wiki.yoctoproject.org/wiki/Web_Hob_design_project_with_T%26T
Apr 16 15:26:07 <darknighte> belen: oh, come on, it's fun too!
Apr 16 15:26:22 <belen> http://www.yoctoproject.org/webhob/phase3_final_web_prototype/dashboard.html
Apr 16 15:27:55 <darknighte> belen: the screenshots look pretty nice...
Apr 16 15:28:19 <darknighte> dvhart: you get my email about the fri2?
Apr 16 15:28:25 <belen> darknighte: good to hear
Apr 16 15:28:32 <dvhart> darknighte, I did indeed, also replied
Apr 16 15:28:49 <darknighte> Song_Liu: lots of people are probably at collab summit
Apr 16 15:28:52 <darknighte> ?
Apr 16 15:28:57 * darknighte digs in email
Apr 16 15:29:25 <darknighte> hah… dvhart, you are *spam*!
Apr 16 15:32:04 <dvhart> indeed
Apr 16 16:07:16 <rburton> just had a scam call guy swear blind he was "calling from the world wide web"
Apr 16 16:08:36 <fray> did you ask how the weather was?
Apr 16 16:09:43 <rburton> fray: my approach this time was to deny that he was calling from the world wide web, and wait for him to insist that my Windows machines were insecure.  no windows here blaa blaa and oh yes STOP CALLING ME
Apr 16 16:09:58 <rburton> third time in three days they've called here :(
Apr 16 16:10:50 <fray> My ISP (actual call even) was calling me at one point because their automated intrusion detection shit kept telling them that my Windows machines were insecure.
Apr 16 16:11:08 <fray> I asked them which IP address, they first said they couldn't tell me over the phone, and then finally told me my main server..
Apr 16 16:11:11 <fray> which is Linux based..
Apr 16 16:11:29 <fray> apparently their little software experiment decided that since they got an odd response on a port.. I must be vulnerable...
Apr 16 16:11:49 <fray> I was port forwarding something over a strange, low number..  and they considered that insecure behavior
Apr 16 18:06:46 <kergoth> seebs: we should really get your bitbake patch to improve the error for a set -e failure merged, or something equivalent
Apr 16 18:06:54 * kergoth just got bit by one of these
Apr 16 18:08:07 <seebs> <badly dubbed voiceover> I heartily endorse this product and/or service.
Apr 16 18:10:57 <kergoth> i actually don't really like set -e, and don't use it for my own scripts, but given the quality fo recipes sometimes, best to retain it..
Apr 16 18:11:00 <kergoth> heh
Apr 16 18:14:47 <seebs> We've been keeping it merged in our tree because we got bitten by it.
Apr 16 18:15:21 <seebs> Took us TWO WEEKS of very very sporadic failures to find a particular problem. It was a case where the lack of fsync() was, on some filesystems, causing tar to emit "file changed while we were reading it" messages.
Apr 16 18:15:27 <seebs> In the middle of a tar -v.
Apr 16 18:16:07 <seebs> So we'd see a few thousand lines of file names, then a script aborting with no diagnostics that looked at all like error messages in sight.
Apr 16 18:16:17 <kergoth> ugh
Apr 16 18:16:24 <kergoth> file changed during a tar, I've definitely seen that one before
Apr 16 18:16:33 <seebs> Eventually someone browsed through carefully enough to see the messages, and realize that tar exits 1 when it prints that message, even though it doesn't print a diagnostic after the file list.
Apr 16 18:16:52 <seebs> BTW, if you see it more now, it may be because of pseudo suppressing fsyncs.
Apr 16 18:17:08 <kergoth> will keep that in mind in case it comes up
Apr 16 18:17:11 <seebs> We have had problems on, I think, one family of systems, in which a prelink done on a rootfs without fsync enabled will result in that happening.
Apr 16 18:17:24 <seebs> Our prelink calls fsync().e
Apr 16 18:17:28 <seebs> fsync() even.
Apr 16 18:17:40 <kergoth> we're using a release recipe that archives up downloads/sstate/layers/bitbake/etc into separate artifacts for creation of installers
Apr 16 18:17:50 <kergoth> ah, interesting
Apr 16 18:17:51 <seebs> Because if it doesn't, a du before and after a prelink are uninformative because the one after can report tons of files at 0 size.
Apr 16 18:18:14 <seebs> Because apparently, someone maintaining some Linux filesystem doesn't think the filesystem is obliged to report the size and modification time of files accurately.
Apr 16 18:19:53 <kergoth> yikes.
Apr 16 18:20:14 <seebs> I am fine with "the data may not have been flushed to disk yet".
Apr 16 18:20:26 <seebs> But I am really convinced that at *least* the size in bytes and mtime are obliged to be stable.
Apr 16 18:20:52 <seebs> I can grudgingly tolerate the count of blocks used being meaningless until the writes are flushed, although I dislike it.
Apr 16 18:21:11 <mranostay> hi from collab
Apr 16 18:22:32 <bluelightning> mranostay: hi not from collab... ;)
Apr 16 18:23:16 <Crofton> mranostay, who let you in there, or did you sneak in
Apr 16 18:45:19 <kergoth> okay, do_populate_lic is sstate, so ends up doing an exec_func of sstate_create_package. sstate_create_package does not define a 'dirs' flag. as a result, bitbake sets its dirs to ${B} (ugh, this is so broken), which of course by default is ${S}, whcih means do_populate_lic ends up cd'ing into ${S} unnecessarily, and if any tasks set cleandirs=${S} or equivalent, as do_rootfs does (unnecessarily, it seems, IMAGE_ROOTFS is what's used, not ${S}), it cn
Apr 16 18:45:25 <kergoth> moved
Apr 16 18:45:32 <kergoth> looks like multiple questionable behaviors interacting here
Apr 16 19:04:16 <seebs> I vote that explanation be put up on the Twiki under the heading "bitbake in a nutshell"
Apr 16 19:06:48 <hollisb> :-)
Apr 16 19:08:36 * kergoth chuckles
Apr 16 19:08:54 <kergoth> there's definitely a love/hate relationship involved
Apr 16 19:10:53 <kergoth> possibly more hate than love
Apr 16 20:00:15 <kergoth> Hmm, think I just found a problem with how INCOMPATIBLE_LICENSE is handled for binary packages
Apr 16 20:00:16 * kergoth sighs
Apr 16 20:01:59 <kergoth> Lets say you have a binary package ${PN}-foo, and this package includes ${bindir}/foo. then LICENSE_foo is GPLv3. unless you override the default FILES_${PN}, the removal of ${PN}-foo from PACKAGES will just result in shipping the foo binary with the ${PN} package instead of ${PN}-foo
Apr 16 20:02:04 <kergoth> meaning you end up shipping gplv3 content anyway
Apr 16 20:02:50 <kergoth> it needs to leave the packages in PACKAGES, but skip their actual creation, potentially just removing the files instead of moving them when populpating packages-split, or just let it split but don't emit the actual binary packages.
Apr 16 20:03:18 <fray> skip == remove and don't package.. or package and remove result
Apr 16 20:03:19 <fray> but ya..
Apr 16 20:07:42 * kergoth nods
Apr 16 21:04:46 <mranostay> hi kergoth
Apr 16 22:18:31 <JaMa> RP: ping
Apr 16 22:18:48 <JaMa> v2 was wrong, sending v2-v3 fix
Apr 16 22:19:06 <JaMa> ah you did it
Apr 16 22:19:19 <JaMa> thanks
Apr 16 22:22:01 <RP> JaMa: yes, I saw your v3 and thought I'd better fix
Apr 16 22:23:06 <JaMa> I'm sorry for that, I should have waited for build to finish or send v0 where I had those exports in system recipe
Apr 16 22:23:59 <RP> JaMa: it happens, I'm just very worried about the release now, particularly with systemd :/
Apr 16 23:14:20 <kergoth> RP: question, why are the lists in setscene_depvalid hardcoded?  particularly isSafeDep and isPostInstDep seem like they could be data-driven. i just noticed touching the external toolchain recipe rebuilds the universe.
Apr 16 23:14:26 <kergoth> heh
**** ENDING LOGGING AT Wed Apr 17 02:59:58 2013