**** BEGIN LOGGING AT Tue Apr 12 02:59:58 2016 Apr 12 08:26:21 hi guys, i'm wondering why, when i generate a rootfs.ex4, its size can be 1.2G whereas, when mounting the exact file in a directory, the total amount of data represents 805M. Is there some kind of alignement? Apr 12 08:28:04 s54: empty space Apr 12 08:28:30 you can't boot a 100% full file system, rootfs are generated with a bit of slack so you can use them Apr 12 08:28:55 also depending on how you measured 805M, block size may be relevant Apr 12 12:58:31 hello Apr 12 15:14:51 So I presume this is a decent place to ask about poky ? Apr 12 15:15:31 gtristan: yes Apr 12 15:15:42 I have been trying to build poky (https://www.yoctoproject.org/downloads/yocto-project) from the jethro branch... trying to basically native build on aarch64 Apr 12 15:16:01 Is this something that is relatively tested, do people do this ? Apr 12 15:16:25 my guess would be that aarch is mainly tested in a cross-compile situation... what kind of erros do you get ? Apr 12 15:16:41 gtristan: most people run the builds on x86 hardware. Building directly on aarch64 isn't tested afaik Apr 12 15:17:03 gtristan: in theory it could be made to work but I've not seen such patches Apr 12 15:17:48 I see Apr 12 15:21:03 boucman_work, I've seen a couple errors so far, one of them was that I needed to split gcc-cross-initial.inc do_compile() into 2 separate makes... it seems for some reason make all-gcc configure-target-libgcc doesnt sort itself out so that configuring libgcc is only done after the in-tree gcc is built Apr 12 15:22:26 another was when configuring glibc localedef (cross-localedef-native I think)... needed to have --build=arm-64-linux to pass configure Apr 12 15:22:50 and then I hit another which was a failure to apply a patch Apr 12 15:24:01 well, in any case, this clears things up a bit; I was worried that I was trying to build the wrong thing or such, but if it's not known at all to build from aarch64 then I suppose this is normal Apr 12 15:24:46 I will either A.) Find an alternative or B.) Return with those patches :) Apr 12 15:25:37 :) Apr 12 15:25:56 can't you cross compile on x86 ? (asking as a curious bystander, mainly) Apr 12 15:26:47 gtristan: what distro is on your arm64 builder? (just curious) Apr 12 15:27:45 vmeson, its an Ubuntu 16.04 distro Apr 12 15:29:45 boucman_work, I theoretically could do that to prepare the base runtime environment yes, it's one of the things I'll have to consider Apr 12 15:32:08 once the base runtime is built, we shove it into an ostree repo and build against that output, that part we would prefer to do in a native way Apr 12 15:32:20 at one point Marcin tried to build it on fedora/aarch64 Apr 12 15:32:29 IIRC he succeeded Apr 12 15:32:31 so I guess that base runtime could be built from somewhere else Apr 12 15:32:46 but mainly we use x86 based machines for build Apr 12 15:32:51 we might have regressed Apr 12 15:33:08 Yeah we actually tried to run Fedora but for now there is no support for the m400 cartridge (board) until F24 Apr 12 15:33:57 are you building aarch64 on aarch64 Apr 12 15:34:15 if its native builds Apr 12 15:34:24 you can use other frameworks too Apr 12 15:34:25 Yes, and also plan to build armv7 on aarch64 Apr 12 15:34:35 OE/Yocto rocks on cross builds Apr 12 15:34:45 when build host != target Apr 12 15:35:09 what are you needing to build ? Apr 12 15:35:12 apps Apr 12 15:35:17 or full platform Apr 12 15:35:40 something in between the both of those :) Apr 12 15:35:52 explain a bit more Apr 12 15:36:00 So yeah a whole runtime platform and also app "bundles" Apr 12 15:36:12 which are like apps but with some dependencies packaged together Apr 12 15:36:26 OK Apr 12 15:36:37 something like container ? Apr 12 15:36:50 so there is a versioned runtime environment which goes down to glibc/gcc runtimes, then there are SDK runtimes which sit on top of that, and bundles Apr 12 15:37:04 yes, it's for the xdg-app project Apr 12 15:37:14 You could just use something like lxc or docker Apr 12 15:37:16 no ? Apr 12 15:40:01 essentially I understand that you are are like a statically linked app Apr 12 15:40:23 khem, indeed, we can certainly use something else, I just have to take some time to consider which approach is right and talk it through with the others Apr 12 15:40:33 shush we like xdg-app Apr 12 15:40:36 as they use yocto Apr 12 15:40:37 \o/ Apr 12 15:40:46 hehe :) Apr 12 15:41:46 while I intend for world dominion .. sometimes it may not be right thing Apr 12 15:41:50 :) Apr 12 15:42:18 gtristan: if you were doing cross builds then it would be ideal to use Yocto to generate feeds Apr 12 15:42:20 :D Apr 12 15:42:22 and use them Apr 12 15:42:39 afaiu, xdg-app basically builds an environment using OE which contains the base platform Apr 12 15:43:13 we can generate container images using OE for such usecases yes Apr 12 15:43:38 or if you are using same architecture across build and run host Apr 12 15:43:51 other infras become interesting Apr 12 15:44:33 gtristan: basically, aarch64 as a host *should* work out of the box, if it doesn't its a bug and patches are welcome. Apr 12 15:44:54 obviously until aarch64 actually existed there wasn't a real alternative to x86 hosts, so it was never tested Apr 12 15:46:35 I am having trouble adding x11 to IMAGE_FEATURES for the image core-image-base. When I do the boot freezes immediately with no error messages. Is there a conflict that I do not know about between x11 and core-image-base? Apr 12 15:47:23 rburton1: so I tried various patches with with poky 2.0 to get qemu-native to build and it failed. I tried the 2.0.1 tarball it failed. Now, I have tried the git clone with jethro branch and it fails as well. libSDL devel not found even though its installed. Apr 12 15:47:51 I see the praticallity of kergoth's approach to simply comment out the requirement as valid. Apr 12 16:02:34 riz__: core-image-base boots to a console, so if you want graphics look at core-image-x11 for examples Apr 12 16:03:07 davis: sounds like you've still got an assume provided =libsdl-native still in your local.conf, the git branch will build its own libsdl-native and not use the hosts Apr 12 16:04:13 rburton: Thanks. I guess that is what I am misunderstanding. I don't mind booting to a console, but I just want it to run a sample Qt application. Can I not add the x11 feature from a console without having a desktop UI based image? Apr 12 16:04:50 Eventually I just want to boot straight to my application Apr 12 16:04:57 well to be honest base + x11 bits should boot into x Apr 12 16:05:09 so if you want more help you'll have to say what the problem is instead of "it breaks" Apr 12 16:05:58 Once it boots it says "booting..." and just stays there Apr 12 16:06:02 there is an x11 base image feature Apr 12 16:06:03 There are no error messages Apr 12 16:06:04 also not sure what you mean by 'desktop UI based image', but core-image-x11 isn't gnome :) Apr 12 16:06:06 * kergoth yawns Apr 12 16:07:12 Maybe I didnt understand what core-image-x11 is. What would be the difference between that and core-image-base + x11? Apr 12 16:07:30 davis: Apr 12 16:07:47 riz__: looking at the recipe shows the difference is adding x11-base to IMAGE_FEATURES Apr 12 16:08:09 Right. Which I have done. And then it freezes Apr 12 16:08:26 I will try again just to make sure the image wasnt corrupted Apr 12 16:08:29 Brb Apr 12 16:10:41 Btw, who here was at YDD? It would be nice to know the faces behind the names haha Apr 12 16:11:47 * fray presented in the advanced class on PR Server and useradd stuff Apr 12 16:12:07 Ahh. I was front row in the beginner class Apr 12 16:12:45 riz__: belen did the Toaster demo :) Apr 12 16:13:45 Oh lol. I remember you. There wa sa slight hiccup with the projector :) Apr 12 16:14:09 riz__: yes, that thing crashed my laptop. Apr 12 16:14:22 riz__: for testing, make sure you boot into a standard text console, rather than X. if not using systemd, this would be in /etc/inittab. If using systemd, it has a different mechanism for setting tunlevels. Apr 12 16:16:01 billr: Are you referring to booting directly to my app? Apr 12 16:17:11 riz__: no - just booting into a regular login/shell prompt. Often, when X is installed, the runlevel is changed to try and start X on boot. You don't want that for now. Apr 12 16:18:11 Oh. You are saying that could be the cause for it freezing? Apr 12 16:18:15 Ill look into that Apr 12 16:19:03 Yes. It often is. If there's video driver problems, it can hang the system. I've been that route many times. :) Apr 12 16:23:27 billr: Awesome. Thanks! Apr 12 16:26:03 riz__: if that works, and you get normal login window, then you can try starting X manually from the command line to see what happens. Also, if /var/log is persistent on your target, look for /var/log/Xorg.0.log which will be the X11 log and give much useful information. Apr 12 16:27:43 billr: Will do Apr 12 16:29:47 riz__: good luck, and let us know how it goes. Apr 12 16:29:58 thanks! Apr 12 16:31:07 riz__: you're welcome. I spent many years writing X11 video drivers, so I've been through it a few times. :) Apr 12 16:33:22 billr: This might be a dumb question, but how is it tied to EGLFS, specifically in terms of runnning Qt apps? Basically I am seeing that x11 is needed to run example apps, but I thought that they were separate. Apr 12 16:34:11 riz__: define it. if surely if you're using EGL you don't need x11? Apr 12 16:34:13 riz__: Qt is just an application toolkit that runs on top of X. Apr 12 16:34:43 riz__: unless it's built to run on top of SDL... Apr 12 16:35:23 which it often is, in embedded systems, in which case as ross says, you don't need X.\ Apr 12 16:35:33 Well I know for certain boards (e.g. wanboard) you need to remove x11 for certain examples to work. Apr 12 16:37:09 I could see where Qt+SDL could conflict with X11. Apr 12 16:38:08 if they're both trying to talk to the video h/w Apr 12 16:38:20 I see Apr 12 16:38:54 I have some reading to do Apr 12 16:43:18 riz__: http://doc.qt.io/qt-5/embedded-linux.html (if you haven't already read it) Apr 12 16:45:52 billr: I did read it. I didn;t fully understand it, but I am learning as we go. I dont knownhow to determine whether x11 is required or not. Apr 12 16:50:02 riz__: when using Qt5 and EGLFS, and an application built for Qt5 X11 should not be required. If you have other example apps that don't use Qt and use some other X toolkit, then you would likely need X11. One way to determine is to run 'ldd' on the application and see if it requires libX11.so. Apr 12 16:51:07 riz__: that's my understanding, at least. I've not personally used EGLFS before. Apr 12 16:53:42 billr: Right. ldd might be useful for me to try now. Apr 12 17:17:42 rburton1: I noticed the conf file had that line commented out in a similar fashion to one of the patches. Apr 12 17:18:02 rburton1: i deleted my entire work dir and I am retrying it again. Apr 12 17:18:15 perhaps i had some artifacts left around. Apr 12 17:22:28 actually I went back to double check. I did have it still in the normal build dir. the vendor one .build where I edited it. was overwritten. Apr 12 17:22:55 my mistake. i'm going to restart it once more with a removed build/.build dir Apr 12 17:25:45 davis@lemonvo:~/progs/tiotop/stream/unpack/packages/src/build/.build-yocto$ grep ASSUME ../conf/local.conf Apr 12 17:25:48 #JFD ASSUME_PROVIDED += "libsdl-native" Apr 12 17:25:50 see how it goes this time. Apr 12 17:26:34 billr: Have you ever run into the problem where you run an app using EGL and it says "Could not open display"? Apr 12 17:27:08 davis: just run bitbake -e | grep ASSUME_PROVIDED= and make sure libsdl-native isn't listed Apr 12 17:27:41 sounds good. i'll give it a shot. Apr 12 17:28:01 bitbake -e is always the best way to make sure variables are set the way you think they are Apr 12 17:28:34 btw, I heard at the dev day that bitbake -f foo is bad practice. Is the preferred way to delete a timestamp or something to rebuild a completed step? Apr 12 17:28:57 riz__: not directly, but typically, with X11, that means the xserver could not properly configure the video h/w or the xserver is not running. Apr 12 17:28:58 -f foo won't actually do anything Apr 12 17:29:05 -f without -c will be almost entirely useless Apr 12 17:29:27 hmm. ok this is weird Apr 12 17:29:36 i stopped the build and did as you suggested Apr 12 17:30:04 im going to make a pastebin Apr 12 17:31:04 riz__: did you mean EGLFS? There can be a difference between something built for EGL and something built for EGLFS. Apr 12 17:31:35 Yes, sorry. EGLFS Apr 12 17:32:07 https://gist.github.com/netskink/11a91afa7cc0d0869e77ca0c01e91db2 Apr 12 17:33:18 I don't see a problem there Apr 12 17:33:24 libsdl-native isn't in ASSUME_PROVIDED Apr 12 17:33:46 bitbake -e shows all the metadata, including functions. all the lines but the ASSUME_PROVIDED= are parts of functions Apr 12 17:34:00 which is why i said grep ASSUME_PROVIDED=, not grep ASSUME_PROVIDED Apr 12 17:34:49 riz__: environment variable QT_QPA_EGLFS_DEBUG - When set, some debugging information is printed on the debug output. For example, the input QSurfaceFormat and the properties of the chosen EGL configuration are printed while creating a new context. Together with Qt Quick's QSG_INFO variable, this can provide useful information for troubleshooting issues related to the EGL configuration. Apr 12 17:35:23 my bad Apr 12 17:35:44 billr: Where do I set these environmnet variables? Apr 12 17:36:47 kergoth: how about qmeu-native was in assume profivded but the qemu binares cant be found in the path bit? Apr 12 17:37:09 Set it from the shell before starting your app. E.g., QT_QPA_EGLFS_DEBUG=1 myapp or export QT_QPA_EGLFS_DEBUG=1; myapp Apr 12 17:37:11 yes.. did you not see the fact that that's not actually an error message? Apr 12 17:37:26 it's a line of code, insdie a function call Apr 12 17:37:28 'status.addresult("qemu' Apr 12 17:37:53 ASSUME_PROVIDED="bzip2-native chrpath-native file-native git-native grep-native diffstat-native patch-native perl-native-runtime python-native-runtime tar-native virtual/libintl-native texinfo-native bash-native sed-native " Apr 12 17:37:57 is the only line that matters in that Apr 12 17:38:09 and the fact that it doesn't have libsdl-native Apr 12 17:38:47 billr: Is there anyway of settig this from the poky build such as its config file? Apr 12 17:40:40 no kergoth I did not know it was a message. I thought the -e was for environment. I thought eh line Apr 12 17:40:43 status.addresult("qemu-native was in ASSUME_PROVIDED but the QEMU binaries (qemu-arm) can't be found in PATH") Apr 12 17:40:44 riz__: I believe so (adding it to a system-wide rc file), but I'm sure off the top of my head how it would be done. Apr 12 17:40:56 was a stack trace or something from bitbake running. Apr 12 17:41:00 nope Apr 12 17:41:01 ^sure^not sure^ Apr 12 17:41:01 billr: I actually did an ldd on the app and saw that it does depend on libX11.so, so I have to see what about x11 is freezing my image using the method you mentioned before prior to moving on. Apr 12 17:41:09 like i said, that was grepped out of hte contents of functions Apr 12 17:41:18 [10:33:48] bitbake -e shows all the metadata, including functions. all the lines but the ASSUME_PROVIDED= are parts of functions Apr 12 17:41:23 it has a message line in the envirnement? Apr 12 17:41:46 if you want to see it in context, run bitbake -e | less and search for ASSUME_PROVIDED Apr 12 17:42:49 hmm. it has an entire python function in there. multiple ones in fact. Apr 12 17:43:23 yes, which is what i've told you like 3 times now Apr 12 17:43:28 bitbake -e dumps all metadata, including functions Apr 12 17:44:40 lol, i'm slow. I missed that. I thought -e was environent as in bash variables. I did not know it is the python environment. Apr 12 18:47:42 hmm so I have git Apr 12 18:47:50 repo Apr 12 18:47:55 disappear a branch Apr 12 18:48:07 but I do have it as tarball on pre mirror Apr 12 18:48:13 should git fetcher get it to me Apr 12 18:58:22 assuming some rogue script deleted it ; the commits will still be there, and if they are in your scrollback history from a "git show" or similar, you can just check it out Apr 12 18:58:34 git checkout -b branchname Apr 12 18:58:55 note that the above won't restore any upstream tracking info tho. Apr 12 18:59:41 if someone deleted it and then did a garbage collect, _then_ it may be really gone, gone. Apr 12 19:00:46 also the file .git/FETCH_HEAD may list the commit ID of the vanished branch Apr 12 19:01:34 basically it is really hard to permanently vanish a branch ; you have to work at it ; which is a good thing most times... :) Apr 12 19:14:15 billr: OK, got it working. I saw the dependency on x11, but when using x11 in IMAGE_FEATURES it froze as I said. When using x11_base in image features it worked for some reason. Next thing to do is to understand why :) Apr 12 19:32:56 riz__: happy to hear you got it working! I think the key is, just saying "x11" is not sufficient because it doesn't really pull in all the dependencies required to get a running system, whereas x11_base forces a bunch of other packages to be included. Apr 12 19:34:23 billr: Yup, its what I figured, but I am gonna dive deeper so I understand what those dependencies are. Apr 12 19:34:47 Thanks for the help today! Apr 12 19:35:23 riz__: you're quite welcome, glad I was able to help Apr 12 20:08:16 Where in yocto do I set the kernel configuration variables such as "CONFIG_INPUT_INPUT = y" to enable uinput? Apr 12 20:09:12 riz__: via bbappend on kernel recipe Apr 12 20:10:04 if you look at linux-yocto_xx.bb you will see some .cfg and .scc files Apr 12 20:10:43 you can set the options by adding this files Apr 12 20:11:01 Right. I see the functionality flags Apr 12 20:11:18 so I make a linux-yocto_xx.bbappend and I can just set the variable there? Apr 12 20:11:40 or you can use the variable KERNEL_EXTRA_FEATURES Apr 12 20:11:50 riz i'm not an expert, but it appears you are using a yocto kernel so you can use kernel fragments Apr 12 20:12:17 you can look at yocto kernel repository Apr 12 20:12:23 you can create a dir with a file in it for your specific kernel config mods Apr 12 20:12:45 and see if your options is already in a kernel_extra_feature Apr 12 20:13:41 OK. Let me explore the options. Brb Apr 12 20:20:49 riz__: you can look at https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.14/tree/meta/cfg/kernel-cache?h=meta Apr 12 20:21:06 you can see all features Apr 12 20:21:22 so you can see if there is already a feature with the options that you want Apr 12 20:21:37 read the 00-README file Apr 12 20:22:22 OK, thanks! Apr 12 20:23:34 yay! my new build is at the stage for qemu-native and its compiling. Apr 12 20:36:06 igor: how do you check the kernel configurations to make sure the configuration yuo actually set is taken? Apr 12 20:38:17 I never looked it Apr 12 20:38:32 but I guess you can see it at build/tmp/work/.../linux-yocto... Apr 12 20:38:49 the source code shoud be there Apr 12 20:38:57 so you can look at the .config file Apr 12 20:46:28 riz__: check the value of STAGING_KERNEL_BUILDDIR then look in that directory for .config Apr 12 20:46:58 riz__: a quick way to get that is bitbake -e | grep ^STAGING_KERNEL_BUILDDIR= Apr 12 20:48:01 great. I'll try now Apr 12 20:52:40 well... I think we're off the ground for the aarch64 native builds, hit a few errors and am quite sure that most of my patches for those problems are wrong... but it's a start Apr 12 20:53:42 one thing that baffles me, is the recent addition of a patch against make 4.1, fails to apply Apr 12 20:54:04 that should certainly have nothing to do with building poky on aarch64 Apr 12 20:55:53 bluelightning: I got "STAGING_KERNEL_BUILDDIR="/home/ryan/development/custom-build/tmp/work-shared/minnowboard/kernel-build-artifacts"" Apr 12 20:55:58 But there is no .config in it Apr 12 20:56:16 riz__: has your kernel actually been built? Apr 12 20:56:27 Yes Apr 12 20:56:41 hmm, then it should be there... Apr 12 20:57:11 failing that, you can look at the one in the workdir for the kernel recipe as igor suggested Apr 12 20:57:30 bitbake -e virtual/kernel | grep ^B= Apr 12 20:58:26 (B being the directory where the recipe gets built) Apr 12 20:59:22 find build/tmp/work -name linux-yocto Apr 12 21:00:49 Yeah, nothing in there either Apr 12 21:00:53 Am I missing something Apr 12 21:01:09 When I bitbake my image, doesnt the linux-yocto kernel build? Apr 12 21:01:56 have you enabled 'rm_work' by any chance? Apr 12 21:05:37 bluelightning: Ahhhh. You got it Apr 12 21:05:44 I forgot that I did that Apr 12 21:05:59 :o Apr 12 21:06:16 well that would explain why the workdir doesn't have that file in it Apr 12 21:07:04 odd that it's missing from STAGING_KERNEL_BUILDDIR though Apr 12 21:08:37 Hmm, anyone know why archiver's do_unpack_and_patch is set to run after do_patch, but then runs do_unpack and do_patch itself? it seems like this would result in the diff_gz generation missing new files that were added by do_patch, since that ran before it, and re-running do_unpack will overwrite files, but doesn't wipe S first.. Apr 12 21:08:41 or am i missing something? Apr 12 21:12:18 It still doesnt have the filw Apr 12 21:12:20 file Apr 12 21:21:10 kergoth: archiver seems a bit messy :/ Apr 12 21:21:29 kergoth: given the other bugs I've found recently, I'm not surprised shall we say Apr 12 21:27:22 kergoth: I think the thinking was that if the archiver comes along at any time afterwards (e.g. after compilation) it can't be sure the sources are completely clean Apr 12 21:32:16 bluelightning: right, but shouldn't it run *before* do_unpack so it can capture S to S.orig before the patch is applied, rather than trying to undo it incompletely after the fact? Apr 12 21:32:35 it runs after do_patch, but then runs do_unpack and do_patch and diffs the unpacked tree to th epatched tree at that point Apr 12 21:36:55 hmmm Apr 12 21:43:09 riz__: you must cleansstate and build the linux-yocto again Apr 12 21:43:15 after remove rm_work Apr 12 21:43:55 oh ok Apr 12 21:43:56 thanks Apr 12 21:58:23 archiver seems to get real unhappy combined with externalsrc/devtool :) Apr 13 01:10:16 so in toaster, I try to create a new project Apr 13 01:10:40 so I type "gnuradio" toaster replies "Fields missing: projectversion" Apr 13 01:21:49 Crofton|work: can you please file a bug? **** ENDING LOGGING AT Wed Apr 13 02:59:58 2016