**** BEGIN LOGGING AT Mon Aug 05 02:59:58 2013 Aug 05 07:23:54 Heading to Hong Kong, Anyone know where to pickup a NUC? Aug 05 07:50:07 rburton: have you seen my TOPDIR question? Aug 05 07:51:09 considering i've been on IRC for a good ten seconds, no. :) Aug 05 07:51:18 rburton: it was on Friday. Aug 05 07:51:34 i don't recall seeing it before I left on Friday. Aug 05 07:51:45 rburton: is there a variable dedicated to PROJDIR? Aug 05 07:51:55 rburton: currently, I am using TOPDIR/.. inside the bblayers Aug 05 07:52:02 but it is fragile. Aug 05 07:53:21 something like projdir, or rootdir would be nice Aug 05 07:53:37 we could write ${rootdir}/meta-yocto ... etc then. Aug 05 07:53:53 and it would work for every developer, and even for the CI. Aug 05 07:54:48 and oe-init-build-env knows the rootdir, as it is inside. Aug 05 07:55:51 there's COREROOT or something if you want the location of oe-core, iirc Aug 05 07:56:05 morning all Aug 05 07:56:06 but then I would still need the parent. Aug 05 07:56:48 I need a variable for the container folder of the layers. Aug 05 07:57:15 well, for the rootdir, to be precise, but it is the same 99% Aug 05 07:58:27 that would allow a nice bblayers.conf structure. Aug 05 08:07:12 lpapp: that directory might be in multiple places, you don't have to have all layers in one directory Aug 05 08:09:40 RP: nope Aug 05 08:09:54 it is not related to layers, it is the rootdir or projectdir as its name would say. Aug 05 08:10:25 and yes, most people have the layers in that folder. Aug 05 08:10:52 or semi-relatively to that. Aug 05 08:11:13 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 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 now, this latter is in the RRECOMMENDS of xinput-calibrator Aug 05 08:29:33 ant_work: it'll be elsewhere too via XSERVER surely...? Aug 05 08:29:36 I see there isn't any pointercal-xinput package (it is skipped 'cause empty I guess) Aug 05 08:29:55 ant_work: right, so you shouldn't add it to XSERVER I guess Aug 05 08:30:35 I've added one .bbappend with a bogus pointercal in my layer but no differences.. Aug 05 08:30:50 I had to remove pointercal-xinput from my XSERVER var Aug 05 08:31:06 right, I don't think you need it there anyway Aug 05 08:31:50 the idea was about provifing custom per-machine calibration Aug 05 08:32:02 hm Aug 05 08:32:08 pre-calibration Aug 05 08:32:33 that should be a recommends then as it *can* be empty on machines without a pre-calibration Aug 05 08:33:28 ok but why did it fail with provided not-empty cal. file? Aug 05 08:33:54 hm Aug 05 08:34:06 it was too late to check, I'll do today Aug 05 08:35:03 rburton: in meta-oe xinput-calibrator was one rdeps of xserver-nodm-init Aug 05 08:35:46 but that can't work for non-touchscreen devices Aug 05 08:39:40 https://bugzilla.yoctoproject.org/show_bug.cgi?id=4980 Aug 05 08:39:41 Bug 4980: normal, Undecided, ---, richard.purdie, NEW , Variable for the root/project dir Aug 05 08:46:52 JaMa: ask nicely and i'll push dates patches upstream Aug 05 08:47:37 bluelightning: need surely some kind of conditional Aug 05 08:51:24 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 rburton: the same commit message as eds applies to dates :/ Aug 05 08:52:29 rburton: lets wait for someone to at least test them in runtime, but thanks :) Aug 05 08:52:38 heh Aug 05 08:52:41 * rburton reads Aug 05 08:53:35 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 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 rburton: I've noticed it :) it was also reported in my "state of bitbake world" emails Aug 05 08:54:30 JaMa: well, nobody else Aug 05 08:54:33 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 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 rburton: in core, we would have noticed failures sooner Aug 05 08:59:23 JaMa: do shr users really use dates/contacts still? Aug 05 09:00:21 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 rburton: someone asked for it to be in feed, but I didn't get any feedback since then Aug 05 09:01:32 to be returned to feed, to be precise so he was probably using it before Aug 05 09:18:45 a long vacation is nice. then mailbox when you get back, not so much. Aug 05 09:19:17 Zagor: select all, mark as read. Aug 05 09:19:51 yeah I do it for the most part. Aug 05 09:20:34 Zagor: i feel honoured to get a reply from you then ;) Aug 05 09:21:08 heh :) Aug 05 10:10:34 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 JaMa: thinking a tool to run buildhistory-diff after every commit in a branch might be useful Aug 05 10:12:55 rburton: FWIW, combo-layer does that... not particularly sophisticated Aug 05 10:13:42 a git iterate would be so useful Aug 05 10:13:55 checkout every commit, run this script Aug 05 10:14:48 rburton: google it, it's been done already ;) Aug 05 10:14:59 ha Aug 05 10:16:47 I would write one for loop for that Aug 05 10:18:06 rburton: like history rewriting? Aug 05 10:18:27 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 JaMa: i bet you can drop the cut Aug 05 10:19:46 rburton: true, git rev-list $START..$STOP would be better Aug 05 10:20:04 ah, i was thinking of using the pretty controls Aug 05 10:20:06 forgot about that one Aug 05 10:20:45 and I like the idea of running buildhistory-diff, especially for "upgrade" commits Aug 05 10:20:52 exactly Aug 05 10:21:58 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 JaMa: should be. partly to blame for not checking that myself. Aug 05 10:22:34 thats why i want to automate it Aug 05 10:30:01 we really ought to have buildhistory-web set up on the autobuilder... there is a bug filed for it Aug 05 10:31:53 yeah Aug 05 10:32:01 then we could browse the history from MUT Aug 05 10:38:14 hm you can't amend in an iterate, as the hashes change. that's a shame. Aug 05 10:54:49 JaMa: wrt test-dependencies-2013-07-24, iirc you didn't use meta-initramfs, isn't? Aug 05 10:55:25 JaMa: I guess that's why all -klibc recipes failed Aug 05 11:06:16 ant_work: same config as every world build I do, so meta-initramfs was included Aug 05 11:07:20 ant_work: + all -klibc recipes are in meta-initramfs, aren't they? Aug 05 11:08:16 yea, silly question Aug 05 11:08:40 though, I know the recipes do build ;) Aug 05 11:10:24 I don't fully understand why are listed as failed Aug 05 11:13:05 they were failing quite often in reqular builds so I'm not surprised they failed Aug 05 11:19:03 hm.. again fatal error: linux/limits.h: No such file or directory Aug 05 11:22:24 with yocto, there are no limits Aug 05 11:22:33 boom tish, thankyou everyone, i'll be here all week Aug 05 11:50:26 seems linux-libc-headers were missing Aug 05 12:05:53 hm.. are not in DEFAULT_DEPS Aug 05 12:10:02 JaMa: I'm perplexed because all -klibc recipes do depend on klibc so indirectly on linux-libc-headers Aug 05 12:11:19 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 hm even if the klcc crosscompiler depends on linux-libc-headers to be built? Aug 05 12:13:22 sounds strange Aug 05 12:15:19 try bitbake -e and bitbake -g to be sure Aug 05 12:16:11 will do Aug 05 12:19:24 * bluelightning is looking at bringing over libav into OE-Core Aug 05 12:19:34 these recipes are a bit of a mess :/ Aug 05 12:19:42 they produce bunch of QA warnings as well Aug 05 12:20:40 see about the possible configuration Aug 05 12:20:42 http://wiki.gentoo.org/wiki/Libav Aug 05 12:21:56 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 bluelightning: please move only newer one if possible Aug 05 12:22:21 JaMa: newer one? Aug 05 12:22:39 bluelightning: git version depends on separate libpostproc and older release recipe is conflicting with separate libpostproc Aug 05 12:23:05 JaMa: so should we move to a newer release version then? Aug 05 12:23:15 the release version is quite old by now Aug 05 12:23:35 bluelightning: newer release if possible or move only _git.bb Aug 05 12:23:56 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 hmm seems libvpx may not be needed, configure log indicates it isn't enabled Aug 05 12:31:14 I can add a PACKAGECONFIG for it though Aug 05 12:37:45 bluelightning: th elist would be long... Aug 05 12:38:03 ant_work: I'm only adding a few for the moment :) Aug 05 12:38:19 you've pick up a nasty one this time ;) Aug 05 12:38:46 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 seems libav expects finer config in bsp layer Aug 05 12:44:53 hmm looks like the _git recipe is v9.1+ Aug 05 12:45:15 or at least, the revision pointed to by SRCREV only appears there Aug 05 12:54:09 JaMa: seems like v9 is an API break and the separation of libpostproc was something done upstream Aug 05 12:54:21 so I'm not sure what we should be doing here... Aug 05 12:54:46 if nobody needs 0.8.x then we can drop it, but are we sure this is the case? Aug 05 12:56:43 JaMa: have you been doing world builds with the current libav_git recipe? Aug 05 13:02:41 bluelightning: with default version which is IIRC the release Aug 05 13:02:52 but had to blacklist libpostproc to prevent failures Aug 05 13:06:14 hmm Aug 05 13:06:22 well that suggests that we should be keeping 0.8.x Aug 05 13:07:01 angstrom is using the 0.8.x recipe as well it seems Aug 05 13:10:04 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 oh wait Aug 05 13:10:22 reading comprehension fail Aug 05 13:13:17 actually, it still shouldn't need to Aug 05 14:10:24 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 otavio_: do you remember testing libav_git recipe? ^^^ Aug 05 14:50:51 sgw1, You around? Aug 05 14:52:32 halstead: OTP Aug 05 15:05:07 JaMa: yes I did but looong time ago Aug 05 15:06:02 JaMa: bluelightning: I tested it when working in xbmc patches Aug 05 15:06:12 JaMa: but didn't work on it for a while now Aug 05 15:06:35 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 JaMa: but I did test it Aug 05 15:06:59 JaMa: I am not how/when Aug 05 15:08:04 otavio: hmm, not sure how it could have worked then... Aug 05 15:08:40 bluelightning: only if I did a fix locally and forgot to push it Aug 05 15:08:45 bluelightning: possible Aug 05 15:09:14 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 sure, because with 0.8 libav doesn't depend on libpostproc Aug 05 15:10:00 argh gst-ffmpeg bbappend adds orc as well Aug 05 15:10:42 cannot be orc dependency converted to PACKAGECONFIG? Aug 05 15:10:57 possibly, looking into it Aug 05 15:11:05 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 yes and that is not acceptable Aug 05 15:11:18 or else I might as well just give up Aug 05 15:11:50 true Aug 05 15:12:09 I'm OK with warning to DISTRO maintainers to add PACKAGECONFIG value in their .bbappend Aug 05 15:12:24 bluelightning: what is your goal? Aug 05 15:12:38 otavio: get rid of all bbappends and overlayed recipes in meta-oe Aug 05 15:12:45 :-) Aug 05 15:12:58 one disadvantage of this meta-oe -> distro-layer .bbappends moves is that .bbappend renames were resolved in one place Aug 05 15:13:12 sgw1: can you trigger a build of meta-fsl-arm? I did push evdev bbappend update Aug 05 15:13:23 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 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 might be a good thing to make sure distro maintainers are paying attention :) Aug 05 15:14:09 bluelightning: yes, you could have it in distro itself Aug 05 15:14:09 right Aug 05 15:14:29 * JaMa just splitted meta-shr and meta-shr-distro :) Aug 05 15:14:33 I just want to kill this "meta-oe isn't safe to use" idea once and for all Aug 05 15:14:33 kergoth: can you take a look in the rfc I sent for u-boot-config? Aug 05 15:14:48 bluelightning: you too Aug 05 15:14:56 JaMa: and you too, too Aug 05 15:14:58 :) Aug 05 15:14:59 sure Aug 05 15:15:02 otavio: do we really need another bbclass just for this? Aug 05 15:15:33 bluelightning: no; In fact I was pondering about moving all u-boot.inc to a u-boot class Aug 05 15:15:35 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 JaMa: agreed; this indeed happened Aug 05 15:16:01 JaMa: well, that's not my line of thinking Aug 05 15:16:05 bluelightning: I can add it to u-boot.inc Aug 05 15:16:16 bluelightning: but I am more concerned about the concept itself Aug 05 15:16:27 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 bluelightning: I think people don't see sublayers inside meta-oe as split. Aug 05 15:17:32 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 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 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 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 depends how much demand there is for separate repo versions of meta-openembedded Aug 05 15:20:51 gtg will reply in 4 hours or so Aug 05 15:21:52 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 bluelightning: most of my projects, for example, just use meta-oe. Just few use other layers. Aug 05 15:26:45 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 otavio: OK, will do, I will also be mesa bump soon as well Aug 05 15:32:41 sgw1: tell me when it is merged; so I bump it Aug 05 15:32:44 otavio: fsl-arm triggered. Aug 05 15:32:50 sgw1: thx Aug 05 18:09:02 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 moin Aug 05 20:32:59 sgw1: yes Aug 05 20:33:07 sgw1: we do; master-next Aug 05 20:33:16 sgw1: want me to push something? Aug 05 20:33:55 otavio: mesa update to 9.1.6 Aug 05 20:34:20 sgw1: ok; let me do it Aug 05 20:34:26 sgw1: I ping you in 5min Aug 05 20:36:09 sgw1: done. Aug 05 20:36:16 sgw1: ok, 2m ;) Aug 05 20:39:07 Ok, thanks, I will start a build this afternoon. Aug 05 21:34:44 Good day everybody! When I inherit a class, how can I exclude certain packages/recipes? Aug 05 21:36:26 b1gtuna: not quite understanding the question... can you be more specific? Aug 05 21:39:00 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 b1gtuna: they shouldn't conflict, it sounds like some alternatives config is missing from the networkmanager recipes Aug 05 21:43:36 also, network-manager is a bit piggy for an embedded env Aug 05 21:43:44 bluelightning: does networkmanager manage the interfaces listed in network/interfaces file? With no extra configuration? Aug 05 21:43:50 just make sure you're okay with that... Aug 05 21:44:05 mr_science: i have a console image, and now i'm working on an xfce image Aug 05 21:44:09 b1gtuna: I'm not sure Aug 05 21:44:40 b1gtuna: network manager should ignore configured interfaces (in the interfaces file) Aug 05 21:44:54 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 so if you have a static/dhcp config for eth0 say, then nm should only care about other interfaces Aug 05 21:45:45 bluelightning: more specifically, ifconfig cannot start an interface using wpa-supplicant, because networkmanager is always locking(?) wpa-supplicant Aug 05 21:45:49 if you nm to manage your wired interface, then comment out the interfaces config Aug 05 21:46:54 ifconfig and wpa-supplicant still need wpa-passhrase foo > wpa-supplicant.conf in order to actually work Aug 05 21:47:22 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 and here's what i would recommend for wireless Aug 05 21:47:53 what do you mean wpa-passphrase foo > wpa-supplicant.conf? Aug 05 21:48:18 i mean to use "ifup wlan0" with no NM or other management tools Aug 05 21:48:44 firs you need to set your wpa-passphrase in the config file Aug 05 21:48:49 *first even Aug 05 21:49:16 mr_science: even on a graphical environment? Aug 05 21:49:26 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: i thought providing a GUI tool to manage networks would be cool to demo Aug 05 21:49:47 mr_science: ya.. that's what my problem is really Aug 05 21:50:16 mr_science: i don't mind not having manual/cli-tools on my XFCE image Aug 05 21:50:25 you can either a) ifup wlan0 with no management tools, or b) use NM or wicd or connman Aug 05 21:51:35 mr_science: i think i'm trying to achieve b Aug 05 21:52:01 mr_science: firstly i should comment out the interfaces i want NM to manage right? Aug 05 21:52:07 the leave the static configs alone and don't try to manually manipulate wifi Aug 05 21:52:13 *then Aug 05 21:52:21 b1gtuna: correct Aug 05 21:52:37 mr_science: coolio, anything else you can think of? or would that be enough? Aug 05 21:52:46 NM is probably the most consistent at leaving alone a statically configured interface Aug 05 21:53:03 b1gtuna: that should do it Aug 05 21:53:35 you can always kill nm and then do manual stuff Aug 05 21:53:42 mr_science: wonerful Aug 05 21:54:20 mr_science: thank you :) Aug 05 22:06:14 b1gtuna: np Aug 05 22:07:41 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 since the other three management options are either bloaty, squirrelly, or both Aug 05 22:10:05 mr_science: so wifi-radar in replacement of NM? Aug 05 22:12:33 not really, it's an older more lightweight solution Aug 05 22:13:25 it don't think it handles creating the passphrase, just maintaining basic wireless profiles and switching between them Aug 05 23:03:17 sgw1: jinja should be ok now. Aug 05 23:03:31 sgw1: if its not behaving Aug 05 23:07:39 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 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 khem bug #4854 Aug 05 23:08:42 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 sgw1: It seems to me that kernel needs a patch Aug 05 23:21:28 sgw1: if you could try with linux-yocto-dev that will make it clear Aug 05 23:21:43 sgw1: if it works with linux-yocto-dev which is 3.10.x Aug 05 23:22:09 then probably, I know the kernel patches that needs backporting Aug 05 23:22:24 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 sgw1: yes Aug 05 23:22:35 Ok< will keep you posted, thanks. Aug 05 23:22:43 I think I have a hunch on few patches Aug 05 23:23:17 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 instead of ppc603 Aug 05 23:23:41 khem, I hope you can provide that patch if it's needed Aug 05 23:23:59 since this works OK on real machine I have ruled out eglibc to be buggy Aug 05 23:24:08 sgw1: yes I will Aug 05 23:24:21 this works fine on p2020 Aug 05 23:24:30 which excercises same floor() code Aug 05 23:24:39 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 thats being excercised on qemuppc Aug 05 23:25:15 seebs: we have is wrong anyway Aug 05 23:25:31 Whee. Aug 05 23:25:56 other option is to change qemuppc to emulate 603e core Aug 05 23:25:59 and not mac99 Aug 05 23:26:26 but we made the change from 603e to mac99 last year IIRC Aug 05 23:26:35 and I believe there must be a reason Aug 05 23:26:59 we changed the qemu machine emulation but did not change the default tune Aug 05 23:27:10 which is not very right Aug 05 23:28:03 now we have new LTS/LTSI Aug 05 23:28:23 http://www.kroah.com/log/blog/2013/08/04/longterm-kernel-3-dot-10/ Aug 06 01:28:07 sgw1: any objections to the qt4 patch? Aug 06 01:47:15 sgw1: oh I see it's in MUT now **** ENDING LOGGING AT Tue Aug 06 02:59:58 2013