**** BEGIN LOGGING AT Thu Jan 08 02:59:59 2015 Jan 08 08:25:34 good morning Jan 08 08:36:10 mckoan hi Jan 08 09:11:39 hrm Jan 08 09:11:40 WARNING: QA Issue: php requires /build/linaro/build/build/tmp-glibc/work/aarch64-oe-linux/php/5.4.33-r0/image/usr/bin/php, but no providers in its RDEPENDS [file-rdeps] Jan 08 09:11:43 * koen stabs php Jan 08 09:42:44 morning all Jan 08 09:54:09 hi bluelightning, all Jan 08 09:54:15 hi mckoan Jan 08 09:55:51 hey Jan 08 10:03:06 hi mago_ Jan 08 10:37:49 koen: already reported and bluelightning is working on it Jan 08 10:49:40 JaMa: I hoped that was the case :) Jan 08 10:51:41 what am I working on ? Jan 08 10:52:29 php Jan 08 10:53:40 oh right... yeah, I sent a new series yesterday Jan 08 10:53:53 10:11 < koen> WARNING: QA Issue: php requires /build/linaro/build/build/tmp-glibc/work/aarch64-oe-linux/php/5.4.33-r0/image/usr/bin/php, but no providers in its RDEPENDS [file-rdeps] Jan 08 10:54:05 ah, didn't you say later that it's not enough and still working on it? Jan 08 10:54:39 that was before v4, in v4 that is fixed Jan 08 10:55:42 interesting, I hadn't checked if that was an issue before all my upgrades... glad i didn't cause it :) Jan 08 10:55:49 it was the only non-linaro QA issue reported on todays build :) Jan 08 10:56:16 ah ok, will refresh in master-next Jan 08 10:57:02 you'll want the whole series btw, don't be tempted to grab individual patches Jan 08 10:57:29 well, what I mean is mix in with previous ones Jan 08 11:01:56 I'll trust you and merge whole series without waiting for another jenkins build Jan 08 11:02:07 the master-next diff after refresing it looks good to me Jan 08 11:02:09 thanks Jan 08 11:02:45 JaMa: thanks, and naturally I will investigate if any other issues come up - they shouldn't however ;) Jan 08 11:02:59 it's php Jan 08 11:03:09 having issues in inherent to the package Jan 08 11:03:21 koen: right, by design :) Jan 08 11:04:44 * koen isn't looking forward to unbreaking hiphopvm Jan 08 11:05:32 the issues I found after that last QA check made me wonder if we need a couple more QA checks - symlinks pointing into TMPDIR, and broken shebangs doing the same Jan 08 11:06:37 ah, those won't be dangling Jan 08 11:06:39 hmm Jan 08 11:06:41 good idea Jan 08 11:07:44 I'll file a bug Jan 08 11:09:11 bluelightning: while working on (lib)gphoto I noticed some other areas that were lacking Jan 08 11:09:21 e.g. udev hwdb update class Jan 08 11:09:46 and permission/group management for users Jan 08 11:10:40 not sure about the former, but for perms I thought we had that pretty well covered already ? Jan 08 11:11:09 the gphoto udev rules now want a seperate group Jan 08 11:11:26 how do we make sure the group 'camera' exists and all real users are in it? Jan 08 11:11:40 my complete ignorance of sysadmin stuff is showing here :) Jan 08 11:13:13 addgroup camera || true Jan 08 11:13:22 usermod -G camera Jan 08 11:14:11 XorA: right, but that assumes you know about and his friends Jan 08 11:14:13 usermod -a -G camera that is Jan 08 11:14:38 thats roots job, or a policy on adduser that adds all new users to some groups Jan 08 11:14:41 maybe I should check existing groups, like 'usb' or 'multimedia' Jan 08 11:15:02 I think in OE we just don't have policy based user management Jan 08 11:15:15 <- ignorant Jan 08 11:15:34 pretty sure in debian there is a post trigger on install to do this sort of thing Jan 08 11:15:37 * koen is tempted to take another 2 weeks vacation to finish the gphoto stuff Jan 08 11:17:12 speaking of interesting QA issues, I modiefied one of our in house recipies and the .ipk files got placed in a different folder inside the deploy folder. Jan 08 11:17:17 that meant that there were 2 sets Jan 08 11:17:35 and the image build process kept on picking up the old IPKs Jan 08 11:17:44 wondered if a check could be built for that Jan 08 11:17:49 pompomJuice: did you change PACKAGE_ARCH perhaps? Jan 08 11:17:53 yes that was it Jan 08 11:18:08 it changed Jan 08 11:18:09 right, that is a generally known problem which is not straightforward to fix unfortunately Jan 08 11:18:14 aah ok Jan 08 11:18:22 it got me scratching my head for a while Jan 08 11:18:31 the tricky bit is knowing whether the change is expected or needs to be cleaned up Jan 08 11:19:15 the entire process is kinda magical though so I am sure a way could be found :D Jan 08 11:19:39 FWIW, there is a bug open tracking the general problem https://bugzilla.yoctoproject.org/show_bug.cgi?id=4102 Jan 08 11:21:55 terrible bug really since it is not immediately apparent that something broke, only later on when the 2 versions deviate enough. Jan 08 11:22:00 or issue. Jan 08 11:25:59 it's certainly an issue we want to fix, the question is how to fix it without causing additional problems Jan 08 11:40:03 i tried to buid OE on an tk1 board but autoconf-native failed. error: armv7l-linux not recognized. Jan 08 11:40:39 to get bitbake run i added armv7l architecture to siteinfo.bbclass... Jan 08 12:07:20 how does bitbake create the run.do_configure script ? Jan 08 12:10:22 pwgen: it's part of executing the do_configure task; so it'll be composed in the normal way (based on how do_configure is defined, either via classes that the recipe inherits or within the recipe) Jan 08 12:12:03 i can see in autotools.bbclass are the configure options assembeld. but it seems BUILD_SYS is wron, its armv7l-linux and should armv7l-oe-linux-gnueabi . the Jan 08 12:12:43 question is now how is BULD_SYS defined ? Jan 08 12:44:45 ant_work: the zaurus stuff builds now, but hx4700 is still broken for daisy Jan 08 12:49:16 koen: hi. Yes, 3.17.x needs some adjustments (i.e. one collie patch upstreamed) Jan 08 12:50:17 prolly hx4700 has same issues. I'm testing 3.18 and 3.19 now...pxa will be dt soon ;) Jan 08 12:51:56 daisy is 3.14, right? Jan 08 12:52:23 linux-yocto/3.14.4+gitAUTOINC+183622e809_cb22733185-r0 Jan 08 12:52:27 oh.. Jan 08 12:52:46 3.14 is totally unmaintained ;) Jan 08 13:59:15 zaurus? Jan 08 14:08:44 Who here are linux font gurus? Jan 08 14:09:55 I recently had to add Java to my image, and then suddenly my mono apps started seeing more fonts. I used to have no fonts, now it has 3: Liberation (Sans, Mono, Serif) Jan 08 14:10:08 Where did they come from Jan 08 14:10:11 how can I add more? Jan 08 14:10:50 the only changes to my image.bb was -> Jan 08 14:10:53 JAVA_INSTALL = " \ Jan 08 14:10:53 openjdk-7-jre \ Jan 08 14:10:53 openjdk-7-vm-jamvm \ Jan 08 14:10:53 openjdk-7-vm-cacao \ Jan 08 14:10:53 strace \ Jan 08 14:10:54 binutils \ Jan 08 14:10:54 classpath \ Jan 08 14:10:55 classpath-common \ Jan 08 14:10:55 classpath-examples \ Jan 08 14:10:56 classpath-tools \ Jan 08 14:10:56 jamvm \ Jan 08 14:10:57 cacao \ Jan 08 14:10:57 " Jan 08 14:14:26 don't spam the channel, please Jan 08 14:14:34 anything longer than a few lines belongs in a pastebin Jan 08 14:14:52 aah yea soz Jan 08 14:15:06 pompomJuice: some of it rdepends on fonts then Jan 08 14:15:20 ok so there is a package named fonts? Jan 08 14:15:21 i can't help with the fonts but how'd you get java installed? I've tried adding openjdk-7/8 to local.conf but it's failing.... Jan 08 14:15:44 How does it fail? Jan 08 14:15:46 pompomJuice: probably quite a lot of them Jan 08 14:16:05 thanks hrw il grep quicly for that then inside opkg Jan 08 14:16:15 classpath, xerces-j and another i can't think of right now fail to compile Jan 08 14:16:41 what layer are you using? Jan 08 14:17:02 for java or the image? Jan 08 14:17:20 Because there has been some developments there, the new layer is located at yotco: meta-java,git://git.yoctoproject.org/meta-java,master,HEAD Jan 08 14:17:55 that one seems to work out of the box for me, where the one shipped with setup-scripts does not. Jan 08 14:18:02 images have been core-sato, i've been using the meta-java layer for openjdk-7 and linaro for openjdk-8 Jan 08 14:18:23 what machine are you using pompom? Jan 08 14:18:27 note the actual repository has changed for the layer Jan 08 14:18:58 armv7l Jan 08 14:19:33 i'll have to boot that vm to double check... when that change happen? Jan 08 14:20:31 woglinde notified me earlier today, it might be part of 1.7 already. 1.6 still needs to be updated Jan 08 14:21:20 i'm running off of yocto/master so I expect i'm on the right meta-java repo unless the openombedded layer directory is out of date Jan 08 14:21:56 what repo are you on exactly? can you check? Jan 08 14:22:12 vmware's being a bit slow to resume the vm... one sec Jan 08 14:22:53 I basically just followed the instructions in the README file @ git://git.yoctoproject.org/meta-java and it worked. Jan 08 14:23:29 there are some things that needs to be added to local.conf, and some to your image and it should just work. Jan 08 14:23:37 i'm totally going to check... just letting you know on that in case there's something else it's just as likely to be... Jan 08 14:23:44 np Jan 08 14:24:41 oooo.... looking at another copy of the repo i have, i may be on the wrong one... Jan 08 14:24:43 shiny Jan 08 14:25:14 the new repo has commits as recent as last week Jan 08 14:49:46 yup... wrong repo Jan 08 14:52:06 lets see if it works now... Jan 08 14:53:53 Aethenelle hm yes I think I will finally update my github repo this evening Jan 08 14:54:10 to let the readme say where the new repo is Jan 08 14:54:16 woglinde: thanks Jan 08 14:56:20 bah... still no mips64 support... next machine... Jan 08 14:56:34 woglinde: is that an upstream thing? Jan 08 14:56:53 is there anything i can do to help on your end? Jan 08 14:58:07 Aethenelle update to icedtead 2.5.3? Jan 08 14:58:45 really?!? i can probably bang out a patch for that... Jan 08 14:58:46 combine icedtea-native and openjdk to one recipe? Jan 08 14:58:58 that are longstanding tasks Jan 08 14:59:02 that might take a bit longer... Jan 08 14:59:14 i'll see what i can do Jan 08 15:00:05 sure there are some more people looking at the patches now, namely otavio Jan 08 15:00:15 so if my time is short again he will review them Jan 08 15:09:19 woglinde: similar requirements for openjdk8 support outside of aarch64? Jan 08 15:12:06 woglinde: i'm still getting preferred provider warnings on java2-runtime and java2-vm Jan 08 15:12:39 and the README is missing a " on line 74 Jan 08 15:39:46 woglinde: failure for qemuarm building jamvm-native https://gist.github.com/anonymous/d51e931b1c348fdc381a Jan 08 15:41:21 Aethenelle hm try with -c cleansstate Jan 08 15:41:47 pretty sure that's after cleansstate but i'll try again... Jan 08 15:44:04 running jamvm-initial Jan 08 15:45:41 segfault after initial installed... running -c cleanall and trying again Jan 08 15:49:21 cleaning sstate of classpath and jikes... trying again (i got warnings about missing do_populate_sysroot files Jan 08 15:55:44 cleaning sstate for all the warnings i got didn't clear the warnings but jamvm-native baked successfully Jan 08 15:59:27 without changine a config file is there a way to force bitbake to reparse everything? Jan 08 16:08:10 and/or a way to clean the build entirely without nuking tmp (I have other images i'm building as well) Jan 08 16:11:56 JaMa: in SRCREV_FORMAT what is entry for default SRC_URI if we do not have name=xxx defined in it Jan 08 16:13:04 I know its foo_bar when name=foo and name=bar for given two repos but what would it be if say foo does not define name= and we have name=bar for second repo Jan 08 16:22:22 looks like it's 'default', from looking over fetch2/__init__.py Jan 08 16:22:29 for any url which isn't explicitly named Jan 08 16:22:38 untested, though Jan 08 17:01:26 khem: I'm always using name= (with name=main as default) when using SRCREV_FORMAT, but maybe 'default' also works as kergoth said Jan 08 17:03:53 gah! i think this install is borked... gonna have to nuke everything... Jan 08 17:05:11 ok yes I got 'default' reported in errors so seems thats the fallback Jan 08 21:31:11 hi Jan 08 21:32:23 Do anyone know is it possible to access LCD timings(hsync etc) from userspace? i'm using am3352 cpu and da8xx_fb kernel module. Jan 09 02:01:32 does anyone know where the upstream for libaio is? i cant find much beyond debian patches, and a fedora hosted git Jan 09 02:09:18 any help here: http://layers.openembedded.org/layerindex/recipe/145/ Jan 09 02:09:50 that gets me to a sf page Jan 09 02:10:37 Crofton: Yer i got that page first in google searches, but it appears to have old information and lots of deadlinks Jan 09 02:12:31 Crofton: This looks the most upstream i can fine https://git.fedorahosted.org/cgit/libaio.git/ i might just send Jeff Moyer an email (he looks like he might be the maintainer) **** ENDING LOGGING AT Fri Jan 09 02:59:58 2015