**** BEGIN LOGGING AT Thu Nov 05 03:00:15 2015 Nov 05 08:10:49 good morning Nov 05 09:18:51 morning all Nov 05 09:21:41 why is the default tune for cortexa5 armv7a-neon? Nov 05 09:21:59 I think this is the worst possible one Nov 05 09:22:36 anything useful in git blame? Nov 05 09:23:36 mornin Nov 05 09:24:56 actually, this is the same for all cortex*.inc Nov 05 09:25:19 I'm not exactly sure why anybody would really want to use neon as the fpu Nov 05 09:25:56 especially since 1/ all socs don't have neon and 2/ an other FPU is available when you have neon Nov 05 09:28:02 and the last point being that neon is not ieee compliant, so gcc doesn't actually do any optimisations Nov 05 09:33:10 a11bdc36a1be18cc5aa14682b2a2c9ee83141f51 Nov 05 09:36:06 JaMa: any thoughts? ^ Nov 05 09:37:28 If that was for compatibility with existing feeds, then that is probably fine Nov 05 09:37:37 but it is an unfotunate choice Nov 05 09:39:40 morning Nov 05 09:42:44 bluelightning: why doesn't SRC_URI_ti33x += "myvalue" from a .bbappend append to SRC_URI? Why do I have to use SRC_URI_append_ti33x += "myvalue"? I read the bitbake manual, and it clearly states += should append to the variable (surrounded by spaces). What am I doing wrong here? Nov 05 09:43:14 mago_: because overrides and += operate at different times, leading to a result which is not the one you want Nov 05 09:43:43 mago_: += operates at the time the statement is parsed, the override is applied effectively at the end Nov 05 09:43:44 okay, so += will run before the original recipes SRC_URI = "" ? Nov 05 09:44:05 why are .bbappends parsed before .bb then? Nov 05 09:44:45 mago_: so what you're saying is, *set* SRC_URI_ti33x to "myvalue" then later when overrides are processed, ti33x is (presumably) in OVERRIDES and thus that value completely overwrites SRC_URI Nov 05 09:45:11 technically it gets set to " myvalue" due to the += Nov 05 09:45:44 bbappends are absolutely not parsed before the main bb, it's the other way around Nov 05 09:46:17 ah, i see! Nov 05 09:46:30 basically if you use overrides at all you need to use _append so that the override and the append actually work together Nov 05 09:46:50 well, if you use overrides and you want to add to the existing value Nov 05 09:47:26 hehe.. who thinks we have a fairly complex variables handling ;-) Nov 05 09:47:32 oh, we definitely do Nov 05 09:48:04 it's the unfortunate consequence of handling everything people want to handle (as well as borrowing concepts from probably more than one other system) Nov 05 09:48:27 mago_: you'd also typically do ..._append = " myvalue" rather than ..._append += "myvalue" Nov 05 09:49:20 why? Nov 05 09:49:31 since the += isn't going to do anything useful apart from adding the space, at which point you might as well just be explicit and then it's obvious Nov 05 09:49:38 it there a sanity-checker for this somewhere hidden in meta-oe-core/scripts? :) Nov 05 09:49:59 not for this kind of thing no Nov 05 09:51:41 there was some discussion on layer validation at OEDEM, potentially this sort of thing could go in there though it's less of an actual issue than the problems that script is proposed to pick up on (e.g. BSP layers that don't bother to use overrides and therefore make changes when the relevant machine isn't selected) Nov 05 09:51:49 bluelightning: another thing, if i want to append to a task for a specific machine, like so: do_install_append_mymachine() { .. } .. how would i do it if i want to apply the same override for 2 machines? do i need to duplicate the entire task? Nov 05 09:52:18 there are several ways you could avoid that Nov 05 09:52:32 you could have a common override set by both machines and then use that Nov 05 09:53:02 or, you could move the content you're appending to a separate function and then call that from both machine appends Nov 05 09:53:38 there are one or two other ways I can think of but they are less tidy Nov 05 09:54:43 another thing you could consider is use conditionals in the appended function rather than conditional appends Nov 05 09:55:34 but then your bbappend would be affecting the function unconditionally which could be a bad thing Nov 05 09:55:52 (affecting its signature, that is) Nov 05 09:58:28 okay Nov 05 09:58:34 if you find yourself needing to do this in a few places the common override is probably the way to go Nov 05 09:58:55 i think moving the function body to a separate function and then calling that from each machive append appeals me the most Nov 05 09:59:52 right, it's certainly straightforward Nov 05 09:59:59 yeah, the way we do it now is to override on the arch instead of the machine. it's OK since all our machines on the same arch are more or less the same boards. but if someone were to make a completely different board with that arch some day, we would be in trouble Nov 05 10:01:35 right, indeed Nov 05 10:05:21 abelloni: bluelightning: this commit didn't add neon, it just switched the default to more generic one to re-use binary feeds between different MACHINEs Nov 05 10:05:34 you need to git blame a bit deeper Nov 05 11:02:15 JaMa: hello, just answered you about gnome-vfs Nov 05 11:05:25 I want to add a new library as a dependency to another package, should that be 2 commits (library, then dependency) or 1 ? Nov 05 11:07:39 funman: doesn't matter, but if 2 commits then library first :) Nov 05 11:07:48 eheh sure Nov 05 11:08:03 how do commits migrate (or not) from master-next to master? Nov 05 11:09:21 when there is no negative feedback and all my jenkins builds don't find any issues I cherry-pick OK commits from master-next to master Nov 05 11:16:11 hm weird: WARNING: QA Issue: vlc rdepends on libdvbpsi, but it isn't a build dependency? [build-deps] Nov 05 11:27:23 funman: why weird? Nov 05 11:27:34 funman: probably needs another PACKAGECONFIG for dvbpsi Nov 05 11:27:59 weird because I had just added it, I probably started bitbake before writing my changes to vlc.inc Nov 05 11:28:06 now I don't see this error anymore Nov 05 11:49:44 funman: presumably vlc auto-detected it Nov 05 11:56:04 yes Nov 05 12:13:02 whats the recommended way of deploying oe images to a device? is there a generic tool? that handles stuff like tftp transfer, dfu, u-boot commands etc Nov 05 12:13:37 I'm not sure if there is one generic tool, no Nov 05 12:14:23 we've written one for our devices, but we're having problems packaging it so the tools is version-matched with our dist releases Nov 05 12:14:53 basically, deploytool version X works with distro release Y Nov 05 12:18:09 distro being your distro or host distro? Nov 05 12:18:18 my distro Nov 05 12:19:05 I guess you'd have to expand on the problem because at the moment I'm not quite followin Nov 05 12:19:07 g Nov 05 12:23:41 well, our tool to deploy images to devices runs u-boot commands on the device to initiate tftp transfers etc. we recently did some changes to the u-boot macro for deploying stuff, and changed the deployment tool to match that. It breaks backwards-compatibility, so the latest deployment tool is unable to deploy images to older u-boots (because it doesn't have the new macros). For this reason, we need to make sure Nov 05 12:23:42 users use the older version of the deployment tool on distro versions with the old u-boot, and the new deployment tool on the latest distro version. Basically, we want to make sure users use the correct deployment tool version for the distro version they are using Nov 05 12:23:57 one could argue that we shouldn't be breaking backwardscompatibility in the first place, but in this case we must do it Nov 05 12:25:45 i noticed dfu-util-native recipe in oe-core installs itself to ${DEPLOY_DIR_TOOLS}, what is the purpose of this folder? What would happen if I wrote a bitbake recipe that installs our deployment tool here, and make sure the PATH is setup to look for host tools here? Nov 05 12:28:11 I think DEPLOY_DIR_TOOLS is something that was set up a long time ago but AFAIK it's very rarely used Nov 05 12:28:57 you say it's in OE-Core but I don't see any reference to that var there other than setting it in bitbake.conf Nov 05 12:30:58 sorry, it's in meta-openembedded/meta-oe/.. Nov 05 12:31:23 ah right, yes Nov 05 12:31:45 so for a lot of this kind of thing elsewhere we are simply using the native sysroot Nov 05 12:31:59 e.g. runqemu looks for tunctl there, wic looks for all the tools it needs there, etc. Nov 05 12:32:51 ah, okay. i see, so you have wrapper-scripts that setup PATH to point to native sysroot and then launch the app? Nov 05 12:34:12 our deployment tool is python-based, so ideally we would like a deployment tool native recipe that installs it into the native sysroot, RDEPENDS python-native. And then we would have a small shellscript in our meta-layer that just launches "$SYSROOT/python $SYSROOT/deployment-script.py"? Nov 05 12:40:39 mago_: well not really, the assumption is that you have run the env setup script (e.g. oe-setup-build-env) first Nov 05 12:40:58 and then you can get bitbake to tell you where the native sysroot is Nov 05 12:44:09 bluelightning: just so that i understand how runqemu works: 1) oe-setup-build-env is sourced, sets up PATH to bitbake and oe-core/scripts 2) user runs "runqemu", it launches bitbake to figure out SYSROOT and then launches qemu from that location 3) if user did not yet build qemu-native, runqemu will run bitbake to build it? Nov 05 12:44:43 correct except for 3 Nov 05 12:44:54 if it's not built, it'll just bail out and tell the user what they need to build Nov 05 12:45:31 ok, so in that case i can probably do the same for our deployment tool. Sounds good Nov 05 12:45:57 you may find tinfoil useful rather than bitbake -e for grabbing var values btw Nov 05 12:46:23 a bunch of our scripts do still use bitbake -e but tinfoil is neater (and a bit faster) Nov 05 12:46:43 * bluelightning goes to find a suitable example Nov 05 12:46:48 ah, okay. great. I use bitbake -e in our buildscripts atm, will look into tinfoil instead Nov 05 12:48:20 mago_: scripts/oe-pkgdata-util is probably worth looking at for an example of using tinfoil to just grab a variable value Nov 05 12:48:29 thank you Nov 05 12:49:24 bluelightning: .. but tinfoil is python only? i would prefer if python was not a host dependency Nov 05 12:49:35 .. but then again, bitbake is python *doh* :D Nov 05 12:49:46 (nvm) Nov 05 12:51:19 oe-core/scripts/oe-find-native-sysroot seem useful for me Nov 05 12:51:25 heh Nov 05 12:51:30 right yes there's that too Nov 05 12:51:57 personally I prefer to write these kinds of scripts in python, shell is just a bit painful for anything non-trivial Nov 05 12:51:59 but that's just me Nov 05 12:52:01 brb Nov 05 12:52:50 funman: I've squashed those 2 vlc gnome-vfs commits in master-next, you don't need to resend Nov 05 12:54:43 * Crofton|work needs to fight llvm some more Nov 05 13:27:05 if i BBCLASSEXTEND = "native" in a recipe that RDEPENDS_${PN} = "python-othermodule", do I have to specify RDEPENDS_${PN}_class-native = "python-othermodule-native" \ RDEPENDS_${PN}_class-target = "python-othermodule", or will this be implied by going native? Nov 05 13:27:25 (e.g will a native recipe automatically add -native to all RDEPENDS?) Nov 05 13:58:14 JaMa: thanks Nov 05 14:00:20 JaMa: oops Nov 05 14:07:27 mago_: well, RDEPENDS don't really make sense in the native context Nov 05 14:08:02 having said that, yes they are mapped Nov 05 14:17:39 bluelightning: why is not RDEPENDS applicable in native? they should just be treated as DEPENDS? Nov 05 14:24:43 mago_: well, let's just assume they were applicable, leaving aside that RDEPENDS deals with packages and there is no packaging for native recipes Nov 05 14:26:25 mago_: in that case if a-native RDEPENDS on b-native, then "runtime" would effectively be build time, since runtime for native is running things from the sysroot i.e. a-native's do_configure needs b-native's do_populate_sysroot Nov 05 14:26:33 mago_: which is exactly what DEPENDS does Nov 05 14:27:32 I've just tested, RDEPENDS has no effect on task dependencies for native recipes Nov 05 14:28:11 bluelightning: so if i want to make sure other python modules are installed into native sysroot for my python program, i should DEPENDS_class-native = "..." ? Nov 05 14:28:35 bluelightning: btw, do you know where the root-user account is created and why its home is set to /home/root and not /root (which is more common)? Nov 05 14:28:59 mago_: I believe so yes Nov 05 14:30:22 mago_: largely historical reasons; the idea was all home directories should be able to be together on their own partition/device Nov 05 14:30:40 mago_: we have a variable ROOT_HOME that you can set to change it to /root in your distro config if you prefer Nov 05 15:05:28 bluelightning: if i want to run python from the sysroot, do i manually need to setup the PYTHONPATH to point into the sysroot or is there a way i can run native python with the "correct" sysroot environment? Nov 05 15:07:02 can anyone point me where the code is that displays the list of layers with their git/SCM ids at the start of every build? Nov 05 15:11:49 fray: repo status? Nov 05 15:12:08 (that would be with angstrom) Nov 05 15:13:12 . Nov 05 15:15:43 mago_: just inherit pythonnative for that I think Nov 05 15:30:58 bluelightning: hum, how does that work? isn't it a python thing? i mean if i just run python from the sysroot, it has nothing to do with my python module (where i've inherited pythonnative?) Nov 05 15:31:47 mago_: I assumed you meant in the recipe context; are you trying to run it from outside? Nov 05 15:32:33 bluelightning: yeah, i'm trying to do that runqemu scheme we talked about :) basically 1) discover sysroot path using bitbake 2) run python-native with a native python-script (installed by a python recipe) Nov 05 15:34:18 I'm not sure but I'm guessing you'd ensure PATH and PYTHONPATH and/or PYTHONHOME Nov 05 15:34:29 (ensure they are set, I meant) Nov 05 15:35:11 okay. then i don't see the point in ever building python-native? since python is always on the host? Nov 05 15:36:43 python-native is *required* by python, to cross-compile we need a python we can run with a matching version and which obeys sysroot paths for the sys module. beyond that, its debatable Nov 05 15:36:47 * kergoth yawns Nov 05 15:36:50 version sanity Nov 05 15:39:48 funman, no when you run bitbake ... it prints out the SCM information for each included layer Nov 05 15:40:14 i.e. Nov 05 15:40:18 TUNE_FEATURES = "m32 i586" Nov 05 15:40:19 TARGET_FPU = "" Nov 05 15:40:19 meta = "jethro:4a8f2f24adcb8bacd8c32ad7b3d6c2f0ac422603" Nov 05 15:40:57 I'm looking for the code that actually prints out those values Nov 05 15:41:12 fray: metadata_scm.bbclass, iirc Nov 05 15:41:45 (I've got some non-git branches.. and it's spitting out errors.. and I'm trying to determine if it's an OE bug or if it's a local bug) **** BEGIN LOGGING AT Thu Nov 05 23:50:43 2015 **** ENDING LOGGING AT Fri Nov 06 02:59:58 2015