**** BEGIN LOGGING AT Thu May 12 02:59:58 2016 May 12 05:24:21 hm how do I enable dhcp at boot if I add systemd to the DISTRO_FEATURES? May 12 05:26:07 is it enough to add networkd resolved to the systemd packageconfigs, or is there a better way? May 12 11:09:40 JaMa: ping? I'd like to try and get a patch into fido that removes the ABI breakage. Seems like doing as you have locally and partially reverting the version-script change is the best solution for fido. Would you be willing to submit your patch? May 12 11:21:37 joshuagl: remove the version-script change and add this: May 12 11:21:40 ++OPENSSL_1.0.2g { May 12 11:21:40 ++ global: May 12 11:21:40 ++ SRP_VBASE_get1_by_user; May 12 11:21:40 ++ SRP_user_pwd_free; May 12 11:21:40 ++} OPENSSL_1.0.2; May 12 11:21:44 to fix the build May 12 11:25:03 it was also reported by Andre 2 months back but without any feedback: http://lists.openembedded.org/pipermail/openembedded-core/2016-March/118433.html May 12 11:38:00 JaMa: thanks, that matches the changes I have queued locally May 12 11:42:08 JaMa: FYI here's what I'm testing atm: http://git.openembedded.org/openembedded-core-contrib/commit/?h=joshuagl/fido-next&id=9e27ba10f59c383746958e0355fd48e7288465aa May 12 12:38:19 this morning's raspi2 build: "Error, the PACKAGE_ARCHS variable ... for DEFAULTTUNE ... does not contain TUNE_PKGARCH" May 12 12:38:33 built fine yesterday morning May 12 12:44:37 tlwoerner: well something must have changed... May 12 12:44:50 tlwoerner: bad karma. May 12 13:34:47 does anyone here understand cmake? May 12 13:35:08 no May 12 13:35:12 what is the problem May 12 13:35:28 it's arse May 12 13:36:08 heh May 12 13:36:12 the old need to build a tool to build the code problem, need to build a single binary in the cmakelists with the host compiler instead of cross May 12 13:36:32 hmm, I think I have an example May 12 13:37:12 https://communities.intel.com/thread/62847?start=0&tstart=0 May 12 13:37:16 I better read this :) May 12 13:38:15 https://github.com/balister/meta-sdr/blob/master/recipes-core/gnuradio/gnuradio_git.bb#L42 May 12 13:38:19 does this help? May 12 13:38:45 not really, said binary is a sod May 12 13:39:09 but if i do need to build it by hand, that would be useful, so thanks May 12 13:39:22 I sense it is making you angry May 12 13:39:32 yes May 12 13:39:43 well good luck May 12 13:39:46 can't stand cmake May 12 13:40:04 I am lucky that when i have had to do this the binary is easy to build May 12 13:40:19 this is some epic binary of doom that links to so much May 12 13:40:20 I suffer with it after gnuradio switch from an awful configure.ac to cmake May 12 14:23:33 I'm seeing errors from pseudo during do_rootfs when trying to build on a freshly installed F23 machine, anyone seen anything like? May 12 14:23:34 No real function for mknod: /srv/builds/oecore/tmp-glibc/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64/libpseudo.so: undefined symbol: mknod May 12 14:23:46 fray: perhaps? ^^ May 12 14:45:04 joshuagl, still have psuedo issues? is this a fresh pseudo build or a re-use from an sstate-cache? May 12 14:45:22 pseudo dynamically determines some symbols during build and runtime.. if the glibc version changes, the symbols could have been invalidated.. May 12 14:45:28 the other possibility is selinux is restricting something May 12 14:45:40 if it's a fresh build, then I have no idea May 12 14:45:43 fray: fresh build, could easily be SELinux though. Let me try disabling that May 12 14:45:47 (other then try turning off SE Linux) May 12 14:46:15 (my main build system BTW is Fedora 23.. but it was last updated about a month ago) May 12 14:48:44 fray: hrmm, SELinux is in permissive May 12 14:49:23 what version of glibc is installed? May 12 14:49:31 [mhatle@msp-dhcp15 wr-sdk-toolchain]$ rpm -q glibc May 12 14:49:31 glibc-2.22-11.fc23.i686 May 12 14:49:31 glibc-2.22-11.1.fc23.x86_64 May 12 14:49:41 (as I said, mine is a month or so old) May 12 14:59:29 I have glibc-2.22-15.fc23.x86_64 May 12 14:59:56 maybe something broke? May 12 15:00:05 (I'm not currently in a position to be able to upgrade) May 12 15:00:27 fray: ack, I'll keep prodding May 12 15:01:06 BTW on mys ystem May 12 15:01:06 SELinux status: disabled May 12 16:29:51 why all these security solutions are so hard to use ? May 12 16:30:25 is it job security May 12 16:31:06 yes May 12 16:32:52 for life of me I could never get selinux to work to that extent that I stopped using distro which enabled it by default May 12 16:33:43 nothing beats writing secure code. May 12 16:36:15 rburton: did you make further progress with clang May 12 16:37:17 khem: managed to add enough hacks to my clang-using tool that i don't need llvm-config for the target anymore May 12 16:37:30 khem: (but we really need a cross llvm-config) May 12 16:37:40 yeah ok llvm-config is a helper anyway May 12 16:38:26 yeah, this package uses it to get the crazy long link list for -lclang* May 12 16:38:28 khem: haha, me too (stopped using distro that enabled it by default)! May 12 16:38:42 rburton: I was thinking about it and the power of llvm is tools that are built on top of it. So having an easy way to build them on top of llvm is a good thing in OE May 12 16:38:48 even clang is one such tool May 12 16:39:56 rburton: the latest on my gcc-6 pull request should be pretty much final May 12 16:40:11 rburton: I have merged zeddi's kernel pull into mine May 12 16:40:24 the other day, for fun, i tried doing a core-image-minimal with clang and musl... is that combination expected to work? May 12 16:40:38 and its working ok so far I will see by evening if anything breaks May 12 16:41:07 tlwoerner: yes May 12 16:41:35 khem: ok, i'll poke at it some more May 12 16:42:14 tlwoerner: there is some strage bug with rpi though but thats same with gcc May 12 16:42:24 init cause kernel panic May 12 16:42:38 same works ok on bb May 12 16:43:17 i was trying qemuarm, nodistro May 12 16:43:50 that should work but clang doesnt care too much about arm < v6 May 12 16:44:01 so in future May 12 16:44:58 ok May 12 16:45:33 but they do accept patches May 12 16:46:11 currently, busybox is nonclangable so I would like someone to take a crack at it and see if it can be fixed May 12 16:46:50 khem: any idea if recent toolchains still support sh2 architecture (super-H), i notice crosstool-NG still has a configuration for sh4 (but it failed to build) May 12 16:48:34 tlwoerner: yes sh2 is having a new life since its patents expired suddenly it has become an option May 12 16:48:52 yes :-) j-core FTW May 12 16:49:02 and openrisc May 12 16:49:11 and I am sure more FPGA startups May 12 16:49:27 good to know! May 12 16:49:31 will use it May 12 17:01:40 at 29 messages, Richard's "bblayers.conf - Past, Present and Future?" is the most active architectural discussion May 12 17:02:11 even beating out the whole "let's have a flag day and switch to python 3" discussion, which i thought would cause more of a storm ;-) May 12 17:02:17 (which i'm happy about) May 12 17:03:17 need to figure out what to do next May 12 17:05:16 otavio and fray both said they already have tools that address this issue, my next step is to "play" with those tools and see how they work May 12 17:05:51 i also have a tool, but it broke in the last month or so and it's probably not worth fixing (if most of us can agree on a common tool going forward) May 12 17:07:06 everyone has a tool May 12 17:07:20 I think we need to focus on describing a build in a common format May 12 17:07:25 khem: excellent, qemux86-64 just finished successfully :-) May 12 17:07:32 because there are to many use cases for one solution May 12 17:07:45 oh right, and dvhart has a tool too May 12 17:07:49 here a tool May 12 17:07:52 there a tool May 12 17:07:55 yep May 12 17:08:07 everywhere a tool-tool May 12 17:08:11 and that is fine, but we need to defein some common ground, so we can try each others tools May 12 17:08:17 that sounds dirty May 12 17:09:00 Crofton|work: I am temped to believe we are mixing tools duties. We describe a build using a set of things: (in our case) repo manifest tag, machine and distro options, image. Done. May 12 17:09:11 If we use same tag and same options, we get same result May 12 17:09:40 well, lets write that up and defien a machine readable format May 12 17:09:45 tlwoerner: I should be replying to that thread as well May 12 17:09:47 and see if everyone agrees May 12 17:10:13 The whole CI model is very diverse May 12 17:10:16 khem: i'm guessing you people have a tool too? May 12 17:10:27 I would like to see someone create a build in toaster, then save the build description and feed that to jenkins for automated testing May 12 17:10:38 Crofton: +1 May 12 17:11:04 Crofton|work: aren't us mixing tools here? May 12 17:11:13 CI is one thing, Toaster is another May 12 17:11:21 and both serves different goals May 12 17:11:24 yes, but that is why we need to find common info for tools to share May 12 17:11:32 to make it easy to move from one to another May 12 17:11:33 otavio: i think the common point is to describe a build May 12 17:11:51 tlwoerner: ok but what is the reason for it? May 12 17:11:57 these are the layers, here's where i got them from, this is what i built May 12 17:12:06 tlwoerner: what I mean is, we are using Git as SCM and it has tagging May 12 17:12:18 and unfortunately OE just can not remain just a build system May 12 17:12:27 Using tags and config (machine and distro) it must be enough May 12 17:12:43 it has tantacles into the whole workflow May 12 17:13:08 I think we are jumping to solutions even before identifying what we can/should do May 12 17:13:28 khem: agreed and this is what worries me. OE is already a giant tool and we are adding more complexity to it May 12 17:13:53 this is why we should focus on describing a build May 12 17:14:06 and not bolting function straight into bitbake May 12 17:14:08 That is the main reason why I support the 'script setup' way. Of course, we can share most of it May 12 17:14:15 repo tool was written with android build infra in mind and gerrit and so on May 12 17:14:31 otavio: many beginners can follow the "getting started" well enough to build for qemuXX, but as soon as they want to build for the device sitting on their desk it gets messy May 12 17:14:40 and Idont think we have that amount of money and resources to develop something like that May 12 17:14:43 khem: and works very well. May 12 17:15:06 We should make it simple but no simpler May 12 17:15:13 since we will over engineer it May 12 17:15:47 tlwoerner: but this is another problem and I am afraid even if we make it dead easy, people will still have problem as people usually does not read the docs. May 12 17:16:03 there are many meta-raspberrypi's and many meta-whatevers, the things you find on the layerindex aren't always what one uses May 12 17:16:06 a tool like toaster should be able to orchestrate the workflow May 12 17:16:15 if we want to develop May 12 17:16:17 tlwoerner: and build an embedded image is a complex task May 12 17:16:49 tlwoerner: and it never will be easy; making it too easy is making too many assumpsions May 12 17:17:01 these issues will remain all major infras have such issues May 12 17:17:01 khem: toaster is the tool for end user May 12 17:17:09 khem: exactly May 12 17:17:21 otavio, it can have a cmdline interface as well May 12 17:17:26 khem: and trying to make it easy, make it worse and more complex. May 12 17:17:55 yes, but a month from now when i want to recreate what my CI loop build last night, i can run into problems May 12 17:18:26 currently if you enable buildhistory the metadata-revs records the names of the layers and their HEADs, but it doesn't tell you from where they got them (github? openembedded.org?) May 12 17:18:45 so if this were captured for each build, this would be a _great_ start May 12 17:19:14 and if all the data is captured, then it shouldn't, in theory, be too hard to just feed that into a "build" and have the setup/creation of bblayers automated May 12 17:19:14 tlwoerner: it is just because you are not using the right tools. May 12 17:19:31 tlwoerner: for example, in FSL Community BSP it is really easy to reproduce it May 12 17:20:08 tlwoerner: even if you did that it may still not reproduce same things since build systems and enviroment are not captured May 12 17:20:13 tlwoerner: http://ci.ossystems.com.br/view/FSL%20Community%20BSP%20-%20krogoth/job/fsl-community-bsp-krogoth_framebuffer-imx6qsabreauto/lastBuild/consoleFull May 12 17:20:20 tlwoerner: it has the hashes May 12 17:20:23 so it will ease the pain may be but does not eliminate issues May 12 17:20:52 this is a general ptproblem with source based distros anyway May 12 17:21:11 tlwoerner: and osyis tool is used there. If you pass same options it reproduces same build May 12 17:21:46 tlwoerner is pointing at a reproducability which is a different problm but is real May 12 17:21:49 tlwoerner: why where layers came from matters? It is in your manifest or submodules May 12 17:22:21 khem: if it is not reproducible it is due a bug. A floating dependency or similar May 12 17:22:37 khem: but it will likely be. In worse, same source is taken as is May 12 17:22:59 khem: of course, using less well maintained layers, cause reproducibility issues May 12 17:23:16 khem: but this is not solved by any of those tools May 12 17:23:59 tlwoerner: Did you see the tools I pointed on RP's email? May 12 17:24:08 tlwoerner: those are the tools we are using here. May 12 17:25:00 otavio: there are several cases where multiple layers exist with the exact same name and they're not always clones/branches of each other May 12 17:25:20 tlwoerner: Sorry but this is not OE fault May 12 17:25:31 tlwoerner: and Git allows for it, as does Github May 12 17:25:49 in one specific case, one company has 3-4 products, one such meta-ABC covers some of them, and another such meta-ABC covers a different set May 12 17:25:54 tlwoerner: and it is user duty to check the branches. I am sorry. May 12 17:25:55 yes, there's nothing wrong with it May 12 17:26:06 but if my build only says i used meta-ABC as a layer, then i have no idea which one May 12 17:26:20 so where the repository comes from does matter and needs to be recorded for reproducibility May 12 17:26:22 tlwoerner: you did wrong, in this case May 12 17:26:40 tlwoerner: and I think you are adding a fixup to an issue which is not related May 12 17:26:49 tlwoerner: that can be controlled in a manifest of some sort May 12 17:26:57 khem: exactly May 12 17:27:03 khem: submodules, repo, script May 12 17:27:24 May be integrating/weaving a solution using external tools and leave it there May 12 17:27:41 otavio: okay, maybe i am using a repo manifest May 12 17:27:44 is something wOE can recommend May 12 17:28:02 and maybe before a specific date i'm using meta-ABC from here.com May 12 17:28:13 and maybe after a specific date i'm using meta-ABC from there.com May 12 17:28:16 tlwoerner: That is one of my main problems with this discussion is that people are wishing to solve different problems with a single tool May 12 17:28:31 tlwoerner: manifest is for it May 12 17:28:38 tlwoerner: and it traces it May 12 17:28:49 tlwoerner: using tags allow you to know it has change May 12 17:28:53 just documenting the wrokflows end to nd can solve it May 12 17:29:37 tlwoerner: http://doc.ossystems.com.br/managing-platforms.html and http://doc.ossystems.com.br/release.html is how we does all that May 12 17:30:12 tlwoerner: http://doc.ossystems.com.br/ye.html is another useful tool to help new users. May 12 17:31:20 all i'm trying to say is, at the end of a build, if buildhistory is on, the build will tell you what it used, but it doesn't record where the repositories are from (or what manifest you were using) so, 3 months from now, it is impossible to recreate what your CI did last night (with the tools currently in OE) May 12 17:32:08 and simply saying "use a manifest" doesn't help solve the problem (with the functionality currently in OE) May 12 17:32:35 tlwoerner: buildhistory has the revisions of every layer. May 12 17:32:38 and it's great that many people are thinking about this, but it would be better if the solution were somehow inside The Yocto Project umbrella instead of outside of it May 12 17:32:45 tlwoerner: so it does provide it May 12 17:33:00 otavio: but it doesn't say _where_ the layer is from May 12 17:33:14 tlwoerner: this is not a build responsability May 12 17:33:16 so all you can do is checkout where you think the layer came from and check to see if it has that revision May 12 17:33:19 tlwoerner: this is source mangement May 12 17:33:26 and if it doesn't... then you have to look somewhere else May 12 17:33:35 tlwoerner: as well as buildhistor does not show the git log of layers May 12 17:34:27 i'm not asking for a .5MB log of each layer, i'm asking for a couple dozen characters saying where the layer is from (the output from git remote -v), it's not too much to ask May 12 17:34:57 The question is: does it belong there? May 12 17:37:28 to me that's an obvious "yes", the moment OE started relying on layers it became important to record where those layers came from May 12 17:37:51 if the answer is "no" then maybe the build shoudln't bother recording anything about what it's using (?) May 12 17:38:34 if anything the half-information it's currently providing is the problem: provide no information, or provide all of it ;-) May 12 17:39:11 is there really that big of a leap between: May 12 17:39:18 framebuffer fsl-image-machine-test@imx6qsabreauto meta-poky = "HEAD:898a78357e72fb80f1f8e26ba90bad5b7b054a4f" May 12 17:39:19 and May 12 17:39:53 framebuffer fsl-image-machine-test@imx6qsabreauto meta-poky = "HEAD:898a78357e72fb80f1f8e26ba90bad5b7b054a4f:git://git.yoctoproject.org/meta-yocto" May 12 17:39:53 ? May 12 17:40:08 (or wherever it came from) **** ENDING LOGGING AT Fri May 13 02:59:58 2016