**** BEGIN LOGGING AT Tue Dec 15 02:59:58 2015 Dec 15 08:16:01 What is the cleanest way to add a static ip to boot configuration? Should an existing recipe be appended, or should one create a recipe that installs a custom interfaces file? Dec 15 08:27:37 mrKonge: use a bbappend for init-ifupdown recipe with your custom interfaces file. See for example: https://github.com/netmodule/meta-netmodule-extras/tree/master/recipes-core/init-ifupdown Dec 15 09:53:23 Morning, does somebody have time to help me figure out why a kernel config option I wan't to disable is set back to 'y'? Dec 15 09:54:21 I see a message in the missing_required.cfg where it tells me that the 'Acural value set: "CONFIG_MXC_GPU_VIV=y"' Dec 15 09:54:51 But I have no idea how to figure out, why the option is reenabled during the config step Dec 15 09:57:48 DatGizmo, maybe another kernel features enabled depends on it Dec 15 09:58:30 what recipe, version do you use? Dec 15 09:59:28 aragua yocot is version 2.0, and our recipe is based on the linux-yocto.inc Dec 15 10:00:20 aragua: My problem is, I have no idea how to find out which other config option need the one I want to disable Dec 15 10:01:03 try bitbake -c menuconfig virtual/kernel and help give the dependencies Dec 15 10:03:08 but if you disable the option , quit and then do bitbake -c diffconfig v/k then you must have a correct defconfig Dec 15 10:03:44 In the help for MXC_GPU_VIV I only see, which dependencies this config option has. But I need to know wich other config options have MXC_GPU_VIV as a dependency. Dec 15 10:07:21 ok and if you search for MXC_GPU_VIV , all features depending on it should be displayed Dec 15 10:10:02 wired... the search has only the config option as a result... Dec 15 10:10:49 arf Dec 15 10:10:57 ok Dec 15 10:11:55 do you use a standard defconfig or a custom Dec 15 10:12:36 In the recipe I use KCONFIG_MODE="--alldefconfig" and KBUILD_DEFCONFIG_mx6 ?= "imx_v6_v7_defconfig" Dec 15 10:13:03 And some config fragments to en/disable specific config options Dec 15 10:14:31 did you verifiy with bitbake -e v/k that your fragment is used? Dec 15 10:15:05 yes, it is used, another option i'm disabeling in the fragment works just fine. Dec 15 10:24:00 oh I don't belive it... the config option is hard set to 'y' in a classfile in another layer I need to use. Dec 15 10:25:16 this is the drawback of the concept Dec 15 10:25:46 at least I know now why the option keept setting back to y. Dec 15 10:25:53 aragua: thanks for your help :) Dec 15 10:40:17 sorry if this is too noobish question but im getting "no such file or directory" when i tried run some binaries on jetson pro running on yocto/genivi. Binary is compiled with proper arch, no libraries missing reported ldd either from the actual binary and from 3rd party libs the binaries depend on .. Dec 15 10:40:45 hi everybody Dec 15 10:41:12 can someone help me? i'm looking for a nagios recipes for dizzy Dec 15 10:41:26 i googled with unsuccess Dec 15 11:01:32 maybe try https://github.com/redoop/meta-redoop/tree/master/recipes-monitoring/nagios Dec 15 11:01:50 and adapt depending on issue Dec 15 11:01:56 ilgios, ^ Dec 15 11:02:48 jani, can you be more precise about what do you do to have this error Dec 15 11:03:49 thanks, aragua. i try Dec 15 11:06:46 aragua: solved it .. i was trying to run a binary - found a reason, it was compiled with sfp, not hf. Dec 15 11:57:52 | /home/charl/workspace/fsl-community-bsp/build-ar6mxq/tmp/work-shared/gcc-4.9.2-r0/gcc-4.9.2/libgfortran/../libgcc/gthr.h:148:26: fatal error: gthr-default.h: No such file or directory << Anyone know why 'bitbake libgfortran' fails? Using fido Dec 15 12:12:49 gthr-default.h exists in tmp/work and in the sysroot, so its not like it doesn't exist Dec 15 12:13:35 Is there any nice hack to add a -Ifolder into a .bbappend? Dec 15 12:53:17 There is a comment I read in bb/server/xmlrpc.py "# we don't allow connections if the cooker is running " Dec 15 12:53:32 Is there any issue if we allow connections when cooker is running? Dec 15 13:36:15 hi there ! Regarding BB_NUMBER_THREADS and PARALLEL_MAKE, are these values to be set in local.conf ? Dec 15 13:38:59 PaowZ_: you can yes Dec 15 13:42:17 CTtpollard: thks. Dec 15 14:08:21 PaowZ_: I was wondering the reason for that. Just asking :) Dec 15 14:09:44 sujith_h: regarding what ? the use of these defines or where to add them ? Dec 15 14:12:13 1 Dec 15 14:12:15 I was trying to use xmlrc.py's connect function ( In class BitBakeXMLRPCServerConnection) which was failing. Debugging a bit I found that its because of the if condition in registerEventHandler Dec 15 14:16:15 sujith_h: "running" is a cooker state where a build is in progress Dec 15 14:16:29 sujith_h: it doesn't make sense to allow more connections once something is in progress like that Dec 15 14:17:42 sujith_h: This is related to memory resident bitbake where you wouldn't want to allow knotty to connect to the same server multiple times and try and control it. We did start to create the notion of a read only connection but that work is only partially developed iirc. What issue are you seeing more specifically? Dec 15 14:20:01 RP: I am trying to implement cancellation of build from toaster. While doing so, when I call the connect function from class BitBakeXMLRPCServerConnection, it was causing me trouble in registering event handler Dec 15 14:20:35 sujith_h: doesn't toaster have an open command channel to the build that is running? Dec 15 14:20:58 sujith_h: or are you saying toaster drops that connection once it starts the build? Dec 15 14:22:14 zeddii, you awake? Dec 15 14:24:22 RP: Toaster doesn't drop the connection. I was getting exception when I call establishConnection function which eventually calls connect and registerEventHandle. So I started wondering how to pass runCommand(["stateForceShutdown"]) to stop bitbake server Dec 15 14:25:50 sujith_h: how did toaster start the build? Dec 15 14:26:23 RP: it starts by executing command : bash -c 'source /home/sujith/build/poky-contrib/bitbake/bin/toaster restart-bitbake' Dec 15 14:27:31 sujith_h: that is pretty horrible :( Dec 15 14:27:54 sujith_h: so I'm guessing that starts bitbake using knotty as the controlling UI behind the scenes? Dec 15 14:29:35 RP: I am not that sure about that.. :( Dec 15 14:33:13 sujith_h: I think we may need to enhance the code in bitbake to allow "take over" of a cooker instance if there are only readonly UIs connected, then make knotty connect as a read only UI Dec 15 14:36:08 RP: ok Dec 15 17:53:42 halstead: autobuilder looks like it has diskspace issues Dec 15 17:54:10 RP, I cleared space and messages Ross who started the last build. Dec 15 17:55:12 halstead: thanks! Dec 15 17:55:23 Thank you. Dec 15 17:55:27 halstead: he's afk but I'll restart Dec 15 17:59:14 halstead: any update on openembedded-commits ML? Dec 15 18:01:33 JaMa, I think there are newer hooks to accomplish our goals with that. I'll switch and ask for your help testing. I don't want to leave it broken again. Dec 15 18:05:25 halstead: ok, thanks Dec 15 18:16:16 so about the problems I had with libdrm, now it is fixed when I use the Arago build environment Dec 15 18:16:56 But now I have a problem with omapdrm-pvr and functions not defined in the kernel, can I get help here or should I write on Arago's mailing list? Dec 15 18:23:22 Anarky: SGX driver (omapdrm-pvr) is quite fragile and is currently in a transitional stage to get unified across our platforms. at the moment it requires specific kernel version. Dec 15 18:23:55 Anarky: you can get more info on meta-ti list, if interested Dec 15 18:27:06 denix: thank you for the information; so as of now, is it possible to have Qt5 (or kmscube) working for a TI A15 board? Dec 15 18:28:24 denix: I have a lot of errors if I try to start kmscube, even pvrsrvinit doesn't seem to work Dec 15 18:30:17 why can't I menuconfig uclibc ? ERROR: uclibc was skipped: incompatible with host Dec 15 18:30:21 Anarky: yes, Qt5 and kmscube work just fine on X15 platform - all that is part of our product offering Dec 15 18:31:34 Anarky: please send your specific errors to meta-ti list - we may be able to help you Dec 15 18:43:55 denix: oh, are you talking about the BeagleBord X15? I have both but I was trying with the OMAP5432 uEVM (A15) Dec 15 18:45:20 Anarky: ah, haven't tried that on uEVM lately, but in general it should work Dec 15 18:46:35 denix: ok, I'm trying with the X15 and will post the results Dec 15 18:48:05 denix: just to be sure, omapdrm-pvr and pvrsrvinit are necessary to load/start to get kmscube working? Dec 15 18:48:19 yes Dec 15 19:27:20 should DEPENDS="virtual/kernel" cause the package to rebuild between machines? Dec 15 19:38:14 morning all Dec 15 19:39:12 bluelightning: NZ morning? :) Dec 15 19:39:24 denix: indeed, but also UGT ;) Dec 15 19:40:20 bluelightning: ah, right :) Dec 15 19:41:34 bluelightning: maybe you know the answer - should DEPENDS="virtual/kernel" cause the package to rebuild between machines? Dec 15 19:42:46 denix: it should I believe, are you finding it is or isn't? Dec 15 19:45:28 bluelightning: it does. but then shouldn't all packages that depend on virtual/kernel be semi-automatically marked as machine-specific (PACKAGE_ARCH=MACHINE_ARCH)? Dec 15 19:45:56 I don't think we have that functionality, though we probably ought to Dec 15 19:46:29 IIRC that only happens automatically through machine-specific FILESOVERRIDES and SRC_URI Dec 15 19:46:39 Is it possible to specify a different virtual/kernel recipe via an image recipe, or am I only stuck defining that in a machine definition? Dec 15 19:47:33 deviosity: I'm afraid that needs to be specified at the configuration level; the image cannot affect anything within other recipes - it only chooses the composition of the image Dec 15 19:47:57 bluelightning: ok, I didn't mean to do it automatically, but in general, that's the correct way, right? should then recipes (such as ipsec-tools from meta-oe) be updated to make them machine-specific? Dec 15 19:48:04 so either local.conf or via machine? Or is there another method I am missing Dec 15 19:48:50 deviosity: there's effectively no difference from bitbake's perspective between local.conf and the machine. it's set in the configuration metadata either way Dec 15 19:48:57 local.conf and ${MACHINE}.conf are both included by bitbake.conf Dec 15 19:49:17 as bluelightning says, that's where it has to be set, at the configuration level Dec 15 19:49:43 denix: possibly yes - I do think we ought to have a wider look at this whole problem; ideally we wouldn't have to go around being explicit about PACKAGE_ARCH (and silly things like python recipes being arch-specific purely because they depend on python) Dec 15 19:49:52 basically I need to maintain two different images, but they need different kernels due to differing functionality. Dec 15 19:50:04 then you'll need two machines Dec 15 19:50:31 multiple kernel support is being discussed on the mailing list right now, as it happens Dec 15 19:50:50 deception: either 2 machine configs or build in separate work directories and switch preferred provider Dec 15 19:50:50 on an unrelated note, I threw together this prototype of something, but I can't decide if it's actually of any real use: https://github.com/kergoth/meta-named-configs-prototype#ii-usage, https://github.com/kergoth/meta-named-configs-prototype/blob/master/recipes-core/busybox/busybox_1.23.2.bbappend Dec 15 19:50:52 that's what I thought, I was hoping there may have been some hidden secret somewhere. Dec 15 19:51:15 unfortunately it's rather complicated; just one issue is that there are lots of things that depend on files from the kernel in the sysroot - and which kernel should be used for that when there's more than one? Dec 15 19:52:10 and yes, as bluelightning said, building multiple kernels for the same machine is being discussed on the list right now :) it's a hot topic it seems Dec 15 19:52:45 kergoth: interesting - I had an idle thought about using BBCLASSEXTEND for this some years ago but it never went beyond that Dec 15 19:52:58 Glad there is dialog around it, but unfortunately by the time it is implemented, I'll probably have the drivers I need ported or available in the mainline kernel. :) Dec 15 19:54:56 bluelightning: the basics turned out to be quite simple (as seems to be often the case with that sort of thing). it adds the base recipe to PROVIDES and adds the base packages to RPROVIDES/RCONFLICTS/RREPLACES for all the parse time known packages. doesn't handle dynamic yet, planning to inject a packagefunc for that.. Tested building core-image-base with busybox-minimal instead of busybox, which worked after setting the appropriate VIRTUAL-RUNTIME Dec 15 19:54:59 kergoth: s/propogate/propagate/ in https://github.com/kergoth/meta-named-configs-prototype#iii-limitations Dec 15 19:55:02 I just don't know if it'd be useful in practice.. Dec 15 19:55:04 ah, thanks Dec 15 19:55:08 yw Dec 15 19:56:38 kergoth: super useful Dec 15 19:58:17 bluelightning: as of kernel deps - would it be safe to add the specific kernel recipe name to ABISAFE list, as long as both machines use it from the same source tree with the same configuration? Dec 15 19:59:15 I was just thinking how I would manage my u-boot configs, and custom files due to how the 3.x series kernels work versus the 4.x Dec 15 20:02:43 kergoth: that is interesting... Dec 15 20:03:04 kergoth: did you see the - patch? curious if you agree its a good thing or not... Dec 15 20:03:14 haven't seen it, will take a look Dec 15 20:03:39 kergoth: I keep getting asked for something like this but have held off until this idea of syntax came to mind... Dec 15 20:04:28 the one thing i'm not sure about with the config variants thing is how to make it easy to switch back and forth at runtime with a feed. i think i'd need the rconflicts/rreplaces also set in the non-variant recipe, with the names of all the variants, otherwise i don't think you could switch back from a variant to the main recipe, and switching between variants could be problematic too unless they all refer to one another, but that's theoretical, untested Dec 15 20:04:48 oh, that's interesting. so you could e.g. populate the sstate for an image without building the image itself Dec 15 20:04:58 kergoth: right Dec 15 20:05:12 seems like sane syntax, I like it Dec 15 20:05:29 kergoth: It seems to fit the rest of the system, slightly crazy but effective :) Dec 15 20:05:38 heh, indeed :) Dec 15 20:06:59 The other thing I was experimenting with using bbclassextend to generate recipe variants was to cover a case where you can legally distribute binaries of something, but not its sources. so it generates variants to explicitly generate a tarball of the binary output and then use that in the binary-only variant, so your CI or release builds could explicitly build the source-to-binary variants and then ship the binary tarballs with the sources Dec 15 20:07:08 haven't worked all the kinks out of that one yet Dec 15 20:07:16 kergoth: changing named configs might not make too much sense with packagefeeds... Dec 15 20:07:42 kergoth: you'd certainly not want to be doing that often Dec 15 20:08:17 kergoth: the other way of solving the binary thing would be locked sstate objects in some form Dec 15 20:08:21 I think it could be useful for folks that want to build images from feeds, just select your provider at that level Dec 15 20:08:57 kergoth: agreed on that, but the system would uninstall any unwanted packages from the feed anyway Dec 15 20:09:00 Hmm, that's true. But of course our locking system today only allows aborting a build on the checksum changing, not forcing their use despite the change :) Dec 15 20:09:18 kergoth: the design actually allows you to force a checksum Dec 15 20:09:24 kergoth: just nobody is doing that Dec 15 20:09:44 I'm 99% sure I've done that locally during testing Dec 15 20:10:05 kergoth: the named config thing reminds me of what I'd like to do with bitbake to extend to multiple configurations in one runqueue and finally get multimachine builds as a side effect Dec 15 20:10:41 kergoth: the main problem is the syntax for it and the fact we'd have to support multiple data stores properly in the core Dec 15 20:10:57 denix: I'm not sure they are completely ABI-safe in this case though Dec 15 20:11:31 or the alternative is we make MACHINE and DISTRO very late includes instead of the way they work today I guess Dec 15 20:11:38 then they'd become BBCLASSEXTEND capable Dec 15 20:12:20 Hmm, yes, that does sound interesting. I'd worry about some of the remaining semi-global state we have, like the events system, unless the runqueues are handled in different processes. It could be interesting to attach the events to the metadata Dec 15 20:12:39 kergoth: force use despite checksum changing does work, at least last I tested it Dec 15 20:13:14 kergoth: the code doesn't have an explicit option for "don't warn" in that circumstance, but it turns out you can set the variable to any other value and that will be the result because it doesn't validate it ;) Dec 15 20:13:26 we should probably fix that Dec 15 20:16:28 bluelightning: by "this case" do you mean ipsec-tools specifically or dependency on kernel in general? Dec 15 20:16:30 is force use global across all the locked checksums? if so, that'd be of somewhat limited usefulness, IMO. I think there are recipes I'd want to force, and recipes I'd want to fail if they change. For example, consider a case where we don't want rebuilds, and don't want the person downstream to be changing those things, but we want to allow forcing a single checksum to build a CVE fix for a single recipe. Dec 15 20:16:55 * kergoth ponders Dec 15 20:17:20 denix: ipsec-tools... if it depends on interfaces in the kernel then it's not going to be safe against any changes in that interface Dec 15 20:18:03 denix: the problem with SIGGEN_EXCLUDERECIPES_ABISAFE is it effectively says there will be no ABI issue ever, which is hard to be sure of Dec 15 20:21:49 bluelightning: we've discussed this topic before using oprofile as an example. khem was claiming it should be safe to re-use the same binary between kernels... unfortunately I ran out of time then and ended up with oprofile.bbappend to PACKAGE_ARCH=MACHINE_ARCH... Dec 15 20:23:20 denix: right, it's a long standing problem... I just think somewhere in here there's an architectural problem to be solved rather than band-aiding it every time it breaks, but I'm not quite sure how at the moment Dec 15 20:24:12 bluelightning: ok, I see your point about ABISAFE - it will potentially mask real ABI changes for other packages... :( Dec 15 20:25:24 unfortunately yes Dec 15 20:26:40 there is also SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS for specific relationships between two recipes, but that still has problems if that ABI ever changes in future Dec 15 20:27:22 bluelightning: is there a bugzilla to track this "architectural problem" or should we start another discussion on the new Architecture list? :) Dec 15 20:28:26 there isn't... we probably ought to have one, although it would be nice to have some idea of how we might solve the issue first assuming it's practical to do so Dec 15 20:31:04 bluelightning: how does libc handle kernel ABI and any potential changes? it's not machine-specific... Dec 15 20:31:25 that is the key part of the issue, its a question of a workable way of dealing with the problem Dec 15 20:32:08 denix: libc has pretty strong version checks and is compiled to work with a certain kernel version range. The kernel syscall API is also pretty backwards compatible Dec 15 20:32:10 I think the only viable option would be to have some sort of abi / output analysis / tracking so we can determine when a build resulted in changed output, but we'd need either pluggable methods to anlalyze different types of output, or we'd need fully bit-for-bit ReproducibleBuilds, or both Dec 15 20:33:10 I know we've started looking at binary reproducible builds but it will be a long haul Dec 15 20:34:08 debian is making good progress, but every single package needs fixing up on a per-package basis, it seems Dec 15 20:34:23 well, not every, but a hell of a lot :) Dec 15 20:34:31 they have good tools for comparing build output and stuff for that project though Dec 15 20:34:52 kergoth: right, its going to take a while. We looked as we'd like to feed that data into PR Server Dec 15 20:34:55 kergoth: any links to read up on that debian work? Dec 15 20:34:58 https://reproducible.debian.net/, https://reproducible.debian.net/dbd/unstable/amd64/avrprog_0.2.2-2.diffoscope.html Dec 15 20:35:07 thanks Dec 15 20:35:07 https://wiki.debian.org/ReproducibleBuilds Dec 15 20:37:20 I think a good start would be to initiate a project to make bitbake able to dynamically adjust the runqueue based on some form of pluggable output check. assume everything needs to be rebuilt if something it depends on changes its input checksum, but break that point in the chain if its output is identical to previous Dec 15 20:37:33 whether we just checksum the binaries or use some form of abi comparison, we'd need that either way Dec 15 20:37:53 afaict anyway Dec 15 20:39:48 kergoth: there is a bit of a conflict here since you really need to know what the task graph looks like in advance? Why? So you can build in parallel. For example if you need to build the git based recipe X, you need git-native and would want to build that in advance if you can Dec 15 20:40:22 kergoth: not disagree, just saying that output based changes to the task graph are rather problematic :/ Dec 15 20:40:43 kergoth: we have this issue with sstate too, we can't tell in advance which sstate will be available and therefore how much we need to download Dec 15 20:41:08 e.g. if the sstate for X failed to unpack, we'd need git-native from sstate, otherwise we might not Dec 15 20:41:44 which is why sstate doesn't download everything at once but does it in stages Dec 15 20:43:57 I don't really see a problem with that. Assume its tasks are being rebuilt, so build or pull from sstate things like git-native, worst case we don't end up needing them if the graph gets short-circuited. It might not be perfect, but you'd still avoid rebuilding/building much Dec 15 20:44:44 * kergoth shrugs, clearly a lot would need to be worked out, non-trivial Dec 15 20:45:28 kergoth: my experiences with sstate suggest the amount that would be rebuilt or even downloaded from sstate is significant :/ Dec 15 20:45:48 kergoth: as you say, a lot would need to be worked out, just sharing what I've seen... Dec 15 20:47:31 the alternative would be to assume that the tasks depending on a changed task don't need to be rebuilt until we build it and check its output, but then you'd need to dynamically add to the runqueue, and you could potentially underuse your resources until those tasks are run, so they'd have to be prioritized. regardless, i'd expect it to be opt-in Dec 15 20:49:10 I'd definitely like to experiment with this; finding the time is a problem though Dec 15 20:50:14 I suspect the best way of moving towards this would be to scrap the setscene stage and have that happen dynamically throughout the build Dec 15 20:50:39 then the equailvalence of output becomes a mapping between two different sstate checksums effectively Dec 15 20:51:20 what scares me is we once tried setscene dynamically in the build and it was a nightmare. Admittedly we have a lot better system to start with now at least Dec 15 23:02:26 hmm, odd, buildhistory-collect-srcrevs is emitting an srcrev for this recipe without specifying -a when the recipe has SRCREV set, it's not using AUTOREV Dec 15 23:18:04 ah, i see, it compares the unexpanded and expanded form, so any intermediate variable use in SRCREV causes it to be emitted by collect-srcrevs by default, autorev or no Dec 15 23:18:07 good to know Dec 16 01:01:37 So is MACHINE="foo" bitbake core-image-base supposed to be able to change the MACHINE type for bitbake. Dec 16 01:02:23 I tied exporting, and using BB_ENV_EXTRAWHITE, and it completely ignores any MACHINE variable i used on the command line **** ENDING LOGGING AT Wed Dec 16 02:59:59 2015