**** BEGIN LOGGING AT Wed Dec 02 03:00:59 2015 Dec 02 03:02:51 pevster: automatically (via the alternatives system) Dec 02 03:04:46 bluelightning: Smashing thanks... Is there a way I can just cherry pick dd on it's own? Dec 02 03:05:41 pevster: not out of the box, but you could bbappend the coreutils recipe to split it out into its own package Dec 02 03:06:03 Hm... it seems to add 6M to my image :-D Dec 02 03:06:07 pevster: another (more drastic) alternative would be to switch to ddrescue Dec 02 03:07:14 bluelightning: oooh... I've not seen that before. I take it that it's compatible with 'normal' coreutils dd? Dec 02 03:07:52 it's functionally equivelent, but not drop-in command-line compatible Dec 02 03:07:53 thats the main problem I have - busybox doesn't support skip_bytes so having to do horrible non-block dd operations which is hideously slow Dec 02 03:16:32 Strewth, might just be quicker to port to busybox :-D Dec 02 03:17:59 well, the least intrusive fix is to split coreutils packaging, and that should be trivial Dec 02 03:19:34 you'd just need a bbappend with PACKAGES =+ "${PN}-dd" and FILES_${PN}-dd = "${base_bindir}/dd" Dec 02 03:21:25 probably also ALTERNATIVE_${PN}-dd = "dd" Dec 02 03:23:44 Really? I didn;t think the coreutils recipe knew about all the internal packages? Dec 02 03:23:57 bluelightning: is that a recentish thing? Dec 02 03:24:26 Oh, I see, just define it in the append... Dec 02 03:24:37 right, in adding those you're creating a package just to split out a single file Dec 02 03:25:11 if there are shared libs in the main package though there'll be a dependency created that drags in the main package, hopefully that's not the case Dec 02 03:25:22 (shared libs that dd links to) Dec 02 03:25:47 I was wondering about that - I seem to be 6MB heavier and the main bins don't account for that Dec 02 03:38:34 bluelightning: Tried as quoted but craps out with Dec 02 03:38:40 * opkg_install_cmd: Cannot install package coreutils-dd. Dec 02 03:42:24 for whatever reason the file can't have gone into the package, and thus it ended up empty Dec 02 03:43:09 you can check this by looking under packages-split in the workdir for coreutils Dec 02 03:43:45 you did use =+ and not += to add the item to PACKAGES right? Dec 02 03:43:54 Oh... does it need dd.coreutils not dd? Dec 02 03:44:02 Yes :-) Dec 02 03:44:09 ah - yes that might be it ;) Dec 02 03:44:09 Cut and pasted Dec 02 03:46:23 That was it. Seems to have worked, you are a splendid human being, thank you! Dec 02 03:46:46 (at least it seems find until I do a full clean rebuild and find something is broken...) Dec 02 03:50:40 glad I could help :) Dec 02 03:51:42 pevster: btw I didn't see your answer to my earlier question regarding your issues with building the image from sstate Dec 02 03:55:41 Ah yes - I haven't managed to get a concise summary of WTF im doing :-) I wrote the code ages ago and it's gone cold so need to re-read it to figure it out. The dd optimisation is a side excursion that cropped up along the way ! Dec 02 03:55:50 s/get/write/ Dec 02 03:58:55 the only thing I can think of is you're poking files into the sysroot (or other sstate-managed areas) with the result that the files aren't being properly saved and restored through sstate Dec 02 08:56:40 somehow a directory named the same as the ${S} directory is created in ${D} after do_install(), causing do_package_qa() to fail. any ideas what might be going on? the do_install() comes from a custom bbclass that takes ipk packages as input and extracts them. i've confirmed that the directory does not exist at the end of do_install() (with an 'ls'). Dec 02 08:57:40 the contents of ${D} look fine besides that directory too Dec 02 09:06:01 oh, and ${S} is used to point out the directory where the .ipk files reside Dec 02 09:25:11 sgw_: btw, I updated my kernel and it works fine, thanks! Dec 02 09:26:12 however, when probing gma500_gfx, it switches to a resolution that is not supported by my monitor so I've just blacklisted that module Dec 02 10:06:15 hi all Dec 02 10:06:20 Is there a way to disable/mask systemd services centrally (in the image or local.conf) without using ROOTFS_POSTPROCESS_COMMAND to remove the links in rootfs ? Dec 02 10:07:45 SYSTEMD_AUTO_ENABLE_pn-somerecipe = "disable" in your local.conf might work Dec 02 10:10:17 rburton: thank you very much ! Dec 02 10:29:46 is do_package ever supposed to create things in ${D} Dec 02 10:29:47 ? Dec 02 10:30:46 somehow it ends up creating a directory named the same as ${S}, which do_package_qa then barfs on Dec 02 10:32:42 Ulfalizer: sounds like your recipe is borked, can you share it? Dec 02 10:33:33 i'll see if i can reduce it Dec 02 10:36:17 it noexec's do_patch, do_configure, and do_compile, then does for ipk in "${WORKDIR}/${S}"/*.ipk; do ar p "$ipk" data.tar.gz | tar xz -C "${D}"; done in do_install, assuming S has been set up to point to a directory with IPK packages Dec 02 10:36:34 strangely it works if i use a custom variable instead of S Dec 02 10:37:11 after do_install, the contents of /image look fine too. for some reason do_package creates a directory in it though. Dec 02 10:37:21 the contents of ${D} that is Dec 02 10:40:35 and yeah, i agree that it might be a slightly dubious thing to do :) Dec 02 10:55:05 Hi Guys Dec 02 10:55:55 which iso of yocto can emulate powerpc or cisco 4500 32 bit architecture Dec 02 10:56:11 *iso/image ? Dec 02 10:58:06 where do i find the default do_package implementation? Dec 02 11:02:37 oh, package.bbclass Dec 02 11:33:52 Hello, I am trying to compile f2c for ARM and in the Makefile, I have to execute a binary generated by the Makefile as follow: "./a.out >arith.h" . An error is generated at this step saying "cannot execute binary file". Is there a way to Dec 02 11:33:58 use it ? Dec 02 11:53:18 I know it's not especially yocto related, but does someone of you know if the kernel supports the memmap parameter on ARM? it looks like it doesn't work for me Dec 02 12:48:32 jaeckel: most of it is x86 only Dec 02 12:48:38 see the documentation Dec 02 12:51:25 I already guessed so :( Dec 02 12:51:45 tile and xtense also support a subset Dec 02 12:51:53 xtensa Dec 02 12:52:53 you probably don't need that anyway Dec 02 12:53:08 what do you mean? Dec 02 12:53:24 is there an alternative way to do the same? Dec 02 12:53:39 what do you want to achieve exactly? Dec 02 12:54:12 reserve a memory region that it's not used by the kernel Dec 02 12:55:11 did you have a look at cma? Dec 02 12:55:25 this is probably what you want Dec 02 12:55:50 mh Dec 02 12:57:12 can I use that parameter to tell the kernel to not touch a specific memory region? Dec 02 12:58:11 I'm sharing memory with some other peripheral and I want to exclude that memory from the kernel Dec 02 13:00:16 that is the point Dec 02 13:05:48 cool, looks like a possible solution Dec 02 13:07:00 thx Dec 02 14:11:46 Hi All, I'm having an issue in yocto daisy -- I hope this is the right place to ask. Dec 02 14:15:10 I think this is a bbappend + state problem. Is it even valid to do two builds against the same sstate-cache with different layers where a bbappend is included in one set of layers and not in the other? Dec 02 14:16:10 edbart1, there is a guy in #oe asking wic questions Dec 02 14:17:56 Crofton: thanks, I'll connect there. Dec 02 14:18:10 More specifically: I am doing builds with and without my layer included where my layer contains a bbappend of paxctl which overrides do_install. There are other recipes in my layer which will fail build if the do_install override isn't invoked. I've got these builds going in CI and sometimes I'll get failures. I'm sharing sstate but also running a shared pr service. Dec 02 15:51:58 bengardiner: sstate uses metadata checksumming. if the variables used by a task change, then the checksum changes, and that sstate won't be used. so there's nothing wrong with bbappend and sstate interaction whatsoever Dec 02 15:52:17 but you can use bitbake-dumpsig and bitbake-diffsigs to examine and compare the .sigdata/.siginfo files from your sstate cache or stamps dir Dec 02 16:14:24 thanks, kergoth. Dec 02 16:15:00 I change BBCLASSEXTEND, DEPENDS (and I even tried a hack to change PR) in the bbappend file Dec 02 16:15:32 so logically sstate shouldn't be blocking the rebuild. must be something else then? Dec 02 16:16:44 i use a single sstate cache for tons of yocto versions, machines, distros, etc, there's no bad interaction, any changes invalidate/change the sstate, never reused when it shouldn't be Dec 02 16:16:56 now, the opposite it sometimes true, it rebuilds more than i want sometimes, but better that than the alternative Dec 02 16:17:06 so yes, its unlikely for that to be a problem Dec 02 16:17:27 if your bbappend isn't being applied, either your layer isn't enabled, your BBFILES in your layer.conf is incorrect, or the path to the bbappend doesn't match up with the BBFILES in the layer.conf Dec 02 16:17:36 bitbake-layers show-appends may be of use Dec 02 16:23:58 or the bbappend's version doesn't match the recipe version. Dec 02 16:25:13 good point. bitbake-layers show-appends will warn about that Dec 02 16:25:18 Hi! Is it possible to generate a rawdisk image using bitbake? My build has generated a ext3 rootfs and a kernels, but I wonder if yocto can put them together with a bootloader Dec 02 16:25:26 if an append exists for a non-preferred recipe but not a preferred recipe Dec 02 16:25:33 (for a x86 VM) Dec 02 16:25:36 "[...] it rebuilds more than I want sometimes [...]" -- that's interesting. Because I run the build jobs in parrallel in a CI server Dec 02 16:25:41 pedroalvarez: wic is the best tool for that Dec 02 16:26:20 all contributing to the sstate cache. maybe the build without the layer is winning the race to add to the cache Dec 02 16:26:39 no, that wouldn't make sense Dec 02 16:26:42 kergoth: thanks, I'll have a look Dec 02 16:26:50 again, if the append changes the metadata, it changes the checksum, and both builds will emit different sstates Dec 02 16:26:53 mario-goulart: thanks, I'll check for a warning about a missing bbappend target Dec 02 16:26:58 there's no race, they write entirely different filenames Dec 02 16:27:21 kergoth: ok then; I'm glad you're lending your expertise. Thank you again Dec 02 16:27:23 bengardiner: it errs on the side of caution. if recipe A is changed and recipes B and C depend on A, B and C will also be rebuilt after A is rebuilt. this is obviously needed to handle cases where e.g. the library ABI changes, but of course it also means a change to a comment in do_install will ripple outward through the dependency graph :) Dec 02 16:27:43 but better that than possibly risking brokenness due to using out of date stuff and not relinking Dec 02 16:28:06 makes sense Dec 02 16:28:13 ideally in the long term we'll be able to recognize when the output of a task hasn't changed when the input has, but to do that we'd need heuristic analysis of the output, or reproducible bit-by-bit builds Dec 02 16:28:17 "bitbake -DDD" can also be handy for debugging (you probably want to redirect the output to a file) Dec 02 16:29:27 ok -- so at least now I know I'm not attempting something that is flawed at the outset. Dec 02 16:30:28 I'm going to go have some lunch. I'll pop back and report if I find anything or not. Thanks for all your advice so far Dec 02 16:31:36 oh, good to see that sharing sstate dir for various builds works for people here Dec 02 16:31:58 I'm trying to create some CI pipelines and that was one of my ideas to try to save some time Dec 02 16:32:30 we use it for our incremental CI builds, a common sstate cache for both the automated builds and for use by the engineers Dec 02 16:32:39 then do periodic full builds from scratch Dec 02 16:32:51 much, much, *much* faster Dec 02 16:32:56 yup.. we do the same.. this is what we consider to be best practice.. Dec 02 16:33:09 (with the understanding engineers don't HAVE to use the cache.. since it's juts that a cache) Dec 02 16:33:15 indeed Dec 02 16:33:31 it's so nice though, since the CI machines tend to bef aster than individual engineer workstations Dec 02 16:33:35 bootstraps progress on tasks Dec 02 16:33:47 naturally depends, but.. Dec 02 16:34:03 How do you guys usually share the sstate cache? NFS? Dec 02 16:34:10 yeah, I was pondering how to share the sstate cache Dec 02 16:34:12 snap Dec 02 16:34:17 both NFS and http Dec 02 16:34:23 NFS for local users.. http for some special cases Dec 02 16:34:34 (http is MUCH slower, so it really is special cases) Dec 02 16:34:46 and does bitbake handles that or engineers have to fetch it themselves? Dec 02 16:34:58 it's automatic if the engineers has enble it Dec 02 16:35:19 oh, that's interesting Dec 02 16:35:37 i think we're mostly using http, but we should switch to nfs Dec 02 16:35:47 pedroalvarez: just set SSTATE_MIRRORS appropriately Dec 02 16:35:48 NFS has reliability issues http doesn't Dec 02 16:36:02 thats why I said "local users" ;) Dec 02 16:36:17 yeah, i wouldn't try using it over our vpn.. Dec 02 16:36:20 :) Dec 02 16:36:24 Does anybody use distcc for building stuff with bitbake? Dec 02 16:36:33 people do it, but I always tell them don't.. Dec 02 16:36:41 :-) Dec 02 16:36:47 often it takes longer time to use distcc then just compile and cache (sstate-cache) Dec 02 16:36:53 kergoth: noted, tvm Dec 02 16:36:58 ccache is another one I caution against.. Dec 02 16:37:05 mario-goulart: i'm not sure you'd get all that much benefit since build paths change, binaries change when they're rebuilt, etc, but i know some folks do use it. same iwth icecc Dec 02 16:37:10 distcc is really only useful if you have a LOT of really slow computers with a fast network Dec 02 16:37:23 oh, i thought you said ccache, distcc might be okay, but the overhead is the problem Dec 02 16:37:24 yeah Dec 02 16:37:43 I suppose a low-latency network would be required. Dec 02 16:37:47 it'd be nice if bitbake could offload entire recipe builds, or task execution, rather than distributing at the per-compile/per-link level Dec 02 16:38:21 fray: man, i remember one time having a corrupt object in my ccache Dec 02 16:38:26 it was the last freaking place i thought to look Dec 02 16:38:28 wasted like 2 days Dec 02 16:38:44 ya, thats the downside of the cache.... Dec 02 16:39:06 I think we're exposed to those problems more then typical developers.. Dec 02 16:39:20 I rarely if ever see them when doing recipe work -- but when hacking ont he build system itself they're a lot more possible Dec 02 16:40:07 heh, only tangentally related, but i always have to remember to --no-setscene when i'm screwing around with non-checksummed elements of the build. imported python modules, bitbake itself.. Dec 02 16:40:20 always wanted to get those bits checksummed too, but never got around to it Dec 02 16:42:20 do you normally clean the build environment? I noticed that removing *src-build/tmp makes it "build" some things on the next run even if nothing changed Dec 02 16:42:45 So shared-shared-state :-) is the way to go for multi-seat environments? Here we have this "load distribution" problem. So far we've been investing in build servers, but that doesn't scale very well. Dec 02 16:43:17 pedroalvarez: that should not be the case. i wipe tmp and let things rebuild from sstate all the time and get full 100% reuse unless i modified something Dec 02 16:43:24 if your'e getting unexpected rebuilds, there are useful tools to diagnose Dec 02 16:43:50 bitbake -S printdiff ccore-image-base (or whatever target) is useful Dec 02 16:43:53 as is bitbake-diffsigs Dec 02 16:44:26 there's also bitbake-whatchanged, though i'm not sure if that's still working as well as it used to, iirc right now its method (changing STAMPS_DIR) actually changes checksums itself, cluttering up the output Dec 02 16:44:48 I quoted "build" because I'm not sure they are builds, and just putting things in place to generate rootfs, and so on Dec 02 16:45:12 i've bee mostly leveraging bitbake -S printdiff occasionally overriding SSTATE_DIR to force it to use STAMPS_DIR sigdata to compare against Dec 02 16:45:21 pedroalvarez: you can always examine buildstats or tmp/stamps/ to see what tasks ran Dec 02 16:45:26 the _setscene variants are pulling from sstate Dec 02 16:45:35 the non-_setscene tasks are non-sstate Dec 02 16:45:59 I'd recommend adding INHERIT += "buildstats-summary" Dec 02 16:46:04 right Dec 02 16:46:11 which will tell you at the end of hte build how many tasks ran from sstate vs non Dec 02 16:46:14 really useful Dec 02 16:46:43 it does require buildstats, but i think thats inherited by default nowadays Dec 02 16:48:09 * pedroalvarez saves the conversation Dec 02 16:48:55 * kergoth wonders if the docs cover the available tools for diagnosing sstate reuse problems Dec 02 16:56:59 when all else fails.. use a bigger mallet.. bitbake -c cleansstate (and disable sstate cache mirrors) ;) Dec 02 16:57:54 I like -C fetch for that, to avoid having to disable SSTATE_MIRRORS :) of course, then you need to -c clean first, so tradeoffs to both approaches Dec 02 16:58:22 I'd really like bitbake to know that clean should be done before everything else, so we could do things like bitbake foo:do_cleansstate foo Dec 02 17:01:01 * mario-goulart has a "rebake" shell function that does "bitbake -c cleansstate $@ && bitbake $@" Dec 02 17:01:26 for the moments of despair. :-) Dec 02 17:03:56 gotta watch out for sstate mirrors, though. cleansstate won't prevent re-fetching it from a mirror and using that instead of building from scratch Dec 02 17:04:45 bitbake -c clean $@ && bitbake -C fetch $@ will force the matter by "tainting" fetch, forcing the tasks after it to run regardless of the presence of sstates, mirror or otherwise Dec 02 17:05:02 of course, the downside to that is the stupid taint sticks around permanently even after the thing has been rebuilt once Dec 02 17:05:06 there's an open yocto issue for that Dec 02 17:05:09 Ah, I see. Good point. I only use a local sstate cache though. Dec 02 17:05:51 ah, fair enough Dec 02 17:06:21 i always thought it'd be nice to have cleansstate inject a taint, but then there'd be no way to only clean and refetch an sstate archive :) Dec 02 17:06:30 so best to keep it explicit as is Dec 02 17:36:21 hi Dec 02 17:42:11 is there any documentation/tutorial/whatever how to control which packages are included when building a toolchain with yocto? i need python 3.3 in the toolchain, but there is only python 2.7. both versions are included in the image, this part works fine. but the toolchain is a real mystery :( Dec 02 17:49:12 that depends on what method of building a toolchain you're using. whe using -c populate_sdk, the sdk contents hsould mirror the content of the image, but you can add additional host or target packages with TOOLCHAIN_HOST_TASK and TOOLCHAIN_TARGET_TASK Dec 02 17:49:26 i.e. TOOLCHAIN_TARGET_TASK_append = " python3-dev" or whatever Dec 02 17:55:07 it would really be nice to automatically handle module imports for inline python Dec 02 17:55:18 quite often i have to split out a def'd function just so i can import something Dec 02 18:02:16 kergoth: wrt python, one thing that I was thinking is how to automatically determine runtime dependencies for python packages. I thought about inspecting the bytecode of installed files to find import commands (similarly to ldd for binary files). Do you know if something like that exists? Dec 02 18:02:26 mario-goulart: yes, and we already have it Dec 02 18:02:38 recipetool can create recipes, and it supports this python dependency analysis Dec 02 18:02:41 Oh, really? Dec 02 18:02:47 recipetool create -o - Dec 02 18:02:47 Awesome. Dec 02 18:02:56 its useful even for existing recipes to validate our rdeps Dec 02 18:03:06 i have a gist where i did this for all the existing python recipes Dec 02 18:03:11 the thing is, it always always requires manual review Dec 02 18:03:18 Excellent. Thanks for the hint. Dec 02 18:03:32 since its not perfect, it can pick up things which aren't actually right, or e.g. conditional deps aren't entirely handled. Dec 02 18:03:38 i.e. a tree of try/catch ImportError Dec 02 18:03:46 it doesn't recognize this as a this or that or the other dep Dec 02 18:03:54 Ah, I see. Good point. Dec 02 18:04:04 https://gist.github.com/kergoth/7ad4b5102b2a5fe3a956 has the status of it and future plans Dec 02 18:04:32 Cool Dec 02 18:04:38 https://gist.github.com/kergoth/7d2e9f6c7d0fd759d7f2 is a script that uses recipetool create to identify potential missing rdeps in the available python recipes, along with example output from a while back Dec 02 18:04:57 it both parses setup.py for dep info and scans the code Dec 02 18:05:35 Very nice. Dec 02 18:06:00 it uses an external script to scan, btw, see scripts/pythondeps Dec 02 18:06:05 so it can be run external to oe for testing Dec 02 18:06:21 s/oe/recipetool/ Dec 02 18:06:48 another thing it tends to pick up that might not be quite right is tests Dec 02 18:06:56 in some cases it'll scan the unit tests dir Dec 02 18:07:07 and pick up deps of the tests which of course aren't deps of the module/package itself.. Dec 02 18:07:10 so keep that in mind Dec 02 18:07:21 i see. Dec 02 18:07:35 it tries to avoid this by using the specified package_dir from setup.py, but sometimes unit tests are under that Dec 02 18:08:04 setup.py scanning is limited by the fact that it can only pick up literal values, it can't run functions without worrying about side effects Dec 02 18:08:30 * kergoth was neck deep in this for way too long, it's messier than one might expect Dec 02 18:09:08 I see. We use a similar strategy for meta-chicken, but the metadata file for eggs is not "executable". Dec 02 18:09:49 For meta-chicken, all the recipes (more than 550 at the moment) are automatically generated by a script. Dec 02 18:10:07 oh, that reminds me, it will use EGG-INFO if it exists too Dec 02 18:10:14 mario-goulart: oh, wow, that's quite interesting Dec 02 18:11:05 https://gist.github.com/kergoth/c6b6e08fd24cdde8adc5 might be interesting, it shows how the setup.py ast is transformed to extract all the literals and separate them from the bits we can't process without running it Dec 02 18:11:05 Yeah, the scriptability is quite handy to manage those recipes. Dec 02 18:11:56 sounds like it, never considered such an approach Dec 02 18:12:03 kergoth, when i add TOOLCHAIN_HOST_TASK_append = " python3-dev " and TOOLCHAIN_TARGET_TASK_append = " python3-dev ", it fails: "ERROR: python3-dev not found in the base feeds (x86_64-nativesdk noarch any all)." Dec 02 18:17:15 kergoth: thanks for the gists and hints. Lots of nice ideas. Dec 02 18:39:04 Matt____: you can't add target packages to HOST_TASK Dec 02 18:39:14 Matt____: that's for host stuff, stuff that runs on the machine the sdk is installed on. Dec 02 18:39:17 i..e nativesdk stuff Dec 02 18:39:29 mario-goulart: np. i'll have to take a look at meta-chicken :) Dec 02 18:40:26 :-) Dec 02 18:40:41 I really want to add ast pretty printing (ala astpp.py) to pprintpp one of these days Dec 02 18:41:05 currently you can pretty print ast nodes with that, or anything else with pprint/pprintpp, but nothing will do both at once Dec 02 19:02:37 Hi kergoth, mario-goulart Dec 02 19:03:39 i've got a builddir now where the problem is happening (I can reproduce it locally). bitbake-layers show-appends tells me my bbappend for paxctl is getting picked-up Dec 02 19:08:41 I don't have a buildstats-summary.bbclass (b/c of daisy??) so I can't go down that avenue Dec 02 19:09:08 use bitbake -e paxctl to examine its metadata and make sure it's what you think it is Dec 02 19:12:17 Hi all, I need to change an existing machine configuration to use a different devicetree. Do I need to make a branch new machine file, or can I use like a bbappends? Dec 02 19:13:18 see the KERNEL_DEVICETREE variable. if the machine defines it with ?=, you could just set it in local.conf, otherwise you can use KERNEL_DEVICETREE_forcevariable. i think that variable is probably in the yocto reference manual, though haven't checked offhand Dec 02 19:13:58 https://github.com/Xilinx/meta-xilinx/blob/master/conf/machine/zc706-zynq7.conf here's what I want to change. Dec 02 19:14:16 It's a conf, so I have my own custom layer I'm working on. I would add my devicetree files there and somehow have it point to that, but not sure. Dec 02 19:14:53 kergoth: yep. the do_install() in the -e output is what I'm expecting Dec 02 19:16:12 bengardiner: are you not sure it's being run the way you want? add 'exit 1' and bitbake the recipe and make sure it fails. Dec 02 19:16:39 * kergoth is unclear on what the problem is you're hitting Dec 02 19:17:05 kergoth: yep good point. all data points to the sstate-cache working properly. So I've gotta look elsewhere :) Dec 02 19:18:08 kratsg: a layer can't override something a machine is doing, under normal circumstances, it'd violate our orthogonal distro/machine/image axes and layering mechanism. you could add a config file to the layer and instruct the person using it to add the layer and include that config from their local.conf, or you could provide a custom machine that pulls in the other machine and modifies it and instruct users to set MACHINE to that. you can't bbappend a Dec 02 19:18:08 machine, only a recipe. that said, you could bbappend the kernel recipe and modify KERNEL_DEVICETREE there, so maybe that would do what you want Dec 02 19:18:13 really depends on your goals Dec 02 19:26:12 kergoth: thanks! So I tried making my own new machine: https://github.com/kratsg/meta-l1calo/blob/master/conf/machine/preprototype.conf Dec 02 19:26:59 kratsg: you could just do require conf/machine/zc706-zynq7.conf, and then add your tweaks after that Dec 02 19:27:02 But I get an error like "Nothing provides 'virtual/zynq7-platform-init'" which I think is because it's not seeing the meta-xilinx layer which has the original machine definition. Dec 02 19:27:02 instead of copying it Dec 02 19:27:12 then make your layer depend son meta-xilinx Dec 02 19:27:17 oh, really? Dec 02 19:27:17 * kergoth nods, that sounds accurate Dec 02 19:27:32 yeah, any relative include/require path will be found via BBPATH, which means it searches layers for it Dec 02 19:28:18 naturally there are other approaches you could take, thats one thing that's both nice and annoying about oe/yocto, always multiple ways to do things :) Dec 02 19:28:26 flexible, but also potentially confusing figuring out whats best Dec 02 19:28:35 often have to experiment and see what feels cleanest Dec 02 19:28:52 at mentor, we've done the new machine that builds on another machine approach a number of times in the past Dec 02 19:29:16 Ok, it makes more sense for me to do the `include` approach Dec 02 19:29:31 since I'd rather depend on meta-xilinx directly and only make the changes I need -- such as a custom devicetree Dec 02 19:30:08 One thing that I can't figure out is how to make sure it finds these things? EG: how do you ask for a list of machines that exist so you know your machine is parsed right? Dec 02 19:30:57 all thats needed to make a machine exist is create a conf/machine/ file and add that layer to your bblayers Dec 02 19:31:08 beyond that, set MACHINE=yourmachine and do a build :) Dec 02 19:31:17 Unfortunately, it's still complaining Dec 02 19:31:28 hmm Dec 02 19:31:31 oh, i bet i know what's wrong Dec 02 19:31:37 Could not find conf/machine/include/zc706-zynq7.conf Dec 02 19:31:48 it's something with dependency resolution for sure. Dec 02 19:32:25 add MACHINEOVERRIDES .= ":zc706-zynq7" to your machine config Dec 02 19:32:31 otherwise those overrides in recipes won't apply Dec 02 19:32:34 since the machine name is different Dec 02 19:32:44 forgot about that Dec 02 19:33:32 https://github.com/kratsg/meta-l1calo/blob/master/conf/machine/preprototype.conf Dec 02 19:33:35 here's what I have so far Dec 02 19:34:08 "Could not include required file: conf/machine/include/zc706-zynq7.confg" Dec 02 19:34:34 I have meta-xilinx in my bblayers, and this is my layer.conf: https://github.com/kratsg/meta-l1calo/blob/master/conf/layer.conf Dec 02 19:35:00 typo, confg Dec 02 19:35:16 Err, that's my typo. Sorry. Dec 02 19:35:20 It's "zynq7.conf" Dec 02 19:35:39 (I'm inside a VM so copy/pasting isn't trivial!) Dec 02 19:35:45 it's probably also not in conf/machine/include/ but conf/machine/ Dec 02 19:35:49 but double check that Dec 02 19:35:54 the path has to be form the root of the layer Dec 02 19:36:44 Is meta-xilinx in BBLAYERS? Dec 02 19:36:44 D'oh. I see. Dec 02 19:36:50 Yeah, it is mario-goulart Dec 02 19:36:55 ok Dec 02 19:36:55 It looks like it parsed it now. Dec 02 19:37:17 Is there a way to ask for "is an existing machine?" Dec 02 19:37:23 or list all machines or something? Dec 02 19:37:39 not really, bitbake doesn't consider machines magic Dec 02 19:37:46 bitbake.conf has a line: include conf/machine/${MACHINE}.conf Dec 02 19:37:52 that's what causes it to be pulled in Dec 02 19:37:58 it has no awareness of machines other than the one that's currently set Dec 02 19:38:08 you could script it yourself, of course Dec 02 19:38:12 Usually find -path "*/conf/machine/*.conf" does the trick, assuming conventions. Dec 02 19:38:21 Oh, I see. Dec 02 19:38:46 Ok, so it looks like it's recompiling everything for this machine, even though I had already compiled it for zc706. Dec 02 19:38:54 I guess it's machine-by-machine, so it can't know the difference. Dec 02 19:39:00 i guess that's totally fine. Dec 02 19:39:10 some recipes are machine specific, not all are, though Dec 02 19:47:04 Side note: we noticed if the SD clock was set to < 50 MHz, U-boot doesn't function properly. Is that a known thing? Dec 02 19:49:00 Oh, hrmm, the dts include failed Dec 02 19:49:18 Do I need to explicitly add all the dts files in the machine definition, for the dts files to find it? Dec 02 19:51:07 "Fatal Error: Could not open 'zynq-7000.dtsi': No such file or directory" Dec 02 19:51:33 i'm presuming it's because the .dts file references it via an include, but I don't have it in the MACHINE_DEVICETREE := list. Dec 02 20:03:56 thank you very much, kergoth! with just TOOLCHAIN_TARGET_TASK_append = " python3-core " it seemed to work :-) Dec 02 20:04:02 np Dec 02 20:04:28 ~/QorIQ-SDK-V1.8-20150619-yocto/build_t4240rdb-64b_release/tmp/deploy/sdk$ find /opt/fsl-networking/QorIQ-SDK-V1.8/ -iname python3 /opt/fsl-networking/QorIQ-SDK-V1.8/sysroots/ppc64e6500-fsl-linux/usr/bin/python3 /opt/fsl-networking/QorIQ-SDK-V1.8/sysroots/ppc64e6500-fsl-linux/usr/src/debug/python3 Dec 02 20:08:23 we're checking things now :) hopefully it should work! Dec 02 20:21:41 hi... I believe (now) that the problem is due to the paxctl command getting deployed to native sysroot when built, but not when retrieved from the cache. I must be writing the bbappend wrong Dec 02 20:53:42 kergoth: I had a missing FILES_${PN} in the bbappend *facepalm* -- so I added it, built. cleaned everything up and tried to rebuild (from sstate). same error again. paxctl-native isn't installing paxctl to the sysroot when coming from sstate Dec 02 20:54:31 I should just double-check my bbappend. Can anyone recommend the right bbappend to look at for adding native support to a recipe? Dec 02 21:17:38 so, we tested everything. Seems like with the custom DTS, the ethernet isn't really working. Still need to figure out where along the line it's broken. Dec 02 22:02:13 RP: do we have documented the bitbake/oe-core compatibility breaks, so we know what's involved to try to use a newer bitbake with an older oe-core? Dec 02 22:02:17 i'm guessing probably no Dec 02 22:17:37 Crofton|work: I wasn't trying to troll :) Dec 02 22:19:44 moto-timo, you are fine Dec 02 22:26:42 there are shitty days in America? Maybe you just need more guns :) Dec 02 22:28:41 except in San Bernandino where they need fewer guns :/ Dec 02 22:34:50 kergoth: not officially, no Dec 02 22:35:04 We just need more mental health providers Dec 02 22:35:15 kergoth: only really big one I'm aware of was the data store changes Dec 02 22:38:25 hmm, right Dec 02 22:41:29 RP, kergoth I was just dreaming of the day that one version of bitbake worked across more than one release of meta-data Dec 02 22:42:09 in the good news dept, my first pass at a minfest for people doinf sdr stuff seems to work (jethro based) Dec 02 22:42:43 also, there is a special place in hell for the person that named a release after someone named close to the community manager Dec 02 22:43:21 * armpit got kicked out of hell Dec 02 22:43:43 oops special level of hell Dec 02 22:43:50 https://www.youtube.com/watch?v=vVgbX_YeK-s Dec 02 22:43:51 lol Dec 02 23:24:24 * moto-timo starts a petition to rename to JEFRO Dec 02 23:24:52 too late? Dec 02 23:24:54 lol Dec 02 23:26:12 I suppose it will get just as far as the petition to get Firefly back on the air Dec 02 23:26:27 Perhaps we can make a JEFRO movie Dec 02 23:26:37 +1 Dec 02 23:43:31 but then it would be spelt wrong to match the scheme Dec 02 23:43:40 which afaik, nobody has guessed yet **** ENDING LOGGING AT Thu Dec 03 03:01:11 2015