**** BEGIN LOGGING AT Tue Oct 08 02:59:59 2013 Oct 08 05:48:10 morning. Oct 08 05:58:26 I have an issue with the SDK. gcc uses ld from the host machine, and that breaks when I deploy the SDK on an older distro. Oct 08 05:58:36 Sorry for repeating myself, but this time I'm gonna stay a while and hope to get this sorted out :) Oct 08 05:59:15 ldd output: http://pastebin.com/J2UW4Puv Oct 08 07:00:26 good morning Oct 08 07:33:43 hello Oct 08 07:33:54 I have one question about do_populate_sysroot stage Oct 08 07:35:14 One module which has only Makefile generate no output under sysroot-destdir Oct 08 07:36:48 This module has proper outputs under images and packages-split folder but nothing in sysroot-destdir Oct 08 07:47:21 hello, I have bitbaked the "qt4e-demo-image" and load the root file system via NFS. It boots ok and I can ping my beaglebone black but SSH connection is always refused :( Oct 08 07:47:50 Anguel: what is the message you get when trying to connect ? Oct 08 07:49:16 ericben: ON UBUNTU: ssh: connect to host 192.168.0.34 port 22: Connection refused ON WIN7 PUTTY: Network error: Connection refused Oct 08 07:49:33 Anguel: is there a ssh server running on the target ? Oct 08 07:50:56 hard to tell without logging in, I use the rootfs from the Angstrom-qt4e-demo-image-eglibc-ipk-v2012.12-beaglebone.rootfs.tar.xz under /deploy/ Oct 08 07:52:40 Anguel: IIRC that image doesn't have any ssh server Oct 08 07:52:51 Anguel: try adding IMAGE_FEATURES += "ssh-server-dropbear" Oct 08 07:53:31 Anguel: don't you have a serial console ? Oct 08 07:53:56 of course if you don't have a ssh server in image_features that won't work ;-) Oct 08 07:54:00 hi mckoan btw Oct 08 07:54:14 gm ericben, all Oct 08 07:55:12 mckoan: thank you, I'll try that. BTW, is it possible to simply "merge" images together? probably not Oct 08 07:55:54 Anguel: what do you mean by "merge" images together ? Oct 08 07:56:35 either merge their rootfs OR maybe bitbake two in one? :) Oct 08 07:56:39 depending on how the image recipe is done you may include one in an other Oct 08 08:00:13 ericben: ok, I will briefly try to explain. Yesterday I had bitbaked "meta-toolchain-qte", it seems to include everything I need for cross development, but people told me here that it for the HOST only. Now I need the counterpart image for the TARGET, i.e. containing Qt libs, TSlib, etc. How should I do this? Oct 08 08:00:45 Anguel: theoretically using a NFS you should do that Oct 08 08:01:51 Anguel: gosh! I'd better redo all the build step-by-step avoiding binary mismatch in this case Oct 08 08:03:40 mckoan: you mean I could try to export some directory from the bitbaked "meta-toolchain-qte" via NFS? sorry, I am still confused, thought that many people are using this kind of Qt setup Oct 08 08:04:57 Anguel: you said you have bitbaked the "qt4e-demo-image" and load the root file system via NFS Oct 08 08:10:41 mckoan: ok, so I will probably have to add the missing ssh through IMAGE_FEATURES += "ssh-server-dropbear" and look around what else might be missing. When I installed my Qt SDK that I had built with "meta-toolchain-qte" I also got a /usr/local/oecore-x86_64/sysroots/armv7a-vfp-neon-angstrom-linux-gnueabi directory but people told me yesterday that this is not meant to be used on the target, is this correct? Oct 08 08:14:28 Anguel: no. the SDK contains target folder because the SDK contains the target libs too, e.g. required to cross compilation. but it's not meant to be a running image Oct 08 08:20:57 ndec: what probably confused me was that the sysroots/armv7a... directory of the SDK contains folders like boot, dev, sbin Oct 08 08:23:51 Here http://www.angstrom-distribution.org/toolchains/ I read about the Qt Embedded SDK: "The SDK should contain a build of Qt Embedded, but also optional dependencies like directFB, glib-2.0, gstreamer-0.10, tslib and more esoteric dependencies like mysql and postgres. This allows developers to simply start developing using Qt and enables system integrator to easily recompile Qt and base libraries without tracking down extra dependencie Oct 08 08:24:03 gm Oct 08 08:25:07 So I thought that there must be a similar counterpart Qt image meant to be used on my target Oct 08 08:25:32 Anguel beware its older qt 4.6.3 Oct 08 08:26:47 woglinde: If follow the instructions and do "bitbake meta-toolchain-qte" I get Qt 4.8.1 Oct 08 08:27:07 Anguel okay Oct 08 08:27:15 so where is your problem? Oct 08 08:30:36 my problem is to find an image recipe for a rootfs that contains Qt Embedded 4.8.1, tslib, etc. that I can simply use for my target. I have found a "qt4e-demo-image" recipe but there seem to be some things missing, including ssh, connman probably too Oct 08 08:30:55 o.O Oct 08 08:31:00 Anguel make your own image Oct 08 08:31:09 and its easy just add the packages you want Oct 08 08:31:22 deps are put in automagically Oct 08 08:32:28 woglinde: sounds good, can you point me to some instructions to look how this is done? Oct 08 08:32:55 o.O Oct 08 08:32:59 woglinde: do I have to rewrite recipes? Oct 08 08:33:30 Anguel: http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#usingpoky-extend-customimage Oct 08 08:36:22 ericben: Thanks! Looks like overkill for a beginner like me that just wants to write some Qt app but I will try my luck Oct 08 08:36:41 overkill? Oct 08 08:37:09 just take an existing recipe and add your packagname to PACKAGES += Oct 08 08:37:22 exisiting image-recipe Oct 08 08:38:31 Anguel: you're right working to get a result is overkill. I don't understand why the community hasn't already finished your project ;-) Oct 08 08:39:19 ok - it's actually very easy ;) thanks. just thought that there are thousands of people using qt :) Oct 08 08:39:42 Anguel: there are thousand peoples using Qt but not all are working on your project ;-) Oct 08 08:41:14 ericben: my project is currently to get qt running :) Oct 08 08:41:57 ericben btw. where were you first half of 2013? Oct 08 08:43:14 woglinde: under water ;-) trying to manage to join Family, Sport & Work with these stupid days only having 24 hours ;-) Oct 08 08:43:26 woglinde: do you know if the recipes used to create the images here http://downloads.angstrom-distribution.org/demo/beaglebone/ are documented somewhere? Oct 08 08:43:27 ericben good Oct 08 08:43:48 Anguel yes Oct 08 08:44:03 in meta-angstroem and meta-beagle Oct 08 08:44:21 but again recipe might not be package-name Oct 08 08:44:44 look into your tmpdir/deploy/packages do scan over all the ipk Oct 08 08:45:15 here is the layerindex Oct 08 08:45:17 http://layers.openembedded.org/layerindex/branch/master/layers/ Oct 08 08:45:19 Anguel: https://github.com/Angstrom-distribution https://github.com/Angstrom-distribution/meta-angstrom https://github.com/beagleboard/meta-beagleboard Oct 08 08:45:41 btw. you have it anyway in sources while using angstroem's setup-scripts Oct 08 08:57:34 woglinde, ericben : Thank you, this is probably what I should look for: https://github.com/Angstrom-distribution/buildhistory/blob/v2012.12/images/beaglebone/eglibc/systemd-image/image-info.txt Oct 08 08:58:14 ericben: Hi, do you have some branch with all those qt5 change? Oct 08 08:58:22 anguel tinylogin is gone Oct 08 08:58:36 ericben: and possibly also for qtbase repo Oct 08 09:00:40 JaMa: I'm going to upload that in a few minutes Oct 08 09:05:18 woglinde: thanks, which one is actually the ssh server? Oct 08 09:06:35 dropbear Oct 08 09:06:45 which is installed by core image Oct 08 09:07:21 woglinde: ah, ok Oct 08 09:12:41 JaMa: concerning http://thread.gmane.org/gmane.comp.handhelds.openembedded/59838 in the end is RDEPENDS_${PN}-dev = "" what you prefer ? Oct 08 09:13:10 morning all Oct 08 09:17:07 hi bluelightning Oct 08 09:19:27 ericben: yes it looks OK (somehow I've missed this patch in patchwork) Oct 08 09:20:30 gm bluelightning, all Oct 08 09:20:57 hi mckoan Oct 08 09:22:50 JaMa: https://github.com/eukrea/meta-qt5.git branch eb/qt511update & https://github.com/eukrea/qtbase.git branch oe-5.1.1 Oct 08 09:23:18 JaMa: do you also want the dora branch update for meta-qt5 ? Oct 08 09:24:44 hm do we have directfb 1.7? Oct 08 09:27:16 JaMa: https://github.com/eukrea/meta-qt5.git branch eb/qt511dora Oct 08 09:27:50 ericben: thanks a lot Oct 08 09:28:32 ericben: I'll pass it to jenkins today and test it in webos-ports, if both tests look OK I'll merge it tomorrow (master) and dora a bit later Oct 08 09:28:35 JaMa: thanks for your work on meta-qt5 when I see the troubles oinly to update from 5.1.0 to 5.1.1 I imagine the hard work you had to bring all that together ! Oct 08 09:28:55 JaMa: I'm currently finishing my images to runtime test it Oct 08 09:29:37 yes it was quite a mess :/ now it's just a bit fragile but working Oct 08 09:30:36 if you have some hardware you can give a try to cinematicexperience it's interesting to test graphical performances Oct 08 09:31:17 I would be interesting in the FPS reported on some cortex A8 such as OMAP3 as I have a perf problem on i.MX53 Oct 08 09:31:45 btw JaMa I think we should remove qtjsondb in master as it doesn't compile anymore and the project seems dead Oct 08 09:32:40 ericben: it doesn't compile with qtbase 5.1.1? Oct 08 09:32:54 I'm pretty sure it did with 5.1.0 (at least in my env) Oct 08 09:41:05 JaMa: yes with 5.1.1 it doesn't compile anymore and sends "Project ERROR: Module jsondbpartition has no public API." Oct 08 09:42:56 this is due to commit 6d8f7a8d34906187c834e948b3ccd12a92fcccaa and 68fd6878ab5f40ee00dad00e3f46f9a3368ef5d8 in qtbase but I don't know how to workaround that Oct 08 09:44:08 the problem was also reported here : http://www.qtcentre.org/threads/56170-Module-has-no-public-API Oct 08 09:48:22 JaMa: and here is a comment about qtjsondb being dead : https://bugreports.qt-project.org/browse/QTBUG-31741 Oct 08 09:55:10 ericben: OK, fair enough, let's remove it together with 5.1.1 upgrade Oct 08 10:08:44 ericben: all in jansa/test branch with 2 minor modifications in commit message and added http://thread.gmane.org/gmane.comp.handhelds.openembedded/59838 with RDEPENDS Oct 08 10:11:48 JaMa: I'll send patch for qtgraphicaleffects & PN in PN-dev RDEPENDS Oct 08 10:11:50 thanks Oct 08 10:14:50 ericben: the same as qtquickcontrols? I'll squash it to the same commit Oct 08 10:14:58 dora changes are now in dora-next Oct 08 10:15:50 JaMa: same as qtquickcontrols : it was http://article.gmane.org/gmane.comp.handhelds.openembedded/59959 Oct 08 10:17:05 done Oct 08 10:39:11 ericben: can you please recheck qtquick SRC_URI checksums? maybe they have changed the tarball, but I'm getting different Oct 08 10:40:07 denix: with the latest build of libgles-omap3 I'm missing /usr/include/GL/gl.h in the dev package. is that the way it should be? Oct 08 10:40:18 JaMa: ok I'm checking it now. ( and now I'm not sure if I finished to compile qtquick or if I stopped at webkit) Oct 08 10:40:33 as it was late ;-) Oct 08 10:41:40 np Oct 08 10:41:54 JaMa: you're right I forget to change de checksums. patch is following Oct 08 10:43:32 tasslehoff hm does gles stuff provide gl.h? Oct 08 10:43:43 its gles not gl Oct 08 10:49:08 woglinde: hm. that's right. What I have lost is the provider of GL/gl.h :) Oct 08 10:49:48 hm? Oct 08 10:50:12 why you need a provider for GL/gl.h when you are using gles? Oct 08 10:53:34 ericben: I'll update it Oct 08 10:53:35 SRC_URI[md5sum] = "05956168e0a4bba44c31b61dd4fc5e6e" Oct 08 10:53:35 SRC_URI[sha256sum] = "f5dc431fb33a195414d2d75d7dff1c101f4101489f38b4ea9c5e8782b1807a64" Oct 08 10:54:00 woglinde: there may be a lot of pebkac here. meta-qt5 has no recipe for an sdk, so I'm trying to fix it myself. have added libs and include files, but not gotten the tools (qmake, moc, uic) in place yet. Oct 08 10:54:43 therefore I take those from an install on my desktop, and it seems to be that one that wants gl.h ... Oct 08 10:56:10 ericben: done in both jansa/test and dora-next Oct 08 10:56:52 I need what nativesdk-qt4-tools*.bb provides for qt4 Oct 08 10:59:47 tasslehoff hm ask jama and ericben to fix it for you Oct 08 10:59:58 they are working on qt5 anyway Oct 08 11:02:08 many people already said that they are working on sdk support so I don't plan to work on it too Oct 08 11:02:21 and I don't have any use-case for it, so I cannot test it properly Oct 08 11:06:51 woglinde: it was a bad include path. thanks for making me think twice :) Oct 08 11:11:21 tasslehoff fine I hope you will send some patches for sdk support Oct 08 11:14:39 woglinde: that is the plan, but I never get the time to finish it properly. as it stands now it is a hack that requires the user to have a local installation of Qt as well :/ Oct 08 11:14:49 uh lol Oct 08 11:15:06 because of the tools Oct 08 11:15:10 qmake and stuff? Oct 08 11:15:25 woglinde: yes Oct 08 11:16:54 woglinde: you told me that dropbear is in core-image, now I see that the "qt4e-demo-image" recipe says "inherit core-image" but does not include dropbear. how is that possible? Oct 08 11:39:47 ericben: my image build finished with 5.1.1 testing in runtime now Oct 08 11:49:44 Anguel: hi, have you solved your sdk issue? Oct 08 11:50:30 ant_work: hi! well, turned out that the SDK does NOT have any root file system that can be used directly for the target Oct 08 11:50:42 ant_work: thank you for asking! Oct 08 11:50:50 yw Oct 08 11:52:31 ant_work: the experts here told me to build my own image including qt etc. by modifying an exisiting recipe Oct 08 11:56:06 ant_work: and this is what I am now experimenting with :) Oct 08 12:04:58 JaMa: I confirm the checksum for qtquick1 Oct 08 12:12:53 Anguel than simply add it to your image Oct 08 12:13:10 Anguel or do a quick git grep SSHD Oct 08 12:13:34 Anguel: example image http://pastebin.com/0Q1aHDUc (probably a lot you don't need here, and it is console only) Oct 08 12:15:54 woglinde, tasslehoff : I now simply modified systemd-image.bb and added "packagegroup-core-qt4e" to IMAGE_INSTALL, let's see if it will work :) Oct 08 12:17:05 anguel meta-oe/recipes-core/packagegroups/packagegroup-basic.bb Oct 08 12:17:21 Anguel yes good idea Oct 08 12:17:35 agreed. my image is ooooold :) Oct 08 12:18:32 hm, guys, the -nativesdk packages, when unpacking them, I see all unpack to a /usr/local prefix but i somehow can not find who is setting it, any hints? Oct 08 12:29:50 I think I figured it out, when one changes the SDK path, all nativesdk ipk's need to be rebuilt Oct 08 12:31:21 wow, my new image booted right into the qt demo :) Oct 08 12:32:47 ok, I had to remove connman.service as this causes some serious conflict with the NFS rootfs, loaded via U-Boot Oct 08 12:34:30 Anguel yes Oct 08 12:49:04 hm, tslib seem to not to be in the image, however I see the following line in "packagegroup-core-qt4e.bb" --> TOUCH = ' ${@base_contains("MACHINE_FEATURES", "touchscreen", "tslib tslib-calibrate tslib-tests", "",d)}' Oct 08 12:49:31 what could this mean? Oct 08 12:51:00 this means your machine.conf does not list touchscreen in M_F Oct 08 13:03:15 ant_work: so therefore it does not install tslib? Oct 08 13:07:27 yes, you'd get TOUCH = "" Oct 08 13:08:06 ant_work: thanks! so I will add these to my main recipe :) Oct 08 13:09:21 machine recipe Oct 08 13:09:47 right Oct 08 13:11:08 JaMa: I'm currently fixing this in qtquick1 : ERROR: QA Issue: non debug package contains .debug directory: qtquick1-examples path /work/armv7a-vfp-neon-oe-linux-gnueabi/qtquick1/5.1.1-r0/packages-split/qtquick1-examples/usr/share/qt5/examples/declarative/cppextensions/plugins/org/qtproject/TimeExample/.debug/libqmlqtimeexampleplugin.so Oct 08 13:13:48 woglinde: I meant to add the packages to my modified systemd-image.bb :) Oct 08 13:15:57 ofc you can do that but it isn't the most elegant way :p Oct 08 13:16:48 right, but this way I have to mod only one file :) Oct 08 13:17:29 and tslib will not harm any target ;) Oct 08 13:17:37 but you are adding a couple of unneeded lines to the metadata and keeping a broken machine.conf Oct 08 13:20:19 fill in a complete list, i.e. MACHINE_FEATURES = "apm alsa pcmcia irda usbgadget keyboard touchscreen screen vfat ext2 usbhost wifi" Oct 08 13:20:36 check it once for all Oct 08 13:21:17 ok, but I currently don't find where the machine conf is in /setup-scripts/ Oct 08 13:21:31 what's your target? Oct 08 13:21:53 Beaglebone Black - or is in the environment setup Oct 08 13:22:23 Angstrom Oct 08 13:22:53 oh, BB is a different story. touchscreen is optional there Oct 08 13:24:33 yep Oct 08 13:25:18 so modify the main recipe? Oct 08 14:34:42 does the package order in the recipe actually matter? i notice that when the qt demo autostarts (default in qt4-demo-image) it ignores touchscreen calibration. however, when i kill the qt demo process and restart it, everything is calibrated ok Oct 08 14:35:15 calibration is done through tslib Oct 08 15:55:37 I think we have a public TSC/workgroup meeting starting in here in 5 mins Oct 08 15:55:46 apologies for the lack of announcement... Oct 08 15:56:26 * Crofton|work beat bluelightning Oct 08 15:56:46 did you submit the stand app for FOSDEM? Oct 08 15:57:05 not yet no Oct 08 15:57:36 tomorrow Oct 08 15:57:57 should be a search and replace from last year's this time Oct 08 16:02:20 bluelightning: I believe we have a meeting, yes Oct 08 16:02:28 I am here as well Oct 08 16:04:01 do you want to use the bot to take minutes? Oct 08 16:04:48 can do Oct 08 16:05:06 say #startmeeting Oct 08 16:05:17 #startmeeting Oct 08 16:05:17 Meeting started Tue Oct 8 16:05:17 2013 UTC. The chair is bluelightning. Information about MeetBot at http://wiki.debian.org/MeetBot. Oct 08 16:05:17 Useful Commands: #action #agreed #help #info #idea #link #topic. Oct 08 16:05:17 then use #char rp fray to add more chairs Oct 08 16:05:28 er #chair Oct 08 16:05:35 do we want everyone to be chair or just the actual chairperson? Oct 08 16:05:43 it helps with some of the commands Oct 08 16:06:13 https://wiki.debian.org/MeetBot Oct 08 16:06:16 #chair rp fray koen khem Oct 08 16:06:16 Current chairs: bluelightning fray khem koen rp Oct 08 16:06:22 hmm Oct 08 16:06:29 #chair RP fray koen khem Oct 08 16:06:29 Current chairs: RP bluelightning fray khem koen rp Oct 08 16:06:39 so basically each of you can enter topics Oct 08 16:06:43 great Oct 08 16:06:51 we've stumbeled on that in the past :) Oct 08 16:08:01 so I don't think we have a formal agenda for this meeting Oct 08 16:08:17 no jefro? :/ Oct 08 16:08:25 it seems not Oct 08 16:08:29 we replaced jefro with a bot :) Oct 08 16:08:37 The idea is that we'd have basic status, see if there are any concerns, and open the floor for others.. Oct 08 16:09:32 ok, RP perhaps you'd like to give a quick summary of the current release status? Oct 08 16:09:42 Well, to summarise where we're at with OE-Core, we're coming to the end of 1.5. It should be the last -rc build today Oct 08 16:10:18 There were some ADT/SDK issues in the last one which have meant we need this last -rc. I did take the opportunity to merge more patches than I probably should have done, all good fixes though Oct 08 16:10:38 master and dora are likely to start diverging now Oct 08 16:11:30 Happy to answer questions if anyone has any Oct 08 16:12:24 How is planning for the next dev cycle going? Oct 08 16:12:37 I think it's just starting.. Oct 08 16:12:57 so input, working groups, etc... it's a good time for peoople to start thinking (and doing) now Oct 08 16:13:04 Crofton|work: Its a bit late. We have a rough idea of the themes Oct 08 16:13:23 such as? Oct 08 16:13:24 but basically if anyone has things they'd like to see in the next cycle get them in bugzilla yesterday Oct 08 16:14:03 Crofton|work: Continue to extend the runtime QA tests, integrate ptest into those QA tests, also look at real hardware testing Oct 08 16:14:12 nice Oct 08 16:14:19 also non-runtime tests (tests of the build system itself) Oct 08 16:14:27 I'll be pushing my own agenda a bit.. more on the deployment side of the world.. Oct 08 16:14:53 package feeds, runtime package upgrades, spdx generation/processing, etc... Oct 08 16:14:55 yes, wic came in late but can be thought of as beta and something which will develope Oct 08 16:15:17 and webhob will land in 1.6 with some special released standalone meanwhile Oct 08 16:17:05 speaking of SPDX, I'll be giving a talk about the spdx/Yocto Project (oe-core) integration at ELC-E in a couple weeks.. the topic is basically the spdx.bbclass that went in and where we think it's going to go... Oct 08 16:17:20 (hint we want end-to-end license/source/binary traceability) Oct 08 16:18:57 fray: for a second I read that as "we want to end" Oct 08 16:19:10 ha Oct 08 16:19:52 btw you forgot to say #topic RP review blah blah :) Oct 08 16:21:23 bluelightning: I'm kind of assuming you're chairing FWIW Oct 08 16:21:38 lol.. Oct 08 16:21:38 I guess I'm volunteered then ;) Oct 08 16:22:09 can we move to concerns? Oct 08 16:22:17 yes let's do that Oct 08 16:22:29 #topic community concerns Oct 08 16:23:04 It seems like we are very good at building images for bits of hardware, Oct 08 16:23:10 does anyone have anything they'd like to raise? Oct 08 16:23:16 but not so good at fixing run time issues Oct 08 16:23:41 I think runtime issues (i.e. the package upgrades I mentioned earlier) are things we need to start spending more time on.. Oct 08 16:23:54 we're finding and fixing the bugs I've seen.. but I know testing is far from complete. Oct 08 16:23:59 yes, I think it's fair to say we haven't concentrated enough on improving and maintaining runtime Oct 08 16:24:00 basically, I am thinking about the problem of end users getting binary images for their hardware Oct 08 16:24:10 I realize this is not directly an OE issue Oct 08 16:24:14 ahh thats a little different then Oct 08 16:24:16 more for distros Oct 08 16:24:36 but, I think it is important enough we need to think about it Oct 08 16:24:43 if it's giving distros tools that help them do their jobs, then it is within our remit Oct 08 16:24:52 yup Oct 08 16:24:57 distros should not be fixing up stupid metadata issues Oct 08 16:25:21 Crofton|work: can you be more specific about the problem? Are distros having to fix stupid metadata issues? Oct 08 16:25:23 I jsut wanted to get this out there for people to be thinking about Oct 08 16:25:43 well, I had to listen to some guy praising a linaro rootfs becuase it just worked Oct 08 16:26:08 and I am thinking, what aren't we doing to be in that position Oct 08 16:26:35 Crofton|work: I think it's worth mentioning our additional runtime testing should help avoid errors during boot and other regressions creeping in as they have during previous development cycles Oct 08 16:27:04 Crofton|work: A lot of what happens in the core is not end user enabling. It turns out that is rather specific to particular projects and products :/ Oct 08 16:27:05 and I'd like to see the hw vendors caring more about stuff working on their hw etc Oct 08 16:27:08 i have previously thought that QA should be testing the upgrade path for packages to ensure that week N can upgrade to N+1, for example. Oct 08 16:27:14 that said, we now need to look at expanding those runtime tests in the forthcoming cycle, including adding tests in other layers in the OE ecosystem (which is now possible) Oct 08 16:27:25 Crofton|work I do hear people talking about the need for 'validation' images.. an image known to work (or at least with a known set of problems) for hardware bring-up, and early application development.. Oct 08 16:27:29 Crofton|work: Its a question of *what* working? A webserver? A GL app? HTML page? Oct 08 16:27:40 sure Oct 08 16:27:41 rburton yes Oct 08 16:27:54 these are things we need to care about Oct 08 16:27:57 rburton: we should automated testing that... Oct 08 16:28:14 rp: sure, it's a "trivial" thing to do. Oct 08 16:28:35 rburton: perhaps file an ehancement bug? Oct 08 16:28:41 rp: aye Oct 08 16:28:52 I thought there was one open for that already Oct 08 16:29:15 https://bugzilla.yoctoproject.org/show_bug.cgi?id=4304 Oct 08 16:29:18 yes, i filed it already :) Oct 08 16:29:24 There is a serious point here, only today I heard that people are struggling to figure out what test cases are needed... Oct 08 16:29:26 rburton: you filed it, do I get a cookie? ;) Oct 08 16:30:00 its marked as Future, which is why it "disappeared" Oct 08 16:30:20 rburton: Its no longer marked as future ;-) Oct 08 16:30:34 RP: to give a proper answer to that question we would need to define the functionality we expect to provide, so we can verify it works... Oct 08 16:31:00 obviously each time we add a new feature we know we ought to have a test for it Oct 08 16:31:04 I think that is certainly one of the trickier aspects of any open source distro.. defining what should work and verification.. Oct 08 16:31:08 bluelightning: agreed, we're just struggling to have all the right information with the right people though Oct 08 16:31:16 yup to both Oct 08 16:32:24 I'd also add that whilst I've done a lot to drive some of these things in the past I'm not scaling well so I need people to help with it... Oct 08 16:33:01 * RP also notes that he really should stop looking at C++ bugs as it makes his head hurt Oct 08 16:33:13 we all mail RP sets of hw we want to work well and he tests! Oct 08 16:33:43 next update RP cloning machine.. Oct 08 16:33:44 I'd like to hope that with the added focus on automated testing we'd get some more direct contributions from QA engineers in the various organisations Oct 08 16:34:01 Crofton|work: I can then forward them on to you and delegate ;-) Oct 08 16:34:18 and from other projects Oct 08 16:34:38 i.e. if they know we can test and find regressions, perhaps we'll get more users/contributores Oct 08 16:35:55 so, anything else people would like to talk about? Oct 08 16:36:08 Yep Oct 08 16:36:32 At the GNU Radio Conference last week we talked about moving gnuradio and uhd to "meta-sdr" Oct 08 16:36:44 The feedback has always been people want to be more involved with the TSC so it would be good to see more people talking here :/ Oct 08 16:36:51 I suspect some other stuff will find a home there, but not amateur radio stuff Oct 08 16:37:11 Crofton|work: sounds like a reasonable move to me Oct 08 16:37:35 I'm going to send something to the oe list, but was wondering if we had guildeines in place? Oct 08 16:37:52 for the meta-openembedded stuff, I think we've been pretty fluid.. Oct 08 16:37:59 that is what I think Oct 08 16:38:00 Crofton|work: its usually for discussion between the layer maintainers Oct 08 16:38:02 new layers/divisions get created when necessary.. Oct 08 16:38:17 well, AIUI what we care about when it comes to creating new layers be they in meta-openembedded or outside of it is that there's a maintainer and there's some level of maintenance of the layer Oct 08 16:38:46 I was going o make it inside meta-oe, since it will retain a dependency on meta-oe I suspect Oct 08 16:38:47 yup.. someone has to step up.. Oct 08 16:39:01 we just want to be able to mess around with it as a group Oct 08 16:39:13 fair enough Oct 08 16:39:14 I'd suggest RFCing it as you've proposed Oct 08 16:39:17 thanks Oct 08 16:39:52 I need to run, when you are done do #endmeeting and I'll send the output to jefro Oct 08 16:39:59 speaking of layers, there are still a huge number of unindexed layers on github etc., and more are added weekly Oct 08 16:40:17 use topic :) Oct 08 16:40:22 #topic layers Oct 08 16:40:41 Personally, I'd really like people to consider sharing the layers on git.oe.org or git.yp.org Oct 08 16:40:49 if you're maintaining a layer that others might find useful please submit it at http://layers.openembedded.org/ Oct 08 16:40:59 just so there is some standard place people can look at... Oct 08 16:41:07 (as well as the index) Oct 08 16:41:51 yes, it's worth pointing out that yoctoproject.org and openembedded.org can both provide hosting for maintained layers Oct 08 16:42:56 people really like github etc Oct 08 16:43:20 Crofton|work: its good for some things, less good for others Oct 08 16:43:23 Crofton|work, for people posting there or elsewhere, the layer index is advisable... Oct 08 16:43:47 yep, as far as the layer index is concerned, it doesn't matter where it is as long as it's publicly accessible Oct 08 16:43:48 right the layerindex is awesome Oct 08 16:43:53 my only issue w/ github (and other places) is that it's harder to find layers that are -maintained- because you don't really know the commitment level of the people working on the layer Oct 08 16:43:56 it's not even mandatory that it has a web interface Oct 08 16:44:07 we need to focus our efforts on indexing Oct 08 16:44:24 the layer index does report "last updated" information Oct 08 16:44:42 we could always collect/analyse more if desirable Oct 08 16:46:24 I'd almost say it's not mandatory for a layer to be *heavily* maintained to be in the layer index either; if it's there people can find it and contribute to it Oct 08 16:47:11 right Oct 08 16:47:23 not having people rewrite the same recipes was a key goal for setting it up Oct 08 16:48:07 I think my worry is that OE is seen as this fragmented and inconsistent mess :/ Oct 08 16:48:28 the index helps but I do think a bit more standardisation would also help... Oct 08 16:48:31 I haven't heard that comment a lot, FWIW Oct 08 16:48:40 but it is hard to get started Oct 08 16:49:13 well, we need to work out from oe-core to improve layers Oct 08 16:49:26 there's certainly more we could do with analysing (and testing, with some community help) of layers outside OE-Core Oct 08 16:49:40 we can not digest everything at once, but we can work with critical layer s to improve them Oct 08 16:50:16 I'm hoping if we get more good testing in the core, this will spread... Oct 08 16:50:29 and with better tests, quality in other layers may improve Oct 08 16:51:20 FWIW, I think this cycle has already seen quite significant quality improvements in meta-oe thanks to JaMa's autobuilder testing/fixing Oct 08 16:51:31 sorry for late comment, I think that for QA and upgrade-path issues I should finish https://bugzilla.yoctoproject.org/show_bug.cgi?id=3505 soon Oct 08 16:51:50 ah yes, good point Oct 08 16:51:59 JaMa, excellent.. Oct 08 16:52:58 ok, 8 mins left - anything else folks would like to discuss? Oct 08 16:53:21 JaMa: yes, that will help too... Oct 08 16:56:27 so I see 4 minutes or so till the hour.. Oct 08 16:56:33 yep Oct 08 16:56:42 any thing else, otherwise.. we may have run out of topics.. Oct 08 16:56:52 Next meeting would be first or second week of Nov.. right? Oct 08 16:56:57 #topic next meeting Oct 08 16:57:05 yay bluelightning Oct 08 16:57:06 I think Nov 5th will be the next meeting Oct 08 16:57:20 so the only thing I can think of is nominate a person to send out the next meeting invite Oct 08 16:57:42 bluelightning, try recording that via the #action command Oct 08 16:57:43 I can do it, but someone needs to actually do it Oct 08 16:58:14 #action bluelightning send out meeting invite for nov 5th Oct 08 16:58:24 presumably that did something... Oct 08 16:59:06 we'll see Oct 08 16:59:22 ok, if nothing further, I guess we can call it a meeting? Oct 08 16:59:30 works for me! Oct 08 16:59:31 thanks! Oct 08 16:59:36 thanks everyone Oct 08 16:59:41 type #endmeeting Oct 08 16:59:41 bluelightning: sounds good, thanks Oct 08 16:59:42 #endmeeting Oct 08 16:59:42 Meeting ended Tue Oct 8 16:59:42 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Oct 08 16:59:43 Minutes: oe/2013/oe.2013-10-08-16.05.html Oct 08 16:59:43 Minutes (text): oe/2013/oe.2013-10-08-16.05.txt Oct 08 16:59:43 Log: oe/2013/oe.2013-10-08-16.05.log.html Oct 08 16:59:57 do you have atsc address? Oct 08 17:00:19 tsc@lists.openembedded.org you mean? Oct 08 17:00:23 yeah Oct 08 17:00:37 lo, I read that as 'ATSC', wondering what video has to do with it.. :) Oct 08 17:00:46 well, yes that mailing list exists if that's what you're asking... Oct 08 17:01:51 heh Oct 08 17:01:55 yeah, me to Oct 08 17:01:59 gr-atsc Oct 08 17:25:16 I cant find a opkg binary to inspect the generated .ipk-files.. Is it located somewhere in my build directory ? Fedora doesnt seem to ship a opkg package Oct 08 17:25:34 install dpkg Oct 08 17:25:37 works the same Oct 08 17:26:04 woglinde, aha Oct 08 17:30:34 jkroon: mc and emacs can inspect them too Oct 08 17:31:34 woglinde, thanks Oct 08 17:31:51 ensc|w, oh, another emacs feature :-) Oct 08 19:38:09 Does anyone know if its possible to use Qt with hardware accelerated OpenGL, without Xorg, on the Wandboard Solo ? Oct 08 19:38:42 I tried building an image but any application I start complains that it cant find the xcb platform plugin Oct 08 19:40:21 Or is Xorg always required whenever you want to do hw-accelerated graphics on ARM/Linux ? Oct 08 20:03:34 jkroon: no it's not always required. Oct 08 20:03:40 are you using Qt4 or Qt5? Oct 08 20:03:44 qt5 Oct 08 20:03:56 master, dylan or dora? Oct 08 20:03:59 master Oct 08 20:04:01 for meta-qt5, i mean Oct 08 20:04:13 yup, all layers I use are master Oct 08 20:04:17