Friday, 2019-08-30

*** learningc <learningc!~learningc@> has quit IRC00:25
*** fatalhalt <fatalhalt!> has joined #yocto00:27
*** fatalhalt <fatalhalt!> has joined #yocto00:29
*** learningc <learningc!> has joined #yocto00:36
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:49
*** chinhuat647 <chinhuat647!~chinhuat@> has joined #yocto02:02
*** chinhuat64 <chinhuat64!~chinhuat@> has quit IRC02:04
yoctiNew news from stackoverflow: Where can I find my Linux kernel source directory? <>02:20
*** scottrif <scottrif!> has quit IRC04:06
*** fatalhalt <fatalhalt!> has quit IRC04:38
*** kroon <kroon!~kroon@> has joined #yocto04:39
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto04:42
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC05:15
*** AndersD <AndersD!> has joined #yocto05:30
LetoThe2ndarmpit: my day so far: 1) open mutt 2) read mail 3) mentally picture behanw as Miss California. 4) thanks armin.05:50
LetoThe2ndarmpit: hum how comes you around this time?05:51
armpitits only 11pm here.. getting sleepy.. will leave shortly05:52
LetoThe2ndarmpit: ah, thought you were more east.05:53
armpitnope, California05:54
* LetoThe2nd nods silently. rereads mail.05:54
behanwLetoThe2nd: uh. I just don’t want to know...06:10
LetoThe2ndbehanw: blame armpit06:13
behanwI still don’t want to know06:13
*** jeanba <jeanba!~jbl@> has joined #yocto06:15
LetoThe2ndbetter that is, probably.06:15
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:22
*** jeanba <jeanba!~jbl@> has left #yocto06:24
*** iceaway <iceaway!~pelle@> has quit IRC06:41
*** iceaway <iceaway!~pelle@> has joined #yocto06:45
iceawayLetoThe2nd: thanks for the great live coding sessions on youtube/twitch. Very helpful for a newcomer!06:47
LetoThe2ndiceaway: oh, thanks! glad it helps, and if theres more questions just them in here :)06:48
LetoThe2nd*just shoot them in here :)06:49
qschulz__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() }06:58
*** jmiehe <jmiehe!> has joined #yocto06:58
*** yacar_ <yacar_!~yacar@> has joined #yocto07:11
*** mckoan|away is now known as mckoan07:15
iceawayLetoThe2nd: 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.07:16
LetoThe2ndiceaway: yes it certainly is.07:17
LetoThe2ndiceaway: 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! :)07:18
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto07:23
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto07:24
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto07:28
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC07:30
iceawayLetoThe2nd: That would be awesome, I will see if that's possible with regards to family/work situation.07:32
LetoThe2ndiceaway: depends on your whereabouts and such, of course. but its a good occasion to get your hands dirty :)07:33
*** yann <yann!> has quit IRC07:44
RPkanavin_: that /dev/fb0 error is still in -next after I remove the 5.2 kernels :/07:45
__angeloqschulz, thanks, very appreciated, testing it07:45
RPkanavin_: that raises the likelihood its one of your patches :/07:46
qschulz__angelo: if that doesn't make it, then I don't know more, I haven't developed that part of our Yocto07:49
__angeloqschulz, thanks a lot, let you know in short07:50
LetoThe2ndanybody run into smb/nmb not coming up reliably on low-end hardware? systemd seems to be confused over them and timeouts.07:52
*** goliath <goliath!> has joined #yocto07:57
iceawayI'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: not08:01
iceawayfound". 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?08:01
LetoThe2ndiceaway: first thought is, did you make sure the release of all your layer align?08:01
iceawayHmm, 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:
iceawayI would assume that their repo manifest file pulls in the proper versions of everything.08:04
LetoThe2ndiceaway: yes i would assume the same08:05
LetoThe2ndupdate-rc.d at least sounds like something being cofused over classic init and systemd or such08:05
iceawayAgreed, 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?08:07
LetoThe2ndiceaway: probably, yes.08:08
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:09
bisbarnMorning,  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 to08:20
bisbarntouch the original recipe.08:20
qschulzbisbarn: what does your bbappend look like and where exactly is your boot.cmd located?08:39
RPAhrg. 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 :(08:41
bisbarnqschulz: 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) ;)08:47
yoctiNew news from stackoverflow: I2C driver changes to recognize multiple buses <>08:51
iceawayWhen 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: 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 that09:01
iceawaycommand resets everything in local.conf so apparantly that is not the way to go.09:01
LetoThe2ndiceaway: usually one would source poky/oe-init-env-or-whatsitcalled again09:04
iceawayrunning "source sources/poky/oe-init-build-env build_poky" seems to work for me, just not 100% that is the correct way.09:04
LetoThe2ndiceaway: 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.09:05
*** tprrt <tprrt!> has joined #yocto09:09
qschulzbisbarn: yes, that's what happened to me multiple times already :/ It gets tricky very quick09:09
bisbarnqschulz: 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" ;)09:11
qschulzbisbarn: it depends, you make it harder to override afterwards if you have another bbappend which should be a boot.cmd for all machines09:12
bisbarnqschulz: true09:13
*** mckoan is now known as mckoan|away09:16
iceawayLetoThe2nd: thanks! Referring back to my earlier pulseaudio issue, in the file it has on the inherit line: "systemd". Would that implicate that it supports exclusively systemd and not i.e. SysV init?09:24
iceawayor merely that it can be configured with systemd?09:26
LetoThe2ndiceaway: don't know, and no time to look it up at the moment, sorry.09:27
LetoThe2ndqschulz: ^^^ maybe you have time for a peek?09:27
iceawayNo worries!09:30
qschulziceaway: which version of poky? where is this /run.do_install.29140: update-rc.d: not found" coming from (which recipe?)?09:32
qschulzLetoThe2nd: we use update-rc.d here and we don't have systemd.09:33
LetoThe2ndqschulz: i have no experience on neither update-rc nor gstreamer, hence its a bit too much for me ATM09:34
iceawayI'm using poky 2.5.2. The recipe is pulseaudio-11.109:35
qschulzneither do I :D just had a few issues with update-rc.d so I'm learning on the fly :D09:35
iceawayApparantly I have update-rc.d both on the target and on my development machine09:35
iceawayCould it be some issue that the bitbake environment cannot find the update-rc.d executable?09:35
iceawayIf I run "bitbake -c devshell pulseaudio" I can run update-rc.d in the devshell.09:37
qschulzI don't use devshell :/09:38
RPAhrg, second clean build failed in the same area. I'm going to have to debug this :(09:38
*** learningc <learningc!> has quit IRC09:39
qschulziceaway: could you paste somewhere the run.do_install?09:42
*** yacar_ <yacar_!~yacar@> has quit IRC09:48
kroonRP, at least you can reproduce it more easily it seems!09:50
*** AndersD <AndersD!> has quit IRC09:54
iceawayqschulz: definitely, here it is:
RPkroon: right, at the more inopportune moment :/09:59
* alessioigor waves10:06
alessioigorIs it expected that wic has started to ignore IMAGE_ROOTFS_SIZE since one or two weeks ago (on master)?10:06
*** learningc <learningc!~learningc@> has joined #yocto10:19
iceawayNote 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".10:22
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC10:23
*** jmiehe <jmiehe!> has quit IRC10:23
*** iceaway <iceaway!~pelle@> has quit IRC10:23
*** sgw <sgw!~sgw@> has quit IRC10:23
*** tsjsieb <tsjsieb!~quassel@> has quit IRC10:23
*** cpo <cpo!~cpo@> has quit IRC10:23
*** neverpanic <neverpanic!> has quit IRC10:23
*** JaMa <JaMa!> has quit IRC10:23
*** tgoodwin <tgoodwin!> has quit IRC10:23
*** sbach <sbach!~sbach@> has quit IRC10:23
*** alimon <alimon!alimon@gateway/shell/linaro/x-aordrllpakefcuat> has quit IRC10:23
*** Saur <Saur!pkj@nat/axis/x-ecvvkhhtbodjlxhn> has quit IRC10:23
*** seebs <seebs!~seebs@> has quit IRC10:23
*** miwa_ <miwa_!~miwa@unaffiliated/miwa> has quit IRC10:23
*** svuorela <svuorela!~svuorela@kde/sune> has quit IRC10:23
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC10:23
*** yates <yates!> has quit IRC10:23
*** rewitt <rewitt!~rewitt@> has quit IRC10:23
*** thaytan <thaytan!> has quit IRC10:23
*** falk0n <falk0n!> has quit IRC10:23
*** wooosaiiii <wooosaiiii!> has quit IRC10:23
*** jaeckel <jaeckel!~jaeckel@unaffiliated/jaeckel> has quit IRC10:23
*** Ad0 <Ad0!~Ad0@> has quit IRC10:23
*** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC10:23
*** dfrey <dfrey!~dfrey@> has quit IRC10:23
*** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has quit IRC10:23
*** adelcast <adelcast!~adelcast@> has quit IRC10:23
*** Pharaoh_Atem <Pharaoh_Atem!~neal@fedora/ngompa> has quit IRC10:23
*** flying_sausages <flying_sausages!> has quit IRC10:23
*** yourfate <yourfate!~yourfate@unaffiliated/yourfate> has quit IRC10:23
*** lpoulain <lpoulain!lpoulain@gateway/shell/linaro/x-whcbvwpfkezrgrqk> has quit IRC10:23
*** fullstop <fullstop!~fullstop@> has quit IRC10:23
*** Chaser <Chaser!~Chaser@> has quit IRC10:23
*** Striking7 <Striking7!> has quit IRC10:23
*** dl9pf <dl9pf!~quassel@opensuse/member/dl9pf> has quit IRC10:23
*** tsjsieb <tsjsieb!~quassel@2a06:5b80:1::2be3:ec4> has joined #yocto10:23
*** cpo <cpo!> has joined #yocto10:24
*** sbach <sbach!~sbach@> has joined #yocto10:24
*** iceaway <iceaway!~pelle@> has joined #yocto10:25
*** georgem <georgem!~georgem@> has quit IRC10:25
*** Pharaoh_Atem <Pharaoh_Atem!~neal@fedora/ngompa> has joined #yocto10:26
*** tgoodwin <tgoodwin!> has joined #yocto10:26
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto10:26
*** seebs <seebs!~seebs@> has joined #yocto10:26
*** georgem_ <georgem_!~georgem@> has joined #yocto10:26
*** yourfate <yourfate!~yourfate@unaffiliated/yourfate> has joined #yocto10:27
*** fullstop <fullstop!~fullstop@> has joined #yocto10:27
*** flying_sausages <flying_sausages!> has joined #yocto10:27
kanavin_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.10:28
*** lpoulain <lpoulain!lpoulain@gateway/shell/linaro/x-dzqnckydpijeibqp> has joined #yocto10:29
*** falk0n <falk0n!> has joined #yocto10:29
*** Ad0 <Ad0!~Ad0@> has joined #yocto10:33
*** thaytan <thaytan!> has joined #yocto10:33
*** yizhao <yizhao!> has joined #yocto10:37
*** learningc <learningc!~learningc@> has quit IRC10:38
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto10:40
*** wooosaiiii <wooosaiiii!> has joined #yocto10:40
*** dfrey <dfrey!~dfrey@> has joined #yocto10:41
*** jaeckel <jaeckel!~jaeckel@unaffiliated/jaeckel> has joined #yocto10:41
iceawayCould 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?10:41
*** learningc <learningc!~learningc@> has joined #yocto10:41
*** Chaser <Chaser!~Chaser@> has joined #yocto10:42
qschulz"your" native update-rc.d?10:43
*** Striking7 <Striking7!> has joined #yocto10:44
iceawayYes, in the devshell if I run which update-rc.d I get the one that came with my Linux distribution, not one from within Yocto10:45
*** neverpanic <neverpanic!> has joined #yocto10:45
iceawayTHere 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.10:47
*** kaspter <kaspter!~Instantbi@> has quit IRC10:50
*** kaspter <kaspter!~Instantbi@> has joined #yocto10:51
*** jmiehe <jmiehe!> has joined #yocto11:02
qschulziceaway: do you have any bbappend for pulseaudio somewhere?11:05
qschulzI don't understand where the end of the do_install comes from11:07
iceawayTHere 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)11:17
qschulz`bitbake-layers show-appends` apparently11:18
iceawayYeah now I found it, it is in a bbappend-file from the variscite meta-layer.
iceawayNo idea how to fix it in the most correct way though.11:22
qschulziceaway: create a new bbappend and add DEPENDS_append = " update-rc.d-native"11:24
iceawayqschulz: really cool, now it seems to work! Thank you for the help.11:31
*** learningc <learningc!~learningc@> has quit IRC11:31
iceawayWhat 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?11:32
*** yacar_ <yacar_!~yacar@> has joined #yocto11:33
*** mischief <mischief!> has joined #yocto11:33
*** berton <berton!~berton@> has joined #yocto11:37
qschulzDEPENDS is for dependencies at build time11:38
qschulzit's going to put binaries and headers into a sysroot for your recipe so it can use those resources for compiling the software11:38
qschulzwhen you have -native in the name, it's binaries and libraries compiled for the host system which are needed at build time11:39
qschulzrecipe-sysroot for the first, recipe-sysroot-native for the second11:39
qschulz_append is an almost same (BUT NOT) mechanism as DEPENDS +=11:39
qschulzone or the other is fine here AFAICT11:40
*** berton <berton!~berton@> has quit IRC11:40
qschulzwhat 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 DEPENDS11:41
*** berton <berton!~berton@> has joined #yocto11:42
iceawayqschulz: thanks for the detailed explanation. I will notify the maintainers about that issue.11:49
qschulziceaway: happy to help :)11:51
qschulzQuestion: I've this package with prebuilt libraries which depends on I have a package which provides Obviously, Yocto isn't happy because it can't find a RPROVIDER for for the mentioned package.11:52
qschulzI don't really like our INSANE_SKIP file-rdeps at the moment :D11:53
qschulzalso, 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... :/)11:56
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC12:01
*** georgem_ is now known as georgem12:19
iceawayPull request with the fix done \o/12:22
RPand after a lot of debugging, its a race in my debug code :(12:26
RPbut shows a design problem in the main code which may also be a problem12:26
qschulziceaway: the open source community is thanking you :)12:28
*** jmiehe <jmiehe!> has quit IRC12:38
iceawayAlways feels good when you can contribute back to the community.12:43
*** yates <yates!> has joined #yocto12:43
yatesdoesn't bitbake/yocto set pn to the recipe name? so if i'm bitbake, pn = abc?12:44
yatesif so then why am i getting "WARNING: load-initramfs-scripts-1.0+3653-r0 do_package_qa: QA Issue: /etc/init.d/ contained in package load-initramfs-scripts requires /bin/bash, but no providers found in RDEPENDS_load-initramfs-scripts? [file-rdeps" ...12:45
yateswhen i have "RDEPENDS_${pn} = "bash"" in my bb file?12:45
yatesin, i.e.12:46
*** Saur <Saur!pkj@nat/axis/x-xrbzzpoadaoriuft> has joined #yocto12:47
kanavin_RP: aww, i just missed the master-next queue12:50
kanavin_there's some tasty py2->3 work I sent :)12:51
mcfriskquite often I wish bitbake would throw an error when referencing non-existing variables, and that bash snippets would be executed with set -euxo pipefail...12:51
kanavin_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 itself12:51
RPkanavin_: typical! :)12:54
RPkanavin_: although I'm trying only to remove patches to get to a point where something can merge!12:54
RPkanavin_: patches look good at a quick glance!12:56
kanavin_RP: a bit disappointed that py2 cannot build without having a binary of itself already available. I might poke into why is that.12:57
RPkanavin_: hmm, yes. I guess we never used to have to worry about that12:58
yateskinda like using C to write a C compiler?12:58
kanavin_RP: we'll probably remove py2 from HOSTTOLS/self-hosted and py2 recipes as a single patch.12:58
kanavin_yates, yes, except python is written in C12:59
yateskanavin_: then why does it need a binary of itself to build?12:59
kanavin_yates,  it needs to run .py scripts at build time to produce some generated stuff12:59
kanavin_yates, and - surprise - they didn't make those scripts py3 compatible12:59
kanavin_down to still using print "stuff" for example13:00
yatesi'm a python idiot, so i'll shutup now..13:00
yatesbeen resisting learning it for a decade now13:00
kanavin_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 machines13:01
kanavin_that is not actually true: not only the lists differ, but also the default cards if you do not specify -vga13:01
RPkanavin_: ok, glad we've figured it out!13:05
smurraykanavin_: yeah, I was also surprised to see that py2 needs itself on the host in my test builds the other day13:06
kanavin_smurray, I suspect it might be because we do 'make regen-all'13:07
kanavin_I am not sure if that is actually necessary, maybe it isn't, and if we drop it, then py2 binary is no longer used13:07
*** goliath <goliath!> has quit IRC13:08
smurrayhrm, is it worth digging into, considering it should be going away?13:08
kanavin_smurray, distributions are now actively making moves to remove py2 altogether13:09
kanavin_so we should be prepared for a situation where a widely used distro won't let you install py2 on the host13:09
smurrayso the concern would be no longer being able to build it for versions of OE where we still support it13:10
kanavin_smurray, not necessarily, those versions have a list of tested distributions, which will not include any new ones13:10
kanavin_I am thinking more of upcoming distro releases and how we handle them in master13:11
smurrayI'm guessing the u-boot py2 -> py3 fixes won't make it for zeus, so would be a concern for its lifetime13:12
kanavin_smurray, Tartarus said he13:13
kanavin_he's actively looking into it actualyl13:13
smurrayyeah, we've discussed it a bit13:13
TartarusSo, what's the cutoff for zeus?13:14
TartarusI am hoping that for v2019.10 u-boot will be python3 happy13:14
TartarusAnd that's oct 713:15
kanavin_Tartarus, would it be feasible to create a backport?13:15
kanavin_oct 7 does seem like too late13:15
TartarusIt'd sure be a pain13:15
TartarusWe've already closed the merge window13:15
TartarusIt'd be great for us, and for you too perhaps, to track the -rc releases?13:16
kanavin_Tartarus, what I mean is that you create a 'custom' backport patch to the version that is currently in oe-core13:16
smurrayiirc, RP indicated we're close to zeus feature freeze13:16
Tartaruskanavin_: 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 set13:17
kanavin_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 winter13:17
TartarusI really would advocate for tracking U-Boot releases here instead13:17
kanavin_Tartarus, we do track them, once every month AUH robot sends an email to u-boot maintainer telling what the latest non-rc version is13:18
TartarusI'm saying, do a one off in this case13:18
TartarusUpgrade "today" to v2019.10-rc313:18
kanavin_that maintainer at the moment is.... Marek Vasut <>13:18
TartarusAnd -rc when it comes out in a weeek and change13:18
TartarusYes, marex-cloud is here too :)13:18
kanavin_if he is okay with that then sure13:19
TartarusWell, is RP going to allow those upgrades in, for zeus?13:19
kanavin_I'd say maybe we defer it to post-zeus13:20
TartarusIf you're doing it post zeus, you can just catch it with the normal release cycle13:20
TartarusBut if you want zeus to be python2 free13:20
kanavin_then you can take your time with getting the py3 support u-boot nice and polished13:20
TartarusIt's not actually that far off13:20
TartarusSimon did a lot of the back-end stuff a while ago, but kept it 2 compatible13:21
TartarusThe pylibfdt stuff really is just s/python2/python3/13:21
TartarusAnd the fedora folks are less flexible about python2 support than you are :)13:21
smurraykanavin_: just a thought, would it be feasible to just have a python-native recipe for zeus?13:22
kanavin_smurray, nope, because py2 still needs to be in self-hosted13:22
kanavin_smurray, also we can't drop it from HOSTTOOLS because as discussed it needs itself :)13:22
kanavin_it's like a circular dependency, the only way to handle it is to remove all three13:23
smurraykanavin_: right, it'd have to stay in HOSTTOOLS, but then it'd not be buildable for target at all?13:23
kanavin_yes, which breaks the self-hosted13:23
smurrayah, like the builder images, etc.13:23
kanavin_smurray, also, brace yourself for the fallout when it is removed13:24
kanavin_I expect half the meta-oe will break, and most other layers13:24
smurraykanavin_: yeah, I've not been brave enough to attempt building that yet13:24
kanavin_the sad experience I have is that warning people in advance about upcoming breakage has no effect13:24
kanavin_the only way to have things fixed is either do it yourself, or do the breaking change and face the shouting and screaming13:25
smurraylikely will need to have the meta-python2 in hand for people to use in the short-term13:26
kanavin_this is more or less standard approach for obsolete things like qt3, qt4, lsb etc that were once in oe-core13:27
kanavin_gplv2 as well :)13:27
smurrayit'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-python213:28
kanavin_yeah, upstream however has made it clear that they won't do any py2 work post-jan 1 20213:29
kanavin_I guess they'll knock out one final release and shut it down for good13:29
kanavin_also centos 8 is much welcome, centos 7 is seriously ancient at this point13:30
smurrayyeah, 7 is painful to use for building anything13:30
kanavin_(not centos fault obviously)13:31
*** luneff <luneff!~yury@> has joined #yocto13:33
luneffhey 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-613:34
kanavin_luneff: you probably need to change what /usr/bin/gcc points to13:34
kanavin_however, it may only get worse with an older version ;)13:35
luneffit can... but I wonder if there's a cleaner solution, like a local.conf variable13:35
kanavin_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 guess13:36
luneffexport CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}" ;-(13:37
luneffI guess I really should change /usr/bin/gcc :-)13:37
kanavin_I wonder what HOST_PREFIX does13:37
luneff/usr/bin/, I think13:38
smurrayit would be BUILD_CC that you would change, I believe13:38
kanavin_ah, I thought you could set it to 'my-awesome-'13:38
*** Crofton|mini <Crofton|mini!> has joined #yocto13:38
luneffno, I needed gcc-6 instead of just gcc, which is gcc-713:38
luneffso it's more like a suffix in this case :-)13:39
smurrayI'd try sticking a gcc -> gcc-6 symlink in ~/bin or the like first, see if it'll get picked up13:39
smurrayif that doesn't work, try: export BUILD_CC = "${CCACHE}${BUILD_PREFIX}gcc-6 ${BUILD_CC_ARCH}" in local.conf13:40
* kanavin_ just got handed a beer, in the office13:40
kanavin_productivty goes downhill for the rest of the day13:40
kanavin_the germans are *very* liberal in that department13:40
kanavin_never in a million years could happen in finland13:41
*** Bunio_FH <Bunio_FH!> has joined #yocto13:41
RPkanavin_: :D13:43
RPkanavin_: I could use a beer right now...13:43
smurraykanavin_: heh, I'm several hours away from beer, I'm envious13:44
Tartarussmurray: I promise not to tell HR ;)13:44
luneffsmurray, thanks! trying :-)13:44
* 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 :/13:44
*** Crofton|mini <Crofton|mini!> has quit IRC13:45
smurrayTartarus: are you saying I should be drinking beer atm? ;)13:46
*** Crofton|mini <Crofton|mini!> has joined #yocto13:46
Tartarussmurray: It's Friday and I know you've had several hard meetings :)13:46
Tartarusthis week13:46
smurrayTartarus: still AGL stuff needed for the point release, sadly13:46
luneffoh, got passed through elfutils-native. Never though I'll have to build Krogoth again13:48
kanavin_RP, I'd totally pick the fun stuff. We all want you healthy and well.13:48
smurrayTartarus: +1, toying with making another aeropress coffee13:53
*** Crofton|mini <Crofton|mini!> has quit IRC13:55
RPzeddii: FWIW the mpc build failure reproduces locally for me13:56
*** lfa_ <lfa_!~lfa@> has quit IRC14:01
*** stew-dw <stew-dw!~stew-dw@> has quit IRC14:05
*** iceaway <iceaway!~pelle@> has quit IRC14:09
tgoodwinhas anyone used crops in gitlab-ci?14:11
*** stew-dw <stew-dw!~stew-dw@> has joined #yocto14:11
RPzeddii: could you share a copy of recipe-sysroot/usr/include from a working mpc build from the eudev directory?14:14
*** alimon <alimon!alimon@gateway/shell/linaro/x-jgbtkxiflkqtvjob> has joined #yocto14:25
khemRP:I changed the kernel to 4.19 for qemuppc and eudev build worked ok14:26
khemRP:so its specific to mpc I believe14:26
RPkhem: Its some kind of header overlap/define problem14:26
RPkhem: if I put #include <asm-generic/socket.h at the top of log.c, it works. If I it anywhere else I see the error14:27
RPso somehow the include is being masked14:27
khemRP: it would be helpful to get gcc -E output of the failing file14:27
RPkhem: its finding include-fixed/asm-generic/socket.h14:31
RPand that file is totally wrong14:32
RPkhem: I suspect it depends which machine we compile gcc for :/14:33
*** luneff <luneff!~yury@> has quit IRC14:37
khemRP:can you paste this file somewhere14:38
RPkhem: which one, the wrong include?14:38
RPkhem: or -E output14:39
khemyes otally wrong14:39
khemwrong file14:39
*** Bunio_FH <Bunio_FH!> has quit IRC14:39
khemglibc has added a wrapper for ppc so I wonder if this is in play here14:39
RPkhem: I just sent something to the list with my findings so far too14:41
*** alessioigor <alessioigor!~alessioig@> has quit IRC14:42
RPkhem: that file is missing a chunk from the end of it14:44
* zeddii is here14:45
zeddiiRP: still want that directory ? I can tar it up and put it on my server14:45
RPzeddii: no, I think we're further forward now, thanks!14:46
RPkhem: I rebuild gcc-cross-powerpc and the include-fixed file is now correct14:46
zeddiiok. cool. I see the email. will read and ponder.14:46
RPzeddii: basically we have some idea what is happening but not why14:46
RPzeddii: or how to reproduce14:47
* zeddii nods14:47
zeddiibut at least I probably wasn’t going insane to think that my builds were actually completing.14:47
zeddiiI still wonder if fixincludes is firing sometimes and not others.14:47
zeddiiI admit to knowing nearly nothing about fixincludes14:47
zeddiiI had to google it when I ran into it mid august while first doing the header update.14:48
khemRP:/usr/include/asm-generic/socket.h is kernel headers right14:51
RPkhem: yes14:51
khemso is this file changing between different ppc machines ?14:51
khemthen we cant use common gcc-cross14:52
RPkhem: it shouldn't  because linux-libc-headers is not machine specific14:52
khemother option is to tell gcc not to fix include socket.h14:52
RPwe should diff linux-libc-headers for mpc vs. qemuppc14:53
khemRP:I think thats a good idea14:53
RPkhem: right, I don't think it should be trying to "fix" it either but I want to get to the root cause of the difference14:53
RPkhem: its also possible 5.0 somehow leaked into my original buil14:53
* RP doesn't quite see how14:54
RPoh, I do :/14:55
RP  gcc-cross-${TARGET_ARCH}->linux-libc-headers \14:55
khemRP: the file you pasted seems to be using old ./arch/powerpc/include/uapi/asm/socket.h when generating the fix-include14:55
RPI bet we can change liunx-libc-header versions and the above means gcc doesn't rebuild14:56
khemold meaning from < 5.2 kernel headers14:56
RPthe socket.h in gcc is then from 5.0 and breaks as it doesn't match 5.214:56
RPkhem: yes14:56
khemit clearly means we are missing dep on linux-libc-headers14:56
khemin gcc-cross14:56
RPkhem: we have the dep, we just whitelist it14:56
RPkhem: bottom line, gcc shouldn't be "fixing" these14:57
khemRP: I think we can do something like FreeBSD and ignore fixed-include14:57
RPzeddii: so reproduce is to configure with linux-libc-headers 5.0, build gcc-cross-powerpc, then switch to linux-libc-headers14:58
RPkhem: we could just delete them? :)14:58
khemRP: now that we know gcc-cross uses kernel headers to build itself, we probably can not whitelist the dep14:58
khemRP: pretty much14:59
RPkhem: it is ok, we just need to stop it doing this14:59
khemthat mostly what BSD does, but they then take the needed bits into BSD system headers14:59
RPkhem: fixed-include is pretty much empty anyway14:59
khemyeah limits.h might be the only king there15:00
RPkhem: right15:00
RPBecause 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".15:01
* RP mutters about inconvenience 15:01
RP(from the README in the directory)15:01
khemRP: lets delete it and see if hell breaks lose15:02
RPkhem: delete "anything not limits.h and syslimits.h"?15:02
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC15:03
RPzeddii: I think this also explains how your mystery headers disappeared last time15:03
khemRP: I would say everything15:11
*** kroon <kroon!~kroon@> has quit IRC15:20
*** yacar_ <yacar_!~yacar@> has quit IRC15:20
* zeddii reads15:30
* zeddii doesn’t like “magic”, unless it’s in some cheesy sci-fi book I’m reading :D15:32
zeddiiRP: 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.15:33
zeddiiI’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.15:34
*** JPEWhacker <JPEWhacker!> has joined #yocto15:35
RPzeddii: I'd like to try that so please send. I'll send a patch for the headers...15:38
RPwell, the gcc piece of the headers puzzle15:38
*** adelcast <adelcast!~adelcast@> has joined #yocto15:41
JPEWhackerRP: looks like the reproducible build test passed with the clean build patch?15:45
RPJPEWhacker: yes, I'm curious why15:45
*** bisbarn <bisbarn!> has quit IRC15:47
*** yates <yates!> has quit IRC15:47
JPEWhackerit'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)15:48
JPEWhackerRP: it's not where we want to be, but at least we won't regress if the test is in place.15:49
RPJPEWhacker:  we shouldn't have rebuild issues15:49
JPEWhackerRP: I agree we shouldn't. empirically speaking, we do have at least a few15:52
*** kroon <kroon!> has joined #yocto15:52
JPEWhackerRP: and, of course they need to be fixed :) I just not sure how ATM15:53
RPzeddii: when you get your patches out we can have a new build (after autobuilder maint I guess)15:54
RPJPEWhacker: I mean that the autobuilder doesn't rebuild :/15:54
zeddiiabout to send them now. I’m not resending anything 5.2 header related, just the pure kernel parts.15:55
zeddiilet me know if you’d like any other parts resent.15:55
RPzeddii: can you send what I'm missing from -next? :)15:56
zeddiiok. checking!15:57
JPEWhackerRP: Ahhh..... hmmm.... curious. that makes me think that the recipes are restoring from sstate and what's in sstate doesn't match16:00
RPJPEWhacker: yes16:00
*** sgw <sgw!~sgw@> has joined #yocto16:02
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto16:11
* zeddii steps away for a few hours. will be back later.16:13
RPJPEWhacker: right, which worries me16:14
*** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has joined #yocto16:24
qschulzis there any way to ignore the LAYERSERIES_COMPAT of a layer?16:25
JPEWhackerRP: 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?)16:31
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:32
RPJPEWhacker: the autobuilder always has a clean tmp at the start of a build so it can't have rebuilds16:32
JPEWhackerRP: how do the OEQA test case builds work? do they share sstate or tmpdir?16:34
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC16:37
RPJPEWhacker: they do share sstate and sometimes a tmpdir16:42
*** ralu <ralu!> has quit IRC16:47
JPEWhackerRP: 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.16:49
*** harryfan <harryfan!uid387287@gateway/web/> has quit IRC16:49
RPJPEWhacker: ah, we should test that, yes. Could be16:56
RPJPEWhacker: I'd assumed it was a clean tmpdir previously like the patch enabled16:56
JPEWhackerok, 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.16:58
*** lucaceresoli <lucaceresoli!> has quit IRC17:00
RPJPEWhacker: right, it would give me peace of mind to test though17:04
*** JPEWhacker <JPEWhacker!> has quit IRC17:06
RPkanavin_: I'll queue you changes after we test the libc headers stuff in isolation17:06
*** kaspter <kaspter!~Instantbi@> has quit IRC17:10
*** JPEWhacker <JPEWhacker!> has joined #yocto17:22
*** kroon <kroon!> has quit IRC17:26
*** WillMiles <WillMiles!> has joined #yocto17:40
*** JPEWhacker <JPEWhacker!> has quit IRC17:44
*** berton <berton!~berton@> has quit IRC17:58
*** berton <berton!~berton@> has joined #yocto18:00
*** kaspter <kaspter!~Instantbi@2409:8928:662:2d69:2434:8a4f:7f6:e177> has joined #yocto18:05
*** goliath <goliath!> has joined #yocto18:11
*** JPEWhacker <JPEWhacker!> has joined #yocto18:11
*** JPEWhacker <JPEWhacker!> has quit IRC18:30
*** yann|work <yann|work!> has joined #yocto18:50
*** kroon <kroon!> has joined #yocto19:09
tgamblinalimon: you there?19:20
alimontgamblin: yes19:22
*** berton <berton!~berton@> has quit IRC19:48
*** berton <berton!~berton@> has joined #yocto19:49
*** kroon <kroon!> has quit IRC20:01
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto20:13
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC20:33
*** kaspter <kaspter!~Instantbi@2409:8928:662:2d69:2434:8a4f:7f6:e177> has quit IRC20:33
*** camus <camus!~Instantbi@> has joined #yocto20:33
*** camus is now known as kaspter20:35
*** Bunio_FH <Bunio_FH!> has joined #yocto20:43
*** WillMiles <WillMiles!> has quit IRC21:14
*** berton <berton!~berton@> has quit IRC21:15
*** kaspter <kaspter!~Instantbi@> has quit IRC21:25
*** tprrt <tprrt!> has quit IRC21:26
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has joined #yocto21:59
*** jacques2 <jacques2!~jacques@nslu2-linux/jacques> has quit IRC22:02
*** jacques2 <jacques2!~jacques@nslu2-linux/jacques> has joined #yocto22:10
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has quit IRC22:12
*** jacques <jacques!~jacques@nslu2-linux/jacques> has joined #yocto22:13
*** jacques2 <jacques2!~jacques@nslu2-linux/jacques> has quit IRC22:15
armpitRP, backported the toolchain tests to warrior to see what works22:39

Generated by 2.11.0 by Marius Gedminas - find it at!