**** BEGIN LOGGING AT Tue Jan 27 02:59:58 2015
Jan 27 03:04:35 <oldtopman> Hmm, not quite.
Jan 27 03:04:40 <oldtopman> Any ideas - ERROR: Recipe bluez5 is trying to change PR from 'r0' to 'r10'. This will cause do_package_write_* failures since the incorrect data will be used and they will be unable to find the right workdir.
Jan 27 03:12:12 <nrossi> oldtopman: Looks like a bug, have a look at https://bugzilla.yoctoproject.org/show_bug.cgi?id=5165
Jan 27 03:12:43 <nrossi> oldtopman: You might have some dependency that is causing both bluez4 and bluez5 to be build
Jan 27 03:12:53 <oldtopman> Yeah, that's what I'm seeing in the logs.
Jan 27 03:13:20 <oldtopman> How do I remove one?
Jan 27 03:13:49 <oldtopman> just 「EXCLUDE_FROM_WORLD_append = " lib32-bluez4"」?
Jan 27 03:13:56 <nrossi> oldtopman: first figure out how both are getting in
Jan 27 03:14:09 <nrossi> oldtopman: bitbake -g <your-target>
Jan 27 03:14:50 <nrossi> oldtopman: will generate some dependency graphs, unfortunately you will have to look through and figure out what depends on bluez4/5
Jan 27 03:16:21 <oldtopman> Eh, I've done worse in this project alone. I'll let you know what's up after I get graphviz installed.
Jan 27 03:21:58 <nrossi> oldtopman: http://lists.openembedded.org/pipermail/openembedded-core/2015-January/101033.html that looks like a patch to resolve the issue you are getting, have a look at some of the recipes it modifies (they are probably what is causing your issue)
Jan 27 03:22:53 * oldtopman takes a look
Jan 27 03:47:23 <oldtopman> Man, these graphs take a bit to make :/
Jan 27 03:47:57 <nrossi> oldtopman: i normally just read them with less/vim and grep... visually they are tooo big :P
Jan 27 03:49:53 <oldtopman> nrossi: bluez5 shows up a heck of a lot more than bluez4, so I'm thinking 5 was the one intended for the edison.
Jan 27 03:50:21 <oldtopman> Just connman and packagegroup-base, if I'm reading the .dot file correctly.
Jan 27 03:50:33 <oldtopman> (which seem really important, but bluez5 seems to be linked to even more things :/
Jan 27 03:50:42 <oldtopman> Thoughts?
Jan 27 03:52:49 <nrossi> oldtopman: makes sense, try changing the recipes for connman, so that it depends on bluez5 instead of bluez4
Jan 27 03:53:26 <nrossi> oldtopman: after all thats exactly what that about patchset i linked is doing: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=pabigot/rfc-v2/bluez5&id=2c6dcda1e6ab4caee05c9ec7b2a6d47c77536afa
Jan 27 03:53:36 <nrossi> above*
Jan 27 04:01:46 <oldtopman> nrossi: Looks like pulseaudio depends on it too.
Jan 27 04:02:22 <nrossi> oldtopman: do that same thing ;) http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=pabigot/rfc-v2/bluez5&id=ae898954fec807b75dc96083a3aff837476dbeba
Jan 27 04:02:48 <oldtopman> lol
Jan 27 04:06:54 <oldtopman> nrossi: Is there a way to exclude a package from being built?
Jan 27 04:07:28 <oldtopman> I don't really want gst-meta-base, it isn't depended on by anything, and it adds pulseaudio (which I don't want)
Jan 27 04:08:11 <nrossi> oldtopman: Never done it myself, but have a look at this variable: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-PACKAGE_EXCLUDE
Jan 27 04:55:13 <oldtopman> nrossi: So it still doesn't work :/
Jan 27 04:56:28 <nrossi> oldtopman: hmmm which 'it' and whats the 'error'?
Jan 27 04:57:34 <oldtopman> nrossi: Still throwing the same "trying to change PR from r0 to r10" error. I've tried changing the bluez versions in the offending scripts, as well as blacklisting one/the other/both with PACKAGE_EXCLUDE in local.conf
Jan 27 04:58:40 <oldtopman> My next step would be to find where some of these packages (read: pulseaudio) are being called as dependencies, then nuke 'em from there.
Jan 27 04:58:41 <nrossi> oldtopman: If you think you have solved the dependency, try wiping out the tmp/ directory and let yocto rebuild from shared state
Jan 27 04:59:08 <nrossi> oldtopman: audo might be coming from a machine/distro feature being set, e.g. 'alsa'
Jan 27 04:59:58 <oldtopman> It wasn't there before I added x11, if I recall correctly.
Jan 27 05:01:23 <nrossi> oldtopman: hmmm, you could always remove the core-image-sato and start adding smaller pieces of that image
Jan 27 05:01:57 <oldtopman> nrossi: That's a way better idea. How would I go about finding what composes core-image-sato?
Jan 27 05:02:15 <nrossi> oldtopman: https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-sato/packagegroups/packagegroup-core-x11-sato.bb
Jan 27 05:02:26 <oldtopman> Also, can I just delete the build/tmp folder? I thought some stuff didn't regenerate.
Jan 27 05:02:51 <oldtopman> (It's 52.5gb, so I'd really love to be able to.
Jan 27 05:04:08 <nrossi> oldtopman: i live on the edge and rebuild on my nice 20 core server so... but shared state should be able to populate most of you build out
Jan 27 05:05:04 <oldtopman> Aww boo. I've only got a quad core computer here. Never thought I'd call it slow, but it is :/
Jan 27 05:05:24 <oldtopman> Also, the graphviz graph finished, but it blew up gimp trying to open it.
Jan 27 05:05:58 <nrossi> oldtopman: yer i imagine the image is probably over the max size that gimp can handle :|
Jan 27 05:08:12 <nrossi> oldtopman: also if you need to reduce build output size, try the 'INHERIT += "rm_work"' setting
Jan 27 05:11:32 <oldtopman> nrossi: Thanks for the link, this is very likely going to be a lot more manageable now.
Jan 27 05:12:27 * oldtopman waits for it to catch fire again
Jan 27 05:14:22 <nrossi> oldtopman: 'i fell into a ring of fire'
Jan 27 05:14:59 <oldtopman> nrossi: If you don't mind me asking, what hardware do you use openembedded on?
Jan 27 05:15:24 <nrossi> oldtopman: I work for Xilinx... so Xilinx hardware ;) (ARM and MicroBlaze)
Jan 27 05:15:52 <oldtopman> Ah, nice!
Jan 27 05:24:58 <oldtopman> nrossi: Alright, after much troubleshooting, apparently the DISTRO_FEATURES_append += " x11" is causing the problem.
Jan 27 05:25:25 <oldtopman> Where should I be looking to chase problems there down?
Jan 27 05:26:20 <nrossi> oldtopman: out of query, before digging do you actually need bluetooth?
Jan 27 05:26:49 <oldtopman> I'd really like it; the edison has it built in.
Jan 27 05:27:06 <oldtopman> But no, I don't need it at all. More than happy to remove it if that's what it takes to get X going.
Jan 27 05:27:42 <nrossi> oldtopman: well it looks like the easiest path to getting x11 building out would be to disable it for now
Jan 27 05:28:09 <nrossi> oldtopman: remove it from DISTRO_FEATURES, either from your local.conf or via DISTRO_FEATURES_remove = "bluetooth"
Jan 27 05:30:39 <oldtopman> Actually, Intel's been pretty lazy with support. It works with HID devices, and not much else. If it had A2DP support, then I'd want it really badly :p
Jan 27 05:31:42 <nrossi> oldtopman: I've actually been looking at using the edison for a personal project. Was turned off a bit after seeing some chatter about non-public yocto layers
Jan 27 05:32:01 <oldtopman> nrossi: Alright, same error even with 「DISTRO_FEATURES_remove = "bluetooth"」. Delete build/tmp directory?
Jan 27 05:32:05 <oldtopman> How do you mean?
Jan 27 05:32:26 <nrossi> oldtopman: yer, wipe temp. Seems like it might be getting stuck
Jan 27 05:32:52 <oldtopman> damn
Jan 27 05:33:01 <oldtopman> I wonder how long it's been stuck like that.
Jan 27 05:33:02 <nrossi> oldtopman: they hadn't release support in meta-intel or via a seperate layer... it was only supported within a specific download tarball
Jan 27 05:35:08 <oldtopman> Ah, right.
Jan 27 05:35:35 <oldtopman> At least it's not a bunch of binary blobs.
Jan 27 05:36:09 <nrossi> oldtopman: true
Jan 27 05:36:51 <oldtopman> They've even got a whole document dedicated to adding the meta-oe recipe box, which is why I'm here.
Jan 27 05:42:05 <oldtopman> nrossi: Well, thanks for your help this evening. I think you've given me the tools required to troubleshoot this thing.
Jan 27 05:42:26 <oldtopman> I'll be back, I'm sure, but rm-rf is still going strong, so it'll be a bit before it finishes compiling.
Jan 27 05:42:54 <nrossi> oldtopman: hope you sort it out :), im not particularly familar with the bluetooth stuff in OE. So maybe someone on list might know more
Jan 27 05:43:41 <oldtopman> Well, bluetooth is smaller than X, so if I get X working, hopefully it will be fairly easy to add to the mix.
Jan 27 05:43:54 <oldtopman> At least now I can say that I've rolled my own distro :p
Jan 27 07:54:17 <mckoan> good morning
Jan 27 08:00:51 <woglinde> gm
Jan 27 08:07:36 <mckoan> hi woglinde 
Jan 27 08:27:46 <Noor> hi
Jan 27 08:28:02 <Noor> do we have apt-get kind of recipe in openembedded?
Jan 27 08:28:35 <Noor> which can install a package on the target from the server
Jan 27 08:34:10 <woglinde> noor opkg?
Jan 27 08:34:50 <Noor> woglinde: doesn't we have to provide ipk file to opkg
Jan 27 08:35:03 <woglinde> no
Jan 27 08:35:08 <woglinde> opkg update
Jan 27 08:35:19 <woglinde> opkg install packagename
Jan 27 08:35:33 <woglinde> if you setup /etc/opkg/ files right
Jan 27 08:41:19 <Crofton> A customer stumbled into this
Jan 27 08:41:20 <Crofton> http://git.alsa-project.org/?p=alsa-utils.git;a=commit;h=8f361d83cfcb39887f5fc591633e68d9448e3425
Jan 27 08:41:53 <woglinde> gm crofton
Jan 27 08:42:00 <Crofton> We can work around, but it might be nice to get it into the alsa-utils recipe to avoid the regression
Jan 27 08:42:02 <Crofton> gm
Jan 27 08:42:58 <woglinde> crofton make a patch?
Jan 27 08:43:12 <Crofton> yeah, just checking if it is worth y time :)
Jan 27 08:43:17 <Crofton> will do so in a bit
Jan 27 09:28:28 <bluelightning> morning all
Jan 27 09:28:36 <mckoan> hi bluelightning, all
Jan 27 09:30:10 <woglinde> hi bl
Jan 27 09:30:54 <Crofton> gm
Jan 27 09:31:06 <Crofton> good to be at work before bluelightning 
Jan 27 09:31:18 <Crofton> belen, you ready for FOSDEM
Jan 27 09:32:22 <belen> Crofton: ready for beer, that's for sure ;)
Jan 27 09:32:49 <LetoThe2nd> "screw you conf people we're drinking at home!!1!one!"
Jan 27 09:33:51 <woglinde> haha
Jan 27 09:36:13 <Crofton> belen, I'm at the point where I start to freak out
Jan 27 09:36:29 <Crofton> I need to recruit some people to deal with the video
Jan 27 09:36:45 <Crofton> and i am not looking forward to picking up the box :)
Jan 27 09:37:44 <belen> Crofton: everything will sort itself out, I am sure … I hope …. *glup*
Jan 27 09:38:21 <Crofton> yep
Jan 27 09:38:38 <Crofton> Pick a bunch of beer to hand out to people that help
Jan 27 09:38:46 <woglinde> haha
Jan 27 09:38:52 <Crofton> I'd also get some water early in the day for speakers
Jan 27 09:39:30 <koen> and some doner for Crofton, we'll follow the lettuce trail
Jan 27 09:39:42 <Crofton> that was a bagette
Jan 27 09:39:47 <belen> Crofton: right, I should remember that. 
Jan 27 09:40:53 <belen> water, bagettes…. *makes list*
Jan 27 09:41:04 <Crofton> heh
Jan 27 09:41:16 <Crofton> I'll need to explain koen's comment better :)
Jan 27 09:49:53 <koen> hmmm, prepare for cold or rain?
Jan 27 09:50:03 <hrw> both
Jan 27 09:50:17 <hrw> in my case it means same clothes
Jan 27 09:51:12 <hrw> but I go home->sxf->bru->fosdem->crl->prg->brno->home so a bit more variety of weather
Jan 27 09:58:35 <woglinde> hoi hrw
Jan 27 09:59:02 <hrw> woglinde: you going?
Jan 27 09:59:07 <woglinde> hrw fine
Jan 27 09:59:14 <woglinde> but the family was sick
Jan 27 09:59:49 <woglinde> hrw whats crl in your list?
Jan 27 10:00:05 <hrw> woglinde: that ryanair airport under brussels
Jan 27 10:00:35 <woglinde> hm oh okay
Jan 27 10:00:51 <hrw> it is hard to get from brussels to brno. ->prg or ->vie are best options
Jan 27 10:01:38 <woglinde> yes
Jan 27 10:01:54 <woglinde> hrw how is it at red hat in general?
Jan 27 10:02:39 <hrw> woglinde: good
Jan 27 10:03:13 <hrw> woglinde: I think that when it comes to armv8 it is best place to put hands on hardware
Jan 27 10:03:26 <Crofton> vie then take studentagency.cz bus :)
Jan 27 10:03:38 <hrw> Crofton: prg and same bus but wifi all the way
Jan 27 10:03:49 <Crofton> ok
Jan 27 10:04:01 <belen> Crofton: now I know what you meant by "the box" 
Jan 27 10:04:06 <hrw> Crofton: and I have O² Slovakia simcard ready for that trip
Jan 27 10:04:09 <Crofton> very true, no wifi in the austria bit
Jan 27 10:04:23 <Crofton> belen, catching up on email
Jan 27 10:04:34 <belen> Crofton: yep
Jan 27 10:04:40 <mago_> morning all
Jan 27 10:04:45 * woglinde wonders if crofton spends more time on eu as in us
Jan 27 10:06:09 <hrw> woglinde: probably tries to keep 184 days in us 
Jan 27 10:11:34 <Crofton> heh
Jan 27 10:11:41 <Crofton> I wish
Jan 27 10:16:57 <Crofton> belen, https://fosdem.org/2015/schedule/event/session_3/
Jan 27 10:17:02 <Crofton> could stand some ditting
Jan 27 10:17:04 <Crofton> editing
Jan 27 10:18:07 <belen> Crofton: in what sense? Too long? Or grammatically incorrect? Or both?
Jan 27 10:18:21 <Crofton> first para is duped :)
Jan 27 10:18:49 <belen> just saw that. Better get that fixed
Jan 27 10:18:52 <belen> Thanks!
Jan 27 10:21:35 <mago_> bluelightning: have you ever seen anything like this when moving between different OE versions (e.g dizzy back to daisy) in the same directory? http://pastebin.com/d9hv1fXa .. looking at the bitbake code, it seems that the "unpickler" de-serialization of some cache .lock-file fails. And the code does gracefully handle IOErrors and EOFError exceptions, but not this kind of AttributeError. I see this on my build
Jan 27 10:21:37 <mago_> server when I tell it to build an older build (based on daisy), which it does in the active tree (e.g just checkout the correct revisions of everything and rebuild, it does not wipe the whole build tree first)
Jan 27 10:22:29 <bluelightning> mago_: no, but I can't say I would advise that kind of reverse move with the same build directory / TMPDIR as a general rule
Jan 27 10:23:00 <mago_> i always wipe the TMPDIR, but i leave sstate-cache, cache and such files
Jan 27 10:23:35 <mago_> so you would recommend putting sstate-cache elsewhere and always start from scratch when doing server-builds?
Jan 27 10:26:01 <hrw> mago_: different OE versions should have own copies of cache. you can share dl_dir but avoid other
Jan 27 10:27:05 <hrw> mago_: anything can change between OE versions so you are asking for troubles (and storage is cheap)
Jan 27 10:27:22 <mago_> gotcha, thanks
Jan 27 10:29:59 <bluelightning> you should be able to share the sstate-cache, but I usually don't - the amount of commonality between two releases is going to be pretty small given the amount of churn at the lower levels
Jan 27 10:30:15 <bluelightning> e.g. if we upgrade m4 or autotools, that's pretty much all of the signatures changed
Jan 27 10:35:05 <mago_> bluelightning: okay, sounds logical. Also, about #7024, i've been unable to reproduce it again on Dizzy (which we moved up to now). If you want, I can check if it was a daisy issue (which would mean its either a problem in bitbake 1.22 or the daisy-branch of meta-oe-core), or should I just drop it?
Jan 27 10:37:29 <bluelightning> mago_: hmm, let me just see if I can see that the dependency code got added after daisy
Jan 27 10:38:03 <mago_> i'm rebuilding my tree on daisy now to see if i can reproduce it there still
Jan 27 10:38:40 <mago_> (but it's gonna take a few hours, cause my workstation is doing other stuff right now)
Jan 27 10:39:13 <bluelightning> mago_: if that's the only reason you're doing that, you can kill it - I just verified, the commit that fixed it never made it into daisy
Jan 27 10:39:25 <bluelightning> OE-Core commit b8b6214b885a0757f0e628937f8fe21c92c45155
Jan 27 10:39:36 <bluelightning> I'm unsure as to whether we would backport that at this stage
Jan 27 10:39:42 <mago_> ah, okay
Jan 27 10:40:05 <mago_> well, it was annoying on daisy, but no issue for me anymore since we've moved to dizzy
Jan 27 10:40:15 <bluelightning> could you make a comment on the bug, and then I'll mark it accordingly?
Jan 27 10:40:20 <mago_> sure
Jan 27 10:55:19 <bluelightning> mago_: thanks!
Jan 27 11:00:02 <bluelightning> mago_: bit on your earlier question re the pythonCacheLine error, I suspect that's an issue with loading the cache from cache/ under the build directory, perhaps we changed the format between releases
Jan 27 13:07:33 <bottazzini> Guys, I've got PACKAGECONFIG ??= "lib_here", I want to remove this without changing the original recipe. Are there any way of doing this ? Example: PACKAGECONFIG_EXCLUDE = "lib_here"
Jan 27 13:19:03 <bluelightning> bottazzini: PACKAGECONFIG_remove = "lib_here"
Jan 27 13:19:17 <bluelightning> if you mean in a bbappend
Jan 27 13:19:33 <bluelightning> if you mean at the configuration level, you would need to use an override to make it specific to the recipe
Jan 27 13:19:50 <bluelightning> i.e. PACKAGECONFIG_remove_pn-xyz = "lib_here"
Jan 27 13:20:26 <bottazzini> bluelightning, got it! Thanks a lot 
Jan 27 14:16:36 <Crofton> stat: invalid option -- 'L
Jan 27 14:16:48 <Crofton> I see this when an image made from recent master boots
Jan 27 14:16:52 <Crofton> a couple of times I think
Jan 27 14:20:27 <bluelightning> Crofton: there's a patch on the list for that I think
Jan 27 14:25:12 <Crofton> ok
Jan 27 14:25:18 <Crofton> that would be great
Jan 27 14:25:36 <Crofton> I have a bleeding edge build so I can help find these things
Jan 27 14:25:44 <Crofton> working on the fosdem demo :)
Jan 27 14:26:00 <Crofton> this item is not critical
Jan 27 14:34:47 <Crofton> wtf happened to top?
Jan 27 14:34:51 <Crofton> fray__, ?
Jan 27 14:36:36 <bluelightning> Crofton: the colours you mean?
Jan 27 14:38:58 <bluelightning> Crofton: if yes, that's procps-ng, we had a community rant about it the other day in #yocto
Jan 27 14:39:24 <bluelightning> I think paulg was planning on sending a patch to force it back to the standard display
Jan 27 14:39:31 <Crofton> :)
Jan 27 14:39:53 <Crofton> I think I saw the rant. I thought fray__ was involved :)
Jan 27 14:40:28 <Crofton> I am looking at it now
Jan 27 14:40:34 <Crofton> omg, they were right to rant
Jan 27 14:44:26 <bluelightning> I'm not sure what they were thinking when they changed the default upstream
Jan 27 15:02:22 <mago_> is there a way to build dsp firmware with OE? i guess that would involve at least another toolchain, possibly some kind of DSP_MACHINE-concept, and possibly another sysroot 
Jan 27 15:07:42 <bluelightning> mago_: there's nothing in the core to directly support that, but in principle that should be possible
Jan 27 15:08:12 <koen> meta-ti does it for the dsp, m3, m4 and pru
Jan 27 15:08:16 <koen> it isn't pretty
Jan 27 15:11:10 <mago_> ok, i'll have a look at that then
Jan 27 15:11:15 <mago_> thanks
**** BEGIN LOGGING AT Tue Jan 27 16:12:13 2015
Jan 27 16:13:04 <bluelightning> probably helpful if you mention roughly when the patch should be dropped, e.g. [merged for 2.0 release]
Jan 27 16:13:26 <bluelightning> maybe merged is not quite the right word but you get the idea
Jan 27 16:13:38 <Crofton> I would do that in the commit message
Jan 27 16:13:54 <Crofton> drop next alsa-utils release
Jan 27 16:14:13 <Crofton> http://git.alsa-project.org/?p=alsa-utils.git;a=patch;h=8f361d83cfcb39887f5fc591633e68d9448e3425
Jan 27 16:14:25 <bluelightning> better in the patch file itself, that's the idea with having this header, so you only have to look there
Jan 27 16:15:05 <kergoth> people have a tendency to not bother looking through git history for things like that
Jan 27 16:19:03 <Crofton> well, when the version bumps it will fail as being reverse applied
Jan 27 16:20:26 <kergoth> so adjust it to apply, its okay if it's not 100% pristine, that's why its a backport not a cherry pick :)
Jan 27 16:20:59 <bluelightning> Crofton: in theory yes, but I have found that quilt will not complain sometimes on reverse-applicable patches
Jan 27 16:22:16 <Crofton> ok
Jan 27 16:22:42 <bluelightning> in my scan late last year I found at least three in that state that nobody had noticed
Jan 27 16:22:58 <bluelightning> not that having those around was a terrible thing, but interesting to note
Jan 27 16:23:58 <kergoth> huh
Jan 27 16:23:59 <kergoth> interesting
Jan 27 16:24:42 <bluelightning> it was only when I attempted to use devtool extract/modify on them that they became apparent
Jan 27 16:27:27 <koen> don't feel bad about patches, the mozjs package in fedora has a patch that adds a .rej file
Jan 27 16:27:35 <koen> and that patch came from RHEL
Jan 27 16:27:45 <koen> quality review proces :)
Jan 27 16:29:39 <bluelightning> heh
Jan 27 16:29:54 <bluelightning> anything can slip through if nobody's looking :)
Jan 27 16:35:08 <woglinde> koen the qs process at redhat for fedora is fairly poor
**** ENDING LOGGING AT Wed Jan 28 02:59:59 2015