**** BEGIN LOGGING AT Wed Mar 10 02:59:56 2021 Mar 10 06:44:18 hello there! my kernel module recipe fails to pass installed-vs-shipped QA check due to modules.builtin file. isn't this supposed to be automagically included in FILES_${PN} ? Mar 10 06:54:51 hi is there special recipe to define a new service in /etc/init.d ? **** BEGIN LOGGING AT Wed Mar 10 07:45:52 2021 Mar 10 08:05:08 yo dudX Mar 10 08:39:09 kanavin: hehe, exactly my thoughts @pw Mar 10 10:34:00 kmaincent: will you reply to Bruce with the perf diffoscope logs (e.g. https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20210310-pc9vzt2k/packages/diff-html/) ? Mar 10 10:38:09 RP: yes I will, thanks for the diffoscope link Mar 10 10:44:21 RP the issue wrt libtool-native has multiple sides of the medal ... aka as it embeds very compiler/host specific paths, we might conclude that we can't sstate-cache it. or we need to try and mangle it better (which I don't know yet if that produces side effects). Mar 10 10:45:37 compiler_lib_search_dirs is _very_ host specific if we're honest, even if we're on the same host, there might have been an update. Mar 10 10:48:31 RP: did you include the last dnf patch from alexander, in this build https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1608 ? Mar 10 10:49:03 *libdnf patch Mar 10 10:50:26 kmaincent: that looks like it is from the util-linux patch Mar 10 10:51:23 dl9pf: does it actually need that value on linux? Mar 10 10:53:08 e.g. x86_64-linux-libtool still contains: Mar 10 10:53:43 https://www.irccloud.com/pastebin/zpnuDLyN/ Mar 10 10:53:59 this is build-host specifics that end-up in the sstate-cache Mar 10 10:54:15 and predep postdep are quite specific Mar 10 10:55:24 that is at least what happened here. got the sstate from a debian builder with /usr/lib/gcc/.../5/ Mar 10 10:58:01 kmaincent: we should have diffoscope links for the other two failures as well, need to check it was the same issue. Looks like symbol reordering FWIW so perhaps object linking order isn't deterministic Mar 10 10:58:41 dl9pf: I wonder why libtool needs to care. RPATH supression maybe? Mar 10 10:59:41 digging some more ... wonder why its a problem here now Mar 10 11:00:00 on multiple hosts Mar 10 11:00:28 dl9pf: I was wondering why it was showing up now Mar 10 11:02:13 the builder populating the sstate mirror in question does use prserv and hashserv Mar 10 11:05:59 RP: is there a way to find easily the diffoscope of a build? Mar 10 11:12:19 kmaincent: the directory location is mentioned in the build logs so you can easily build the url from that Mar 10 11:17:58 ah yes got it Mar 10 11:20:38 dl9pf: it is possible that may expose some issues a bit more but I'm not seeing a direct connection Mar 10 11:21:38 might have been exposed by accident Mar 10 11:35:59 LetoThe2nd, huh? Mar 10 11:49:19 zeddii: are you actually working on that qemuarmv5 bug? I'll take a look if you've not got around to it. Mar 10 12:29:09 kanavin: re the "why should PW go into oe-core" mail Mar 10 12:31:25 LetoThe2nd, I am famous for removing things from oe-core :) Mar 10 12:31:37 LetoThe2nd, X server is next on the chopping block Mar 10 13:02:49 kanavin: we just need to be careful not to alienate users though, for better or worse the X pieces do have users Mar 10 13:03:11 zeddii: when you're around I can try and give perf hints if it helps Mar 10 13:10:59 should be easy enough to move the old server to meta-oe for people who want it Mar 10 13:12:48 RP: *sing* "I'm an alien, I'm an evil alien, I'm an Englishman in New Yo-hork..." Mar 10 13:37:16 RP: unfortunately, I'm out of time on perf. It'll be a few weeks again before I can pick it up. Mar 10 13:43:55 rburton: it was fixed in the queue that I sent last night. Mar 10 13:44:03 awesome Mar 10 13:57:25 zeddii: ok, no problem. I will merge the patch so far since its steps in the right direction, there is obviously just some remaining gremlin Mar 10 13:59:23 I did glance quicky at the diffoscope, and it looks like some machine specific instructions are captured. since that's the nature of perf, it isn't surprising. Mar 10 13:59:35 but they should still be reproducible of course. Mar 10 13:59:49 "diffoscope" -- sounds so 1950s.... Mar 10 14:00:08 glowing vacuum tubes and the whole bit. Mar 10 14:02:43 paulg: vacuum tubes are quite cool though, do love my old school 'scope Mar 10 14:03:27 * RP once had to create a sample in evacuated glass and has a lot of respect for anything made inside vacuums Mar 10 14:04:40 I know several people who carry around a complete vacuum in their head. Mar 10 14:05:11 * RP ponders incomplete vacuums Mar 10 14:05:50 I imagine that'd be quite similar, except their head would make high pitched noises Mar 10 14:08:39 OT: anyone fancy 2K EUR Zen Nixie Tube Clock? https://www.daliborfarny.com/product/zen-nixie-clock/ there is also YT channel how they are producing the tubes nowaydas Mar 10 14:17:32 RP: certainly, I guess you've seen the branches I am preparing? Mar 10 14:17:34 http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/log/?h=contrib/akanavin/transition-to-weston Mar 10 14:17:44 http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/transition-to-weston Mar 10 14:17:53 kanavin: I have looked at some of it, yes Mar 10 14:20:18 RP: one other missing item I want to look into is to package the upcoming separate-xwayland release - that's the only X piece that has a future, and even then only as a legacy compatibility layer. Standalone x server is effectively dead. Mar 10 14:22:08 kanavin: it would certainly make sense to have that Mar 10 14:23:06 of course oe-core will continue to provide and test core-image-sato on top of xorg-xserver, but I think the time has come to transition the core and the test matrix (the bulk of it) to wayland/weston (in the next development cycle of course) Mar 10 14:24:22 kanavin: I agree on changing the mix, how much so, tbd :) Mar 10 14:25:30 RP: yeah, it's best to discuss over specific patches, I'm holding them until after the release is done :) Mar 10 14:43:46 zeddii: I'm wondering if tools/perf/Makefile.perf:$(patsubst perf-%,%.o,$(PROGRAMS)): $(wildcard */*.h) needs a $(sort ) around the wildcard Mar 10 14:45:09 although I think that is just a dependencies line so perhaps doesn't matter Mar 10 14:53:51 RP: I was looking at your other reproducibility fixes and wondered if that was the remaining thing as well. But didn't have a look at all yet. Mar 10 14:54:14 since like you said, it really just looks like the objects are in a different order between the two builds, which didn't happen on my local one. Mar 10 14:54:22 zeddii: I'll quickly run a diff between the autobuilder logs and some local ones, see if anything obvious jumps out Mar 10 15:25:28 zeddii: was a nice idea but perf compile corrupts the output and interleaves the commands :/ Mar 10 15:29:40 ahah. yuck. Mar 10 16:35:57 armpit: can you please reply in "[dunfell 00/41] Pull request (cover letter only)" thread about connman upgrade backport to dunfell? Mar 10 17:01:33 JaMa, I did in the engr meeting. now I need to find that email Mar 10 17:06:16 rburton: when you first bitbake a project, doesn't yocto have to build the cross-binutils (as, ld, etc.)? if so, by what mechanism is this accomplished? via class files? also where do the source files for this process come from? any specific pointers (e.g., in the default yocto build) would be appreciated. Mar 10 17:06:55 yates: the gcc and binutils recipes Mar 10 17:17:41 zeddii: after a lot of head scratching I think it is pmu-events.c which differs because of JSON = $(shell [ -d $(JDIR) ] && find $(JDIR) -name '*.json' -o -name 'mapfile.csv') as the mapfile.csv file isn't ordered deterministically Mar 10 17:20:36 armpit: please do for us plebs not attending another engr meeting :) Mar 10 17:21:16 RP: ahaha. indeed. filesystem ordering on that find. Mar 10 17:22:19 and then within the csv, is it generated ? Mar 10 17:35:50 zeddii: the find generates the mapfile.csv contents Mar 10 17:37:10 zeddii: sorry, I'm misreading Mar 10 17:40:52 zeddii: its the handling in jevents.c, the ntfw() walks the tree and won't be deterministic Mar 10 17:48:37 zeddii: Fixing that doesn't look fun. Who would write that kind of thing in C? :) Mar 10 17:48:55 kernel savages. Mar 10 17:49:04 but I state the obvious Mar 10 17:50:09 zeddii: scandir() would sort if we could butcher it to use that Mar 10 17:53:31 zeddii: https://codereview.stackexchange.com/questions/213435/c-recursive-opendir-wrapper-to-sort-directories-first-ascending-descending maybe Mar 10 17:54:58 I was just reading nftw's opengroup page. Mar 10 17:55:58 zeddii: I'd never really run into this problem as I'd write it in python :) Mar 10 17:58:51 what about a post processing step ? IF it's the order in pmu-events.c, can't we suck it in, re-order and spit it back out ? Mar 10 17:59:17 sort on .name, or something like that. Mar 10 17:59:45 zeddii: sounds good to me. That would solve the issue Mar 10 18:00:35 zeddii: I'm partly guessing at what the issue is but the trace clearly points at something in pmu-events.c changing Mar 10 18:00:46 * RP -> food Mar 10 18:00:48 it also fits the detail that we can't easily patch perf. I can have a go at a small python thing to do it Mar 10 18:01:13 zeddii: yes, I was worrying about that too Mar 10 18:07:54 rburton: so do you mean /meta/recipes-devtools/gcc (for gcc)? Mar 10 18:08:00 yes Mar 10 18:08:06 ok thanks Mar 10 18:31:47 is there a recipe that will just make the sdk? bitbake sdk? Mar 10 18:33:56 define 'sdk' Mar 10 18:35:41 rburton: Surely Demented Khem :) Mar 10 18:37:02 sdk in my mind means the binutils + compilers, basically Mar 10 18:37:21 it looks like "bitbake meta-toolchain" does this? Mar 10 18:46:01 in build/conf/local.conf i see "MACHINE ??= "qemux86-64"" Mar 10 18:46:36 does this set the target of the sdk/toolchain? e.g. cross-tools will be built for a qemux86_64? Mar 10 18:47:31 rburton: ^^^^ ? Mar 10 18:47:48 if so, where are the MACHINEs defined? Mar 10 18:50:46 ? Mar 10 18:54:56 yates: SDK is a losely held term. its collection of tools and workflow to develop some sort of software Mar 10 18:55:20 e.g. if you were building containers as output then you will also call this SDK Mar 10 19:18:38 should image.bbclass inherit nopackages? Mar 10 19:25:54 yates: meta-toolchain will build a basic tarball containing binutils/gcc yes. SDKMACHINE sets that target for the platform that *runs* the sdk (as documented in local.conf for starters) Mar 10 19:39:27 yates: the sections on building the regular and extended SDKs in https://docs.yoctoproject.org/sdk-manual/index.html might be helpful Mar 10 19:51:50 rburton: thanks. yes, i saw SDKMACHINE is the "host" (I believe "host" and not "target" is the correct nomenclature, using the triplet syntax defined in https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Specifying-Target-Triplets.html) Mar 10 19:54:12 is it correct to say that "MACHINE" defines the "target" in that nomenclature? Mar 10 19:56:20 yates: yes, machine is the target in that, but it's even more specific than that. i.e. it's not just the target architecture, it's the specific board being targeted, usually Mar 10 19:57:23 kergoth: +1 Mar 10 21:22:34 JaMa: I don't think it can as there was some key dependency chain that breaks Mar 10 21:44:21 RP: for me a dependency on image.do_image_complete somehow includes a search for image.packagedata manifest (which is now an error with my recent change), so nopackages was simples work around, but will look a bit further how it happened Mar 10 21:44:29 RP: https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/master&id=5ee66b49ef8ab0e2df386c862a09c15629cfa1a0 has few more details Mar 10 21:45:14 RP: and on ML I've reported that I've seen it only in gatesgarth build, but then the same build locally shown an error with hardknott while gatesgarth was fine, so there is something else in play :/ Mar 10 21:57:56 JaMa: image.bbclass already has a lot of task pruning, I think I did as much as I could get away with at the time Mar 10 21:58:21 JaMa: the world has changed since but I think some of the dependencies are probably needed. It sounds like there is some underlying issue at play but I'm not quite sure what Mar 10 23:45:25 guys, does yocto/tmp/deploy/sdk/poky-glibc-x86_64-meta-toolchain-core2-64-qemux86-64-toolchain-3.2.2.sh actually embedded all the Mar 10 23:45:31 tools Mar 10 23:47:18 ? it is a shell with binary data Mar 10 23:52:38 yates: that's the SDK installer, a tarball wrapped with an install script, see https://docs.yoctoproject.org/sdk-manual/using.html#installing-the-sdk Mar 11 01:48:23 yates: yeah you need to execute that binary and it will give instructions where it will extract **** ENDING LOGGING AT Thu Mar 11 02:59:57 2021