**** BEGIN LOGGING AT Wed Aug 20 02:59:59 2014 Aug 20 06:04:46 i am getting packagegroup-core-x11-base : Depends: packagegroup-core-x11-utils but it is not going to be installed error Aug 20 06:04:52 any help Aug 20 06:10:17 good morning; is it possible to specify custom commands for the SDK to be added to the sdk environment setup after the installation? Aug 20 06:54:47 morning all Aug 20 07:22:37 bluelightning: you are on weirdo side of the pond :P Aug 20 07:30:29 bluelightning: hi Aug 20 07:31:24 is this the right syntax? Apparently, this did not work: grep RM_WORK_EXCLUDE ../meta-foo/recipes-core/images/foo-core-image-dbg.bb Aug 20 07:31:27 RM_WORK_EXCLUDE += " foo-core-image-dbg.bb" Aug 20 07:34:05 fray: do you happen to know how I can print out what path gdb is looking for? Aug 20 07:44:13 oh, show directories, maybe. Aug 20 09:10:32 fray: got it working by using the set substitute-path thing, but is this really needed for every developer? Shouldn't Yocto set up the right rootfs path by default? Aug 20 09:11:41 fray: on a second thought, that would be breaking on the target though, so it is yeah .. probably it is better to prioritize it for the target, and once can set it up explicitly on the host. Anyway, this is the kind of thing I am talking about with regards to missing tutorials. I will write one up later since I now got all the pieces in place, I think! Aug 20 09:20:48 Good Morning. Is anybody else having issue with pushing some stuff to the git server. Or I am the only one getting "No space left on device"? Aug 20 09:22:01 to the yocto git server you mean? Can you show the git push output? Aug 20 09:22:19 yes, the yocto git server Aug 20 09:22:47 close log failed: No space left on device Aug 20 09:22:47 fatal: Could not read from remote repository. Aug 20 09:23:29 void-dev: do not commit 500 TB lol Aug 20 09:27:45 lpapp: it just a changed SRCREV :) Aug 20 09:30:44 void-dev: not sure, can you poke the guys at Intel? It might be quicker. Aug 20 09:37:49 halstead: ^ Aug 20 10:22:43 <_rink> bluelightning, ping Aug 20 10:28:28 I'm pretty sure only a few people can push to the yoctoproject git servers Aug 20 10:50:55 _rink: pong Aug 20 10:51:40 I think git.yoctoproject.org is out of space (which affects poky-contrib which a lot of folks do have push access to) Aug 20 10:52:17 void-dev: its got some space back now Aug 20 10:52:24 RP: great, thanks Aug 20 10:52:59 JaMa: Any thoughts on the allarch/packagegroup proposed changes? Aug 20 11:00:23 RP: thank you, git push did work again now Aug 20 11:19:22 <_rink> bluelightning, I've got a reply regarding the dosfstools patch Aug 20 11:19:29 <_rink> bluelightning, author is okay with relicensing Aug 20 12:16:15 RP: I haven't tried them yes, but looks OK Aug 20 12:17:10 RP: just feels strange that we need so many exceptions to support such small corner case (that's why I was proposing just to quickly rebuild them) Aug 20 12:23:14 _rink: ok, great Aug 20 12:24:19 <_rink> bluelightning, so, should I submit a bugtrack issue or something? Aug 20 12:32:34 _rink: if you could send the patch (in the form of a patch adding the patch to the recipe that is) that would be awesome Aug 20 12:32:58 <_rink> bluelightning, sure, what's your e-mail address? Aug 20 12:34:01 _rink: mailing list? Aug 20 12:35:30 _rink: typically patches are sent to the mailing list, in this case (as it's an OE-Core recipe) it would be openembedded-core@lists.openembedded.org Aug 20 12:35:50 I may have linked before but FYI: http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded Aug 20 12:36:52 <_rink> thanks for the hand-holding, I'll prepare something Aug 20 12:37:08 thanks Aug 20 12:39:47 Just a quick check before I send more fixes based on patches from Sabotage Linux Aug 20 12:39:58 The patches in Sabotage are licensed as per https://github.com/sabotage-linux/sabotage/blob/master/LICENSE Aug 20 12:40:11 I think that makes them ok to include in OE Aug 20 12:40:15 any other opinions? Aug 20 12:41:26 I'm no lawyer, but it looks pretty good to me... Aug 20 12:44:54 bluelightning: That's pretty much my thoughts Aug 20 12:45:08 I'll keep going, 'mc' next Aug 20 12:49:28 JaMa: void-dev: A backup script used all available space last night. The script is fixed and space is available now. Aug 20 12:50:34 JaMa: Most of the patches are not exceptions as such, just small improvements to process. I made the patches pretty granular Aug 20 12:54:10 so who is working on getting rm_old_work into oe-core? Aug 20 12:57:24 you? Aug 20 12:58:53 :-) Aug 20 13:00:24 hmm, I changed the source code in the workdir, and then I did bitbake -c cleansstate foo-git; bitbake foo-core-image-dbg Aug 20 13:00:41 yet, the rootfs was not populated with the modified source and the unmodified is there; why? Aug 20 13:01:20 what is the correct way to update the debug rootfs after some custom source code experiment in a package that is part of the dbg image? Aug 20 13:01:52 I even tried bitbake -c cleansstate foo-core-image-dbg Aug 20 13:06:34 now I am always pushing to the repository for testing so that I can use bitbake foo-core-image-dbg since that detects the autorev'd package has changed, but this is not optimal. I would like to be able to test before committing. Aug 20 13:08:22 Hi all. I have added below lines: But still not able to create a branch called "dev/test": [access "refs/heads/dev/*"] create = group Registered Users Aug 20 13:08:50 Only get: Code review error - 404 Not found Aug 20 13:10:20 Any suggestions what I might do wrong? I know that it should be possible to create branches under a certain keyword (like /dev/). Aug 20 13:13:32 hmm sorry. Wrong window.. Should be in the gerrit channel =) Aug 20 13:45:45 _valle_, Aug 20 13:45:47 you said Aug 20 13:45:48 <_valle_> Hi I can't get qtdeclarative-examples to run from meta-qt5, master branch. Aug 20 13:45:48 <_valle_> The error given is module "QtQuick" is not installed Aug 20 13:45:53 any luck with that? Aug 20 14:07:15 Is there anybody out there who has successfully built qt5 on yocto, using the meta-qt5 layer, and also got a working sdk from it by using bitbake -c populate_sdk? I don't get the qmake executable on my sdk (moc, uic etc are there). Aug 20 14:09:32 Mattias_: yes Aug 20 14:10:13 fray: do you know how Yocto knows which source files to move to the sysroot? Aug 20 14:11:43 the debugedit program (sourced from RPM) inspects the dwarf symbols we were talking aobut yesterday.. Aug 20 14:11:51 ipapp: How did you get the qmake executable to your sdk? Is there som packare I have missed perhaps? Aug 20 14:12:14 it then creates a list of referenced files which are copied into the /usr/src/... directory... and files it can't find (i.e. the libgcc.a and .o files mentioned yesterday) are ignored Aug 20 14:12:15 lpapp: How did you get the qmake executable to your sdk? Is there som packare I have missed perhaps? Aug 20 14:12:54 the code occurs in meta/classes/package.bbclass -- splitdebuginfo function Aug 20 14:13:18 debugedit will output a list of source files.. (as well as modify the references within the dwarf symbols).. Aug 20 14:13:29 we then split the binary... Aug 20 14:13:33 add the 'debuglink' Aug 20 14:13:56 and then the 'copydebugsources' is run, this uses the list generated by the debugedit program... Aug 20 14:14:13 fray: I am surprised that it did not pick up some files that it should have. Aug 20 14:14:51 fray: how can I fix that? Is there a fallback rule added for explicit decision? Aug 20 14:14:54 it's either debugedit didn't output the file in it's list, or the cpio couldn't find the file.. Aug 20 14:15:06 (retval, output) = oe.utils.getstatusoutput(cmd) Aug 20 14:15:36 that is what does the build.. 'output' is ignored.. you can add in a bb.warn afterwards and pring out the output if you want to see the cpio errors.. Aug 20 14:15:43 search for: Aug 20 14:15:49 cmd = processdebugsrc % (sourcefile, workbasedir, workparentdir, dvar, debugsrcdir) Aug 20 14:15:49 (retval, output) = oe.utils.getstatusoutput(cmd) Aug 20 14:15:49 # Can "fail" if internal headers/transient sources are attempted Aug 20 14:15:59 after the 'Can "fail"' comment.. just put: Aug 20 14:16:29 bb.warn("dbg-src: %s" % output) Aug 20 14:16:45 (note it may be a lot of output, I don't remember off hand if it's just warnings/errors or if it's the full file list..) Aug 20 14:17:18 has anyone here made qt applications with yocto? Aug 20 14:18:00 any idea why myWidget->update() would not be triggering a redraw in a timer event when running in yocto? Aug 20 14:20:43 joran_: can you not reproduce it with stock Qt without Yocto? Aug 20 14:23:19 it works fine in linux and windows ... but my timerEvent is not refreshing the screen in yocto Aug 20 14:23:35 you mean built with Yocto, not in Yocto. Aug 20 14:23:40 as Yocto is just a build environment. Aug 20 14:23:54 yeah ... built with yocto for arm7 Aug 20 14:24:08 semantics meh :P you knew what I meant :P Aug 20 14:26:03 which plugin is it trying to use for the drawing? Aug 20 14:26:34 none ... just using qPainter to draw on the canvas Aug 20 14:27:09 btw, the Yocto people are usually not Qt experts... so you need to know what Qt should be doing, but it does not do. Aug 20 14:27:22 it may be because I spawn a second thread that does the work and reports the data ... the timer event just polls if the data is ready ... maybe the CPU is working too hard Aug 20 14:27:22 you can know that either yourself or by talking to Qt experts. Aug 20 14:27:58 and of course, you need an SSCCE :-) Aug 20 14:28:23 the painting works on resize ... it just doesnt seem to call the timer event ... bah of coarse :P Aug 20 14:28:30 SO attacks even here :P Aug 20 14:28:34 hehe Aug 20 14:29:40 well, try to run the examples ... that are presumably generated by Yocto. Aug 20 14:33:08 hi all Aug 20 14:33:09 yeah Im going to try and use myWidget->redraw() which should repaint immediatly rather than just put it in some event queue Aug 20 14:39:41 bah no luck ... oh well I'll keep trying ... Im pretty sure ill be able to get it ... off to work for now Aug 20 15:44:36 halstead: thank you for the update, and the fix Aug 20 15:54:32 how to override/bbappend some environment variables in meta/conf/licenses.conf (i.e. SPDX_MANIFEST_DIR and FOSS_SERVER) ? Pointers to specific RTFM chapter are fine Aug 20 15:55:48 Thanks for reporting void-dev . :) Aug 20 19:03:21 Hey guys, I'm back again Aug 20 19:03:32 Still having issues with my LCD shutting off after 15 minutes Aug 20 19:06:33 Does anyone know what could be causing it to do that? Aug 20 19:07:48 I most recently tried echo 0 > /sys/class/vtconsole/vtcon1/bind Aug 20 19:07:59 but if I do a cat /sys/class/vtconsole/vtcon1/bind I get 1 Aug 20 19:16:51 Hello Aug 20 19:19:06 Hey cha5on Aug 20 19:22:54 First time on the channel, with a newb question: I'm looking to transition a homebrew rootfs project to use poky or some other system like openwrt or buildroot, but haven't really found a good comparison between them. Anyone have any pointers? Aug 20 19:59:31 cha5on I believe openwrt uses buildroot as its build system Aug 20 20:00:13 this is an older blog post comparing openembedded/yocto to buildroot: http://free-electrons.com/blog/experiment-with-yocto/ Aug 20 20:09:21 Jefro: Thanks! That's one of the articles I stumbled upon a couple of days ago. Openwrt actually uses a fork of an old buildroot that's pretty different---although they're both makefile-based, the projects have gone in quite different directions, with openwrt having package support and buildroot being focused on large numbers of platforms Aug 20 20:14:21 I find buildroot to be best when you're wanting to do a quick bringup, e.g. new board bringup work, or just need a quick rootfs for testing, but oe/yocto is nicer for long term maintainance of the fs and distro, but that's just my view on the subject. oe/yocto has more overhead, but a great deal of power and flexibility as well. Aug 20 20:15:56 kergoth, I've heard the same from others.. YP wins at long term maintenance (and also larger systems).. but has a steeper learning curve.. Aug 20 21:07:50 kergoth and fray_: good to know, thanks! One of the concerns I have right now with yocto is with the build system requiring python 2.7, which isn't supported on RHEL6. I see that there's a "buildtools" tarball that provides these, but telling everyone to install that seems like a major hassle, especially since it'll probably need updating sometime in the future Aug 20 21:14:05 we use (current) YP all the way back to RHEL 5.8? I think.. using the buildtools.. Aug 20 21:14:26 it's really easy to install.. and doesn't require any regular updates.. we just update it when new YP versions are released Aug 20 21:14:58 on one of my RHEL 6 machines, I installed the build-tools into a common location on hte machine.. and all of the users who need it can just source it... avoids some hastle Aug 20 21:39:50 fray_: cool, I think something like that might be workable here too Aug 21 02:06:49 a[ **** ENDING LOGGING AT Thu Aug 21 02:59:59 2014