**** BEGIN LOGGING AT Mon Aug 05 02:59:58 2013
Aug 05 07:23:54 <arky> Heading to Hong Kong, Anyone know where to pickup a NUC?
Aug 05 07:50:07 <lpapp> rburton: have you seen my TOPDIR question?
Aug 05 07:51:09 <rburton> considering i've been on IRC for a good ten seconds, no. :)
Aug 05 07:51:18 <lpapp> rburton: it was on Friday.
Aug 05 07:51:34 <rburton> i don't recall seeing it before I left on Friday.
Aug 05 07:51:45 <lpapp> rburton: is there a variable dedicated to PROJDIR?
Aug 05 07:51:55 <lpapp> rburton: currently, I am using TOPDIR/.. inside the bblayers
Aug 05 07:52:02 <lpapp> but it is fragile.
Aug 05 07:53:21 <lpapp> something like projdir, or rootdir would be nice
Aug 05 07:53:37 <lpapp> we could write ${rootdir}/meta-yocto ... etc then.
Aug 05 07:53:53 <lpapp> and it would work for every developer, and even for the CI.
Aug 05 07:54:48 <lpapp> and oe-init-build-env knows the rootdir, as it is inside.
Aug 05 07:55:51 <rburton> there's COREROOT or something if you want the location of oe-core, iirc
Aug 05 07:56:05 <bluelightning> morning all
Aug 05 07:56:06 <lpapp> but then I would still need the parent.
Aug 05 07:56:48 <lpapp> I need a variable for the container folder of the layers.
Aug 05 07:57:15 <lpapp> well, for the rootdir, to be precise, but it is the same 99%
Aug 05 07:58:27 <lpapp> that would allow a nice bblayers.conf structure.
Aug 05 08:07:12 <RP> lpapp: that directory might be in multiple places, you don't have to have all layers in one directory
Aug 05 08:09:40 <lpapp> RP: nope
Aug 05 08:09:54 <lpapp> it is not related to layers, it is the rootdir or projectdir as its name would say.
Aug 05 08:10:25 <lpapp> and yes, most people have the layers in that folder.
Aug 05 08:10:52 <lpapp> or semi-relatively to that.
Aug 05 08:11:13 <lpapp> it would not make TOPDIR/.. more difficult after all, just easier.
Aug 05 08:11:17 * lpapp is filing a bugreport
Aug 05 08:28:42 <ant_work> rburton: bluelightning: I run a quick build adding xinput-calibrator *and* pointercal-xinput to my XSERVER and then sato's do_rootfs fails because task packagegroup-core-x11-base cannot install pointercal-xinput.
Aug 05 08:29:01 <ant_work> now, this latter is in the RRECOMMENDS of xinput-calibrator
Aug 05 08:29:33 <bluelightning> ant_work: it'll be elsewhere too via XSERVER surely...?
Aug 05 08:29:36 <ant_work> I see there isn't any pointercal-xinput package (it is skipped 'cause empty I guess)
Aug 05 08:29:55 <bluelightning> ant_work: right, so you shouldn't add it to XSERVER I guess
Aug 05 08:30:35 <ant_work> I've added one .bbappend with a bogus pointercal in my layer but no differences..
Aug 05 08:30:50 <ant_work> I had to remove pointercal-xinput from my XSERVER var
Aug 05 08:31:06 <bluelightning> right, I don't think you need it there anyway
Aug 05 08:31:50 <ant_work> the idea was about provifing custom per-machine calibration
Aug 05 08:32:02 <rburton> hm
Aug 05 08:32:08 <ant_work> pre-calibration
Aug 05 08:32:33 <rburton> that should be a recommends then as it *can* be empty on machines without a pre-calibration
Aug 05 08:33:28 <ant_work> ok but why did it fail with provided not-empty cal. file?
Aug 05 08:33:54 <rburton> hm
Aug 05 08:34:06 <ant_work> it was too late to check, I'll do today
Aug 05 08:35:03 <ant_work> rburton: in meta-oe xinput-calibrator was one rdeps of xserver-nodm-init
Aug 05 08:35:46 <bluelightning> but that can't work for non-touchscreen devices
Aug 05 08:39:40 <lpapp> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4980
Aug 05 08:39:41 <yocti> Bug 4980: normal, Undecided, ---, richard.purdie, NEW , Variable for the root/project dir
Aug 05 08:46:52 <rburton> JaMa: ask nicely and i'll push dates patches upstream
Aug 05 08:47:37 <ant_work> bluelightning: need surely some kind of conditional
Aug 05 08:51:24 <ant_work> rburton: bluelightning: I correct myself: in meta-oe it is one of the RDEPENDS of xserver-common (which is a RDEPEND of xserver-nodm-init)
Aug 05 08:51:51 <JaMa> rburton: the same commit message as eds applies to dates :/
Aug 05 08:52:29 <JaMa> rburton: lets wait for someone to at least test them in runtime, but thanks :)
Aug 05 08:52:38 <rburton> heh
Aug 05 08:52:41 * rburton reads
Aug 05 08:53:35 <rburton> JaMa: so i was right to move them out of oe-core then, if nobody noticed its been broken for months
Aug 05 08:53:45 <ant_work> rburton: bluelightning: if we keep the oe-core structure we could add xinput-calibrator to x11-common (and remove xtscal from there?)
Aug 05 08:54:12 <JaMa> rburton: I've noticed it :) it was also reported in my "state of bitbake world" emails
Aug 05 08:54:30 <rburton> JaMa: well, nobody else
Aug 05 08:54:33 <JaMa> rburton: now I had to fix it just to allow test-dependencies.sh to test if at least dependencies are correct :)
Aug 05 08:55:22 <JaMa> I remember that I've asked you to move dates becuse someone wanted it in SHR feeds, but SHR feeds are now using dylan release so I haven't noticed it there too
Aug 05 08:58:37 <RP> rburton: in core, we would have noticed failures sooner
Aug 05 08:59:23 <rburton> JaMa: do shr users really use dates/contacts still?
Aug 05 09:00:21 <JaMa> rburton: true about devilspie, I'll probably update that commit after test-dependencies.sh run is completed (if it reveals that libwnck autodetects startup-notifications), this commit was just to get the script going
Aug 05 09:00:47 <JaMa> rburton: someone asked for it to be in feed, but I didn't get any feedback since then
Aug 05 09:01:32 <JaMa> to be returned to feed, to be precise so he was probably using it before
Aug 05 09:18:45 <Zagor> a long vacation is nice. then mailbox when you get back, not so much.
Aug 05 09:19:17 <rburton> Zagor: select all, mark as read.
Aug 05 09:19:51 <Zagor> yeah I do it for the most part.
Aug 05 09:20:34 <rburton> Zagor: i feel honoured to get a reply from you then ;)
Aug 05 09:21:08 <Zagor> heh :)
Aug 05 10:10:34 <rburton> JaMa: you seem like someone who will know... is there a way to easily step through ever commit in a branch, i.e. looping through a checkout of each commit?
Aug 05 10:11:00 <rburton> JaMa: thinking a tool to run buildhistory-diff after every commit in a branch might be useful
Aug 05 10:12:55 <bluelightning> rburton: FWIW, combo-layer does that... not particularly sophisticated
Aug 05 10:13:42 <rburton> a git iterate would be so useful
Aug 05 10:13:55 <rburton> checkout every commit, run this script
Aug 05 10:14:48 <bluelightning> rburton: google it, it's been done already ;)
Aug 05 10:14:59 <rburton> ha
Aug 05 10:16:47 <JaMa> I would write one for loop for that
Aug 05 10:18:06 <lpapp> rburton: like history rewriting?
Aug 05 10:18:27 <JaMa> for rev in `git log --oneline $START..$STOP | cut -d ' ' -f 1`; do git checkout $rev; do_something | tee log.$rev; done
Aug 05 10:18:40 <rburton> JaMa: i bet you can drop the cut
Aug 05 10:19:46 <JaMa> rburton: true, git rev-list $START..$STOP would be better
Aug 05 10:20:04 <rburton> ah, i was thinking of using the pretty controls
Aug 05 10:20:06 <rburton> forgot about that one
Aug 05 10:20:45 <JaMa> and I like the idea of running buildhistory-diff, especially for "upgrade" commits
Aug 05 10:20:52 <rburton> exactly
Aug 05 10:21:58 <JaMa> I'm sorry if I sounded too negative when reporting last libpng issue, but it's not the first time simple upgrade caused some issues and IIRC using buildhistory was considered almost mandatory
Aug 05 10:22:29 * JaMa should find some time to finish world-image support
Aug 05 10:22:29 <rburton> JaMa: should be. partly to blame for not checking that myself.
Aug 05 10:22:34 <rburton> thats why i want to automate it
Aug 05 10:30:01 <bluelightning> we really ought to have buildhistory-web set up on the autobuilder... there is a bug filed for it
Aug 05 10:31:53 <rburton> yeah
Aug 05 10:32:01 <rburton> then we could browse the history from MUT
Aug 05 10:38:14 <rburton> hm you can't amend in an iterate, as the hashes change. that's a shame.
Aug 05 10:54:49 <ant_work> JaMa: wrt test-dependencies-2013-07-24, iirc you didn't use meta-initramfs, isn't?
Aug 05 10:55:25 <ant_work> JaMa: I guess that's why all -klibc recipes failed
Aug 05 11:06:16 <JaMa> ant_work: same config as every world build I do, so meta-initramfs was included
Aug 05 11:07:20 <JaMa> ant_work: + all -klibc recipes are in meta-initramfs, aren't they?
Aug 05 11:08:16 <ant_work> yea, silly question
Aug 05 11:08:40 <ant_work> though, I know the recipes do build ;)
Aug 05 11:10:24 <ant_work> I don't fully understand why are listed as failed
Aug 05 11:13:05 <JaMa> they were failing quite often in reqular builds so I'm not surprised they failed
Aug 05 11:19:03 <ant_work> hm.. again  fatal error: linux/limits.h: No such file or directory
Aug 05 11:22:24 <rburton> with yocto, there are no limits
Aug 05 11:22:33 <rburton> boom tish, thankyou everyone, i'll be here all week
Aug 05 11:50:26 <ant_work> seems linux-libc-headers were missing
Aug 05 12:05:53 <ant_work> hm.. are not in DEFAULT_DEPS
Aug 05 12:10:02 <ant_work> JaMa: I'm perplexed because all -klibc recipes do depend on klibc so indirectly on linux-libc-headers
Aug 05 12:11:19 <bluelightning> ant_work: I'm not sure if the system works that way - if your recipe fails to build without linux-libc-headers in the sysroot, you need to add an explicit DEPENDS on it
Aug 05 12:12:56 <ant_work> hm even if the klcc crosscompiler depends on linux-libc-headers to be built?
Aug 05 12:13:22 <ant_work> sounds strange
Aug 05 12:15:19 <JaMa> try bitbake -e and bitbake -g to be sure
Aug 05 12:16:11 <ant_work> will do
Aug 05 12:19:24 * bluelightning is looking at bringing over libav into OE-Core
Aug 05 12:19:34 <bluelightning> these recipes are a bit of a mess :/
Aug 05 12:19:42 <bluelightning> they produce bunch of QA warnings as well
Aug 05 12:20:40 <ant_work> see about the possible configuration
Aug 05 12:20:42 <ant_work> http://wiki.gentoo.org/wiki/Libav
Aug 05 12:21:56 <bluelightning> a bit annoying that it seems we might have to pull in x264 and therefore yasm (and maybe libvpx which doesn't seem to be explicitly enabled?)
Aug 05 12:22:09 <JaMa> bluelightning: please move only newer one if possible
Aug 05 12:22:21 <bluelightning> JaMa: newer one?
Aug 05 12:22:39 <JaMa> bluelightning: git version depends on separate libpostproc and older release recipe is conflicting with separate libpostproc
Aug 05 12:23:05 <bluelightning> JaMa: so should we move to a newer release version then?
Aug 05 12:23:15 <bluelightning> the release version is quite old by now
Aug 05 12:23:35 <JaMa> bluelightning: newer release if possible or move only _git.bb
Aug 05 12:23:56 <bluelightning> JaMa: I don't mind upgrading; the only issue would be testing to make sure there aren't any regressions
Aug 05 12:28:48 * JaMa haven't used libav on target for long time
Aug 05 12:31:00 <bluelightning> hmm seems libvpx may not be needed, configure log indicates it isn't enabled
Aug 05 12:31:14 <bluelightning> I can add a PACKAGECONFIG for it though
Aug 05 12:37:45 <ant_work> bluelightning: th elist would be long...
Aug 05 12:38:03 <bluelightning> ant_work: I'm only adding a few for the moment :)
Aug 05 12:38:19 <ant_work> you've pick up a nasty one this time ;)
Aug 05 12:38:46 <bluelightning> I've been putting this off for ages, I just want to get rid of one more bbappend in meta-oe (the gst-ffmpeg one)
Aug 05 12:39:45 <ant_work> seems libav expects finer config in bsp layer
Aug 05 12:44:53 <bluelightning> hmm looks like the _git recipe is v9.1+
Aug 05 12:45:15 <bluelightning> or at least, the revision pointed to by SRCREV only appears there
Aug 05 12:54:09 <bluelightning> JaMa: seems like v9 is an API break and the separation of libpostproc was something done upstream
Aug 05 12:54:21 <bluelightning> so I'm not sure what we should be doing here...
Aug 05 12:54:46 <bluelightning> if nobody needs 0.8.x then we can drop it, but are we sure this is the case?
Aug 05 12:56:43 <bluelightning> JaMa: have you been doing world builds with the current libav_git recipe?
Aug 05 13:02:41 <JaMa> bluelightning: with default version which is IIRC the release
Aug 05 13:02:52 <JaMa> but had to blacklist libpostproc to prevent failures
Aug 05 13:06:14 <bluelightning> hmm
Aug 05 13:06:22 <bluelightning> well that suggests that we should be keeping 0.8.x
Aug 05 13:07:01 <bluelightning> angstrom is using the 0.8.x recipe as well it seems
Aug 05 13:10:04 <bluelightning> argh why does the git recipe need to filter out --enable-libpostproc? it's not even in EXTRA_OECONF to begin with...
Aug 05 13:10:15 <bluelightning> oh wait
Aug 05 13:10:22 <bluelightning> reading comprehension fail
Aug 05 13:13:17 <bluelightning> actually, it still shouldn't need to
Aug 05 14:10:24 <bluelightning> JaMa: I wonder if this libav git recipe has been tested, because the libpostproc recipe has libav in its DEPENDS -> circular dependency loop
Aug 05 14:31:12 <JaMa> otavio_: do you remember testing libav_git recipe? ^^^
Aug 05 14:50:51 <halstead> sgw1, You around?
Aug 05 14:52:32 <sgw1> halstead: OTP
Aug 05 15:05:07 <otavio_> JaMa: yes I did but looong time ago
Aug 05 15:06:02 <otavio> JaMa: bluelightning: I tested it when working in xbmc patches
Aug 05 15:06:12 <otavio> JaMa: but didn't work on it for a while now
Aug 05 15:06:35 <JaMa> otavio: I know it's long time ago, but looks like bluelightning is right and circular dependency was there since it was introduced
Aug 05 15:06:52 <otavio> JaMa: but I did test it
Aug 05 15:06:59 <otavio> JaMa: I am not how/when
Aug 05 15:08:04 <bluelightning> otavio: hmm, not sure how it could have worked then...
Aug 05 15:08:40 <otavio> bluelightning: only if I did a fix locally and forgot to push it
Aug 05 15:08:45 <otavio> bluelightning: possible
Aug 05 15:09:14 <JaMa> I know that libpostproc builds with libav_0.8 (and then do_package fails because of new check which detects 2 recipes building the same package)
Aug 05 15:09:40 <bluelightning> sure, because with 0.8 libav doesn't depend on libpostproc
Aug 05 15:10:00 <bluelightning> argh gst-ffmpeg bbappend adds orc as well
Aug 05 15:10:42 <JaMa> cannot be orc dependency converted to PACKAGECONFIG?
Aug 05 15:10:57 <bluelightning> possibly, looking into it
Aug 05 15:11:05 <JaMa> well to keep things as they are you would need to add new .bbappend which sets PACKAGECONFIG for meta-oe :)
Aug 05 15:11:13 <bluelightning> yes and that is not acceptable
Aug 05 15:11:18 <bluelightning> or else I might as well just give up
Aug 05 15:11:50 <JaMa> true
Aug 05 15:12:09 <JaMa> I'm OK with warning to DISTRO maintainers to add PACKAGECONFIG value in their .bbappend
Aug 05 15:12:24 <otavio> bluelightning: what is your goal?
Aug 05 15:12:38 <bluelightning> otavio: get rid of all bbappends and overlayed recipes in meta-oe
Aug 05 15:12:45 <otavio> :-)
Aug 05 15:12:58 <JaMa> one disadvantage of this meta-oe -> distro-layer .bbappends moves is that .bbappend renames were resolved in one place
Aug 05 15:13:12 <otavio> sgw1: can you trigger a build of meta-fsl-arm? I did push evdev bbappend update
Aug 05 15:13:23 <JaMa> now every DISTRO maintainer will need to update it on his own when bumping oe-core revision with some updates
Aug 05 15:13:46 <bluelightning> JaMa: true, but it's one or the other; besides PACKAGECONFIG changes don't mandate the use of a bbappend if you'd prefer to avoid one
Aug 05 15:14:05 <kergoth> might be a good thing to make sure distro maintainers are paying attention :)
Aug 05 15:14:09 <otavio> bluelightning: yes, you could have it in distro itself
Aug 05 15:14:09 <JaMa> right
Aug 05 15:14:29 * JaMa just splitted meta-shr and meta-shr-distro :)
Aug 05 15:14:33 <bluelightning> I just want to kill this "meta-oe isn't safe to use" idea once and for all
Aug 05 15:14:33 <otavio> kergoth: can you take a look in the rfc I sent for u-boot-config?
Aug 05 15:14:48 <otavio> bluelightning: you too
Aug 05 15:14:56 <otavio> JaMa: and you too, too
Aug 05 15:14:58 <otavio> :)
Aug 05 15:14:59 <kergoth> sure
Aug 05 15:15:02 <bluelightning> otavio: do we really need another bbclass just for this?
Aug 05 15:15:33 <otavio> bluelightning: no; In fact I was pondering about moving all u-boot.inc to a u-boot class
Aug 05 15:15:35 <JaMa> bluelightning: it looks like some people changed their view from "meta-oe isn't safe to use" to "meta-oe is too big for us to use, lets move bits we need to oe-core"
Aug 05 15:15:58 <otavio> JaMa: agreed; this indeed happened
Aug 05 15:16:01 <bluelightning> JaMa: well, that's not my line of thinking
Aug 05 15:16:05 <otavio> bluelightning: I can add it to u-boot.inc
Aug 05 15:16:16 <otavio> bluelightning: but I am more concerned about the concept itself
Aug 05 15:16:27 <bluelightning> JaMa: there will always be folks that think it's too large, can't do a lot about that other than make splits where it makes sense
Aug 05 15:16:59 <otavio> bluelightning: I think people don't see sublayers inside meta-oe as split.
Aug 05 15:17:32 <otavio> bluelightning: I agree it is better to have it in a single place but meta-networking brings up a valid point about size.
Aug 05 15:18:27 <otavio> bluelightning: one possibility would be to have auto-generated sublayers in separated repositories; so people can choose what to take
Aug 05 15:18:50 <bluelightning> otavio: I don't have a strong preference over inside or outside the meta-openembedded repo; Joe has chosen to provide a broken-out version for meta-networking, I don't think there's anything wrong with that
Aug 05 15:19:27 <otavio> bluelightning: me neither; but might be good to have it in a global / general way. So we avoid in-house solutions for it
Aug 05 15:20:13 <bluelightning> depends how much demand there is for separate repo versions of meta-openembedded
Aug 05 15:20:51 <JaMa> gtg will reply in 4 hours or so
Aug 05 15:21:52 <otavio> bluelightning: I think providing a splited version, if done automatically, it does not hurt and make all people happy. The point is it avoids in-house solutions and put all those in a single place for people to look at.
Aug 05 15:22:40 <otavio> bluelightning: most of my projects, for example, just use meta-oe. Just few use other layers.
Aug 05 15:26:45 <bluelightning> JaMa: I'm tempted to add a PACKAGECONFIG for orc but disable it by default; reason being, the rest of gstreamer in OE-Core handles orc that way
Aug 05 15:27:00 <sgw1> otavio: OK, will do, I will also be mesa bump soon as well
Aug 05 15:32:41 <otavio> sgw1: tell me when it is merged; so I bump it
Aug 05 15:32:44 <sgw1> otavio: fsl-arm triggered.
Aug 05 15:32:50 <otavio> sgw1: thx
Aug 05 18:09:02 <sgw1> otavio: do you have a master-next or mut equivlant for fsl-arm (I don't think you touch fsl-ppc)
Aug 05 18:46:55 <mr_science> moin
Aug 05 20:32:59 <otavio> sgw1: yes
Aug 05 20:33:07 <otavio> sgw1: we do; master-next
Aug 05 20:33:16 <otavio> sgw1: want me to push something?
Aug 05 20:33:55 <sgw1> otavio: mesa update to 9.1.6
Aug 05 20:34:20 <otavio> sgw1: ok; let me do it
Aug 05 20:34:26 <otavio> sgw1: I ping you in 5min
Aug 05 20:36:09 <otavio> sgw1: done.
Aug 05 20:36:16 <otavio> sgw1: ok, 2m ;)
Aug 05 20:39:07 <sgw1> Ok, thanks, I will start a build this afternoon.
Aug 05 21:34:44 <b1gtuna> Good day everybody! When I inherit a class, how can I exclude certain packages/recipes?
Aug 05 21:36:26 <bluelightning> b1gtuna: not quite understanding the question... can you be more specific?
Aug 05 21:39:00 <b1gtuna> Hello bluelightning :) It looks like packagegroup-core has ifconfig, ifupdown included. They conflict with Gnome's NetworkManager package. I'm trying to exclude the command line tools
Aug 05 21:41:47 <bluelightning> b1gtuna: they shouldn't conflict, it sounds like some alternatives config is missing from the networkmanager recipes
Aug 05 21:43:36 <mr_science> also, network-manager is a bit piggy for an embedded env
Aug 05 21:43:44 <b1gtuna> bluelightning: does networkmanager manage the interfaces listed in network/interfaces file? With no extra configuration?
Aug 05 21:43:50 <mr_science> just make sure you're okay with that...
Aug 05 21:44:05 <b1gtuna> mr_science: i have a console image, and now i'm working on an xfce image
Aug 05 21:44:09 <bluelightning> b1gtuna: I'm not sure
Aug 05 21:44:40 <mr_science> b1gtuna: network manager should ignore configured interfaces (in the interfaces file)
Aug 05 21:44:54 <bluelightning> b1gtuna: I don't have any direct experience building networkmanager within OE although I've always meant to try it
Aug 05 21:45:25 <mr_science> so if you have a static/dhcp config for eth0 say, then nm should only care about other interfaces
Aug 05 21:45:45 <b1gtuna> bluelightning: more specifically, ifconfig cannot start an interface using wpa-supplicant, because networkmanager is always locking(?) wpa-supplicant
Aug 05 21:45:49 <mr_science> if you nm to manage your wired interface, then comment out the interfaces config
Aug 05 21:46:54 <mr_science> ifconfig and wpa-supplicant still need wpa-passhrase foo > wpa-supplicant.conf in order to actually work
Aug 05 21:47:22 <b1gtuna> mr_science: i think my problem has more to do with wpa_supplicant. Any devices that use wpa_supplicant (throgh config file in /etc/wpa_supplicant) gets all screwy everytime I configure another interface with wpa-suplicant using  NM
Aug 05 21:47:31 <mr_science> and here's what i would recommend for wireless
Aug 05 21:47:53 <b1gtuna> what do you mean wpa-passphrase foo > wpa-supplicant.conf?
Aug 05 21:48:18 <mr_science> i mean to use "ifup wlan0" with no NM or other management tools
Aug 05 21:48:44 <mr_science> firs you need to set your wpa-passphrase in the config file
Aug 05 21:48:49 <mr_science> *first even
Aug 05 21:49:16 <b1gtuna> mr_science: even on a graphical environment?
Aug 05 21:49:26 <mr_science> so that's really the rub, it think, ie, you don't want to mix NM and manual on the same type of interface
Aug 05 21:49:35 <b1gtuna> b1gtuna: i thought providing a GUI tool to manage networks would be cool to demo
Aug 05 21:49:47 <b1gtuna> mr_science: ya.. that's what my problem is really
Aug 05 21:50:16 <b1gtuna> mr_science: i don't mind not having manual/cli-tools on my XFCE image
Aug 05 21:50:25 <mr_science> you can either a) ifup wlan0 with no management tools, or b) use NM or wicd or connman
Aug 05 21:51:35 <b1gtuna> mr_science: i think i'm trying to achieve b
Aug 05 21:52:01 <b1gtuna> mr_science: firstly i should comment out the interfaces i want NM to manage right?
Aug 05 21:52:07 <mr_science> the leave the static configs alone and don't try to manually manipulate wifi
Aug 05 21:52:13 <mr_science> *then
Aug 05 21:52:21 <mr_science> b1gtuna: correct
Aug 05 21:52:37 <b1gtuna> mr_science: coolio, anything else you can think of? or would that be enough?
Aug 05 21:52:46 <mr_science> NM is probably the most consistent at leaving alone a statically configured interface
Aug 05 21:53:03 <mr_science> b1gtuna: that should do it
Aug 05 21:53:35 <mr_science> you can always kill nm and then do manual stuff
Aug 05 21:53:42 <b1gtuna> mr_science: wonerful
Aug 05 21:54:20 <b1gtuna> mr_science: thank you :)
Aug 05 22:06:14 <mr_science> b1gtuna: np
Aug 05 22:07:41 <mr_science> i hit that same question for my rpi openbox build and the answer i came up with was to document the manual config and resurrect wifi-radar as a wireless config gui
Aug 05 22:08:31 <mr_science> since the other three management options are either bloaty, squirrelly, or both
Aug 05 22:10:05 <b1gtuna> mr_science: so wifi-radar in replacement of NM?
Aug 05 22:12:33 <mr_science> not really, it's an older more lightweight solution
Aug 05 22:13:25 <mr_science> it don't think it handles creating the passphrase, just maintaining basic wireless profiles and switching between them
Aug 05 23:03:17 <khem> sgw1: jinja should be ok now.
Aug 05 23:03:31 <khem> sgw1: if its not behaving
Aug 05 23:07:39 <sgw1> khem: I will try again later this week, I already have my MUT request pending on the AB, I will try it local again.
Aug 05 23:08:13 <sgw1> khem any news on the ppc floor() issue and qemu, I updated the bug report with the qemu commit that caused it, but athat's as far as I can take it.
Aug 05 23:08:42 <sgw1> khem bug #4854
Aug 05 23:08:42 <yocti> Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=4854 normal, Medium+, 1.5, raj.khem, NEW , floor call (from math.h) is broken on qemuppc
Aug 05 23:21:08 <khem> sgw1: It seems to me that kernel needs a patch
Aug 05 23:21:28 <khem> sgw1: if you could try with linux-yocto-dev that will make it clear
Aug 05 23:21:43 <khem> sgw1: if it works with linux-yocto-dev which is 3.10.x
Aug 05 23:22:09 <khem> then probably, I know the kernel patches that needs backporting
Aug 05 23:22:24 <sgw1> khem: sure, I have the setup to try, I will put my results in the bug, will you or zeddii beable to figure out what needs backporting?
Aug 05 23:22:33 <khem> sgw1: yes
Aug 05 23:22:35 <sgw1> Ok< will keep you posted, thanks.
Aug 05 23:22:43 <khem> I think I have a hunch on few patches
Aug 05 23:23:17 <khem> if it fails same way then next thing I will recommend is to align the tune for qemuppc to be ppc7xxx
Aug 05 23:23:23 <khem> instead of ppc603
Aug 05 23:23:41 <sgw1> khem, I hope you can provide that patch if it's needed
Aug 05 23:23:59 <khem> since this works OK on real machine I have ruled out eglibc to be buggy
Aug 05 23:24:08 <khem> sgw1: yes I will
Aug 05 23:24:21 <khem> this works fine on p2020
Aug 05 23:24:30 <khem> which excercises same floor() code
Aug 05 23:24:39 <seebs> I would be a little nervous about a change of qemuppc, just because our prebuilt-binary multilib selection is based in part on working with qemuppc...
Aug 05 23:24:40 <khem> thats being excercised on qemuppc
Aug 05 23:25:15 <khem> seebs: we have is wrong anyway
Aug 05 23:25:31 <seebs> Whee.
Aug 05 23:25:56 <khem> other option is to change qemuppc to emulate 603e core
Aug 05 23:25:59 <khem> and not mac99
Aug 05 23:26:26 <khem> but we made the change from 603e to mac99 last year IIRC
Aug 05 23:26:35 <khem> and I believe there must be a reason
Aug 05 23:26:59 <khem> we changed the qemu machine emulation but did not change the default tune
Aug 05 23:27:10 <khem> which is not very right
Aug 05 23:28:03 <khem> now we have new LTS/LTSI
Aug 05 23:28:23 <khem> http://www.kroah.com/log/blog/2013/08/04/longterm-kernel-3-dot-10/
Aug 06 01:28:07 <Net147> sgw1: any objections to the qt4 patch?
Aug 06 01:47:15 <Net147> sgw1: oh I see it's in MUT now
**** ENDING LOGGING AT Tue Aug 06 02:59:58 2013