**** BEGIN LOGGING AT Wed Jun 11 02:59:59 2014 Jun 11 06:13:25 Are there any known issues with quilt-native/chrpath on Ubuntu? Jun 11 06:13:38 (12.04 LTS) and Dora? Jun 11 06:29:49 RP: how can I see the output of a bb.note from within a python routine? Jun 11 06:30:32 RP: it is not printed to my pty, it doesn't show up in the log file. I am semi-confident that the code got executed Jun 11 06:32:10 looks like I had to nuke the cache too Jun 11 07:34:15 good morning Jun 11 07:54:30 hi all :) Jun 11 07:55:15 anyone have time for a quick q? i'm trying to make an initrd/initramfs-based rootfs.cpio.gz - it builds okay, but includes the zImage which I obviously don't want Jun 11 07:55:30 how can I ensure the kernel image ends up in tmp/deply/zImage, but won't be part of the rootfs? Jun 11 07:58:22 rink_: looking at kernel.bbclass, RDEPENDS_kernel-base = "" looks like it might help Jun 11 07:58:44 hmm I also just noticed it was part of IMAGE_INSTALL_append = "kernel" Jun 11 07:59:04 is it safe just to 'rm -rf tmp' and bitbake the image again to be sure it builds what I need? Jun 11 07:59:58 rink_: that dependency won't help, yes Jun 11 08:00:24 rink_: should be safe although even if you don't do that, it should adjust to the changes Jun 11 08:01:00 Well, for your platform, I need a separate kernel, rootfs and devicetrees, combined in a single custom image Jun 11 08:01:07 s/your/our/ # doh Jun 11 08:04:27 rink_: shouldn't be a problem, its just a matter of configuration. if you change the image configuration, it should get accurately regenerated as per the change Jun 11 09:01:47 morning all Jun 11 09:29:13 hmm, I've added custom image_type, with IMAGE_CMD_custom = ..., but it isn't buitl Jun 11 09:29:31 the .bbclass is built, however Jun 11 09:30:45 uhm ,i mean, it is processed Jun 11 09:41:48 rephrase Jun 11 09:42:03 I've made classes/image_type_sys.bb Jun 11 09:42:15 added it using IMAGE_CLASSES += "image_type_sys" in the machine.conf file Jun 11 09:42:18 the .bb is processed Jun 11 09:42:44 the machine.conf contains IMAGE_FSTYPES = "sys" Jun 11 09:43:03 however, the IMAGE_CMD_sys = "..." command in the image_type_sys.bb file isn't called Jun 11 09:43:04 why not? Jun 11 09:46:56 http://cgit.openembedded.org/openembedded-core/tree/meta/classes/image_types.bbclass#n128 Jun 11 09:47:00 rink_: ^ Jun 11 09:47:21 isn't that exactly what I am doing? Jun 11 09:47:38 note IMAGE_TYPES = Jun 11 09:48:10 hmm, my 'sys' type shows up in bitbake -e |grep ^IMAGE_TYPES Jun 11 09:49:08 so why is it ignoring the IMAGE_CMD_sys = "..." thing completely ? how can I find what it does? Jun 11 09:51:06 you have to check the logs and the run. files in the image workdir Jun 11 09:54:10 this is odd Jun 11 09:54:18 the command _does_ get executed after a cleansstate Jun 11 09:54:52 how does yocto decide that the command should be run? Jun 11 09:55:40 short version: if the checksum of the task has changed Jun 11 09:56:58 btw, it is bitbake and not Yocto Jun 11 09:56:58 hmmm, I don't see a means to tell my image recipe what the output file is Jun 11 09:59:25 what do you mean by output file? Jun 11 09:59:32 what kind of filesystem? Jun 11 09:59:55 i'm making a TAR file of the kernel, the initrd, the boot script and the device tree Jun 11 10:00:40 ah that's what you want to do... Jun 11 10:00:51 odd thing is Jun 11 10:01:01 now that I've run cleansstate, it will rebuild the file as needed Jun 11 10:03:01 you ran bitbake yourimage -c cleansstate and now it works? Jun 11 10:03:22 yes Jun 11 10:07:20 it seems that bitbake doesn't recognize a new IMAGE_CMD_ it automatically, it probably decided to not run do_rootfs alltogether since you ran it before already and didn't change the image recipe Jun 11 10:08:24 sometimes it can be a little difficult with the whole dependecy chains and stuff, especially with features like IMAGE_CMD_ or thelike. Jun 11 10:09:02 I can imagine that :) Jun 11 10:10:01 hmm it never even seems to rebuild the IMAGE_CMD_ ... likely because the input hasn't changed Jun 11 10:10:56 I think the IMAGE_CMD is part of the do_rootfs task and if thatone isn't run then so is the IMAGE_CMD_ Jun 11 10:11:26 You can probably force it with bitbake yourimage -c rootfs -f Jun 11 10:11:59 If you know everything up to that point is already as it should be Jun 11 10:15:27 thanks! Jun 11 10:16:12 bluelightning: ping? Jun 11 10:19:24 hhmmm after deleting 'tmp' my deploy directory is almost empty :( Jun 11 10:19:26 save for modules-* Jun 11 10:19:28 *sigh* Jun 11 10:21:36 Denwid, and after doing the -c rootfs -s line, I don't have my own tar file but the rest is built Jun 11 10:21:37 this is off Jun 11 10:21:41 *scratches had* Jun 11 10:21:45 head, even Jun 11 10:29:22 mhh did you have a look at the logs in tmp/work/*/yourimage/temp? Jun 11 10:30:58 need to be afk, will have a look afterwards Jun 11 10:31:05 Denwid, ant_work, thanks! Jun 11 11:38:48 when running GST_DEBUG=5 with my application, I do see full path of where GStreamer was built Jun 11 11:38:54 0:00:00.003091334 941 0x261200 DEBUG GST_MEMORY /data/BoundaryDevices/yocto/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/gstreamer1.0/1.2.4-r0/gstreamer-1.2.4/gst/gstallocator.c:586:_priv_gst_memory_initialize: memory alignment: 7 Jun 11 11:39:04 is there a way to remove that path, bevause it makes GST Logs hard to read? Jun 11 11:39:36 tobiash: sed? Jun 11 11:40:04 the log contains the source, so you either change the logging code to remove that, or sed it out before reading Jun 11 12:12:56 the same message on my PC: Jun 11 12:12:57 0:00:00.000197984 25813 0x2140a00 DEBUG GST_MEMORY gstallocator.c:586:_priv_gst_memory_initialize: memory alignment: 7 Jun 11 12:13:26 I have never seen logs with full paths before, so I assume it is some configuration of yocto / poky compiler ? Jun 11 13:16:21 otavio, help - still can't get the gpu-viv samples to be removed Jun 11 13:16:33 well, I can, but not without losing the libraries as well Jun 11 13:17:27 if anyone reads, gpu-viv-bin-mx6q_3.10.17-1.0.0-hfp.bb includes gpu-viv-bin-mx6q.inc - see http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-graphics/gpu-viv-bin-mx6q Jun 11 13:18:15 I've made a .bbappend file - see http://pastebin.com/PNgmyHtw Jun 11 13:18:32 the idea is to throw away everything in /opt/viv_samples and keep the libraries it installs intact Jun 11 13:18:47 but the result is that absolutely nothing of the gpu-viv- ... recipe is installed anymore Jun 11 13:18:48 Help! :) Jun 11 13:26:50 i wonder if the problem is that bb things: Hey, these libraries aren't needed by anything => let's remove them from the image Jun 11 13:26:55 *thinks Jun 11 13:37:36 otavio, turns out adding the lib*-mx6 specifically to IMAGE_INSTALL_append solves it for me; it was indeed deciding no one needed the libs Jun 11 13:38:30 rink_: uh? Jun 11 13:38:48 scroll up a bit? :) Jun 11 13:39:23 as before, I was having problems with removing the viv_samples directory from the installed image - this would also remove libGLES etc Jun 11 13:40:12 but adding IMAGE_INSTALL_append += 'libgles-mx6' fixes this for me Jun 11 14:10:06 RP, I have some preliminary prototype work on www.yoctodev.org/downloads for your review and shared some notes with your lf address Jun 11 14:11:48 RP, things are just roughed in right now. I won't focus on visual presentation too much until the structure and naming are right. Jun 11 14:14:49 anyone around that’s comfortable with formfactor stuff? Jun 11 14:15:11 I’m trying to figure out how to rebuild when I change a machconfig file Jun 11 14:15:19 because I’m unclear where that configuration data actually goes Jun 11 14:24:47 hi. i need to refetch a recipe (using git). so i run: bitbake linux-raspberrypi -c fetch -f Jun 11 14:25:32 umm, wait.. Jun 11 14:25:47 it seems to have worked anyway. nevermind... Jun 11 14:27:37 ok, another problem. anyone familiar with the raspberry pi bsp? i can't get "kernel_configure_variable" to work.. Jun 11 14:28:32 umm, wait ... :) Jun 11 14:39:21 bluelightning: ping? Jun 11 14:39:30 zecke: pong Jun 11 14:40:48 bluelightning: I think gmane ate my mail. Should www.yoctoproject.org/downloads/pseudo/pseudo-1.5.1.tar.bz2 lead to the pseudo sources? Jun 11 14:41:40 zecke: did you have that link from somewhere else? Jun 11 14:42:08 ah, it's in the recipe isn't it Jun 11 14:42:10 bluelightning: pseudo_1.5.1.bb in dora Jun 11 14:42:28 so the answer is yes it absolutely should Jun 11 14:42:38 bluelightning: but it looks like it is broken in master too Jun 11 14:42:57 zecke: I am filing a bug now Jun 11 14:43:11 thanks. i didn't know who to chase. :) Jun 11 14:47:26 https://bugzilla.yoctoproject.org/show_bug.cgi?id=6426 Jun 11 14:47:28 Bug 6426: major, Undecided, ---, melissa, NEW , pseudo broken download Jun 11 15:05:01 ok. anyone in the knows about meta-raspberrypi? i've created a bbappend for the kernel. i've added do_configure_prepend to it and included kernel_configure_variable to change some defaults. Jun 11 15:05:05 it doesn't work though Jun 11 15:06:17 if i understand it correctly do_configure_prepend in my bbappend is called first, and then do_configure_prepend in meta-raspberrypi. and meta-raspberrypi clears all my changes at the start... Jun 11 15:06:31 so what is the preferred way to change some kernel configs with meta-raspberrypi? Jun 11 15:08:14 ionte: is there a reason you don't do an append instead? Jun 11 15:08:51 blloyd: yes. the kernel_configure_variable simply appends to the .config file. Jun 11 15:09:41 blloyd: so if i use append i can get CONFIG_SPI_SPIDEV=y in the middle of the file, and then my "# CONFIG_SPI_SPIDEV not set" at the end of the file Jun 11 15:15:08 perhaps do a sed in an append operation? Jun 11 15:15:41 that's exactly what config fragments are designed to allow Jun 11 15:26:48 721.0K grub-sparc64-setup Jun 11 15:28:10 I’ve got a second question related to machines and formfactors: Jun 11 15:28:30 what’s the difference between enabling keyboard in MACHINE_FEATURES and setting HAVE_KEYBOARD=y in a formfactor machconfig? Jun 11 15:28:49 any enlightenment would be much appreciated Jun 11 15:29:04 machine features control what hardware the machine has and generally control things like kernel modules Jun 11 15:29:38 formfactors are unrelated and saying HAVE_KEYBOARD tells eg Sato that it doesn't need to display a virtual keyboard because you have a real one Jun 11 15:30:08 huh, okay Jun 11 15:31:05 and formfactors are chosen based on machine name Jun 11 15:31:19 okay, it looks like HAVE_KEYBOARD ends up as a bash variable Jun 11 15:31:25 which can then be used in other things Jun 11 15:32:44 ah, and formfactor/config gets called in things like sato config scripts Jun 11 15:32:47 alright, that makes sense Jun 11 15:32:48 thanks Jun 11 15:45:26 Hello, I've a simple bbappend recipe question... Jun 11 15:46:52 I'm building several images with Yocto Daisy. One use meta-ti and others only Yocto. I've created a kernel bbappend for ti-linux-staging in my own meta. Jun 11 15:47:34 Now if i want to build an image not based on meta-ti I got an error : No recipes available for... Jun 11 15:48:02 This is normal because my current build doesn't include meta-ti... how can I solve that ? Jun 11 15:48:23 Piziwate, which recipes aren't available? Jun 11 15:48:29 which image are yout rying to build Jun 11 15:48:34 which machine? Jun 11 15:48:43 he has a general layer that wants to bbappend to a bsp specific recipe, and wants to use it whether that bsp layer is included or not Jun 11 15:48:44 afaict Jun 11 15:48:48 the linux-ti-staging Jun 11 15:48:50 i've had to support that case before Jun 11 15:48:58 this is my own machine file Jun 11 15:49:05 ah Jun 11 15:49:15 yes Kergoth you're right Jun 11 15:49:16 you can split up your layer into two, one with the ti specifics and one without, or you can structure your layer to support layer-specific appends Jun 11 15:49:30 we do this in meta-mentor Jun 11 15:49:39 https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mel/conf/layer.conf#L5-L8 Jun 11 15:50:20 layer-specific appends will be a good choice... Jun 11 15:50:39 then you can create a subdir in your layer from the layer name . e.g. move your recipes-kernel/linux/linux-ti-staging_3.12.bbappend to meta-ti/recipes-kernel/linux/linux-ti-staging_3.12.bbappend Jun 11 15:50:48 that'll only be included when meta-ti is included Jun 11 15:50:52 it works quite well for us Jun 11 15:51:12 e.g. see all the layer subdirs in https://github.com/MentorEmbedded/meta-mentor/tree/master/meta-mentor-staging Jun 11 15:51:57 of course, you can always set bb_danglingappends_warnonly, but then you can miss a legitimate case where it *should* fail if the recipe goes missing but the append still exists, for example if upstream bumps a recipe version Jun 11 15:52:04 so this is a better approach than that Jun 11 15:53:09 kergoth, thanks - I learned something here today too ;-) Jun 11 15:53:17 great ! thank you kergoth ! Jun 11 15:53:25 np Jun 11 15:54:42 OT, but anyone know of a good script to backup your github repositories for a user/org? Actually, it'd be ideal to also extract issues, etc, to truly get all your data out, but a dead simple iterate-over-the-repos-from-the-github-api might be a start Jun 11 15:54:43 ls Jun 11 15:54:49 oops, wrong window Jun 11 16:38:00 bluelightning: right. i could not use fragments before, when i used the freescale bsp, but hopefully they work eith meta-raspberrypi. thanks Jun 11 16:38:13 kergoth: thanks for sharing that. That's a much more elegant solution to that headache than I had come up with. (.bbappend where .bb may not be there) Jun 11 16:38:43 np Jun 11 16:39:20 ionte: I think it depends on whether the kernel recipe does "require recipes-kernel/linux/linux-yocto.inc" Jun 11 16:39:59 FYI we have an example of a kernel recipe that supports config fragments but doesn't need the split meta branch in meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb Jun 11 16:40:18 bluelightning: yes, the freescale bsp is based on oe, not yocto Jun 11 16:40:38 ionte: the base support is available in OE-Core, it's not yocto-specific Jun 11 16:41:01 (if that means anything...) Jun 11 16:42:10 Yocto is a project to make embedded development easier Jun 11 16:42:15 repeat after me Jun 11 16:42:51 right ;) Jun 11 16:42:53 I played with the raspberry pi image a while ago (people wanted to know if we could run our stuff on raspberry and answer came back no). Anyways, I found that bsp didn't play well with modifications. It's why I suggested the sed in an append. I got that method to work to change the config, while it seemed the bsp itself works to a hardcoded .config Jun 11 16:43:38 blloyd: the answer there is to badger the maintainer to fix the issues preventing modifications (or send patches to fix them) Jun 11 16:44:14 true, or just not use it. (We aren't going to support raspberry pi so no need for that bsp) Jun 11 16:47:16 are there any examples of creating bootp images using yocto? Jun 11 17:10:18 so, is there a command in bitbake to invalidate everything after a given item? So, while working on an update to say the live-boot script, we can get that package and all images that use it cleaned? Jun 11 17:12:23 all you have to do is rebuild it. bitbake automatically erbuilds stuff that depends on it for you if their deps changed Jun 11 17:12:54 bitbake -C fetch foo; would result in rebuilding foo from scratch and then if you did a regular build that included the stuff that depends on foo, they'd be rebuilt too Jun 11 18:10:19 python installation with 9 additional python-* packages takes up a lot of space Jun 11 18:30:55 Is there a option to only pack python pyc files and not the pyo files? deleting .py and pyo halfs the size python needs Jun 11 18:34:52 good question Jun 11 18:35:10 meta/recipes-devtools/python Jun 11 18:35:16 ls|wc -l => 42 Jun 11 18:49:06 volker-: not sure the details of .pyc vs .pyo. is .pyc generic but .pyo machine specific? is .pyo machine specific but for the wrong machine? Jun 11 18:49:59 pyo is an 'optimized' pyc Jun 11 18:50:17 but there are debates about pyo if you should use it or not Jun 11 18:50:22 i know that much, what does that mean :) Jun 11 18:50:27 oh, its missing assertions and line numbers Jun 11 18:50:33 that's not much of an optimisation Jun 11 18:50:37 hell, wipe them all Jun 11 18:50:47 https://bugzilla.yoctoproject.org/show_bug.cgi?id=6434 ;-) Jun 11 18:50:49 Bug 6434: normal, Undecided, ---, richard.purdie, NEW , python packages every build output: .py, .pyc and .pyo Jun 11 18:52:39 AFAIR ubuntu ships all python files without the pyc and compiles it on installation (don't take that for granted, I think I saw it somewher ein the past) Jun 11 18:52:59 beside this, pyo are not even installed on my ubuntu system here Jun 11 18:54:36 pyo seems like a waste of time and effort Jun 11 18:55:12 yes, debian and derivs generate byte code on install, because they let you install a single .py and then symlink it into multiple python versions Jun 11 18:55:17 so it has to compile for each one Jun 11 18:55:55 volker-: fwiw, the meta-yocto component is only for the meta-yocto* layers Jun 11 18:56:03 good, at least I am note alone in the opinion that we can reduce data here :) Jun 11 18:56:22 rburton: yeah, I am not sure about that. But then the question is if meta is oe-core or if it is 'other layer' Jun 11 18:56:29 meta *is* oe-core Jun 11 18:56:37 and python is oe-core Jun 11 18:56:53 i've moved it to oe-core/devtools as the python recipes are in meta/recipes-devtools Jun 11 18:57:16 and now i need to sneak out of my daughters room with a dead foot Jun 11 18:57:28 hmmm, apparently changes to IMAGE_FEATURES or FEATURE_PACKAGE_* don't cause re-execution of do_rootfs Jun 11 18:57:36 * kergoth preps fix Jun 11 18:58:07 rburton: thanks for the info. the naming here is a little bit confusing for me because it does not match directly the directory naming Jun 11 18:58:22 oe-core/meta == poky/meta, same for scripts Jun 11 18:58:32 so the directory naming does match, just underneith toplevel Jun 11 18:58:57 oh, it doesn't match the bugzilla category, gotcha Jun 11 18:59:22 I am not familiar with oe-core. Therefore I am not sure about it Jun 11 19:00:37 wit also seems like not the entire meta-openbedded repository is provided in yocto Jun 11 19:00:48 s/wit/it/ Jun 11 19:01:26 nothing from meta-openembedded is in poky/yocto Jun 11 19:01:53 oe ~= oe-core + meta-oe + whatever else, poky ~= oe-core + meta-yocto + meta-yocto-bsp Jun 11 19:02:07 naturally you can use meta-oe with poky fine Jun 11 19:03:31 poky is the Yocto project reference distribution. OpenEmbedded is the build system :) Jun 11 19:04:18 to elaborate on kergoth's point, poky literally is oe-core+meta-yocto+meta-yocto-bsp+yocto-docs, squashed together into a single git repo using combo-tool. Jun 11 19:04:35 Crofton: i thought bitbake was the build system ;) Jun 11 19:05:27 * Crofton slaps rburton with a large trout Jun 11 19:05:58 sounds like yocto reinvented the wheel ;-) Jun 11 19:06:22 Crofton: i'm still mourning so liable to grab a frying pan/cricket bat Jun 11 19:06:36 volker-: yocto was formed around projects that have existed for ~10 years Jun 11 19:06:40 volker-, long story :) Jun 11 19:07:03 I was kidding now you guys start to argue about it ;-) Jun 11 19:07:10 volker-: it's a touchy subject ;) Jun 11 19:07:11 I use it and am fine with it. Jun 11 19:08:05 :) Jun 11 19:13:33 Yeah, yocto is just an umbrella project, and poky is a reference distro and integration of various components. people naturally get confused with all the terms and where all the pieces come from and how they fit together Jun 11 19:15:44 Ok... the yocto book release got pushed back to July... Jun 11 19:22:30 https://github.com/MentorEmbedded/meta-mentor/pull/219 /me adds to his upstream submission todo list Jun 11 19:22:44 ok, there has to be a less painful way to do this. I'm editing a package (taking several attempts to get it working properly). Used to I could just -c cleansstate on the package, and get that package and the images to rebuild. Now, with the images tracking sstate they don't rebiuld. So how do I get around this fun during the initial testing? Of course, during commit the PR is incremented, so no problems once shared. But what abou Jun 11 19:22:44 t during that initial development phase where we got images produced already so it doesn't recreate them? Jun 11 19:25:04 I don't understand the question Jun 11 19:25:46 oh, you're making changes outside of bitbake's knowledge? Jun 11 19:25:48 changes to the metadata will automatically change checksums and result in re-building recipes which depend on it, including the image Jun 11 19:26:05 you can "taint" a task to make bitbake believe it needs to rebuild it and everything after it with bitbake's -C argument Jun 11 19:26:09 that sounds like it may be what you want Jun 11 19:26:23 blloyd: I am confused. I tell you how I do it: "make -c clean ; make -c build " for development. and then a build script that updates the changes and execute the bitbake Jun 11 19:27:11 he wants to rebuild a recipe from scratch, and still rebuild the image to include those changes, explicitly, afaict Jun 11 19:27:31 it'd be better to let bitbake know about your changes, to avoid the need to manually force a rebuild entirely, but -C may get you what you want for now Jun 11 19:27:37 kergoth: should also work with the clean flag Jun 11 19:27:41 no Jun 11 19:27:47 it'll just pull from sstate and not rebuild Jun 11 19:29:08 I need to look in the newer samba soon Jun 11 19:29:16 the availableone installes 81M Jun 11 19:30:14 kergoth: so you are suggesting that each attempt should increment the PR variable? So when I submit a patch, PR could go from 11 to 21? Jun 11 19:30:41 again, if you adda patch to SRC_URI it'll rebuild and bump pr automatically, if your'e using the pr server. there's no need to force a rebuild at all in that case Jun 11 19:31:08 if you're modifying an scm repository, then you should add SRCPV to PV and use AUTOREV so bitbake picks up the change Jun 11 19:31:20 in either case, bitbake knows the source changed and knows to rebuild and bump pr automatically Jun 11 19:31:43 if you're maintaining a feed, and honestly even if you aren't, you should really use the pr server :) Jun 11 19:32:28 blloyd: it really depends on what steps you're taking outside of bitbake's knowledge, and how you can tell bitbake you're making changes. Jun 11 19:32:36 indeed Jun 11 19:32:48 kergoth: a number of items I am working on are like initramfs-live-boot. They have a source file in files subdirectory. I'm modifying that file. Thus two files get changed for patch (one to increment PR in recipe, and the source file itself). Jun 11 19:33:21 you never have to touch pr in a recipe anymore Jun 11 19:33:27 just run the pr server and get on with your day :) Jun 11 19:33:35 if the source file is referenced in SRC_URI, bitbake will detect those changes to that file Jun 11 19:33:57 sadly, if that is the case, there appears to be a bug. Jun 11 19:34:26 blloyd: don't suppose you can share the layer Jun 11 19:34:45 insufficient information to say whether thats the case or not, from our perspective :) Jun 11 19:34:48 (or replicate in a dummy recipe that you can share) Jun 11 19:35:44 so, let's use my current update as an example: meta/recipes-core/initrdscripts/files/init-live.sh Jun 11 19:37:28 I've modified that file. Then I rebuild image-restore8 (generates a .hddimg) that uses the live-boot. After file change, the build of image-restore8 gets 5825 of which 5825 didn't need to be rerun. Jun 11 19:38:24 Building core-image-sato-dev has the same behavior (which means it can be done with a base yocto installation). Jun 11 19:39:21 so the dependency from the hddimg to the live image isn't right Jun 11 19:40:03 it builds properly from an empty tmp folder. Jun 11 19:42:02 if you bitbake initrdscripts, does it get rebuilt? Jun 11 19:42:27 conveniently this can be replicated fairly simply Jun 11 19:42:29 I've actually seen a user put 2 boot disks into a system. Systems like Fedora's live boot make it where it is possible to identify which disk was used to load the root filesystem. The init-live.sh doesn't allow this, so was adding and testing (and finding issues, fixing and retesting). Jun 11 19:42:49 No kergoth. Not without the -c cleansstate or a -f. Jun 11 19:43:11 that'd be a serious problem. that's not how it's supposed to work Jun 11 19:43:16 is init-live.sh in SRC_URI? Jun 11 19:43:22 yes Jun 11 19:43:27 bitbake checksums every file:// file in SRC_URI Jun 11 19:43:30 SRC_URI = "file://init-live.sh" Jun 11 19:43:34 and includes that in the do_fetch checksum Jun 11 19:44:08 blloyd: master or daisy? Jun 11 19:44:08 what version of yocto/poky / what branch? Jun 11 19:44:11 :) Jun 11 19:44:42 blloyd: this is initramfs-live-boot_1.0.bb right? Jun 11 19:44:42 master, latest Jun 11 19:44:48 yes sir Jun 11 19:45:54 I've got build directories that use only meta-oe, yocto, and meta-intel, as well as one that uses those and my companies custom layers. Jun 11 19:46:14 c'mon disks faster faster Jun 11 19:46:27 oh, so you'd want to bitbake initramfs-live-boot and see if that rebuilds when the file changes, in that case Jun 11 19:46:45 fwiw it appears to be working here Jun 11 19:46:47 will retest Jun 11 19:47:02 its busy setscening the universe right now, presumably because its about to do stuff Jun 11 19:47:15 ok why does a kernel setscene take SO LONG Jun 11 19:47:20 I just did a git pull a little bit ago, moving forward a few days. Jun 11 19:47:34 yep, works here Jun 11 19:47:51 blloyd: try replicating with a clean poky Jun 11 19:48:17 I have one of those, due to my fun with meta-oe recently. :) Jun 11 19:48:35 so no meta-oe or meta-intel, or your own layers Jun 11 19:49:17 also, is there a better way to do something like sed -i 's#^\(1:[S123456789]*:\)respawn:/sbin/getty\(.*\)$#\1once:/sbin/getty -n -l /usr/bin/automaticrestore\2#g' "$D/etc/inittab"? Jun 11 19:51:09 Task initramfs-live-boot:do_fetch couldn't be used from the cache because: Jun 11 19:51:09 We need hash dd6928066425f1742c6114ce7da5939e, closest matching task was d8869f65dcedcf345170e804f62896c9 Jun 11 19:51:09 Checksum for file init-live.sh changed from cbe75c87da1dcd01c70660b33b144bfb to c07ecdc8d43b750e696c3591f53ad732 Jun 11 19:51:32 that's from bitbake -S printdiff initramfs-live-boot after doing a build and the changing init-live.sh Jun 11 19:51:46 so yes, it works here Jun 11 19:51:59 maybe you've a layer that's breaking something Jun 11 19:52:10 possibly its pulling another init-live.sh from a different layer :) Jun 11 19:55:32 does anyone run TPM with yocto? Jun 11 19:56:35 well, it just fired do_package, with only the file changed. That's nice. Jun 11 19:57:35 and now it's running do_rootfs for the minimal ram disk. Wonder why it was skipping them earlier. (I like the current behavior!) Jun 11 19:58:55 volker-: TPM as in in trusted stuff? there's a layer on git.yocto iirc Jun 11 19:59:23 yes, TPM the cryptochip. didn't find anything when grepping through the code Jun 11 19:59:25 blloyd: it should have started at do_fetch but that might have passed very quickly that you didn't get to see it Jun 11 19:59:34 only found something in layers.openembeeded.org Jun 11 19:59:48 meta-measured, not official layer Jun 11 20:00:15 I think it did rburton, but as you said, it runs fast (the file to "download" is on a local disk after all). Jun 11 20:01:14 volker-: yeah, there's meta-measured, or experimental/meta-trusted on git.yoctoproject.org Jun 11 20:01:27 volker-: official layers are only official if they are proposed to be official Jun 11 20:02:04 ok, didn't know about the experimental. We try to stay around 1.6 Jun 11 20:02:22 better I... man, I need a new job Jun 11 20:02:38 not official != not good Jun 11 20:02:53 now i can't vouch for either but meta-measured is active at least Jun 11 20:03:08 rburton: not official = needs more reviews Jun 11 20:03:37 volker-: well its simply not official == author hasn't proposed it, or doesn't want to move it to git.yoctoproject.org Jun 11 20:03:42 what do you define as official Jun 11 20:03:43 ? Jun 11 20:03:47 rburton: not in yocto = needs to be added to the current base in some other ways like meta-openembedded :) Jun 11 20:04:00 on git.yoctoproject.org? that's not a requirement. Jun 11 20:04:11 rburton: official in kind of "well known project" like hosting it on openembeeded or yocto Jun 11 20:04:30 I wouldn't call layers I throw somewhere on github as official :) Jun 11 20:04:38 there are more layers on github than anywhere else :) Jun 11 20:04:51 yocto is not on github ;-) Jun 11 20:05:12 actually, most of it is mirrored there :) Jun 11 20:05:22 support is often a problem with such packages. I saw it in other fields. Jun 11 20:05:39 s/support/continuous development/g Jun 11 20:06:09 volker-: joining forces with an existing layer must be easier than starting from scratch, right? Jun 11 20:06:14 anyway time to cook Jun 11 20:06:22 * rburton goes Jun 11 20:30:14 blloyd, bluelightning: regarding the kernel config trouble on rpi we discussed earlier. i tried to add configuration fragments, but they do not change the final config :( Jun 11 20:30:47 ionte: I'm guessing because the kernel recipe does not use linux-yocto.inc as I mentioned earlier Jun 11 20:30:55 without that, there is no config fragment support Jun 11 20:31:01 AIUI Jun 11 20:32:38 guess so.. Jun 11 20:44:06 bluelightning: the config is modable, but it's different... Jun 11 20:46:00 probably do it different now, but i made the recipe look for a custom defconfig in workdir Jun 11 20:48:01 .oO( tpm-tools used by most distribution wasn't updated since 2012!?!?!? ) Jun 11 20:50:42 * nerdboy triggers the superblock mount time in the future error Jun 11 21:14:21 I’ve got a headscratcher related to root filesystem construction: Jun 11 21:14:32 If I build a core-image-base with the beaglebone machine, it puts uImage in /boot of the filesystem Jun 11 21:15:53 on the other hand, if I make a new machine that’s exactly the same but with a different name (so different file in conf/machine, same preferred KBRANCH for the new machine name, etc), it doesn’t install uImage Jun 11 21:17:07 is there something weird I have to do with the COMPATIBLE_MACHINE variable? that’s the only config variable that I don’t understand in the kernel .bbappend file Jun 11 21:17:45 mkeeter: perhaps look for beaglebone setting MACHINE_ESSENTIAL_EXTRA_RDEPENDS. Jun 11 21:21:32 Or look at KERNEL_IMAGETYPE. Beaglebone sets it in their machine conf, does your new one do so? Jun 11 21:21:46 yes, I just copied the beaglebone conf file and gave it a new name Jun 11 21:21:51 but I’ve found something suspicoius: Jun 11 21:22:04 it’s warning me that linux-dummy is trying to install files into a shared area when those files already exist Jun 11 21:22:13 in tmp/sysroots/beagleboo/sysroot-providers/virtual_kernel Jun 11 21:22:34 and telling me “Please verify which package should provide the above files" Jun 11 21:22:45 so that sounds relevant to these issues Jun 11 21:22:56 besides changing the file name, the internal of the file needs to be updated to be consistent with the new name. Jun 11 21:23:44 the beaglebone.conf file? Jun 11 21:23:56 I don’t see anything name-specific other than the #@NAME header, which I changed Jun 11 21:25:58 just looked, looks like it derives the name from filename now. Sorry Jun 11 21:26:18 yeah, I think it’s to do with the warnings about installing files into a shared area where the files already exist Jun 11 21:28:04 is there a convenient way to tell which recipes are trying to provide which files? Jun 11 21:31:50 hmmm, something like a conflict between linux-dummy and linux-yocto? Jun 11 21:32:05 those are the only two manifests that contain kernel-modules.packaged Jun 11 21:32:43 and similarly, linux-dummy.populate_sysroot and linux-yocto.populate_sysroot both contain “virtual_kernel”, which I was also warned about Jun 11 21:33:25 ah, and this brings me back to COMPATIBLE_MACHINE something Jun 11 21:33:26 maybe Jun 11 22:14:02 you are putting two kernels on your system? Jun 11 22:14:52 and I would expect those to conflict. They generate the same thing to go on the filesystem. Jun 11 22:41:44 whois sgw_ Jun 11 22:41:54 * fray notes a '/' would help.. whoops ;) Jun 11 22:44:13 fray, I am sgw! Jun 12 00:09:50 sgw_: do you have any proof? **** ENDING LOGGING AT Thu Jun 12 02:59:59 2014