**** BEGIN LOGGING AT Fri May 09 03:00:01 2014
May 09 03:02:18 * nerdboy discovers a diversity issue in gentoo
May 09 03:43:54 <pmcgougan> Hi. I just wanted to see if anyone else is seeing something I am. We're using poky 1.5.0. If I create a linux-yocto.bbappend file and put a do_install_append function in it (even if it's empty), the kernel install step happens on every build even if nothing has been changed.
May 09 03:43:57 <pmcgougan> Has anyone else seen this? Is it a known issue?
May 09 04:14:31 <khem> pmcgougan: it should not happen
May 09 04:15:11 <pmcgougan> that's what I would have thought. But it's unfortunately 100% reproducible
May 09 04:15:58 <pmcgougan> bug I guess
May 09 04:21:12 <pmcgougan> maybe there is another way to attack the original problem? So what we are trying to accomplish is that we want to create a new-style FIT image for our kernel and it's DTB file. So in our custom layer I added a do_install_append function to a recipes-kernel/linux/linux-yocto_3.10.bbappend file that creates the uboot FIT image from the kernel and DTB. Is there a better place to do this that might then not trigger this bug?
May 09 07:49:50 <mckoan> good morning
May 09 08:07:46 <_valle_> Thanks bluelightning, solved by changing the kernel config
**** BEGIN LOGGING AT Fri May 09 08:32:12 2014
May 09 08:33:05 <bluelightning> morning all
May 09 08:51:32 <kiruthika> Hi bluelighting
May 09 08:51:51 <kiruthika> i am trying to test mesa-demos
May 09 08:53:30 <kiruthika> when i execute glxinfo i am getting  couldnt find RGB GLX visual or fbconfig
May 09 08:54:24 <kiruthika> any body has clues. I am using mesa demos and mesa driver bundled in yocto
May 09 09:01:46 <bluelightning> kiruthika: not sure I'm afraid, it's not my area of expertise
May 09 09:01:58 <bluelightning> it's likely to be specific to whatever board you are running on as well
May 09 09:03:17 <kiruthika> i checked the h/w
May 09 09:03:22 <rburton> what hardware is it?
May 09 09:03:26 <kiruthika> it used HD4500 graphics
May 09 09:03:36 <kiruthika> Kontron
May 09 09:03:42 <kiruthika> i will tell u the h/w config
May 09 09:03:49 <kiruthika> it has h/w graphics accleration
May 09 09:04:19 <kiruthika>  COM Express® basic pin-out type 6 Computer-on-
May 09 09:04:19 <kiruthika>  Module with Intel® CoreTMi7-4860EQ, 4x1.8GHz QM87
May 09 09:04:19 <kiruthika>     PCH, GT3e, 2x DDR3 SO-DIMM
May 09 09:04:31 <rburton> you probably failed to install the drivers
May 09 09:04:56 <kiruthika> i hv installed libdrm, libgl, libdrm-intel, every thing i have
May 09 09:05:03 <kiruthika> startx is working
May 09 09:05:14 <binBlob> Hi, I am here not because of yocto but because of Mr. Zanussi. I have a question about perf-script-python. Is he here ?
May 09 09:05:17 <rburton> mesa-dri-i965?
May 09 09:05:29 <rburton> binBlob: wrong timezone, he's in america
May 09 09:05:58 <kiruthika> root@x86-generic-64:~# rpm -qa | grep mesa
May 09 09:05:59 <kiruthika> mesa-driver-swrast-9.0.2-r9.1.2.1.x86_64
May 09 09:05:59 <kiruthika> mesa-dbg-9.0.2-r9.1.2.1.x86_64
May 09 09:05:59 <kiruthika> mesa-driver-i965-9.0.2-r9.1.2.1.x86_64
May 09 09:05:59 <kiruthika> mesa-driver-nouveau-vieux-9.0.2-r9.1.2.1.x86_64
May 09 09:05:59 <kiruthika> mesa-driver-r200-9.0.2-r9.1.2.1.x86_64
May 09 09:06:01 <kiruthika> mesa-driver-radeon-9.0.2-r9.1.2.1.x86_64
May 09 09:06:03 <kiruthika> libgl-mesa-9.1.3-r0.x86_64
May 09 09:06:05 <kiruthika> libgl-mesa-dev-9.1.3-r0.x86_64
May 09 09:06:07 <kiruthika> libgles1-mesa-9.1.3-r0.x86_64
May 09 09:06:09 <kiruthika> libgles2-mesa-9.1.3-r0.x86_64
May 09 09:06:13 <kiruthika> libgles3-mesa-dev-9.1.3-r0.x86_64
May 09 09:06:15 <kiruthika> libgles1-mesa-dev-9.1.3-r0.x86_64
May 09 09:06:17 <kiruthika> libgles2-mesa-dev-9.1.3-r0.x86_64
May 09 09:06:19 <rburton> yeah, mesa-driver-i965
May 09 09:06:19 <kiruthika> mesa-demos-8.0.1-r4.x86_64
May 09 09:06:21 <kiruthika> mesa-demos-dev-8.0.1-r4.x86_64
May 09 09:06:23 <kiruthika> mesa-dev-9.1.3-r0.x86_64
May 09 09:06:25 <kiruthika> mesa-driver-i915-9.1.3-r0.x86_64
May 09 09:06:27 <kiruthika> libegl-mesa-9.1.3-r0.x86_64
May 09 09:06:29 <kiruthika> mesa-driver-swrast-9.1.3-r0.x86_64
May 09 09:06:31 <kiruthika> let me know if i am missing anything
May 09 09:06:37 <kiruthika> shall i share the x server logs with you
May 09 09:06:49 <rburton> knowing what BSP you used would be helpful too
May 09 09:07:09 <kiruthika> this is our customized BSP
May 09 09:07:20 <kiruthika> but we have taken all packages from yocto
May 09 09:07:35 <kiruthika> we did not add anything extra for graphics part
May 09 09:08:25 <rburton> as long as you based it on a bsp that does in fact support that hw
May 09 09:08:43 <rburton> the genericx86 bsp should just work on that hardware, fwiw
May 09 09:09:05 <kiruthika> ok
May 09 09:09:40 <kiruthika> shall i share the Xserver logs
May 09 09:36:41 <_valle_> bluelightning: Solved the problem yesterday with change of the kernel config, thank you
May 09 09:36:49 <bluelightning> _valle_: great!
May 09 09:36:51 <bluelightning> np
May 09 09:49:58 <kiruthika> am i missing anything
May 09 09:50:17 <kiruthika> in userland or kernel side for graphics acceleration to work
May 09 09:52:26 * nerdboy 's new boss: "looks like i'll get a (rather trivial) patch into 3.15..."
May 09 09:52:38 <nerdboy> trivail...  sheesh...
May 09 09:52:50 * nerdboy losing keys
May 09 09:56:14 <rburton> kiruthika: please share any relevant logs
May 09 10:42:13 <kiruthika> installing xserver-xorg-extension-glx-1.14.0-r8.1.1.x86_64.rpm solves the problem for me
May 09 10:42:24 <kiruthika> now i am getting graphics acceleration
May 09 10:45:21 <rburton> yeah not having GLX would be a problem if you want GLX :)
May 09 10:48:26 <LetoThe2nd> yeah like not havin time and money is a problem if you want time and money.
May 09 13:03:03 <seezer_> hi. i'm trying to use libav from poky/dora. to be actually usable together with depending software, i'd need the libav*-dev headers "native". is there any way to do that with that generic (0.8.8) recipe?
May 09 13:05:16 <bluelightning> seezer_: when you say "depending software" you mean software for the target? or for the build host?
May 09 13:05:50 <seezer_> software for the target yes
May 09 13:06:22 <bluelightning> ok, so when we build libav (or indeed any library), the headers and library files go into the sysroot
May 09 13:06:37 <bluelightning> in tmp/sysroots/<machine-arch>
May 09 13:07:04 <bluelightning> if your depending software is correctly configured at build time to look there, then it should be able to build properly
May 09 13:08:31 <seezer_> hm you're totally right.. i guess i failed to set that.. sorry for the noise and thank you very much ;)
May 09 13:28:56 <bluelightning> seezer_: no worries
May 09 13:47:09 <seezer_> bluelightning: is there a common variable i could use? i'm a little irritated because i never specified the sysroot include paths for other (working) applications yet
May 09 13:47:32 <bluelightning> sure, there are a number of variables depending on which directory you need
May 09 13:48:19 <bluelightning> e.g. STAGING_LIBDIR, STAGING_INCDIR
May 09 13:48:28 <bluelightning> STAGING_DATADIR
May 09 13:48:59 <bluelightning> search for one of those in meta/conf/bitbake.conf and you will see all of the definitions
May 09 13:49:02 <seezer_> are those documented anywhere?
May 09 13:49:08 <seezer_> ah i see ;) thanks!
May 09 13:49:50 <bluelightning> sadly we don't currently have those in the variable reference, we definitely should
May 09 13:56:09 <seezer_> bluelightning: can you also tell me what mechanism causes libs to be deployed into sysroots/*? i'd like to use that for my own libs/headers too
May 09 13:56:31 <seezer_> or is that done for each lib in do_install or something
May 09 14:00:48 <seezer_> hm strange.. some of my own packages end up there, another doesn't.. all only state their FILES_${PN}
May 09 14:08:03 <seezer_> you're right.. i broke it..
May 09 14:20:02 <bluelightning> seezer_: it's automatic from what you install within do_install
May 09 14:20:55 <bluelightning> we are selective about which directories are staged to the sysroot from that, but it covers standard library, include and shared data directories
May 09 14:50:48 <volker-> I run into a strange problem on installation. I recreate the partition and format/dd it then. Now that script is executed via .bashrc hack on auto-boot and fails on the partition schema (because somehow it the formating is not done). but exiting the shell (which will respawn the login) and it works. manual execution: works, just the first time always fails
May 09 15:01:45 <binBlob> Hi, I was here asking for Mr. Zanussi some hours ago. Is he here at this moment ? I have some questions about perf-script-python.
May 09 15:06:15 <dvhart> binBlob, does not appear so
May 09 15:07:05 <binBlob> dvhart: At which times is he usually here ?
May 09 15:08:27 <dvhart> I don't know that he has a specific schedule
May 09 15:09:29 <binBlob> dvhart: Ok thanks, I guess writing a maill will be better than.
May 09 15:20:02 <tomz2> Hi, I guess someone was looking for me (Tom Zanussi)
May 09 15:20:46 <rburton> tomz2:  binBlob was, but he just left!
May 09 15:20:52 <rburton> he'll write a mail, apparently.
May 09 15:21:19 <rburton> (he was also here at about 10am BST, so there's minimal timezone overlap)
May 09 15:21:30 <tomz2> rburton: oh, i see, binBlob
May 09 15:21:46 <tomz2> ok, i'll wait for something from binBlob
May 09 15:21:52 <tomz2> rburton: thx
May 09 15:45:26 * mckoan has a MinnowBoard and a DE3815TYBE on his desk at last :-D
May 09 16:00:14 <scottrif> halstead: ping
May 09 16:00:44 <halstead> scottrif: pong
May 09 16:01:40 <scottrif> halstead: private
May 09 16:02:07 <halstead> scottrif: pm is fine.
May 09 17:11:04 <Prasad> hello guys!
May 09 17:11:59 <Prasad> i have a simple question about Linux distribution creation.
May 09 17:12:06 <nerdboy> howdy
May 09 17:12:22 <volker-> Prasad: we can't answer questions we do not know :)
May 09 17:12:32 * nerdboy still has questions about life, the universe, and everything...
May 09 17:12:34 <Prasad> i was searching on google for creating a debian based distribution
May 09 17:12:50 <nerdboy> debootstrap is your friend...
May 09 17:13:07 <Prasad> and one of member form LFS group here i can get help for it.
May 09 17:13:23 <Prasad> i want to create a debain based OS.
May 09 17:13:30 <Prasad> i want to make it from scratch
May 09 17:13:34 <volker-> mckoan|away: where did you order the DE3815TYBE>
May 09 17:14:01 <Prasad> is it possible and are their any tutorial for it.
May 09 17:14:12 <volker-> Prasad: Yocto does not create debian distributions. the only thing you can do is creating an OWN NOT-debian based distribution from scratch that has and supports .deb packages
May 09 17:14:12 <nerdboy> Prasad: if you can boot it with anything that will run deboostrap you should be good to go
May 09 17:14:29 <nerdboy> not really the right channel for that topic...
May 09 17:14:42 <Prasad> ok
May 09 17:14:46 <nerdboy> i'm sure #debian has some helpful people
May 09 17:14:48 <volker-> Prasad: if you want a debian based distribution, try #debian :)
May 09 17:14:53 * nerdboy crosses fingers
May 09 17:15:05 <Prasad> thanks then i will try to find a right channel to get answer for this
May 09 17:15:13 <Prasad> and thanks for the chaneel name
May 09 17:15:14 <nerdboy> deboostrap!
May 09 17:15:55 <nerdboy> <ahem>
May 09 17:17:16 <volker-> since I work with the NUC I see kernel panics again
May 09 17:17:23 <volker-> I thought we are past that issues.
May 09 17:17:52 <Prasad> volker- as you said " Yocto does not create debian distributions. the only thing you can do is creating an OWN NOT-debian based distribution from scratch that has and supports .deb packages" so can Yocto help me to create my distribution
May 09 17:18:19 <volker-> Prasad: yes, but for regular systems you still might check in the #debian channel
May 09 17:18:49 <volker-> Prasad: yocto is more for really small images and embedded systems and more learning/timeconsuming as a small modified debian distribution
May 09 17:18:59 <Prasad> no actually i am interested in my own distribution
May 09 17:19:21 * nerdboy guesses maybe a native apt environment might be a good first step
May 09 17:19:25 <Prasad> i have allready worked with LFS...
May 09 17:19:31 <volker-> Prasad: http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html
May 09 17:20:20 <nerdboy> Prasad: i'm gonna go out on a limb here and say debootstrapping debian arm is the easier/faster way to get started
May 09 17:20:39 <nerdboy> *then* maybe build your own with yocto
May 09 17:21:05 <nerdboy> plus you need a working kernel/bootloader either way, so...
May 09 17:21:12 <Prasad> sure i will try out debootstrapping
May 09 17:21:26 <Prasad> actually i have a LFS system running...
May 09 17:21:44 <nerdboy> if there's a reasonably recent/maintained oe layer for your machine...
May 09 17:22:16 <nerdboy> then maybe not so bad, otherwise making your own will take some time...
May 09 17:22:33 <Prasad> ok
May 09 17:22:57 <nerdboy> i guess it depends on how you want to split your time
May 09 17:23:20 <nerdboy> build/deploy or doing things on your machine
May 09 17:24:05 <Prasad> lfs is good but the problem is that it does not support new application
May 09 17:24:17 <kergoth> some days I wish it was possible to use yocto in a native bootstrap approach the way other distros do, since it still has value above what other distros provide, in its orthogonal approach to distro/machine/image. would be nice to handle both
May 09 17:24:48 * nerdboy didn't think he was finished yet
May 09 17:25:30 <nerdboy> i was about to revert and say "read the yocto docs on making a BSP"
May 09 17:27:08 <volker-> nerdboy: how do you install your images?
May 09 17:27:27 <nerdboy> depends
May 09 17:27:39 <nerdboy> rpi builds an sdcard image
May 09 17:28:00 <nerdboy> bbb i deploy tarball to custom-formatted microsd
May 09 17:28:22 <volker-> ok, so no automated partitioning and deployment
May 09 17:28:33 <nerdboy> i'll make bbb image class one of these days...
May 09 17:28:52 <nerdboy> the rpi bbclass does all that
May 09 17:29:31 <volker-> that bigger NUC here always looses its default-boot-from-usb setting. even with the latest bios
May 09 17:29:58 <nerdboy> https://github.com/VCTLabs/meta-raspberrypi/blob/master/classes/sdcard_image-rpi.bbclass  <=  you mean like that?
May 09 17:30:44 <volker-> nerdboy: no, based on the actual rotating disk size at the installation step
May 09 17:31:00 <nerdboy> ah
May 09 17:31:10 <nerdboy> way more specific...
May 09 17:31:42 <bluelightning> there is also wic these days
May 09 17:32:14 <bluelightning> it uses kickstart files to define partition layouts
May 09 17:33:03 <volker-> bluelightning: wic is only on the image level if I see it correct
May 09 17:33:39 <kergoth> it's for creating the disk image including partitioning / rootfs split by path and bootloader stuff
May 09 17:33:44 <kergoth> seems quite nice for that
May 09 17:34:37 <volker-> kergoth: yes, but from my understanding it is not dynamic about the size. e.g. if you have something like |rootfs|data-with-variable-size-depending-on-disk|
May 09 17:40:30 <nerdboy> the image bbclass thing does expect someone to do something with the leftover space
May 09 17:40:58 <nerdboy> make another partition, expand the rootfs partition, whatever
May 09 17:41:16 <nerdboy> i suppose you could just leave it unused, but...
May 09 17:57:57 <kergoth> sigh, we're missing parity between volatiles and tmpfiles.d still
May 09 17:58:05 <kergoth> afaict systemd builds are still missing /run/lock
May 09 19:11:16 * nerdboy liked it better when /run was not persistent
May 09 19:41:13 <kergoth> RP: I have a case where a couple vars are added to the hashbase whitelist, yet defining/exporting them through from the shell environment (via BB_ENV_EXTRAWHITE) still alters checksums relative to a build without them set in the shell environment, according to -S printdiff.
May 09 19:42:37 <kergoth> I'm guessing that even if their *value* isn't affecting checksums, whether they exist at all *is*, due to the change of the dependency list of the shell tasks, but this seems wrong to me
May 09 19:42:38 <kergoth> hmm
May 09 19:42:57 * kergoth digs
May 09 19:44:37 <kergoth> Hmm, it's possible -S printdiff is reporting that even though it's not changing the checksums. verifying that now..
May 09 19:44:49 <kergoth> if so it means -S printdiff doesn't accurately reflect whether bitbake will use the sstates
May 09 19:51:48 <volker-> how can I get a shell variable to be exported to the do_configure command execution?
May 09 19:52:02 <rburton> volker-: "export"
May 09 19:52:39 <volker-> rburton: oh
May 09 19:57:05 <volker-> somehow "export P4PASSWD" does not work, while export P4PASSWD='manualset' works
May 09 19:58:13 <kergoth> volker-: i'd suspect bitbake is currently incorrectly doing a 'if value: ' when exporting, so a var set to the empty string doesn't get exported at all, whereas we really only want to not export if it's not set at all (if value is not None)
May 09 19:59:51 * kergoth fights coffee shop wifi
**** ENDING LOGGING AT Sat May 10 02:59:59 2014