Monday, 2020-09-07

*** khem <khem!~khem@unaffiliated/khem> has quit IRC00:02
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC00:49
*** nerdboy <nerdboy!~sarnold@> has joined #yocto00:50
*** nerdboy <nerdboy!~sarnold@> has quit IRC00:58
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto00:58
*** yann <yann!~yann@> has quit IRC01:01
*** radsquirrel <radsquirrel!> has quit IRC01:54
*** radsquirrel <radsquirrel!> has joined #yocto02:11
*** radsquirrel <radsquirrel!> has quit IRC02:47
*** radsquirrel <radsquirrel!> has joined #yocto02:50
*** sakoman <sakoman!> has quit IRC03:00
*** stacktrust <stacktrust!> has quit IRC03:27
*** stacktrust <stacktrust!> has joined #yocto03:29
*** feddischson <feddischson!> has joined #yocto04:34
*** jwessel <jwessel!~jwessel@> has quit IRC05:32
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC05:33
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto05:39
*** AndersD <AndersD!> has joined #yocto05:44
*** zangman <zangman!7458c728@> has joined #yocto05:45
zangmanI am really confused about how package management works with Yocto. If I set PACKAGE_CLASSES = "package_deb" and then do a 'bitbake core-image-full-cmdline', it doesn't auto populate the repository sources05:47
zangmanIt's the same problem with package_ipkg05:47
zangmanI don't want to set up a package repo myself, can I not have this set to whatever repository is used at the time of build?05:48
zangmanAlso to clarify, I'm building this for the de10-nano-soc, and using the meta-altera layer -
kergoththere's a package-index recipe you can build if you want a feed. the feed used to build images isn't meant for external consumption.05:50
erbozangman: I guess that's "by design", it's not supposed to set up a package feed unless you explicitly tell it to since you need to be careful when using feeds to not mess up.05:50
kergothindeed :)05:50
zangmanAh I see - are there publicly available feeds I can set up for such purposes? Does the package-index recipe include these?05:51
erbozangman: You can find some details here if you just want something quick for development:
zangman@erbo: Thank you, I've gone through the page, I tried copying the same thing for deb and used the official debian repository, but it doesn't populate it correctly in sources.list:
zangmanEven after I correct it after booting the device, it still doesn't work saying error with the signature yada yada05:54
zangmanfix the signature issue, then it dies with a cryptic error05:54
*** pohly <pohly!> has joined #yocto05:54
*** agust <agust!> has joined #yocto06:03
erbozangman: just so I understand correctly, did you try to use the original debian repo? Or did you use it as a template to create a source pointing to your own repo?06:04
zangmanerbo: I tried to use the original debian repo. Basically booted up Yocto on my SoC device, copied debian repo URLs from my desktop debian and pasted them in the Yocto build06:06
erbozangman: you can't use debian repos, that will never work. Those packages are built for debian systems06:07
zangmanerbo: But I checked the debian repo, they do have an armhf repository. My device uses an armv7hf06:08
zangmanerbo: I assumed it would sort of work :|06:08
erbozangman: yes, but it's different distributions. Like you don't use rpms from Fedora in other rpm based distros.06:08
zangmanerbo: Ah - so package_deb is not sufficient to make it a debian based distro06:09
zangmanso the approach listed on the tips and tricks page is a way for me to fetch all the packages that I want to make available to my device and upload them to my own server?06:10
zangmani.e. bitbake package-index06:10
*** zangman <zangman!7458c728@> has quit IRC06:11
*** zangman <zangman!7458c728@> has joined #yocto06:11
erbozangman: yes. that approach creates a repo containing all the .deb created in your yocto build06:12
zangmanerbo: How does it handle package updates? For example, if there's a new version of vim, I would have to ...06:14
zangmanerbo: run `bitbake package-index`, upload the package to my server, and then run apt-get update on my device?06:15
*** mbulut <mbulut!> has joined #yocto06:16
*** goliath <goliath!> has joined #yocto06:18
erbozangman: I haven't used package feeds for anything other than quick n dirty dev work. But you'll need to use a PR-server to ensure that package versions keep increasing etc in order to get updates to work06:28
*** simonpe^1 <simonpe^1!> has joined #yocto06:28
simonpe^1Hey! It's me again, the dude with the config fragments. I've switched from the meta-imx stuff to meta-freescale @ dunfell and the linux-fslc-imx kernel, I managed to get m06:29
simonpe^1the meta-virtualization layer working by adding some weird kernel meta yocto-kernel-cache stuff to my kernel bbappend06:29
simonpe^1but my custom fragments are still not applied06:30
zangmanerbo: Talk about rabbit holes! But this is great, thank you - First, I will try and spin up my own package server at home to at least get that going and second, I will go through the PR_Service link and see if I need to set that up06:30
zangmanerbo: Thank you so much, appreciate it! :)06:30
*** mckoan|away is now known as mckoan06:32
simonpe^1I realize I have two irssi opened so I'm closing this one :S06:32
*** simonpe^1 <simonpe^1!> has quit IRC06:32
*** zandrey <zandrey!> has quit IRC06:33
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/> has joined #yocto06:47
*** frsc <frsc!> has joined #yocto06:50
*** fl0v0 <fl0v0!> has joined #yocto06:55
*** chris_ber <chris_ber!~quassel@> has joined #yocto07:02
*** beneth <beneth!> has joined #yocto07:09
*** rcoote <rcoote!> has joined #yocto07:13
*** zandrey <zandrey!~zandrey@> has joined #yocto07:28
*** yann <yann!~yann@> has joined #yocto07:31
*** zangman <zangman!7458c728@> has quit IRC07:31
*** jmiehe <jmiehe!> has joined #yocto07:34
*** jkimblad <jkimblad!> has joined #yocto07:54
*** zandrey_ <zandrey_!~zandrey@> has joined #yocto08:02
*** zandrey <zandrey!~zandrey@> has quit IRC08:06
*** awe001 <awe001!~awe00@unaffiliated/awe00> has joined #yocto08:08
*** Bunio_FH <Bunio_FH!> has joined #yocto08:11
simonpe^^what happened to u-boot-fw-utils? It seems to not exist anymore to me08:14
qschulzsimonpe^^: libubootenv now :)08:16
simonpe^^also, what's the difference between the u-boot-fslc/u-boot-imx/u-boot variations of u-boot?08:18
simonpe^^and which one is preferred08:18
qschulzsimonpe^^: u-boot is the upstream one with potential patches for making it build for all archs with Yocto. u-boot-imx is probably the official NXP version, and u-boot-fslc a community based one?08:20
simonpe^^so why would one pick the fslc over the upstream one?08:22
qschulzsimonpe^^: not full support in upstream. Usually what happens for vendors is that they add support to a fixed version of u-boot as quickly as possible so they can start selling their HW08:23
qschulz**some** vendors then start upstreaming a few patches to upstream projects (it takes time)08:24
qschulzso, upstream might not work fully or have support for everything you need08:24
qschulzuntil it's taken from the vendor versions and put into upstream (vendor or community effort)08:24
simonpe^^oh I see, so its vendor -> community -> upstream08:26
simonpe^^so the best solution for me would be to try out the upstream one, if that doesn't work the community one, and if all else fails the vendor one?08:27
*** goliath <goliath!> has quit IRC08:27
qschulzsimonpe^^: most of the time yes (while community can be clients of said vendor), very few vendors (NXP does it) upstream stuff directly and do not rely 100% on the community to do it08:27
simonpe^^ok cool, thanks08:28
qschulzsimonpe^^: yeah, especially for u-boot, if you don't need fancy stuff, go for upstream08:28
qschulzsee if it works good enough for you08:28
simonpe^^Imma need HAB eventually08:28
qschulzif not, it might just be a few patches you need from vendor08:28
simonpe^^not sure if that's a factor08:28
qschulzsimonpe^^: HAB is supported on imx6 for sure upstream08:28
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:28
qschulzdon't know for the other stuff08:28
simonpe^^I'm on imx808:28
*** AndersD <AndersD!> has quit IRC08:28
simonpe^^thanks, thats super helpful08:31
*** awe002 <awe002!~awe00@unaffiliated/awe00> has joined #yocto08:34
*** awe001 <awe001!~awe00@unaffiliated/awe00> has quit IRC08:37
*** awe003 <awe003!~awe00@unaffiliated/awe00> has joined #yocto09:00
*** xicopitz[m] <xicopitz[m]!xicopitzma@gateway/shell/> has quit IRC09:02
*** awe002 <awe002!~awe00@unaffiliated/awe00> has quit IRC09:02
*** Tartarus <Tartarus!sid72705@gateway/web/> has quit IRC09:03
*** Tartarus <Tartarus!sid72705@gateway/web/> has joined #yocto09:04
*** iamarobott <iamarobott!4d6ff777@> has joined #yocto09:09
iamarobotthello lovely people09:10
iamarobotthow do I add a waveshare display or any other display to my build configuration?09:10
iamarobotti mean the drivers because I don't have lets say gcc on my target device and I don't want to build that09:11
*** Bunio_FH <Bunio_FH!> has quit IRC09:12
*** goliath <goliath!~goliath@> has joined #yocto09:12
*** zand__ <zand__!~zandrey@> has joined #yocto09:16
*** Bunio_FH <Bunio_FH!> has joined #yocto09:17
iamarobotti know its monday but come on guys, tell me what I want to know and I'll get you the stuff xD09:20
rburtonJaMa: re harfbuzz the easy fix is to just explictly build that target first in a do_compile_prepend, but i was trying to fix the meson build properly.  of course the meson files are designed to be a clone of the autotools, instead of doing it properly for meson...09:20
*** zandrey_ <zandrey_!~zandrey@> has quit IRC09:20
*** hpsy <hpsy!~hpsy@> has joined #yocto09:25
*** iamarobott <iamarobott!4d6ff777@> has quit IRC09:45
*** submux <submux!~submux@2a01:79c:cebd:fee8:8822:9716:c5bd:c1dd> has joined #yocto09:48
*** behanw <behanw!uid110099@gateway/web/> has joined #yocto10:01
*** marble_visions_ <marble_visions_!~user@> has quit IRC10:21
*** marble_visions <marble_visions!~user@> has joined #yocto10:23
*** marble_visions <marble_visions!~user@> has joined #yocto10:24
*** micka_ <micka_!> has joined #yocto10:31
*** micka <micka!> has quit IRC10:33
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC10:44
*** mbulut_ <mbulut_!> has joined #yocto10:57
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto10:58
*** mbulut <mbulut!> has quit IRC10:58
*** fbre <fbre!91fdde45@> has joined #yocto11:06
fbreHi! A .bbappend file here has a line "include".  In is a function   do_configure_prepend() {  echo "huhu" }    but this is never called. Do you have an idea why?11:12
fbreAnyway I can't find such echo entry in the log files11:13
RobertBerger@fbre don't use echo, but bbwarn "--> huhu <--"11:18
fbreRobertBerger: Do I have to cleansstate after changing from echo to bbwarn?11:21
RobertBerger@fbre cleansstate is always a good idea ;)11:22
RobertBerger@iamarobott: What stuff and how much of it if I tell you what to read ;)11:22
qschulzfbre: no need for cleansstate as Yocto will know that your do_configure changed and need to be re-run11:24
qschulzfbre: if you need to use cleansstate => badly written recipe and fixes are needed11:24
simonpe^^there should be a shellcheck for bitbake files11:25
qschulzfbre: though, cleaning sstate-cache is heavily recommended before releasing software to make sure you're not based on some broken behavior/sstate-cache11:25
fbreI wonder where I should actually see that bbwarn output, I mean, In which logfile should I see it?11:25
qschulzfbre: shake with bitbake-layers show-appends that your bbappends is found11:25
qschulzfbre: s/shake/check /me facepalms11:25
RobertBerger@fbre you should see it on the terminal as well11:26
RPRobertBerger: cleansstate is not a good idea and I wish people would stop saying it was11:27
qschulzI'm back with some devshell question again :) is there any difference between executing run.do_task scripts with and without devshell?11:29
RPqschulz: pseudo?11:31
RobertBerger@RP: Then you have to  make sure all recipes in all layers are written in way that it's not needed anymore ;) - Which is certainly not the case at the moment.11:32
*** luneff <luneff!~yury@> has joined #yocto11:33
luneffwhen I do "devtool modify linux-raspberrypi" the resulting source tree does not contain patches applied from my .bbappend. Is that ok?11:34
RPRobertBerger: people should be highlighting those broken layers then11:35
RobertBerger@RP - poky ;)11:36
RPRobertBerger: what exactly breaks in poky?11:36
qschulzluneff: no. Have you checked with bitbake-layers show-appends that Yocto can find your bbappend?11:36
luneffhaven't looked before. yes, it includes my bbappend. And when I do full image build, it's ok11:37
fbrehmm... there is not output of bbwarn for do_configure_prepend. Which logfile should contain that?11:38
RPfbre: the do_configure task log11:38
qschulzfbre: even your console should have it. check with bitbake-layers show-appends that your bbappend is found by Yocto11:38
*** micka_ <micka_!> has quit IRC11:39
RobertBerger@RP: - In this specific one it's an SSTATE server, but if you don't cleansstate you will not have kernel sources and it's not going to build11:39
fbreno such logging there11:40
RobertBerger@RP and it's from 2017! - Not a bug!11:41
fbrethough do_configure_append() does log11:41
luneff"INFO: SRC_URI contains some conditional appends/prepends - will create branches to represent these"11:41
qschulzfbre: one more time... check with bitbake-layers show-appends that your bbappend is found by Yocto11:41
*** micka <micka!> has joined #yocto11:42
RPRobertBerger: that is really a workflow problem, the tools are using files which need to be built and aren't tracked by sstate11:42
RPRobertBerger: telling everyone sstate is broken because of that usecase is insane :(11:42
RobertBerger@RP I'm not saying SSTATE is broken.11:43
RPRobertBerger: by telling everyone to always run cleansstate, you are11:44
RobertBergerI am also not saying to always run cleansstate.11:44
qschulzluneff: :/ I had weird things with SRC_URI_append_<machine> as well with devtool. Probably worth sharing something with bluelightning when he's here (or by mail), I should probably do the same11:45
RobertBergerI am saying that if things are not working as expected it might be a good idea to run it - at least for me it helps sometimes.11:45
RPRobertBerger: "(12:22:11) RobertBerger: @fbre cleansstate is always a good idea ;)"11:45 (skipped):11:45
qschulzfbre: (skipped): ***skipped*** <= !!!!!11:45
RobertBergerLet me rephrase that: "If you don't see the output of a bbwarn, you might try to run cleansstate"11:46
qschulzfbre: are you building the correct machine? are you building the correct distro? are you building the correct kernel?11:46
RPRobertBerger: I'd much rather people used the --no-setscene type options for example to avoid the corner case you linked to11:46
RobertBergerWell then this should be also documented as such somewhere plus where it should be used.11:49
RobertBergerBTW currently I have another interesting issue with DEPENDS vs. [depends] which went magically away ;)11:50
RobertBergerJust as I came up with an explanation why DEPENDS does not work for what I want it, I can't reproduce the problem.11:50
fbreRobertBerger: I did cleansstate11:51
qschulzfbre: you're not building the kernel you think you are11:52
RobertBerger@fbre you will burn in BitBake hell ;)11:53
RobertBerger@fbre is this about a raspberry-pi kernel ?11:53
fbreno, imx811:54
RobertBerger@fbre and which kernel recipe?11:55
fbrebitbake --read=../mystuff.conf core-image-minimal   calls linux-fslc_5.4.bbappend. This is for sure because I see how it comes to an echo output there.   This linux-fslc_5.4.bbappend  calls         include linux-imx/mystuff/           and also shows that testwise added echo call there.11:58
fbreBut    do_configure_prepend() {.....} is not called although it is also in mystuff.inc11:59
RobertBerger@fbre maybe someone else does a do_configure_prepend?12:01
RPRobertBerger: please help us document the crosstap case, its very rare you'd need to do anything like that12:02
RobertBerger@RP - once I understand how to get it fixed with --no-setscene I can do so. At the moment I am just hacking around and sometimes it even works ;)12:04
RPRobertBerger: "bitbake virtual/kernel -c clean; bitbake virtual/kernel --nosetscene" will force the kernel to have a full build present12:06
RPand is much much less evil that removing things from sstate which is slow and high impact12:06
RobertBerger@RP: Now you got me interested ;)12:06
fbreRobertBerger: I thought my layer overwrites the other ones. So my do_configure_prepend() should be the one which is called12:08
RobertBerger@RP: and how about SSTATE mirrors? Will it not fetch it from mirrors?12:08
*** submux <submux!~submux@2a01:79c:cebd:fee8:8822:9716:c5bd:c1dd> has left #yocto12:08
RPRobertBerger: not with --no-setscene it won't12:08
RobertBerger@RP - That's the thing I was searching for then ;)12:09
RobertBerger@fbre: If your layer has a high prio then I would say you bbappend is applied at the end after all potential other bbappends.12:12
qschulzfbre: the only "overwrites" that happens are for classes or recipes, not bbappends. Your linux-fslc is skipped so please find out why before trying to understand why your bbappend is not being applied (because well... you're building a completely different recipe so it's to be expected your bbappend does not "work")12:17
RobertBerger@RP: So to elaborate a bit more on the --no-setscene vs. cleansstate12:20
simonpe^^Does anyone have a good suggestion for a nice chroot script that does all the mounting unmounting of /proc /sys etc automagically?12:20
RobertBerger@If I would want to be sure that do_configure is executre, I would do a cleansstate followed by a do_configure (before knowing the new trick)12:22
RobertBerger@RP But now I would do that: bitbake linux-yocto-custom-up -c clean && bitbake linux-yocto-custom-up -c do_configure --no-setscene12:25
*** zand__ <zand__!~zandrey@> has quit IRC12:25
*** zandrey <zandrey!~zandrey@> has joined #yocto12:26
fbre(facepalm)  I think it uses meta-freescale/recipes-kernel/linux/   but I have a file my-layer/recipes-kernel/linux/linux-fslc_5.4.bbappend12:27
zandreyfbre: " (skipped):" <- this means your PREFERRED_PROVIDER_virtual/kernel is not set to point to that kernel12:27
RobertBergeruse 5.4.%.bbappend12:27
zandreyfbre: correct! :D you just found the answer while i was typing it12:27
fbreI thought bitbake uses meta-freescale/recipes-kernel/linux/linux-fslc_5.4.bb12:28
fbreI wasn't aware there are multiple kernel .bb files, and is default12:29
RPRobertBerger: configure isn't a setscene task so " bitbake linux-yocto-custom-up -c clean && bitbake linux-yocto-custom-up -c do_configure" is enough12:29
zandreyfbre: please inspect
RPRobertBerger: I'd just do bitbake linux-yocto-custom-up -c do_configure -f personally12:29
*** rcoote <rcoote!> has quit IRC12:30
zandreylinux-fslc in a more-or-less "vanilla" kernel, while linux-fslc-imx is an NXP+latest stable patchlevel12:30
RobertBerger@RP OK, but the other one would work as well and not kill my sstate - just for my understanding12:31
zandreyRP: would bitbake linux-yocto-custom-up -C configure work in this case as well? Capital C should invalidate the configure sstate in this case12:31
fbreBut somehow it uses here, not  but I don't know why12:31
fbreand either (don't know why)12:32
RobertBerger@zandrey: I guess as well, but not sure if the same tasks will be executed. It invalidates the SSTATE12:32
RPRobertBerger: yes, just trying to be really clear :)12:32
RPzandrey: yes, -C is basically adding a -f12:33
*** radsquirrel <radsquirrel!> has quit IRC12:33
zandreyfbre: as you can see here [] mx8 machines uses linux-fslc-imx by default12:33
RP-f will cause sstate to be skipped as the hash is now invalid12:33
fbrezandrey: But it don't use the one with -fscl-12:35
fbrezandrey: linux-imx instead12:35
zandreyfbre: just again for clarity. "linux-fslc" is a vanilla stable kernel from with few cherry-picks from upstream. "linux-imx" is a *default* kernel from NXP, which is also found in their BSP release. "linux-fslc-imx" is a merge of *default* NXP kernel with latest 5.4.y patchlevel from stable branch of kernel.org12:36
qschulzfbre: PREFERRED_PROVIDER_virtual/kernel = "linux-fslc-imx" in your machine conf if it's the one you really want12:37
zandreyqschulz: my point exactly! ;)12:37
qschulzzandrey: didn't say otherwise :)12:39
zandreyfbre: basically, linux-fslc-imx has all features that NXP provided at the time or release + latest stable versions (current in 5.4.63, current in recipe: 5.4.62) so you get all critical fixes.12:40
*** radsquirrel <radsquirrel!> has joined #yocto12:41
zandrey5.4.63 is now under PR in and once merged - would be updated in recipe12:41
fbreAh, I think I found the reason because I copied a few .conf and .inc files from the old NXP-sumo stuff to our own meta layer.  And there is a file with PREFERRED_PROVIDER_virtual/kernel_imx = "linux-imx"12:44
fbreThis is the reason why my bitbake uses meta-freescale/recipes-kernel/linux/ in the end12:45
fbreToday I've learned there are many kernels and PREFERRED_PROVIDER sets the kernel to use :-)12:47
fbreI mean PREFERRED_PROVIDER_virtual/kernel12:48
*** rcoote <rcoote!> has joined #yocto12:48
qschulzfbre: indeed :)12:50
fbreI can't remember why I downloaded the RT patch for 5.4.61, but anyway now that my .bbappend file is really called, I get the error it cannot apply patch-5.4.61-rt37.patch  to my kernel.12:57
fbreI suppose uses 5.4.61 but uses 5.4.3, right?12:58
fbreI reckon I have to set my PREFERRED_PROVIDER_virtual/kernel  to linux-fslc-imx  to use 5.4.6112:59
*** rcoote <rcoote!> has quit IRC13:03
zandreyfbre: if you remove all the NXP files from you layer, then the only thing that would be left for you to do is to switch the kernel version and SRCREV in your append to point to 5.4.61 version. you have to do this since the latest RT patch available for 5.4y kernel is indeed 5.4.6113:09
zandreyset SRCREV="8afe26f2c98897b494e641cfc9b20e84389c92b4" and LINUX_VERSION="5.4.61", then go ahead with RT patch - it applies clean13:10
fbrezandrey: thanx! I'll try that13:11
zandreyfbre: bare in mind - this combination is *not* tested, neither by me nor by RT-team. if there is a problem with any of NXP drivers - then you would have to deal with it. :)13:12
fbreWhich combination is tested?13:13
zandreymay i ask you what is the reason to apply RT-patch? do you require determinism?13:13
*** rcoote <rcoote!> has joined #yocto13:13
fbrezandrey: yes, determinism13:14
zandreyRT is not validated at all, i don't think that NXP ever performed any validation here.13:14
fbrewe need very small latency with gpio stuff. The RT patch should help a bit to improve that13:15
*** bzb <bzb!> has joined #yocto13:16
qschulzfbre: you13:17
fbreit's just an example of small latency. Actually we don't need big latency at all (between kernel and user space)13:17
qschulz're probably not using gpio interfaces correctly?13:17
qschulzfbre: there's been a lot of testing done with gpios, try to look up a bit out to read/write to gpios, it's a common topic13:17
zandreyfbre: why not use M-cluster for this? or you really need this in Linux? just a suggestion from my side. see - the RT requires a very precise implementation not only in kernel, but in driver's code. if this is not properly done in those parts that NXP implemented - you might end up with the latencies much higher that those you have wiith normal preemption.13:17
zandreybut you would eventually see it, and probably would tell us here ;)13:18
zandreyi dealt with RT kernels before, but used it only in a very special case where a latency jitter was in microsec range13:20
fbrelinux-fslc-qoriq PROVIDES virtual/kernel but was skipped: incompatible with machine imx8mmevk (not in COMPATIBLE_MACHINE)13:21
zandreyfbre: correct. that one is for Layerscape family13:21
fbreall such errors and in the end: ERROR: Required build target 'core-image-minimal' has no buildable providers.13:22
fbreThe assignment is this: PREFERRED_PROVIDER_virtual/kernel_imx = "linux-fscl-imx"13:23
fbrePREFERRED_PROVIDER_virtual/kernel_imx = "linux-imx"   does not lead to an error but don't use 5.4.6113:25
fbrenot that easy to switch to linux-fscl-imx :-)13:26
*** hch <hch!~hch@unaffiliated/hch> has joined #yocto13:26
fbreHmmmm.... I see there is an RT patch also for 5.4.3. So I could stick to "linux-imx" (instead of "linux-fscl-imx") and use that RT patch13:28
*** crazyfermions <crazyfermions!50ff069b@> has joined #yocto13:29
zandreyfbre: mind the typo ->  "linux-fscl-imx" should be  "linux-fslc-imx". fslc stands for "FreeScaLe Community" :)13:37
fbrehehehe thought fscl is FreeSCaLe :-)13:38
zandreyfbre: nope. ;)13:38
crazyfermionsHi! I am trying to compile linux-yocto-rt (4.14) from yocto on yocto-2.6.4 (migrated from a working 2.6.3) and I am unable to compile the kernel because of an issue, "'struct irq_affinity_notify' has no member named 'work'; did you mean 'swork'?" with this particular code:13:38
crazyfermions -- in preempt-rt context, the field oldnotify->work is not defined, instead there is a new field named swork. That is why there are #ifdefs all over the place to cope with that (for13:38
crazyfermionsexample in line 352). Does someone have experience with that? It feels kind of unrealistic that this is a bug in upstream because it simply fails to compile and it should have been noticed.13:38
zandreylet me guess - no kernel provider found?13:38
zandreyfbre: if you do not modify PREFERRED_PROVIDER_virtual/kernel then you should pick up the correct kernel recipe name -> linux-fslc-imx13:41
fbre*sigh*  now I'm trying what bitbake brings with   MACHINE='imx8mmevk'   and DISTRO ?= "poky"       In other words I don't use the NXP-sumo stuff I once copied to my meta layer.13:49
fbreI hope it's 5.4.61 with that linux-fslc-imx13:50
RobertBerger@fbre this should work, I did this in my writeup13:52
fbreI have an unsecure feeling about that because that copied NXP stuff contains a lot of things I'm not sure if I need it somehow13:53
fbre... all those wayland distro stuff13:54
*** rcoote <rcoote!> has quit IRC13:54
fbretimeout for today. See you guys and thank you for your patience ;-)13:56
*** fbre <fbre!91fdde45@> has quit IRC13:57
*** rcoote <rcoote!> has joined #yocto13:59
*** rcoote <rcoote!> has quit IRC14:10
zandreyguys, what is the nick of Armin here? i've sent an email regarding last 'bind' upgrade, just wanted to check the status back with him.14:13
*** bzb <bzb!> has quit IRC14:14
qschulzzandrey: give him some time, according to the mail's metadata he's in the US, they'll soon start their day and you wrote on Friday late :)14:18
zandreyqschulz: oh sorry... :) didn't mind the time span... :D14:19
*** yann <yann!~yann@> has quit IRC14:25
*** awe004 <awe004!~awe00@unaffiliated/awe00> has joined #yocto14:25
*** awe003 <awe003!~awe00@unaffiliated/awe00> has quit IRC14:27
*** Lihis <Lihis!> has quit IRC14:30
*** crazyfermions <crazyfermions!50ff069b@> has quit IRC14:31
*** yann <yann!~yann@> has joined #yocto14:32
*** Lihis <Lihis!> has joined #yocto14:32
*** goliath <goliath!~goliath@> has quit IRC14:36
*** mbulut_ <mbulut_!> has quit IRC14:50
RPzandrey: he's armpit here14:56
RobertBerger@RP Should DEPENDS do all that or should it have stopped at do_populate_sysroot?14:57
zandreyRP: thanks! i'd go as qschulz suggested and wait a bit, as i realized that there is a span between EU and US and i've sent the report on US late Friday eve.14:58
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto14:58
RPRobertBerger: that would depend on the wider context of what you're doing14:59
RobertBerger@RP The doc says: Here, the dependency is such that the do_configure task for recipe "a" depends on the do_populate_sysroot task of recipe "b".14:59
RPRobertBerger: when recrdeps gets involved it gets more complex14:59
RobertBergerLet me give you the exact context14:59
RPRobertBerger: is recrdeps involved? It so, read the docs for that as it can also process DEPENDS15:00
RobertBergerNot that I am aware of:
RPRobertBerger: what is the command you're running to evaluate this?15:00
RobertBergerYou mean how I get my list of tasks?15:01
RobertBergerI just bitbake and that's from the log dir log.task_order15:01
* armpit and today is a US holiday15:01
*** Bunio_FH <Bunio_FH!> has quit IRC15:01
RPRobertBerger: do_compile[depends] = "firmware-imx-8m:do_deploy" is quite different from DEPENDS += "firmware-imx-8m"15:02
RobertBergerMy problem is, that DEPENDS until recently behaved as expected - stopping at do_populate_sysroot, so I used [depends] instead15:02
RobertBergerYes - this was my fix ;)15:02
RPRobertBerger: which task of  u-boot-phytec-imx are you running?15:02
RobertBergerI tried to reproduce my inital problem15:03
RobertBergerJuts bitbake u-boot-phytec-imx15:03
RPRobertBerger: simplify your probably to "bitbake u-boot-phytec-imx -c clean; bitbake u-boot-phytec-imx -c compile"15:03
RobertBergerAnd it used to break, as expected - hence I replaced DEPENDS with do_compile[depends]15:03
RPsimplify your problem to15:03
RPwell, clean firmware-imx-8m too15:04
RPDEPENDS += "firmware-imx-8m" may or may not trigger a do_deploy by the time do_compile of uboot runs15:04
zandreyarmpit: "Labor Day" :) as the name suggests - it should actually be a working day! :D15:04
RPin fact the DEPENDS may not run do_deploy at all15:05
RobertBergerYes this is what I am trying to reproduce15:05
RobertBergerbut it can't ;)15:05
RPRobertBerger: the best way to reproduce is as I mention, be explicit about the tasks you're running15:06
RobertBergerIt works15:06
RobertBergerAlso like this:
RobertBergerAnd I even understand why, since I would need to clean up the the other recipes output.15:07
RPRobertBerger: right, clean the other recipe too, first15:07
RobertBerger"bitbake firmware-imx-8m -c clean; bitbake u-boot-phytec-imx -c clean; bitbake u-boot-phytec-imx -c compile"15:09
RobertBergerNow it breaks - Halleluja !15:09
* RP likes the irony of helping people break their builds15:10
armpitzandrey, its a holiday from the work that pays15:10
armpitRP, yes it is15:10
RobertBergerI was really frustrated that I made a fix for something I could not break anymore ;)15:11
RobertBergerThanks - that helps!15:11
RobertBergerLet's see if this proves that my fix is actually needed, but I think it does15:11
* armpit time to play in opensource15:12
*** beneth <beneth!> has left #yocto15:13
zandreyarmpit: we have similar thing here across the Pond, just a bit earlier. :)15:14
RobertBerger@RP: ".. but RP helped me to successfully break it" will be soon on a new blog post ;)15:14
RPCan anyone remember why we get tracebacks on some distros (e.g. ubuntu1804) with zeus in oe-selftest but not in others (e.g. centos8)15:22
*** luneff <luneff!~yury@> has quit IRC15:24
*** j241 <j241!> has joined #yocto15:24
*** goliath <goliath!> has joined #yocto15:26
*** chris_ber <chris_ber!~quassel@> has quit IRC15:30
armpitRP, the system I used to do zeus work was ubuntu1804 and dont recall such an issue.  do you what test?15:31
*** feddischson <feddischson!> has quit IRC15:31
RParmpit: its that worries me15:37
RParmpit: found a few zeus bugs I'm sorting a series for (in an effort to get the stable builds working with the new toolchains)15:37
RPJPEW: I'm wondering if the signing patch I just sent out could explain the gpg issue we saw?15:39
*** beneth <beneth!> has joined #yocto15:41
armpitRP, there are a few additional patches for zeus. I can quere those up and look @ the build issues at the same time if that helps15:45
RParmpit: the one which puzzles me/worries me is why centos8 isn't showing oe-selftest errors15:46
RParmpit: see zeus-next for the things I'm wondering about (to be build with contrib/rpurdie/zeus for autobuilder-helper)15:46
armpitthe error log says the system is CentOS815:49
RParmpit: right, maybe the buildtools tarball being used there is problematic?15:50
*** frsc <frsc!> has quit IRC15:51
armpitIIRC that series gave me issues but since the branch built w/o without them, i put it on the back burner15:56
armpitmaybe the new uniative 2.915:57
armpitdunfell does not have the 2.915:58
RParmpit: series is massively revised now15:59
RParmpit: made a note to tell sakoman about 2.916:00
armpitI can send a patch for dunfell16:01
armpitthat should do the trick16:02
RParmpit: I put something in dunfell-next to remind me16:02
RParmpit: I doubt 2.9 is affecting the autobuilder yet though16:02
*** fl0v0 <fl0v0!> has quit IRC16:08
armpitpatch send as a reminder16:12
*** sakoman <sakoman!> has joined #yocto16:12
*** j241 <j241!> has quit IRC16:14
*** j241 <j241!> has joined #yocto16:14
RParmpit: thanks. I've sent email out on what I think we need to do with stable series builds/patches16:14
zandreyarmpit: saw the reply, thanks a lot! i'd strip the current setup i have to get something really simple and would report back.16:14
armpitRP, do you mean the perf build failures too on zeus?16:14
armpitzandrey, ok. thanks16:15
RParmpit: didn't even see that :(16:16
RParmpit: that doesn't look good :(16:16
*** jmiehe <jmiehe!> has quit IRC16:17
armpitI see autobuild-helper is missing using the new buildtools16:19
RParmpit: in which branch?16:20
armpitmissing from zeus16:20
armpitmaster has this16:20
RParmpit: its in contrib/rpurdie/zeus though16:20
*** yann <yann!~yann@> has quit IRC16:20
RParmpit: to be clear, there are fixes for the gpg and reproducibility failures in zeus-next. What isn't there is why there isn't a proper error on centos8 and that perf build issue is also a worry16:21
RParmpit: I'm testing with contrib/rpurdie/zeus as per the email I've sent16:21
armpitRP, i just found your email16:24
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:25
JaMaRP: the last 6 e-mails in openembedded-commits aren't really from you, right? :)
RPJaMa: no16:26
*** awe004 <awe004!~awe00@unaffiliated/awe00> has quit IRC16:29
*** awe004 <awe004!~awe00@unaffiliated/awe00> has joined #yocto16:31
armpitRP, is there anything at this point I can help with since you have the train on its way?16:32
sakomanI'm attempting to send out a patch series for reviewa nd one of khem's patches ( is causing a problem with send-pull-request:16:34
sakomanfatal: pull-28962/0004-json-c-Fix-CVE-2020-12762.patch: 253: patch contains a line longer than 998 characters16:34
sakomanHas anyone encountered this issue before and if so how did you handle it?16:35
armpitJaMa, except for the ones saying he is " Prince needing some money" ; )16:35
armpitsakoman, the fix in master is missing the "test" changes which I suspect are the issue.16:41
armpitif Khem is the author of the Dunfell patch, maybe he worked around it some how16:42
JaMaI have seen this few times, but usually it was in commit message (like build command being too long) so it was easy to wrap on more reasonable line lenght16:45
sakomanarmpit: the way he worked around it was to bypass email when sending me the patch :-)16:46
sakomanJaMa: in this case it is one of the lines in a patch that originates from upstream json-c16:47
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC16:47
*** zandrey <zandrey!~zandrey@> has quit IRC16:48
sakomanThe patch is already in git and tested, so the issue is just sending out for review via email.  I supposed I could truncate that line and insert a <snip> since I suspect no one will actually review that long line of data!16:49
sakomanAny other ideas?16:49
RPsakoman: I'd probably just truncate as described and mention in the series log16:50
armpityep.. that is the reasonable way to go16:52
*** mckoan is now known as mckoan|away16:58
RParmpit: if it helps I was able to get a backtrace out the centos8 case where the connection dies17:04
armpitk, want me to poke at it?17:11
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto17:13
RParmpit: I'd love someone else to fix it, just not sure its fair to hand it off half way through debugging17:19
armpitI believe the "test_testimage_virgl_gtk" is a known issue we intend on not fixing. we should disable that17:31
RParmpit: yes17:45
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:dda9:6d30:abe4:4c17> has joined #yocto17:47
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC17:56
RParmpit: its easy to reproduce. Just add self.assertTrue(False) into a test and then do oe-selftest -r <testname> -j 117:57
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto17:59
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/> has quit IRC17:59
*** ruru4143 <ruru4143!> has quit IRC18:06
RParmpit: I'm going to guess
RParmpit: confirmed that fixes it18:10
* RP is happier now18:11
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:27
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto20:03
*** awe004 <awe004!~awe00@unaffiliated/awe00> has quit IRC20:07
*** j241 <j241!> has quit IRC20:07
*** j241 <j241!> has joined #yocto20:09
*** simonpe^^ <simonpe^^!> has quit IRC20:11
*** zandrey <zandrey!> has joined #yocto20:28
*** elGamal <elGamal!~elg@> has quit IRC20:30
*** elGamal <elGamal!~elg@> has joined #yocto20:31
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC20:40
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto20:41
*** hpsy <hpsy!~hpsy@> has quit IRC20:59
*** hpsy <hpsy!~hpsy@> has joined #yocto20:59
*** mattsm <mattsm!> has quit IRC21:03
*** mattsm <mattsm!> has joined #yocto21:03
*** pohly <pohly!> has quit IRC21:07
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC21:34
RParmpit: I reran zeus-next and it shows two signing failures in selftest. Help appreciated with those. Not sure if I screwed up the builddir patch or what has happened there :(21:49
RParmpit: looks like it breaks on master too. Maybe I get to keep the pieces22:05
*** j241 <j241!> has quit IRC22:06
*** j241 <j241!> has joined #yocto22:07
*** beneth <beneth!> has left #yocto22:17
*** agust <agust!> has quit IRC22:42
*** thaytan <thaytan!> has quit IRC22:44
*** elGamal <elGamal!~elg@> has quit IRC23:16
*** elGamal <elGamal!~elg@> has joined #yocto23:18
*** shoragan <shoragan!~shoragan@debian/developer/shoragan> has quit IRC23:36
*** OnkelUlla <OnkelUlla!> has quit IRC23:36
*** shoragan <shoragan!~shoragan@debian/developer/shoragan> has joined #yocto23:46
*** OnkelUlla <OnkelUlla!> has joined #yocto23:47
*** shoragan <shoragan!~shoragan@debian/developer/shoragan> has quit IRC23:52
*** j2411 <j2411!> has joined #yocto23:53
*** shoragan <shoragan!~shoragan@debian/developer/shoragan> has joined #yocto23:53
*** D`K_C <D`K_C!> has joined #yocto23:53
*** j241 <j241!> has quit IRC23:54
*** dkc <dkc!> has quit IRC23:54
*** sstabellini <sstabellini!sstabellin@gateway/shell/xshellz/x-ztcavbaaemlmsyca> has quit IRC23:57

Generated by 2.17.2 by Marius Gedminas - find it at!