**** BEGIN LOGGING AT Mon Jan 25 02:59:58 2016 Jan 25 03:19:36 * nerdboy thumbs-up yocto @ SCaLE Jan 25 07:53:20 moin Jan 25 08:28:10 hello Jan 25 08:28:35 anyone familiar with Timesys Factory here ? Jan 25 08:30:04 i'm trying to compare that with OE/Yocto, and would be nice if someone could suggest what are main pros of Yocto vs Timesys' Factory Jan 25 08:31:09 the only big difference between then so far I could see is Ts Factory appears to be 'buildroot' like, but they do packages & allow you to roll your own distro Jan 25 08:31:12 alike yocto Jan 25 09:10:33 good morning Jan 25 09:11:48 b00^wk: Yocto Project is open source free software Jan 25 09:12:46 (BONGO) Jan 25 09:12:56 s/BONGO/BINGO/ Jan 25 09:19:25 oingo boingo Jan 25 09:25:21 LinuxLink ask that subscribers identify Timesys as the source for distributed platforms that have been built with Linux components and tools. LOL Jan 25 09:25:51 you get open source stuff but you have vendor lock-in Jan 25 09:31:06 best of both worlds Jan 25 09:31:14 er, wait a minutes... Jan 25 09:31:24 s/s// Jan 25 12:32:41 mckoan, hello Jan 25 12:34:46 mckoan, yea i know yocto is open source, but i didn't know that stuff you wrote about Timesys vendor lock-in Jan 25 12:41:51 hmm, that of course is interesting, all the stuff from the Timesys Factory is open source, but you must identify them as the source .. Jan 25 12:45:21 and i think you do need to have a support agreement / service to get the factory & the sources. And their support of course. Jan 25 12:47:46 I did find that for me personally it was easier to understand / jump into & use Timesys Factory though, than Yocto .. Jan 25 12:52:24 Hello. Anyone know why an update-rc.d boot script might run on shutdown? Service created by command "update-rc.d boot_script.sh defaults 99" Jan 25 12:54:24 geotheory: because that's what init scripts do? Jan 25 12:55:07 I understood that this setup line would create a boot service, not a shutdown service.. Jan 25 12:55:19 nope Jan 25 12:55:32 that creates startup and shutdown links Jan 25 12:55:44 File /etc/rc6.d contains K99boot_script.sh Jan 25 12:55:57 just check whether the script is being called as start or stop in the script Jan 25 12:56:27 It's definitely being called on shutdown. It runs twice during a reboot cycle Jan 25 13:00:31 geotheory: what ross means is that that's how init scripts work. your script needs to deal with it: see other scripts for examples Jan 25 13:01:35 Yeah I'm looking for an example. Not found one yet Jan 25 13:02:50 As usual found lots of documentation, no actual examples.. https://www.debian.org/doc/debian-policy/ch-opersys.html#s-writing-init Jan 25 13:08:40 jku, this looks closest match http://stackoverflow.com/a/2068245/1156245 Jan 25 13:09:10 Should I be trying "update-rc.d myScript start 01 2 ." ? Jan 25 13:11:32 you can, but the script still should check for "start", "stop" and "restart" Jan 25 13:12:36 I assume you have a linux system you're building yocto with? that should contain plenty of init scripts, right? No guearantees they'll be well written but... Jan 25 13:23:42 jku: using stock Poky so can't bake anything new into the system Jan 25 13:43:57 What is the best way to modify "core files" in a layer - like for instance, I want to specify the root filesystem as read-only (by modifying /etc/fstab) - Jan 25 13:44:31 I don't want to furnish a new fstab wholesale, I basically want to patch the one provided in another recipe Jan 25 13:45:18 write a bbappend to the recipe which installs said file Jan 25 13:46:41 Now when I do that, am I modifying the file after it's been installed? Or am I modifying it before that recipe installs it? I have done very simple append files, but the the order of operations is often confusing to me Jan 25 13:48:47 yes, you should modify the file after it's installed if you want to just add stuff to the default /etc/fstab, just create a do_install_append or something similar (any function can be appended to) and do something like this in there "echo tralala >> /etc/fstab" Jan 25 13:49:35 Rather, echo tralalala >> ${D}/${sysconfdir}/fstab Jan 25 13:49:37 correct? Jan 25 13:49:55 yes, sure Jan 25 13:50:07 Because at that stage I'm not in the target system and have to use the variables provided for the installed paths? Jan 25 13:50:38 just look at how the "main" recipe addresses the files and use the same method in the bbappend Jan 25 13:51:14 If I have several different recipes appending the same one - how is the order of appends resolved? Jan 25 13:52:36 through the layer ordering in bblayers.conf i guess Jan 25 13:52:56 but why should you have multiple bbappends for the same .bb? Jan 25 13:53:38 I've never actually had the need for this except when using layers where each had its own bbappend Jan 25 13:59:29 Well, for instance, I have a recipe for my software distribution that appends core files to modify a few things (like issue.net, default hostname, etc) Jan 25 13:59:42 But then I have a specific tool that modifies /etc/fstab Jan 25 13:59:48 they don't really have a thing to do with each other Jan 25 13:59:55 and in this case, the order really doesn't matter Jan 25 14:00:08 I was just curious because I could imagine it might in some cases. Jan 25 14:13:35 Is there a way to configure the Replaces field in a debiian control file via a .bb file? Jan 25 14:23:25 Is there a known problem with ifup running if-up.d scripts in Fido? I've installed resolvconf which puts 000resolvconf in if-up.d but when running ifup -v eth0 I don't see any mention of it being ran? Jan 25 15:11:41 ls Jan 25 15:11:44 oops! Jan 25 15:12:09 So there is a deploy folder, with images of my rootfs Jan 25 15:12:16 which is growing and growing, every time I do a build Jan 25 15:12:48 I get a new many-hundred-megabyte sized file/manifest everytime I mint a new image Jan 25 15:13:19 it seems like these files are of historical interest only, but there is a very clear README_DONT_MANUALLY_DELETE_FILES_IN_THIS_DIRECTORY.txt file Jan 25 15:13:42 that admonishes me on my attempt to remove them, so I am afraid to do so. Jan 25 15:13:59 bitbake -c clean image-name (as the file suggests) does not clear them out Jan 25 15:14:08 Does anybody know what do? Jan 25 15:14:17 it will time stamp the builds Jan 25 15:14:29 yeah, they're stamped Jan 25 15:14:40 and it links them to the non timestamped versions, iirc Jan 25 15:14:51 it's like image-name-timestamp-rootfs.rootfs.ext4 etc Jan 25 15:15:57 hi Jan 25 15:16:01 I think if you keep the non timestamped ones, you're ok to delete the others, but I can't guarantee that Jan 25 15:16:39 how does yocto manage to add debuglinks when cross-building? objcopy seems to look at the full path and there is no way to specify a sysroot etc? Jan 25 15:26:54 I just obliterated the whole /tmp directory under my build folder Jan 25 15:27:16 it seems to have provoked some extra work from bitbake, but it's not having to rebuild the whole thing, so I don't think I'm any worse for wear. Jan 25 15:28:02 sstate cache and your download dir are probably meaning it doesn't have to work from scratch Jan 25 15:32:13 I'm reading about BitBake, here : http://docs.openembedded.org/bitbake/html/ch01s02.html. What does this mean: "Must be able to be self contained, rather than tightly integrated into the build machine's root filesystem." Jan 25 15:32:31 (I'm thinking its comparing this to how things where with buildroot, but I don't know what they mean here ..) Jan 25 15:33:21 it means what it says. nothing gets installed into the host's rootfs, and nothing is used from there other than a few dependencies we explicitly identify Jan 25 15:33:28 also there are no distro dependencies Jan 25 15:33:32 essentially, each task when run is independent of other tasks.. the corresponding build system that you make around bitbake needs to understand this.. Jan 25 15:33:38 some distro build tools require they build on the distro they're building for.. Jan 25 15:33:54 ...and as kergoth said, the results often mean that you don't screw with the host, and dependencies need to be fully qualified Jan 25 15:34:51 ah. for some reason I thought its to do with using Linux usually found tools for building :) Jan 25 15:35:11 now this makes more sense I think : don't use say host's fs layout .. Jan 25 15:35:11 :) Jan 25 15:35:27 while realistically speaking you need Linux as your build system type.. the design of the system is such that it could be adjusted to not need a Linux host.. Jan 25 15:35:39 bitbake -itself- doesn't need Linux, it's some of the things that OE uses that currently do Jan 25 15:35:50 hmm, Jan 25 15:36:06 ok Jan 25 15:36:25 you have to remember bitbake is similar in concept to 'make'. It's the task scheduler, variable handler and some fetch facilities and other utility functions.. but it's not the "build system" Jan 25 15:36:59 the build system is implemented with bitbake handling those tasks, and the rest of the system being implemented separately. This is where oe-core comes into place.. it puts down the ground work for the build system.. which can further be augmented by additional layers Jan 25 15:37:53 indeed, well said Jan 25 15:37:57 yea Jan 25 15:38:16 its the rest that matters quite a bit, me thinks ? Jan 25 15:38:21 http://www.aosabook.org/en/yocto.html may also be of use Jan 25 15:38:45 other then the way the variables are handled in bitbaek (defined, expanded, etc).. most developers will never have to know anything about bitbake.. Jan 25 15:38:48 a bit hard to imagine how bitbake & oe would work anywhere else but on linux Jan 25 15:38:55 oe-core on the other hand is where things are useful to know details.. Jan 25 15:39:22 bitbake/oe-core SHOULD be able to run on most unix platforms.. but there are some tools that are Linux specific (right now) that are in use.. Jan 25 15:39:43 we've (over the years) done research projects on thigns like Darwin support and gotten far enough that it looks possible, but there is simply hasn't been a desire to finish the work Jan 25 15:40:18 The primary tool that needs to be implemented is 'pseudo'. There is a darwin port of pseudo -- but recently some Darwin 'security' features have caused pseudo to not longer work in some cases.. Jan 25 15:40:56 Apple doesn't have a defined configuration for allowing the behavior in this new security model -- so it's unclear if it can be fixed in a sustainable way.. (but I don't believe anyone is actively working on it either) Jan 25 15:41:31 it is likely possible to do this with BSD OSes.. (in the past I'd also say Solaris and AIX, but frankly as developmetn machines they're pretty much dead) Jan 25 15:42:31 I doubt Cygwin / mingw32 will ever have all of the facilities we need to make this work... oe-core assumes the filesystem has standard unix permission mechanisms, such as users, groups, octal permission set and xattributes.. Jan 25 15:43:13 may be you can hook up ext3 with windows ext driver ... ? Jan 25 15:43:59 you'd need the filesystem capabilities to write out a file and do things like chown, chmod... Jan 25 15:44:17 since there is no similar capability that I am aware of in cygwin/mingw32 that is a blocker.. Jan 25 15:44:49 Hmm, I think cygwin gives you some of that, which mingw doesn't, we don't leverage the former at all, but not certain. Jan 25 15:44:52 (and of course you'd need to go throught he programs being compiled and make sure they can handle being built on Cygwin/mingw32... it's a problem that luckily is easy to solve with a VM solution.. so it's not been worth the time and effort.) Jan 25 15:45:07 yes Jan 25 15:45:29 Oh, here is question: does the yocto project actually check that all the cross compiled apps run on target as expected ? Jan 25 15:45:34 Darwin/BSD would both be more likely to be made work without a monumental effort.. but again, with VMs being 'cheap'.. it hasn't been anyone's priority Jan 25 15:46:14 the overall community, including the Yocto Project does regularly check the packages are running.. the Yocto Project has specific tests -- but I don't know off hand the test coverage if it's 100% or not.. (even 100% it would be a does it run, not does it function) Jan 25 15:46:44 most of the tests are more around overall system behavior testing which can be used to show that the common workflows and pieces of the system are intergrated and working properly.. Jan 25 15:47:16 The YP does do regular system behavior/integration testing on all four architectures.. then you add in the commercial OSVs, and that expands quickly to include numerous SOCs from various processor families.. Jan 25 15:47:48 fray, how much of oe-core does one need to know, to customize local setup Jan 25 15:48:01 the system also has built in (compile-time) checks that verify certain atrributes are correct that are known, if wrong, to caused problems Jan 25 15:48:24 local setup = produce my custom distro .. Jan 25 15:48:24 customize, not a lot.. you should be familiar with the variable syntax.. recipe format and how to create an image.. Jan 25 15:48:52 ohh and the location of the .conf, configuration files so you can tailor or create new ones..) Jan 25 15:49:23 understanding layers is a next logical step, since for maintenance you don't want to change the downloaded system -- you want to have your own place for custom configurations, recipe changes and other components.. Jan 25 15:49:23 i feel so frustrated with myself :( We've finished a week of Yocto course a few months back, and now i don't know where to start. I find kconfig & make files easier to understand :( Jan 25 15:49:34 much of this is covered in the YP online docs.. Jan 25 15:49:35 (How Timesys Factory does it .. and buildroot) Jan 25 15:50:00 There is a learning curve here.. no doubt about it. The key is this is a distribution builder.. Jan 25 15:50:10 yea ? Jan 25 15:50:12 what you mean Jan 25 15:50:19 in my experience the other systems are less about building custom linux distributions and more about 'configuring someone elses distribution' Jan 25 15:50:42 The place to start in pull down poky -- or bitbake/oe-core and the meta-yocto layers (poky includes all of those in one bundle) Jan 25 15:50:43 fray, could you explain abit on this last point ? Jan 25 15:50:53 someone elses one Jan 25 15:51:02 run the oe-init-env script as show in the docs.. open up the conf/local.conf and start exploring Jan 25 15:51:25 The old model of embedded Linux was.. I'm going to build a single distribution, which cross compiles.. Jan 25 15:51:36 yes Jan 25 15:51:47 ( i did some of those .. by hand :)) Jan 25 15:51:47 The user may be able to change the settings I wish them to change, but it's still realitivity a static distribution.. Jan 25 15:51:57 the common changes would be to the kernel configuration and some select components.. Jan 25 15:52:02 once off , 'cooked' i think its called Jan 25 15:52:17 the user then builds, modifies some runtime settings and you have a cross-compiled Linux system.. Jan 25 15:52:29 the OE based system, you CAN do that if you want.. Jan 25 15:52:59 BUT it also allows you to go much much deeper and define all of the Operating system components and how they interact.. there are a ton more predefined switches.. but you can also add your own switches very easily.. Jan 25 15:53:20 think of it as a bucket of rope.. you can either build fantastic creations -- or hang yourself.. Jan 25 15:53:25 start simple and you'll avoid the later Jan 25 15:53:41 we have a pool of metadata which is shared by different distributions, target hardware, and images, which fosters a great deal of collaboration. lots of projects can work together, despite fairly large differences in goals and markets Jan 25 15:53:44 you need to start with building the system and looking at the local.conf components and getting a feel for what they are doing. Jan 25 15:54:04 then look at the local.conf.extended.sample (I think that is what it's called) for more options.. Jan 25 15:54:35 then start to look at the 'distribution' configuration files (ability to define a custom distro), machine configuration component [if you care about BSPs]... Jan 25 15:54:42 then start to look into recipes... Jan 25 15:54:56 and if you want even further capabilities start to explore the bbclasses and other components.. Jan 25 15:55:00 yea, bsps would be one place I would look into .. Jan 25 15:55:13 a lot of people 'skip' the distribution configuration pieces.. and only care about the local.conf and recipes and that is it.. Jan 25 15:55:28 the BSPs is another topic, and for that I'd refer you to the docs there.. Jan 25 15:55:40 I generally do operating system pieces myself, and stay away from the kernel.. Jan 25 15:55:55 well, i would need to look at many places i guess . like, i find default image size is fat, for e.g., so I would have to start from 0, and add all myself Jan 25 15:56:00 (build system, toolchains, cross compilation issues, sdks, and target software.. but rarely BSP or kernel) Jan 25 15:56:09 then, i want to say modify how intiramfs is created, overlay that Jan 25 15:56:15 then, customize bootloader, .. Jan 25 15:56:21 then .. ouch, lots of places Jan 25 15:56:25 first learn the basics of the local.conf and distro pieces.. Jan 25 15:56:25 we have a lot of images provided. which image are you referring to as 'default'? Jan 25 15:56:36 err, minimal Jan 25 15:56:39 or stripped Jan 25 15:56:43 ya.. and as kergoth aluded to.. there is no 'default' image.. but there are lots of sample images Jan 25 15:57:18 when you get comfortable configuring the system, one of the first thigns to do in you own layer is to define an image recipe.. Jan 25 15:57:45 ah, here is a quick question, i 've asked our consultant but i think he said no: Jan 25 15:57:52 then will let you tailor exactly what you want ont he target... one thing to keep in mind when doing an image recipe. Specify as little and you -need-, this will allow the system to use it's dependency calculations to build it up Jan 25 15:58:03 you never want to start big and pair -down-, it's MUCH harder Jan 25 15:58:27 (core-image-minimal is a pretty good starting point BTW.. it doesn't have a lot of extra stuff..) Jan 25 15:58:28 if i want to have 2 versions of the same image, one release, one debug. but its same target & rest. is that very easy? Jan 25 15:58:42 for some reason way he explained i understood 'no', need to create many configs & stuff Jan 25 15:58:43 depends, what is different between the two? symbols or something more? Jan 25 15:58:51 tools, Jan 25 15:58:55 extra programs Jan 25 15:58:58 extra compiler flags, Jan 25 15:58:59 then you'd create two images.. Jan 25 15:59:11 i.e. my-project-release, my-project-debug Jan 25 15:59:21 so you need to have two setups for images ? Jan 25 15:59:22 the my-project-debug can INCLUDE the my-project-release, and add additional items.. Jan 25 15:59:39 then when you build you can do: bitbake my-project-release my-project-debug -- it'll then build both in a single command Jan 25 15:59:41 i see Jan 25 16:00:16 well, probably all compiler flags are different Jan 25 16:00:17 may be Jan 25 16:00:18 another thing to be aware of.. OE always builds with debug symbols, and then breaks them out into '-dbg' packages with corresponding sources (unless you change the bheavior, which I do NOT suggest you do) Jan 25 16:00:22 and different bootloader options Jan 25 16:00:32 ah Jan 25 16:00:33 different compiler flags is different projects then Jan 25 16:00:34 ok Jan 25 16:00:43 you should -never- have to do that for regular development.. Jan 25 16:00:59 which part ? Jan 25 16:01:04 it IS useful for special cases, but regular development keep it the same.. and only fall back when you have a problem that actually needs custom flags Jan 25 16:01:24 most people with 'custom' flags do things like -O0 vs -O2 or -Os for release.. Jan 25 16:01:35 yea Jan 25 16:01:38 that is lovely, but it changes the behavior of the apps and actually makes debugging MUCH harder in the end.. Jan 25 16:01:43 since you end up with different behavior.. Jan 25 16:01:45 well, Jan 25 16:01:59 like, enable debug symbols, (was it -g?) Jan 25 16:02:02 if you build everything (release and debug) with a single configuration, your -release- code is debuable.. Jan 25 16:02:03 that is not going to release .. Jan 25 16:02:12 everything in the system is build with -g.. and then the symbols are stripped into the -dbg.. Jan 25 16:02:35 don't release the -dbg to your customers.. those stay with you.. then you can cross-debug (or load to the device, say a debug image) the symbols.. and GDB knows how to deal with them Jan 25 16:02:36 ok, but sometimes, on tight system may be go full opt, which is hard to debug Jan 25 16:02:47 (and may be production system is smaller ) Jan 25 16:03:01 this is the whole reason we're built the way we are.. Jan 25 16:03:11 you can do factory image cross-field debugging with the current system.. Jan 25 16:03:30 if loop unrolling, or other GCC optimizations are a problem.. THEN and only then do you build a custom version of the app.. Jan 25 16:05:01 with Yocto, i probably with one command can be building rel|dbg images for different boards, arch too? x86|arm| etc .. Jan 25 16:05:08 so it will generate many images Jan 25 16:05:21 it's more then one command, but you can do it in a single project for different architectures.. Jan 25 16:05:34 (ha, i think that one Timesys can't do.. may be) Jan 25 16:05:37 note though, when you change "MACHINE" (BSP/arch) targets, you have to do so linearly.. it will re-use what it can.. Jan 25 16:05:43 but it does work.. Jan 25 16:05:58 if you look in the local.conf, you'll see: MACHINE ?= "value" Jan 25 16:06:20 MACHINE is defined to only be set to value if not yet defined.. (i.e. here is your default).. MACHINE also is in the list of variables to inherit from the environment.. Jan 25 16:06:22 so you can do: Jan 25 16:06:30 MACHINE=qemumips bitbake core-image-minimal Jan 25 16:06:37 MACHINE=qemuarm bitbake core-image-minimal Jan 25 16:06:49 and you now have a single project that has BOTH a qemumips and qemuarm build in it.. Jan 25 16:06:56 whatever was common between systems will also have been re-used Jan 25 16:07:20 ...but it's linear, not parallel.. we're hoping in the next year to fix that in some way and allow for multiple parallel machines to be built in a single project... Jan 25 16:07:30 (this BTW is NOT a common use-case, but a specialized one) Jan 25 16:07:51 well actually , i think i don't , myself, care too much if its parallel Jan 25 16:08:08 (and moving to my commercial size, this is something that WR 8, based on YP 2.0, supports out of the box) Jan 25 16:08:17 'er.. size -> side.. (I work for Wind River) Jan 25 16:08:31 more that its a single project like , with different targets. but all sources, etc .. is same Jan 25 16:08:37 there are others in here from Mentor, Enea and etc... Jan 25 16:08:44 yes Jan 25 16:10:06 * fray has to go.. Jan 25 16:10:15 others int he channel may be able ot answer further questions Jan 25 16:10:37 fray, thanks ! Jan 25 16:10:39 ciao Jan 25 16:11:18 i myself have to go .. Jan 25 16:18:15 Is there a good way to create a symbolic link in a recipe? Jan 25 16:18:44 "ln"? Jan 25 16:18:54 well, ln -s, obviously Jan 25 16:19:03 Is a link I create there going to be any good on my target system? Jan 25 16:19:17 I just have a ln -s in my do_install step Jan 25 16:19:35 but will that link be preserved in my image and point to the right place? Jan 25 16:19:55 since it's linking two locations in my build directory? Jan 25 16:20:32 (Confession: I'm not sure how symbolic links actually work - do they preserve an absolute path to their target? Won't that path be bad in my target installation since it's... on the target?) Jan 25 16:21:32 symbol links contain whatever you tell them to contain Jan 25 16:21:37 Is there a package that contains fully functional ifup and ifdown executables, the one's in busybox appear to not support dns-nameservers in the /etc/network/interfaces file Jan 25 16:22:01 so it could be a relative path, or an absolute path, just make sure if you use an absolute path it doesn't contain pointers into the build directories Jan 25 16:22:20 there's a tool 'lnr' in oe-core/scripts that is useful here Jan 25 16:22:37 to generate relative symbolic links when given absolute paths Jan 25 16:22:48 (because ln —relative doesn't exist everywhere yet) Jan 25 16:25:19 aside, does it if we drop Debian 7? Jan 25 16:25:51 yeah i was just thinking that Jan 25 16:25:55 quite possibly Jan 25 16:26:05 i know where you're going with this Jan 25 16:27:07 How do I get access to the lnr tool in my build, do I just DEPENDS on it? Jan 25 16:27:45 just run it. it's not a recipe, it's in the scripts dir which is in the PATH Jan 25 16:28:03 oh cool Jan 25 16:28:47 so presumably, if I replace my ln command with that, that will do the trick (Since I'm linking 2 places that are within my rootfs) Jan 25 16:29:31 note that it creates one link at at ime, and the second argument has to be the full path tot he link to create, not a directory to create it in Jan 25 16:29:41 its syntax is rather more limited than gnu ln Jan 25 16:29:44 but yep, its quite handy Jan 25 16:30:25 rburton: :-D Jan 25 16:34:41 build is clicking away, we'll see how it goes. Jan 25 19:37:18 clear Jan 25 19:38:47 When I am writing a recipe, and I'm not sure what's going on, I'd like to be able to print to a log - is there a way to do this easily? I tried to simply cat a file, or echo an error message in a do_install() step, but my message doesn't appear in the corresponding log files in the build directory. Jan 25 19:39:11 I can tell that the do_install step is being executed Jan 25 19:39:32 but nothing is going to the log, even if I try to send it by way of stderr Jan 25 20:00:10 ryansturmer: bbnote, bbwarn, bberror, bbfatal Jan 25 20:00:25 even echo will end up in the log file for hte task Jan 25 20:00:33 but warn, error, and fatal will show up on the bitbake build console as well Jan 25 20:28:44 oooh excellent kergoth Jan 25 20:28:45 thank you Jan 25 20:32:54 Is there a way to affect the order of .bbappends other than layer priority? Jan 25 20:36:24 And while we're on that topic - how is the order of bbappends defined? Is it related to the layer priority? Jan 25 21:14:42 ryansturmer: bbappends are applied in layer priority order, yes Jan 25 21:18:45 I'm having an error in license_create_manifest. The error is almost identical to http://pastebin.com/XF5br7ni but in a different package. I'm at a loss how to even debug it. Jan 25 21:24:11 if I bitbake-layers show-appends : does that squirt out the appends to a specific recipe in priority order? Jan 25 21:29:16 I'm varying my layer priority (by changing BBFILE_PRIORITY in my layer.conf) and the priority change is appearing in bitbake-layers show-layers Jan 25 21:29:43 but it doesn't appear to have any effect on the bitbake-layers show-appends Jan 25 21:29:56 (I would think the appends would be shown in applied order here) Jan 25 21:47:55 Yes, no variation of the layer priority (changing BBFILE_PRIORITY_layername) seems to be affecting the append order - Jan 25 21:48:15 1) Is there a way i can get bitbake to spit out the fully appended do_install procedure to confirm my suspicions? Jan 25 21:48:35 2) Do i need to be doing something to let bitbake know I changed the layer conf Jan 25 22:06:09 gm all Jan 25 22:10:30 hi khem Jan 25 22:14:49 move to hawaii? Jan 25 22:16:49 huh dont you know UGT http://www.total-knowledge.com/~ilya/mips/ugt.html Jan 25 22:17:57 khem: do you happen to have built mtd-utils static against musl? Jan 25 22:18:24 It'd be interesting to compare the size vs. klibc Jan 25 22:18:47 yeah, too tired to think of better joke... Jan 25 22:19:03 ant_home: good question, I havent tried it but should work well Jan 25 22:19:05 khem_, oh, and kexec-tools too Jan 25 22:19:41 ant_home: it might be worth a try to add --disable-shared --enabled-static Jan 25 22:19:45 and see if it works Jan 25 22:19:55 ok, thx. I'm debugging kernel those days..once I have a bit of time I'll do a test Jan 25 22:19:56 for these packages in a local layer Jan 25 22:20:16 you can also hammer in -static to CFLAGS Jan 25 22:20:26 and LDFLAGS Jan 25 22:20:49 should be less awkward than the klcc compiler... Jan 25 22:21:42 it could be Jan 25 22:21:45 yes Jan 25 22:22:07 I'll do that soon Jan 25 22:22:09 but only if you use musl as your system libc Jan 25 22:22:18 i.e. TCLIBC = "musl" Jan 25 22:22:36 yes, last I tried there was some eror with a native package, weeks ago Jan 25 22:22:51 seems fixed by now Jan 25 22:22:53 if you just want to use musl for static parts and glibc for rest then spaghetti remains Jan 25 22:23:01 he he Jan 26 00:40:02 I'm puzzled by the lack of a cortexa7hf-neon-vfpv3 (or even cortexa7hf-vfp-neon) tuning that would seem suitable for Allwinner H3 - and just attempting to define it by cut'n'paste yields a strange "does not contain TUNE_PKGARCH (${ARMPKGARCH_tune-cortexa7hf-neon-vfpv3}hf-vfp-vfpv3-neon)", what am I missing ? Jan 26 00:41:53 hm, "neon" seems to imply simple "vfp", at least Jan 26 02:17:00 yann|work: the tune files could probably be tuned better in some cases Jan 26 02:17:45 the definitions are mostly there; what does your build output say? Jan 26 02:18:48 if you're thinking of flags like neon-vfpv4, fpv5-d16, or even vfpv3xd-fp16, then you need to hack it in Jan 26 02:21:04 cat just ran in the house with a twitching gopher in her mouth... Jan 26 02:21:34 older son (the zooligist) is "handling" it Jan 26 02:22:43 endless fun at my house... **** ENDING LOGGING AT Tue Jan 26 02:59:58 2016