**** BEGIN LOGGING AT Fri Aug 30 03:00:27 2019 Aug 30 05:50:37 armpit: my day so far: 1) open mutt 2) read mail 3) mentally picture behanw as Miss California. 4) thanks armin. Aug 30 05:51:00 hehe Aug 30 05:51:53 armpit: hum how comes you around this time? Aug 30 05:52:25 its only 11pm here.. getting sleepy.. will leave shortly Aug 30 05:53:21 armpit: ah, thought you were more east. Aug 30 05:54:13 nope, California Aug 30 05:54:47 ... Aug 30 05:54:55 * LetoThe2nd nods silently. rereads mail. Aug 30 06:10:54 LetoThe2nd: uh. I just don’t want to know... Aug 30 06:13:28 behanw: blame armpit Aug 30 06:13:53 I still don’t want to know Aug 30 06:15:46 better that is, probably. Aug 30 06:47:25 LetoThe2nd: thanks for the great live coding sessions on youtube/twitch. Very helpful for a newcomer! Aug 30 06:48:51 iceaway: oh, thanks! glad it helps, and if theres more questions just them in here :) Aug 30 06:49:48 *just shoot them in here :) Aug 30 06:58:21 __angelo: addtask generate_swupdate before do_rootfs; do_generate_swupdate[nostamp] = "1"; do_generate_swupdate[depends] += "swupdate-image:do_build"; do_generate_swupdate () { do_smth_with_swupdate-image() } Aug 30 07:16:42 LetoThe2nd: definitely will, I am just in the process of setting up a Yocto-configuration for a new custom board. I have only worked with buildroot before so it's a bit of a transition. Aug 30 07:17:33 iceaway: yes it certainly is. Aug 30 07:18:47 iceaway: if you're just in the getting started stage and have some time/money in late October, come to Lyon where you can meet and ask all the people responsible for your confusion in person! :) Aug 30 07:32:35 LetoThe2nd: That would be awesome, I will see if that's possible with regards to family/work situation. Aug 30 07:33:51 iceaway: depends on your whereabouts and such, of course. but its a good occasion to get your hands dirty :) Aug 30 07:45:48 kanavin_: that /dev/fb0 error is still in -next after I remove the 5.2 kernels :/ Aug 30 07:45:59 <__angelo> qschulz, thanks, very appreciated, testing it Aug 30 07:46:07 kanavin_: that raises the likelihood its one of your patches :/ Aug 30 07:49:49 __angelo: if that doesn't make it, then I don't know more, I haven't developed that part of our Yocto Aug 30 07:50:30 <__angelo> qschulz, thanks a lot, let you know in short Aug 30 07:52:42 anybody run into smb/nmb not coming up reliably on low-end hardware? systemd seems to be confused over them and timeouts. Aug 30 08:01:15 I'm have created my own image recipe based on core-image-minimal-dev (yep, from your screencast example LetoThe2nd). I want gstreamer to be included so I have added "packagegroup-fsl-gstreamer1.0 packagegroup-fsl-gstreamer1.0-full" to IMAGE_INSTALL. This apparantly pulls in pulseaudio as a dependency, but when it tries to do "do_install" it fails with the message: "/run.do_install.29140: update-rc.d: not Aug 30 08:01:21 found". update-rc.d is available in the target image. Do I need to install it on the host or how should I interpret this message? Aug 30 08:01:52 iceaway: first thought is, did you make sure the release of all your layer align? Aug 30 08:03:33 Hmm, probably not as I am not really sure what that means. We base our board on a SOM from variscite so I follewed their getting started guide for setting up the initial yocto environment: variwiki.com/index.php?title=Yocto_Build_Release&release=RELEASE_SUMO_V1.0_VAR-SOM-MX8X Aug 30 08:04:41 I would assume that their repo manifest file pulls in the proper versions of everything. Aug 30 08:05:31 iceaway: yes i would assume the same Aug 30 08:05:55 update-rc.d at least sounds like something being cofused over classic init and systemd or such Aug 30 08:07:55 Agreed, will see if I can find where it selects SysV init and not systemd. Where would be good place to start? Would that typically be a DISTRO setting? Aug 30 08:08:05 iceaway: probably, yes. Aug 30 08:20:01 Morning, I'm trying to override the default boot.cmd of the u-boot recipe within the meta-sunxi layer using a u-boot.bbappend. I followed my usual workflow of devtool modify and devtool finish. I only used devtool for source editing and not altering recipe local files. Devtool creates a bbappend recipe and adds the boot.cmd and also prepends to FILEEXTRAPATH, but the final u-boot build includes the old boot.cmd. Any ideas? I don't want to Aug 30 08:20:03 touch the original recipe. Aug 30 08:39:56 bisbarn: what does your bbappend look like and where exactly is your boot.cmd located? Aug 30 08:41:36 Ahrg. I added debug to my local builds to investigate a rare problem. Now that problem occurs in a build but I can't afford to time to go off a ta tangent to investigate :( Aug 30 08:47:40 qschulz: nevermind i figured it out. I looked at the expanded FILESPATH variable and discoverd that `meta-sunxi/recipes-bsp/u-boot/files/arm` took presedence over `meta-bei/recipes-bsp/u-boot/u-boot` (which was the path devtool put the boot.cmd in) ;) Aug 30 08:51:03 New news from stackoverflow: I2C driver changes to recognize multiple buses Aug 30 09:01:52 When starting a new devsession (i.e. coming back after a reboot or whatever), do I need to run a script to set up the environment again? Following the guide here: http://variwiki.com/index.php?title=Yocto_Build_Release&release=RELEASE_SUMO_V1.0_VAR-SOM-MX8X it only says run the "MACHINE=xxx DISTRO=yyy . var-setup-release -b build_dir", but not if anything has be done for the next session. Running that Aug 30 09:01:58 command resets everything in local.conf so apparantly that is not the way to go. Aug 30 09:04:39 iceaway: usually one would source poky/oe-init-env-or-whatsitcalled again Aug 30 09:04:55 running "source sources/poky/oe-init-build-env build_poky" seems to work for me, just not 100% that is the correct way. Aug 30 09:05:51 iceaway: its just crucial that you run that either while being in the directory that holds your build dir, or explicitly stating it (like you do. other wise this is perfectly fine. Aug 30 09:09:33 bisbarn: yes, that's what happened to me multiple times already :/ It gets tricky very quick Aug 30 09:11:49 qschulz: indeed ;) bitbake -e is a lifesaver ;) however the good thing about it is that I realized that it would make sense to further restrict the boot.cmd override to the board and not just plain "arm" ;) Aug 30 09:12:41 bisbarn: it depends, you make it harder to override afterwards if you have another bbappend which should be a boot.cmd for all machines Aug 30 09:13:52 qschulz: true Aug 30 09:24:31 LetoThe2nd: thanks! Referring back to my earlier pulseaudio issue, in the pulseaudio.inc file it has on the inherit line: "systemd". Would that implicate that it supports exclusively systemd and not i.e. SysV init? Aug 30 09:26:27 or merely that it can be configured with systemd? Aug 30 09:27:00 iceaway: don't know, and no time to look it up at the moment, sorry. Aug 30 09:27:13 qschulz: ^^^ maybe you have time for a peek? Aug 30 09:30:23 No worries! Aug 30 09:32:46 iceaway: which version of poky? where is this /run.do_install.29140: update-rc.d: not found" coming from (which recipe?)? Aug 30 09:33:13 LetoThe2nd: we use update-rc.d here and we don't have systemd. Aug 30 09:34:00 qschulz: i have no experience on neither update-rc nor gstreamer, hence its a bit too much for me ATM Aug 30 09:35:07 I'm using poky 2.5.2. The recipe is pulseaudio-11.1 Aug 30 09:35:23 neither do I :D just had a few issues with update-rc.d so I'm learning on the fly :D Aug 30 09:35:37 Apparantly I have update-rc.d both on the target and on my development machine Aug 30 09:35:56 Could it be some issue that the bitbake environment cannot find the update-rc.d executable? Aug 30 09:37:56 If I run "bitbake -c devshell pulseaudio" I can run update-rc.d in the devshell. Aug 30 09:38:16 I don't use devshell :/ Aug 30 09:38:34 Ahrg, second clean build failed in the same area. I'm going to have to debug this :( Aug 30 09:42:08 iceaway: could you paste somewhere the run.do_install? Aug 30 09:50:46 RP, at least you can reproduce it more easily it seems! Aug 30 09:54:30 qschulz: definitely, here it is: https://pastebin.com/FusgD9SQ Aug 30 09:59:20 kroon: right, at the more inopportune moment :/ Aug 30 10:06:28 * alessioigor waves Aug 30 10:06:38 Is it expected that wic has started to ignore IMAGE_ROOTFS_SIZE since one or two weeks ago (on master)? Aug 30 10:22:41 Note sure if this is relevant or not, but update-rc.d uses the commandline argument -r which is not available on the version of update-rc.d running on my host machine. Using -r does not give the "not found" error though, but "unknown option". Aug 30 10:28:29 RP: yes, I am farily certain it's the one that tweaks qemu arm configs. I will look into, also Anuj I think mentioned it on the list. Aug 30 10:41:29 Could it be that bitbake is using my native update-rc.d instead of the one created in the sysroot within yocto for the host machine? Aug 30 10:43:09 "your" native update-rc.d? Aug 30 10:45:28 Yes, in the devshell if I run which update-rc.d I get the one that came with my Linux distribution, not one from within Yocto Aug 30 10:47:44 THere are others under my tmp directory, i.e. tmp/work/aarch64-poky-linux/rpcbind/0.2.4-r0/recipe-sysroot-native/usr/sbin/update-rc.d, which have the -r option available. Aug 30 11:05:16 iceaway: do you have any bbappend for pulseaudio somewhere? Aug 30 11:07:52 I don't understand where the end of the do_install comes from Aug 30 11:17:33 THere are a few, is there a bitbake command to check which .bbappend files apply to my build? (I think I remember that this can be done, but cannot recall how) Aug 30 11:18:20 `bitbake-layers show-appends` apparently Aug 30 11:21:40 Yeah now I found it, it is in a bbappend-file from the variscite meta-layer. https://github.com/varigit/meta-variscite-imx/blob/sumo-imx-4.14.98-var01/recipes-multimedia/pulseaudio/pulseaudio_%25.bbappend Aug 30 11:22:53 No idea how to fix it in the most correct way though. Aug 30 11:24:18 iceaway: create a new bbappend and add DEPENDS_append = " update-rc.d-native" Aug 30 11:31:26 qschulz: really cool, now it seems to work! Thank you for the help. Aug 30 11:32:12 What exactly does that DEPENDS_append do? Force any calls to update-rc.d within the bitbake environment to use the one from the local native sysroot? Aug 30 11:38:07 DEPENDS is for dependencies at build time Aug 30 11:38:37 it's going to put binaries and headers into a sysroot for your recipe so it can use those resources for compiling the software Aug 30 11:39:16 when you have -native in the name, it's binaries and libraries compiled for the host system which are needed at build time Aug 30 11:39:32 recipe-sysroot for the first, recipe-sysroot-native for the second Aug 30 11:39:56 _append is an almost same (BUT NOT) mechanism as DEPENDS += Aug 30 11:40:10 one or the other is fine here AFAICT Aug 30 11:41:25 what would be nice of you is to notify the maintainers (open an issue or send a pull request) that they need to add update-rc.d-native to DEPENDS Aug 30 11:49:30 qschulz: thanks for the detailed explanation. I will notify the maintainers about that issue. Aug 30 11:51:30 iceaway: happy to help :) Aug 30 11:52:43 Question: I've this package with prebuilt libraries which depends on libfoo.so. I have a package which provides libfoo.so.1.2. Obviously, Yocto isn't happy because it can't find a RPROVIDER for libfoo.so for the mentioned package. Aug 30 11:53:12 I don't really like our INSANE_SKIP file-rdeps at the moment :D Aug 30 11:56:09 also, libfoo recipes are upstream so I don't really want to have a bbappend for each and every of those rdependencies (but if I can't do any other way... :/) Aug 30 12:22:51 Pull request with the fix done \o/ Aug 30 12:26:21 and after a lot of debugging, its a race in my debug code :( Aug 30 12:26:33 but shows a design problem in the main code which may also be a problem Aug 30 12:28:54 iceaway: the open source community is thanking you :) Aug 30 12:43:26 Always feels good when you can contribute back to the community. Aug 30 12:44:36 doesn't bitbake/yocto set pn to the recipe name? so if i'm bitbake abc_1.0.bb, pn = abc? Aug 30 12:45:10 if so then why am i getting "WARNING: load-initramfs-scripts-1.0+3653-r0 do_package_qa: QA Issue: /etc/init.d/run-swupdate.sh contained in package load-initramfs-scripts requires /bin/bash, but no providers found in RDEPENDS_load-initramfs-scripts? [file-rdeps" ... Aug 30 12:45:44 when i have "RDEPENDS_${pn} = "bash"" in my bb file? Aug 30 12:46:01 in load-initramfs-scripts_1.0.bb, i.e. Aug 30 12:46:18 PN Aug 30 12:46:41 oh?! Aug 30 12:50:49 RP: aww, i just missed the master-next queue Aug 30 12:51:04 there's some tasty py2->3 work I sent :) Aug 30 12:51:30 quite often I wish bitbake would throw an error when referencing non-existing variables, and that bash snippets would be executed with set -euxo pipefail... Aug 30 12:51:43 I have checked yesterday that with this patchset, the runtime py2 dependencies are gone, the buildtime py2 dependencies are down to u-boot and py2 itself Aug 30 12:54:39 kanavin_: typical! :) Aug 30 12:54:52 kanavin_: although I'm trying only to remove patches to get to a point where something can merge! Aug 30 12:56:55 kanavin_: patches look good at a quick glance! Aug 30 12:57:02 RP: a bit disappointed that py2 cannot build without having a binary of itself already available. I might poke into why is that. Aug 30 12:58:06 kanavin_: hmm, yes. I guess we never used to have to worry about that Aug 30 12:58:45 kinda like using C to write a C compiler? Aug 30 12:58:51 RP: we'll probably remove py2 from HOSTTOLS/self-hosted and py2 recipes as a single patch. Aug 30 12:59:00 yates, yes, except python is written in C Aug 30 12:59:19 kanavin_: then why does it need a binary of itself to build? Aug 30 12:59:33 yates, it needs to run .py scripts at build time to produce some generated stuff Aug 30 12:59:50 ah Aug 30 12:59:55 yates, and - surprise - they didn't make those scripts py3 compatible Aug 30 13:00:06 down to still using print "stuff" for example Aug 30 13:00:23 i'm a python idiot, so i'll shutup now.. Aug 30 13:00:41 been resisting learning it for a decade now Aug 30 13:01:21 RP: the graphical hardware mixup is because the qemu documentation made me believe that lists of available options for graphical hardware are the same for all targets and machines Aug 30 13:01:45 that is not actually true: not only the lists differ, but also the default cards if you do not specify -vga Aug 30 13:05:04 kanavin_: ok, glad we've figured it out! Aug 30 13:06:28 kanavin_: yeah, I was also surprised to see that py2 needs itself on the host in my test builds the other day Aug 30 13:07:06 smurray, I suspect it might be because we do 'make regen-all' Aug 30 13:07:33 I am not sure if that is actually necessary, maybe it isn't, and if we drop it, then py2 binary is no longer used Aug 30 13:08:47 hrm, is it worth digging into, considering it should be going away? Aug 30 13:09:17 smurray, distributions are now actively making moves to remove py2 altogether Aug 30 13:09:34 so we should be prepared for a situation where a widely used distro won't let you install py2 on the host Aug 30 13:10:20 so the concern would be no longer being able to build it for versions of OE where we still support it Aug 30 13:10:49 smurray, not necessarily, those versions have a list of tested distributions, which will not include any new ones Aug 30 13:11:05 I am thinking more of upcoming distro releases and how we handle them in master Aug 30 13:12:31 I'm guessing the u-boot py2 -> py3 fixes won't make it for zeus, so would be a concern for its lifetime Aug 30 13:13:37 smurray, Tartarus said he Aug 30 13:13:44 he's actively looking into it actualyl Aug 30 13:13:52 yeah, we've discussed it a bit Aug 30 13:14:41 So, what's the cutoff for zeus? Aug 30 13:14:54 I am hoping that for v2019.10 u-boot will be python3 happy Aug 30 13:15:03 And that's oct 7 Aug 30 13:15:23 Tartarus, would it be feasible to create a backport? Aug 30 13:15:36 oct 7 does seem like too late Aug 30 13:15:46 It'd sure be a pain Aug 30 13:15:52 We've already closed the merge window Aug 30 13:16:06 It'd be great for us, and for you too perhaps, to track the -rc releases? Aug 30 13:16:17 Tartarus, what I mean is that you create a 'custom' backport patch to the version that is currently in oe-core Aug 30 13:16:17 iirc, RP indicated we're close to zeus feature freeze Aug 30 13:17:07 kanavin_: Yeah, I know. Backporting the various series to v2019.07 (which you are on, I would hope) wouldn't be the end of the world, but it would be a huge patch set Aug 30 13:17:24 or then this can be handled in december-ish time, then we can drop py2 from oe-core and HOSTTOOLS, and deal with the fallout during winter Aug 30 13:17:25 I really would advocate for tracking U-Boot releases here instead Aug 30 13:18:02 Tartarus, we do track them, once every month AUH robot sends an email to u-boot maintainer telling what the latest non-rc version is Aug 30 13:18:14 Yes Aug 30 13:18:26 I'm saying, do a one off in this case Aug 30 13:18:36 Upgrade "today" to v2019.10-rc3 Aug 30 13:18:43 that maintainer at the moment is.... Marek Vasut Aug 30 13:18:45 And -rc when it comes out in a weeek and change Aug 30 13:18:57 Yes, marex-cloud is here too :) Aug 30 13:19:23 if he is okay with that then sure Aug 30 13:19:36 Well, is RP going to allow those upgrades in, for zeus? Aug 30 13:20:16 I'd say maybe we defer it to post-zeus Aug 30 13:20:32 If you're doing it post zeus, you can just catch it with the normal release cycle Aug 30 13:20:37 But if you want zeus to be python2 free Aug 30 13:20:38 then you can take your time with getting the py3 support u-boot nice and polished Aug 30 13:20:52 It's not actually that far off Aug 30 13:21:06 Simon did a lot of the back-end stuff a while ago, but kept it 2 compatible Aug 30 13:21:31 The pylibfdt stuff really is just s/python2/python3/ Aug 30 13:21:57 And the fedora folks are less flexible about python2 support than you are :) Aug 30 13:22:19 kanavin_: just a thought, would it be feasible to just have a python-native recipe for zeus? Aug 30 13:22:38 smurray, nope, because py2 still needs to be in self-hosted Aug 30 13:22:51 smurray, also we can't drop it from HOSTTOOLS because as discussed it needs itself :) Aug 30 13:23:14 it's like a circular dependency, the only way to handle it is to remove all three Aug 30 13:23:16 kanavin_: right, it'd have to stay in HOSTTOOLS, but then it'd not be buildable for target at all? Aug 30 13:23:36 yes, which breaks the self-hosted Aug 30 13:23:47 ah, like the builder images, etc. Aug 30 13:24:05 bummer Aug 30 13:24:21 smurray, also, brace yourself for the fallout when it is removed Aug 30 13:24:33 I expect half the meta-oe will break, and most other layers Aug 30 13:24:53 kanavin_: yeah, I've not been brave enough to attempt building that yet Aug 30 13:24:59 the sad experience I have is that warning people in advance about upcoming breakage has no effect Aug 30 13:25:22 the only way to have things fixed is either do it yourself, or do the breaking change and face the shouting and screaming Aug 30 13:26:13 likely will need to have the meta-python2 in hand for people to use in the short-term Aug 30 13:26:44 yeah Aug 30 13:27:05 this is more or less standard approach for obsolete things like qt3, qt4, lsb etc that were once in oe-core Aug 30 13:27:30 gplv2 as well :) Aug 30 13:28:08 it's not clear to me what maintenance folks like RHEL will do for py2, if they do keep it going, someone sufficiently motivated could likely pull their patches into meta-python2 Aug 30 13:29:19 yeah, upstream however has made it clear that they won't do any py2 work post-jan 1 202 Aug 30 13:29:21 2020 Aug 30 13:29:35 I guess they'll knock out one final release and shut it down for good Aug 30 13:30:10 yeah Aug 30 13:30:27 also centos 8 is much welcome, centos 7 is seriously ancient at this point Aug 30 13:30:57 yeah, 7 is painful to use for building anything Aug 30 13:31:28 (not centos fault obviously) Aug 30 13:34:02 hey guys! quick q: how to set host GCC for a Yocto build to use? I have issues with GCC 7, wondering if I can just point to ubuntu's gcc-6 Aug 30 13:34:58 luneff: you probably need to change what /usr/bin/gcc points to Aug 30 13:35:13 however, it may only get worse with an older version ;) Aug 30 13:35:30 it can... but I wonder if there's a cleaner solution, like a local.conf variable Aug 30 13:36:15 luneff, you probably need to inspect bitbake.conf, there is a variable in there that sets it. if it is a weak assignment, you can reset it in local.conf I guess Aug 30 13:37:06 export CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}" ;-( Aug 30 13:37:17 I guess I really should change /usr/bin/gcc :-) Aug 30 13:37:32 I wonder what HOST_PREFIX does Aug 30 13:38:00 /usr/bin/, I think Aug 30 13:38:17 it would be BUILD_CC that you would change, I believe Aug 30 13:38:21 ah, I thought you could set it to 'my-awesome-' Aug 30 13:38:52 no, I needed gcc-6 instead of just gcc, which is gcc-7 Aug 30 13:39:00 so it's more like a suffix in this case :-) Aug 30 13:39:11 I'd try sticking a gcc -> gcc-6 symlink in ~/bin or the like first, see if it'll get picked up Aug 30 13:40:06 if that doesn't work, try: export BUILD_CC = "${CCACHE}${BUILD_PREFIX}gcc-6 ${BUILD_CC_ARCH}" in local.conf Aug 30 13:40:24 * kanavin_ just got handed a beer, in the office Aug 30 13:40:36 productivty goes downhill for the rest of the day Aug 30 13:40:56 the germans are *very* liberal in that department Aug 30 13:41:13 never in a million years could happen in finland Aug 30 13:43:38 kanavin_: :D Aug 30 13:43:46 kanavin_: I could use a beer right now... Aug 30 13:44:06 kanavin_: heh, I'm several hours away from beer, I'm envious Aug 30 13:44:49 smurray: I promise not to tell HR ;) Aug 30 13:44:51 smurray, thanks! trying :-) Aug 30 13:44:54 * RP has a dilemma on trying to sort the release vs. fun activity this weekend. I think the release may just have to wait until next week :/ Aug 30 13:46:14 Tartarus: are you saying I should be drinking beer atm? ;) Aug 30 13:46:35 smurray: It's Friday and I know you've had several hard meetings :) Aug 30 13:46:41 this week Aug 30 13:46:56 Tartarus: still AGL stuff needed for the point release, sadly Aug 30 13:48:25 oh, got passed through elfutils-native. Never though I'll have to build Krogoth again Aug 30 13:48:42 RP, I'd totally pick the fun stuff. We all want you healthy and well. Aug 30 13:48:44 smurray: https://jeremylyons1.bandcamp.com/track/coffee-rag Aug 30 13:53:40 Tartarus: +1, toying with making another aeropress coffee Aug 30 13:56:33 zeddii: FWIW the mpc build failure reproduces locally for me Aug 30 14:11:01 has anyone used crops in gitlab-ci? Aug 30 14:14:20 zeddii: could you share a copy of recipe-sysroot/usr/include from a working mpc build from the eudev directory? Aug 30 14:26:04 RP:I changed the kernel to 4.19 for qemuppc and eudev build worked ok Aug 30 14:26:16 RP:so its specific to mpc I believe Aug 30 14:26:30 khem: Its some kind of header overlap/define problem Aug 30 14:27:10 khem: if I put #include so somehow the include is being masked Aug 30 14:27:25 RP: it would be helpful to get gcc -E output of the failing file Aug 30 14:31:05 khem: its finding include-fixed/asm-generic/socket.h Aug 30 14:32:16 and that file is totally wrong Aug 30 14:33:03 khem: I suspect it depends which machine we compile gcc for :/ Aug 30 14:38:41 RP:can you paste this file somewhere Aug 30 14:38:55 khem: which one, the wrong include? Aug 30 14:39:01 khem: or -E output Aug 30 14:39:03 yes otally wrong Aug 30 14:39:11 wrong file Aug 30 14:39:41 glibc has added a wrapper for ppc so I wonder if this is in play here Aug 30 14:40:55 khem: https://paste.debian.net/1098012/ Aug 30 14:41:13 khem: I just sent something to the list with my findings so far too Aug 30 14:44:06 khem: that file is missing a chunk from the end of it Aug 30 14:45:14 * zeddii is here Aug 30 14:45:22 RP: still want that directory ? I can tar it up and put it on my server Aug 30 14:46:12 zeddii: no, I think we're further forward now, thanks! Aug 30 14:46:27 khem: I rebuild gcc-cross-powerpc and the include-fixed file is now correct Aug 30 14:46:27 ok. cool. I see the email. will read and ponder. Aug 30 14:46:53 zeddii: basically we have some idea what is happening but not why Aug 30 14:47:08 zeddii: or how to reproduce Aug 30 14:47:16 * zeddii nods Aug 30 14:47:31 but at least I probably wasn’t going insane to think that my builds were actually completing. Aug 30 14:47:50 I still wonder if fixincludes is firing sometimes and not others. Aug 30 14:47:58 I admit to knowing nearly nothing about fixincludes Aug 30 14:48:12 I had to google it when I ran into it mid august while first doing the header update. Aug 30 14:51:25 RP:/usr/include/asm-generic/socket.h is kernel headers right Aug 30 14:51:35 khem: yes Aug 30 14:51:52 so is this file changing between different ppc machines ? Aug 30 14:52:08 then we cant use common gcc-cross Aug 30 14:52:34 khem: it shouldn't because linux-libc-headers is not machine specific Aug 30 14:52:47 other option is to tell gcc not to fix include socket.h Aug 30 14:53:00 we should diff linux-libc-headers for mpc vs. qemuppc Aug 30 14:53:18 RP:I think thats a good idea Aug 30 14:53:33 khem: right, I don't think it should be trying to "fix" it either but I want to get to the root cause of the difference Aug 30 14:53:48 khem: its also possible 5.0 somehow leaked into my original buil Aug 30 14:54:02 * RP doesn't quite see how Aug 30 14:55:01 oh, I do :/ Aug 30 14:55:33 SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += " \ Aug 30 14:55:34 gcc-cross-${TARGET_ARCH}->linux-libc-headers \ Aug 30 14:55:59 RP: the file you pasted seems to be using old ./arch/powerpc/include/uapi/asm/socket.h when generating the fix-include Aug 30 14:56:10 I bet we can change liunx-libc-header versions and the above means gcc doesn't rebuild Aug 30 14:56:19 old meaning from < 5.2 kernel headers Aug 30 14:56:38 the socket.h in gcc is then from 5.0 and breaks as it doesn't match 5.2 Aug 30 14:56:42 khem: yes Aug 30 14:56:46 it clearly means we are missing dep on linux-libc-headers Aug 30 14:56:58 in gcc-cross Aug 30 14:56:59 khem: we have the dep, we just whitelist it Aug 30 14:57:07 ugh Aug 30 14:57:19 khem: bottom line, gcc shouldn't be "fixing" these Aug 30 14:57:40 RP: I think we can do something like FreeBSD and ignore fixed-include Aug 30 14:58:10 zeddii: so reproduce is to configure with linux-libc-headers 5.0, build gcc-cross-powerpc, then switch to linux-libc-headers Aug 30 14:58:22 (5.2) Aug 30 14:58:32 khem: we could just delete them? :) Aug 30 14:58:53 RP: now that we know gcc-cross uses kernel headers to build itself, we probably can not whitelist the dep Aug 30 14:59:05 RP: pretty much Aug 30 14:59:10 khem: it is ok, we just need to stop it doing this Aug 30 14:59:33 that mostly what BSD does, but they then take the needed bits into BSD system headers Aug 30 14:59:54 khem: fixed-include is pretty much empty anyway Aug 30 15:00:13 yeah limits.h might be the only king there Aug 30 15:00:18 khem: right Aug 30 15:01:23 Because this is an automated process, sometimes headers get "fixed" that do not, strictly speaking, need a fix. As long as nothing is broken by the process, it is just an unfortunate collateral inconvenience. We would like to rectify it, if it is not "too inconvenient". Aug 30 15:01:38 * RP mutters about inconvenience Aug 30 15:01:51 (from the README in the directory) Aug 30 15:02:32 RP: lets delete it and see if hell breaks lose Aug 30 15:02:57 khem: delete "anything not limits.h and syslimits.h"? Aug 30 15:03:46 zeddii: I think this also explains how your mystery headers disappeared last time Aug 30 15:11:47 RP: I would say everything Aug 30 15:30:24 * zeddii reads Aug 30 15:30:26 indeed. Aug 30 15:32:27 * zeddii doesn’t like “magic”, unless it’s in some cheesy sci-fi book I’m reading :D Aug 30 15:33:14 RP: I do have fixed up, new versions of the 5.2 recipes. I can re-send the queue as a new pull request. since we maybe closer to the bottom of the headers issue. Aug 30 15:34:02 I’ll double check the SRCREVs in Kevin’s yocto-bsp pull and mention if it is ok and if not send a v2 with new SRCREvs. Aug 30 15:38:16 zeddii: I'd like to try that so please send. I'll send a patch for the headers... Aug 30 15:38:26 well, the gcc piece of the headers puzzle Aug 30 15:45:15 RP: looks like the reproducible build test passed with the clean build patch? Aug 30 15:45:57 JPEWhacker: yes, I'm curious why Aug 30 15:48:02 it's the lowest "level" of reproducibility. basically, it eliminates most of the rebuild and RSS issues by never rebuilding recipes (either b/c of changes or via sstate) Aug 30 15:49:18 RP: it's not where we want to be, but at least we won't regress if the test is in place. Aug 30 15:49:30 JPEWhacker: we shouldn't have rebuild issues Aug 30 15:52:22 RP: I agree we shouldn't. empirically speaking, we do have at least a few Aug 30 15:53:48 RP: and, of course they need to be fixed :) I just not sure how ATM Aug 30 15:54:29 zeddii: when you get your patches out we can have a new build (after autobuilder maint I guess) Aug 30 15:54:50 JPEWhacker: I mean that the autobuilder doesn't rebuild :/ Aug 30 15:55:07 about to send them now. I’m not resending anything 5.2 header related, just the pure kernel parts. Aug 30 15:55:16 let me know if you’d like any other parts resent. Aug 30 15:56:23 zeddii: can you send what I'm missing from -next? :) Aug 30 15:57:07 ok. checking! Aug 30 16:00:10 RP: Ahhh..... hmmm.... curious. that makes me think that the recipes are restoring from sstate and what's in sstate doesn't match Aug 30 16:00:35 JPEWhacker: yes Aug 30 16:13:27 * zeddii steps away for a few hours. will be back later. Aug 30 16:14:34 JPEWhacker: right, which worries me Aug 30 16:25:41 is there any way to ignore the LAYERSERIES_COMPAT of a layer? Aug 30 16:31:34 RP: ya. i've always lumped together reproducible rebuilds and reproducible sstate because sstate can't possibly be reproducible if rebuilds aren't since you can't tell if sstate came from a rebuild (in general... perhaps the AB is different?) Aug 30 16:32:44 JPEWhacker: the autobuilder always has a clean tmp at the start of a build so it can't have rebuilds Aug 30 16:34:38 RP: how do the OEQA test case builds work? do they share sstate or tmpdir? Aug 30 16:42:46 JPEWhacker: they do share sstate and sometimes a tmpdir Aug 30 16:49:47 RP: so one hypothesis is that before my clean build change, it was sharing tmpdir from a previous OEQA test, and pulling sstate from the AB mirror is still ok. that could be easily tested. Aug 30 16:56:20 JPEWhacker: ah, we should test that, yes. Could be Aug 30 16:56:43 JPEWhacker: I'd assumed it was a clean tmpdir previously like the patch enabled Aug 30 16:58:24 ok, I'll send a patch to test it later today... it's probably not useful outside the AB though since not everyone is so rigorous about how three sstate mirror is populated. Aug 30 17:04:40 JPEWhacker: right, it would give me peace of mind to test though Aug 30 17:06:51 kanavin_: I'll queue you changes after we test the libc headers stuff in isolation Aug 30 19:20:54 alimon: you there? Aug 30 19:22:14 tgamblin: yes Aug 30 22:39:48 RP, backported the toolchain tests to warrior to see what works **** ENDING LOGGING AT Sat Aug 31 02:59:57 2019