Thursday, 2020-09-03

*** vineela <vineela!vtummala@nat/intel/x-gzbfpddbvmaoignc> has quit IRC00:05
*** vineela <vineela!~vtummala@> has joined #yocto00:06
*** vineela <vineela!~vtummala@> has quit IRC00:06
*** awe00__ <awe00__!~awe00@unaffiliated/awe00> has quit IRC00:12
*** dev1990 <dev1990!> has quit IRC00:51
*** JaMa <JaMa!> has quit IRC00:52
*** vineela <vineela!~vtummala@> has joined #yocto00:55
*** khem <khem!~khem@unaffiliated/khem> has quit IRC02:06
*** hpsy <hpsy!~hpsy@> has quit IRC02:06
*** camus1 <camus1!~Instantbi@> has joined #yocto02:07
*** hpsy <hpsy!~hpsy@> has joined #yocto02:07
*** kaspter <kaspter!~Instantbi@> has quit IRC02:07
*** camus1 is now known as kaspter02:07
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto02:14
*** khem <khem!~khem@unaffiliated/khem> has quit IRC02:16
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto02:16
*** sakoman <sakoman!> has quit IRC03:24
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto04:31
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC04:36
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC04:39
*** jonmason <jonmason!sid36602@gateway/web/> has quit IRC04:39
*** jonmason <jonmason!sid36602@gateway/web/> has joined #yocto04:39
*** bradfa <bradfa!sid297668@gateway/web/> has quit IRC04:40
*** bradfa <bradfa!sid297668@gateway/web/> has joined #yocto04:41
*** itseris <itseris!~itseris@> has quit IRC04:46
*** itseris <itseris!~itseris@> has joined #yocto04:47
*** ThomasD13 <ThomasD13!> has joined #yocto04:53
*** feddischson <feddischson!> has joined #yocto05:02
*** AndersD <AndersD!> has joined #yocto05:46
*** vineela <vineela!~vtummala@> has quit IRC05:46
*** pohly <pohly!> has joined #yocto05:55
*** zandrey <zandrey!> has quit IRC05:59
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto06:00
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto06:08
LetoThe2ndhappy coffee ingestion time, fellow yoctizens06:08
ThomasD13I hope it tastes good!06:09
*** rcoote <rcoote!> has joined #yocto06:16
*** frsc <frsc!> has joined #yocto06:16
LetoThe2ndkhem: get out of my timezone, summer is over!!!!06:16
*** simonpe^^ <simonpe^^!> has joined #yocto06:17
simonpe^^I'm trying to add kernel configuration fragments to NXP:s own kernel (kernel-imx). They don't inherit from the yocto-kernel.bbclass and have their own mechanism where you have to add the fragment filenames to a DELTA_KERNEL_DEFCONFIG variable. I don't expect you guys to help me with NXP stuff but what I would appreciate very much is to try to troubleshoot why after the preconfigure stage the ${B}/.config06:19
simonpe^^file is correct (it has my fragments) but before the configure stage my fragments aren't visible in the file anymore06:19
simonpe^^I even tried to do_preconfigure_append() chmod ugo-r ${B}/.config; } to get an error whenever it changes after but somewhere it is made writable again somehow so an I/O error is  never triggered06:20
simonpe^^I've spent a full dag on this NXP crap now, its driving me nuts06:21
LetoThe2ndsimonpe^^: set the nxp config mechanism on fire, and nail the kernel down with a defconfig you can control. my$.0206:22
simonpe^^Is it known that NXP's attempt at this sucks?06:22
LetoThe2ndif you ask me, all attempts at this suck.06:23
LetoThe2ndplus, nxp has been known to have some peculiar approaches06:23
simonpe^^okay so to nail down the defconfig I would just follow the yocto manual or is it another NXP stunt that I have to perform?06:23
simonpe^^I was actually thinking about ditching the NXP stuff and try out a vanilla build but I'm not sure my project manager will allow that kind of risk06:24
LetoThe2ndyou have their kernel sources, you can almost directly pour them into a linux-yocto-custom recipe. theres an excellent blueprint in poky, and you can extract the starting point from /proc.config.gz06:24
LetoThe2ndyou don't have to ditch their sources, that would be counter productive.06:25
simonpe^^Okay man, this makes me happy! Thanks for the help06:25
LetoThe2ndhace fun. that would at least be my approach.06:26
*** mckoan|away is now known as mckoan06:30
mckoangood morning06:32
*** fl0v0 <fl0v0!> has joined #yocto06:33
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has joined #yocto06:40
mcfriskone zeus to dunfell update done, at least two to go06:41
*** wooosaiiii <wooosaiiii!> has quit IRC06:42
* LetoThe2nd sings "one down, one to go, just another bullet in the chamber..." (alice cooper, love's a loaded gun)06:43
mcfriskLetoThe2nd: hahaha06:43
mckoanLetoThe2nd: LOL06:43
mckoanLetoThe2nd: nice to find you in a good mood today :-D06:44
*** seebs <seebs!~seebs@> has quit IRC06:44
PaowZisn't it usually the case ?06:44
mcfrisknote that when we do yocto updates, we don't update the BSP layers. only critical build failures get fixed there. BSP, kernel etc updates are done separately. works only when BSP layers have been limited to bare essentials and everything else BBMASK'ed away.06:45
* mcfrisk digs into kernel updates, this never ends...06:46
LetoThe2ndin case you want to join in06:46
LetoThe2ndmckoan: hehe06:46
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto06:48
mcfriskLetoThe2nd: hahaha, "red lights, stop and go" how fitting to the Jenkins validation builds! "what's ya gonna do when you play with danger" how fitting to the temptation of force push to master...06:49
LetoThe2ndmcfrisk: i know06:50
LetoThe2ndi keep telling folks that there is so much wisdom in hard rock i nheavy metal, but alas, nobody ever listens06:50
LetoThe2nd*hard rock and heavy metal06:50
*** seebs <seebs!~seebs@> has joined #yocto06:52
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC06:53
* mcfrisk plays Ozzy and Crazy train, will not comment further...06:54
*** pbergin <pbergin!> has joined #yocto06:56
LetoThe2ndmcfrisk: recommends the Pat Boone version for additional enlightenment06:57
* mcfrisk throws over the fence and ducks:
*** hpsy <hpsy!~hpsy@> has quit IRC07:02
*** hpsy <hpsy!~hpsy@> has joined #yocto07:03
*** ilkappe <ilkappe!c65a42b1@> has joined #yocto07:05
LetoThe2ndnow i want a martini07:05
LetoThe2ndmcfrisk but given my local timzone its probably more advisable to start blasting
*** yann <yann!> has joined #yocto07:09
*** agust <agust!> has joined #yocto07:13
*** camus1 <camus1!~Instantbi@> has joined #yocto07:14
*** kaspter <kaspter!~Instantbi@> has quit IRC07:15
*** camus1 is now known as kaspter07:16
ilkappeHello guys. I'm building a customized kernel from a vender which ships a particular dirver in drivers/iio/adc. In the defconfig file used to configure the kernel there is this line to enable it as statically linked module: CONFIG_ADR=y. By the way, after the kernel was built and the target booted I couldn't find any trace of that driver, also in07:18
ilkappe/lib/modules/(uname -r)/module.builtin: So it was suggested to me to build the driver as loadable, so I changed my defconfig in line in CONFIG_ADR=m and recompiled the kernel. By the way no adr.ko file was generated and also the module is still not present in the module.builtin file. So I serached for the source file of the driver and oopened the07:18
ilkappeMakefile. this Makefile is really imple, it's something like:  SRC= <source files>; ccflags-y += -I<vaipus include paths> -DFLAGS ; obj-y =$(SRCS:.c=.o)07:18
ilkappeI can see that in the build directory of the kernel, if I list all the filed in the driver directory, I get all the .o files. So it seems to be compiled07:19
*** ryder32 <ryder32!7458c728@> has joined #yocto07:19
ilkappebut if I run $ find <kernel-build-path> -name ADR.ko no file is found07:19
*** chris_ber <chris_ber!~quassel@> has joined #yocto07:21
ykronsHi all07:25
ykronsilkappe: if I'm right if you build it with CONFIG_ADR=y, it will be builtin into the kernel and so not as a module and so no .ko. You have to built is as a module CONF_ADR=m to have a module (if the makefile support it07:26
kayterina@ilkappe: from my little experience with yocto, when I didn't see the modules in the image, it was because the custom kernel wasn't used because of another layers changing the kernel path07:29
ykronsWhen I'm building my image I have some misses in cache sstate. What is the proper way to identify which tasks are missed and what has caused that miss?07:30
ykronsilkappe: sorry ... too early for me ... I read again your question ... you can forgot my reply07:32
*** kaspter <kaspter!~Instantbi@> has quit IRC07:36
*** kaspter <kaspter!~Instantbi@> has joined #yocto07:36
ilkappe@ykronos no problem !07:39
*** dev1990 <dev1990!> has joined #yocto07:42
*** AndersD <AndersD!> has quit IRC07:50
*** qschulz <qschulz!> has quit IRC07:50
*** qschulz <qschulz!> has joined #yocto07:51
*** PaowZ__ <PaowZ__!~Vince@> has joined #yocto07:57
ilkappekayterina, the kernel is used because I can traceback the Image file to the correct recipe. Inspecting the given Makefile, it has only the entry with obj-y but no obj-m07:59
ilkappeIs this probably why no .ko file is gneerated ?08:00
*** PaowZ_ <PaowZ_!~Vince@> has quit IRC08:00
kayterinaI don't know that,sorry.08:04
kayterinajust from what I read here:
*** sstiller <sstiller!> has joined #yocto08:05
*** kpo_ <kpo_!> has quit IRC08:07
*** zandrey <zandrey!~zandrey@> has joined #yocto08:11
ykronsilkappe: I think the Makefile must have lines like obj-$(CONFIF_ADR) += .... to support CONFIG_ADR=m. Take care ccflags-m doesn't exists, so you have to do something like ccflags-y += ${ccflags-m}08:12
ryder32I built a custom installation of Poky for my DE10-Nano-SoC board and largely it works. However eth0 doesn't work - It picks up an IPV6 address and I can't ping anything. I tried setting a static ip address in /etc/network/interfaces, but it doesn't work.08:15
ryder32Here is the ifconfig output:
ryder32dmesg shows the driver and it seems fine:
ryder32Any suggestions? Pre-built images supplied by the vendor work fine :|08:15
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:17
ilkappe@ykronos, driver is in drivers/iio/adc/adr folder. In drivers/iio/ad/Makefilec there is this line: obj-$(CONFIG_ADR) *= adr/08:18
ilkappeso I expect that when this Makefile is parsed it will add the Makefile in drivers/iio/adc/adr08:18
ilkappethe drivers/iio/adc/adr/Makefile has basically 3 main entriees, the SRC:=<all source files path>, the ccflags-y += <include path and D flags>, obj-y = $(SRC:.c=.o)08:20 docs states that: $(obj-m) specifies object files which are built as loadable kernel modules.08:21
*** beneth <beneth!> has joined #yocto08:21
ilkappeso probably it's why the .ko is not generated08:22
*** sinseman44 <sinseman44!a5e14d32@> has joined #yocto08:23
ilkappealso it's not clear to me if it is ture that every =y module has an entry in /lib/modules/(uname-r)/ module.builtin08:25
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:27
cengiz_iohow can I break the following dependency? `Problem 1: package lttng-modules-2.11.2-r0.mmmm requires kernel-module-lttng-uprobes-5.4.51-fslc+g78f9980f23eb, but none of the providers can be installed`08:30
*** fbre <fbre!91fdde45@> has joined #yocto08:33
*** PaowZ__ <PaowZ__!~Vince@> has quit IRC08:38
*** PaowZ_ <PaowZ_!~Vince@> has joined #yocto08:38
*** awe00__ <awe00__!~awe00@unaffiliated/awe00> has joined #yocto08:49
*** fbre <fbre!91fdde45@> has quit IRC08:49
*** sinseman44 <sinseman44!a5e14d32@> has quit IRC08:53
*** sinseman44 <sinseman44!a5e14d32@> has joined #yocto08:59
kanavin_homeRP: seems like all ok with the version updates? I guess there's just Khem's go 1.15 update left.08:59
*** qschulz <qschulz!> has quit IRC09:01
*** qschulz <qschulz!> has joined #yocto09:04
*** kpo_ <kpo_!> has joined #yocto09:04
*** simonpe^^ <simonpe^^!> has quit IRC09:10
*** kpo_ <kpo_!> has quit IRC09:16
*** simonpe^^ <simonpe^^!> has joined #yocto09:16
*** kaspter <kaspter!~Instantbi@> has quit IRC09:24
*** kaspter <kaspter!~Instantbi@> has joined #yocto09:24
*** kpo_ <kpo_!> has joined #yocto09:26
RobertBerger@cengiz_io: you most likely need a more up to date version of lttng09:28
RobertBergermaybe something like this:
ryder32Okay I got it to work - Issue was with the device tree. Copying over the device tree from the vendor image did the trick. Now to figure out why the device tree from Yocto isn't working.09:29
RobertBerger@ilkappe still fighting against your driver?09:31
RobertBerger@ilkappe do you have it somewhere in a git repo or so which is public?09:31
*** fbre <fbre!91fdde45@> has joined #yocto09:35
*** zandrey_ <zandrey_!~zandrey@> has joined #yocto09:37
*** ryder32 <ryder32!7458c728@> has quit IRC09:38
RPkanavin_home: seemed to build fine so yes, tested and merged. There was one failure but it was bitbake server related. Not gotten to that yet :(09:39
*** zandrey <zandrey!~zandrey@> has quit IRC09:41
*** jmiehe <jmiehe!> has joined #yocto09:52
kanavin_homeRP: what is Randy McLeod's nickname here? I'd like to ask about the current situation with his rust work.09:56
kanavin_homethere has lately been serious movement towards allowing rust code in the kernel, so we should be prepared for that future09:57
dev1990interesting news
LetoThe2ndkanavin_home: vmeson10:02
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto10:03
kanavin_homevmeson: ^^^10:06
*** ilkappe <ilkappe!c65a42b1@> has quit IRC10:12
*** goliath <goliath!> has joined #yocto10:28
*** silkoman <silkoman!> has joined #yocto10:33
rburtonRP armpit: kea patches sent.  feel free to ignore the upgrade if you want.10:47
LetoThe2ndrburton: can't wait for apple to fork it into i-kea!10:49
RPrburton: thanks, M3 isn't done yet so I'll queue/test10:51
RPDoes anyone have knowledge of python's multiprocessing and deadlocks?10:51
rburtonthere's one guy i know, richard something10:51
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC10:51
qschulzRP: all I know is that in most cases, the GIL is still being used. If the GIL is not used, you need to use Manager for sharing data between threads/processes or return data from the ended thread/process and handle it in the main thread. But that's probably not helpful :/10:54
*** marquiz <marquiz!~marquiz@> has quit IRC10:56
RPrburton: I'm trying to work out what cancel_join_thread() does which deadlocks other processes using that queue :/10:59
*** hpsy <hpsy!~hpsy@> has quit IRC11:03
qschulzRP: from a very quick read from the documentation, it seems that it's more or less a kill -9 for the thread. So if it holds a lock, it won't release it?11:06
*** marquiz <marquiz!~marquiz@> has joined #yocto11:06
*** ilkappe <ilkappe!c65a42b1@> has joined #yocto11:08
ilkappeRobertBerger, yes, still fighting and no, it's not public yet.11:09
ilkappeI'm running out of options..11:09
RPqschulz: that is my worry11:10
ilkappeAt the moment I am trying to debug with bitbake multiconfig:zcu102:linux-xlnx -c kernel_configme and  bitbake multiconfig:zcu102:linux-xlnx -c compile_kernelmodules -f -v11:10
ilkappemaybe could be related to a wrong dts file ? I'vve just seen that the dtb that's using is the standard one. So now I've changed the KERNEL_DEVICETREE var to use the correct dtb file (at least the one shipped from the vendor) and recompiling11:12
ilkappeit's a long day..11:14
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto11:19
*** angery <angery!> has quit IRC11:20
*** awe00__ <awe00__!~awe00@unaffiliated/awe00> has quit IRC11:21
LetoThe2ndi think you got it wrong.11:24
*** silkoman <silkoman!> has quit IRC11:25
LetoThe2ndthe citation is "its a long way to the top (if you wanna rock n roll)"11:25
ilkappeLetoThe2nd just rolling for now.. not sure in which direction11:26
*** fbre <fbre!91fdde45@> has quit IRC11:37
*** fbre <fbre!91fdde45@> has joined #yocto11:37
*** berton <berton!~berton@> has joined #yocto11:40
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC11:42
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto11:43
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC11:44
*** eduardas <eduardas!~eduardas@> has joined #yocto11:59
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto12:08
*** emrius <emrius!> has joined #yocto12:16
*** camus1 <camus1!~Instantbi@> has joined #yocto12:17
*** kaspter <kaspter!~Instantbi@> has quit IRC12:19
*** camus1 is now known as kaspter12:19
emriusHello, I'm having an issue gathering enough entropy using `rng-tools` on my SoC. My journald was flooded with warnings similar to "entropy generation is slow" or something (I don't have the exact warning at hand right now). Thus, I replaced `rng-tools` with `haveged`. Unfortunately, there seems to be a cyclic dependency that is injecting a cyclic12:20
emriusdependency with `journald` as described in this bug report:
emriusIs that a bug that people around are aware of? Now, I'm not entirely sure what to do. Do I actually have to configure `rng-tool` differently to get rid of the entropy warning, patch `haveged` or choose a different path?12:21
emriusI'm on dunfell with that issue. The initial problem didn't hit me on warrior.12:22
emriusSo, if anyone has any thought on that I'm happy for any hint :)12:22
*** rcoote <rcoote!> has quit IRC12:35
*** camus1 <camus1!~Instantbi@> has joined #yocto12:41
*** kaspter <kaspter!~Instantbi@> has quit IRC12:42
*** camus1 is now known as kaspter12:42
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/> has quit IRC12:45
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto12:47
*** maudat <maudat!> has joined #yocto12:49
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC12:58
*** rcoote <rcoote!> has joined #yocto13:00
RPemrius: there are probably some kernel and tools options you can change and let some of the "lower quality" entropy data be used as well, at the obvious risk of lowering the quality13:01
RPemrius: my personal view is they did seem to get a bit paranoid about "quality"13:01
emrius@RP Ah that is a good hint in fact. I'll do some research there13:01
emriusRP =D  good to know as a background.13:02
*** rcoote <rcoote!> has quit IRC13:07
*** newb_dev <newb_dev!bb14930d@> has joined #yocto13:09
*** camus1 <camus1!~Instantbi@> has joined #yocto13:10
rburtonemrius: if you're lucky, your SoC has a hardware RNG that you can enable13:11
rburtondig out the reference and see if there's one you can use13:11
rburtonmany boards have one but the kernel driver doesn't know to use it for entropy13:11
*** kaspter <kaspter!~Instantbi@> has quit IRC13:11
*** camus1 is now known as kaspter13:11
emriusrburton Ok, I;ll have a look right away. Thanks!! Oh that is also a great hint!13:12
rburton is useful background13:14
emriusLooks promising!13:15
*** sstiller <sstiller!> has quit IRC13:17
*** jkridner|pd <jkridner|pd!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto13:18
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC13:20
*** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/> has quit IRC13:27
*** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/> has joined #yocto13:28
emriusWhile doing further research I updated `haveged` to the latest version (1.9.9->1.9.13) in my oe clone. `bitbake`d and deployed and sat that the cyclic dependency with journald  and haveged did not occur anymore. Should I file a patch for oe for the dunfell branch?13:31
*** kaspter <kaspter!~Instantbi@> has quit IRC13:31
emriusOr would that be rather put into the upcoming oe release?13:32
*** kaspter <kaspter!~Instantbi@> has joined #yocto13:32
*** sakoman <sakoman!> has joined #yocto13:37
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has quit IRC13:37
*** grembeter <grembeter!c108287e@> has joined #yocto13:38
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has joined #yocto13:39
zandrey_question to audience: i'm currently seeing that for recipes which inherit allarch there are -dev, -dbg and -src are generated. they come out empty, but the question is rather general one: is there a reason why those complimentary packages are generated for allarch?13:43
zandrey_i cannot think of a scenario where those would come handy, since everything allarch - is platform-neutral and therefore would be hard to debug.13:44
*** fitzsim <fitzsim!> has joined #yocto13:50
RobertBergerTo add to what zendrey says: It looks like as soon as you enable IMAGE_FEATURE = "-dev" the -dev packages for all allarch in all layers are being built even if NOT explicitly included in an image recipe or so.13:52
RobertBergerThis somehow destroys they way I thought bitbake works. You don't include a recipe anywhere and bitbake want to build it because of a FEATURE?  ????13:53
RPRobertBerger: there isn't anything in bitbake that forces that13:53
*** awe00_ <awe00_!~awe00@unaffiliated/awe00> has joined #yocto13:54
RobertBerger@RP You mean it's a bug and not a feature?13:54
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC13:56
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/> has joined #yocto13:58
*** ThomasD13 <ThomasD13!> has quit IRC14:00
zandrey_RP: i believe it is not in bitbake, but rather package_depchains() in package.bbclass that automatically creates -dev and -dbg for all.14:05
RobertBergerSo RP is off the hook and who is on the hook?14:05
zandrey_what my original question is: does it make sense to have those packages for allarch?14:06
zandrey_what i saw in some (not all) allarch recipes is that they do set PACKAGES = "${PN}" which effectively flushes out the -dev and -dbg14:07
grembeterI think it controls by PACKAGEGROUP_DISABLE_COMPLEMENTARY14:07
zandrey_i'm just wondering if this is rather a "workaround" or should this behavior be added for all allarch recipes?14:07
*** thecomet <thecomet!> has quit IRC14:09
grembeterah, for packagegroup only, sorry for the noise : )14:13
zandrey_grembeter: PACKAGEGROUP_DISABLE_COMPLEMENTARY is used in packagegroup.bbclass and controls -dev and -dbg for package groups14:13
*** ollie123 <ollie123!d445ba28@> has joined #yocto14:14
ollie123hi. I am trying to code a small utility that uses alsa functions to access a device. However, I am having trouble getting the recipe correct to include the alsa libraries. Does anyone have an example of a correct recipe that links against alsa?14:15
armpitrburton, thanks for sending14:17
*** emrius <emrius!> has quit IRC14:18
mcfriskdoes anyone know URL to meta-imx git tree? can't find it with google14:21
*** diego_r <diego_r!> has quit IRC14:22
RPrburton: and all the other world builds are failing :(14:23
RPkhem: go upgrade fails on musl:
rburtonRP: argh14:24
rburtonkea's crazy library handling no doubt14:25
rburtonok will do a ML build14:25
RPrburton: also failed in no-x1114:26
RPrburton: and musl14:26
*** Konsgnx <Konsgnx!> has joined #yocto14:26
RPrburton: I've emailed14:26
armpitrburton, quick open a bug and get it assigned to the maintainer14:26
armpitYPBT: armpit is on14:27
armpitmcfrisk, isn't imx TI ? if so see meta-ti14:28
sgwMorning all, YPBT: sgw is on14:30
*** JaMa <JaMa!> has joined #yocto14:30
*** shan1 <shan1!> has joined #yocto14:37
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has quit IRC14:41
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has joined #yocto14:43
qschulzarmpit: it's NXP/Freescale14:45
ollie123can anyone help with creating a recipe to build against alsa such that I can call alsa functions?14:45
*** awe00_ <awe00_!~awe00@unaffiliated/awe00> has quit IRC14:46
rburtonollie123: DEPENDS=alsa-lib14:47
ollie123already have that. and include <alsa/asoundlib.h> in my C file14:47
ollie123still getting undefined references for functions such as "snd_mixer_open", or any really14:48
*** awe00_ <awe00_!~awe00@unaffiliated/awe00> has joined #yocto14:48
qschulzollie123: check you have this file in $WORKDIR/recipe-sysroot14:48
qschulzthen check the path to where it is is included when compiling14:48
rburtonollie123: you're probably not linking right14:48
rburtonhand written makefile or something proper like autotools/meson/etc14:49
qschulzprobably CFLAGS/LDFLAGS whatever that is incorrectly set (or not taken from Yocto)14:49
ollie123unfortunately no alsa files are being pulled into the work dir14:49
qschulzollie123: then your DEPENDS is wrong14:49
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has quit IRC14:49
qschulzollie123: bitbake myrecipe -e | grep -e "^DEPENDS=", what's in that?14:49
ollie123exactly how you have written it14:50
qschulzbitbake -e and then we debug from there14:50
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has joined #yocto14:50
ollie123thank you for your help14:50
qschulzollie123: no worries, I suspect DEPENDS is overridden some time later, so please run bitbake -e and check if alsa-lib is in there14:51
ollie123i do see it in the DEPENDS list in the -e output14:52
ollie123DEPENDS=" virtual/arm-poky-linux-gnueabi-gcc virtual/arm-poky-linux-gnueabi-compilerlibs virtual/libc  alsa-lib"14:52
qschulzollie123: ok, that's one thing out of the list of things that could have gone wrong14:53
qschulzollie123: go into WORKDIR/recipe-sysroot (take WORKDIR from bitbake my-recipe -e | grep -e "^WORKDIR=")14:53
qschulzand do a `find` for any alsa header file there14:54
ollie123did n done. nothing14:54
ollie123interestingly it doesnt complain about the asound.h header.14:54
qschulzollie123: did you run `bitbake my-recipe` alone :D?14:55
ollie123also no "recipe-sysroot" folder in the workdir14:55
ollie123? what else would i run14:55
qschulzollie123: people have imagination :)14:56
rburtonyou're looking in the wrong place if there's no recipe-sysroot14:56
*** shan1 <shan1!> has quit IRC14:56
ollie123not sure what to tell you. my binary is generated successfully in this workdir (with the alsa calls removed of course)14:56
ollie123this is where it is14:56
rburtonbut isn't asound.h part of the kernel headers and not alsa-lib?14:57
rburtonwhy is there no /usr/ in there14:58
ollie123the build process is able to find the asoundlib.h file, and when i purposefully mess the name up (asoundllllib.h) I of course get errors15:00
ollie123so that is working15:00
ollie123but i cannot compile against the libraries for some reason to use the functions15:00
rburtoncompile or link failure15:00
rburtonif you're using a hand-written makefile, you're probably missing a bit because its hard to write a proper one15:00
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC15:00
*** grma <grma!~gruberm@> has quit IRC15:01
*** berton <berton!~berton@> has quit IRC15:01
ollie123I haven't even written a makefile as this utility is literally just a single file. I included a "do_compile" section in my recipe for it15:01
rburtonthen your compile call is probably missing something15:02
rburtonwhat did you put?15:02
ollie123quite literally just15:03
*** otavio <otavio!~otavio@> has joined #yocto15:03
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto15:03
*** fbre <fbre!91fdde45@> has quit IRC15:03
ollie123${CC} program.c program15:03
rburtonYou forgot to link to the library15:03
ollie123adding -lasound did the trick15:05
ollie123sorry that was silly15:05
ollie123thank you for walking me through it15:05
rburtonRP: kea breaks locally, not sure how it worked last night as I distinctly remember sitting around waiting for the build to finish15:07
*** feddischson <feddischson!> has quit IRC15:10
*** eduardas <eduardas!~eduardas@> has quit IRC15:12
*** feddischson <feddischson!> has joined #yocto15:13
armpitrburton, you went to bed IIRC15:17
rburtonI definitely sat waiting for compile to finish as my wife was glaring at me reminding me of the time15:17
*** feddischson <feddischson!> has quit IRC15:18
JaMaRP: would it make sense for bitbake -g to show all tasks of given target? I was strugling to find where lib32-python got a dependency on python when it wasn't shown in at all, see
*** ollie123 <ollie123!d445ba28@> has quit IRC15:19
JaMamoto-timo: ^ please check 2 pending patches for meta-python215:20
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has quit IRC15:23
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has joined #yocto15:25
*** grembeter <grembeter!c108287e@> has quit IRC15:25
*** fl0v0 <fl0v0!> has quit IRC15:32
rburtonRP: fired a quick to test just the kea patches, should be over soon15:41
*** sinseman44 <sinseman44!a5e14d32@> has quit IRC15:43
armpitELCe schedule is out15:45
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC15:46
*** maudat <maudat!> has quit IRC15:50
*** maudat <maudat!~moda@> has joined #yocto15:51
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has quit IRC16:12
*** wmills <wmills!~bill@2601:144:4100:fd1:12bf:48ff:fed7:9537> has quit IRC16:13
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has joined #yocto16:14
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has quit IRC16:18
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has joined #yocto16:20
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC16:24
*** otavio <otavio!~otavio@> has joined #yocto16:25
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto16:25
*** RobertBerger <RobertBerger!~rber@> has quit IRC16:26
*** chris_ber <chris_ber!~quassel@> has quit IRC16:28
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/> has quit IRC16:28
*** RobertBerger <RobertBerger!> has joined #yocto16:30
*** grma <grma!~gruberm@> has joined #yocto16:33
*** zandrey_ <zandrey_!~zandrey@> has quit IRC16:35
*** rcw <rcw!~rcw@> has joined #yocto16:38
*** jmiehe <jmiehe!> has quit IRC16:39
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto16:43
*** frsc <frsc!> has quit IRC16:47
zeddiiarmpit: stupid question. with dhcpd replacing dhclient, what actually produces a dhclient binary ? I haven't looked into the package at all, but thought I'd fire out the question as I dig around.16:56
*** vineela <vineela!~vtummala@> has joined #yocto17:01
*** bsmerbeck <bsmerbeck!> has joined #yocto17:03
bsmerbeckhey guys, hoping this is an easy solve. Trying to write a recipe to use useradd and I'm getting the following error "useradd: Warning: missing or non-executable shell '/bin/bash'17:04
JaMazeddii: there is only 1 binary in dhcpd dhcpcd/9.1.4-r0/image/usr/sbin/dhcpcd17:07
zeddiiI was seeing that. I have to figure out the equivalent calls, since I have a whack of dhclient calls in code .. that need to be updated.17:08
zeddiiwhether they are right or wrong calls, that's a different question :D17:08
JaMaor use udhcpc from busybox :)17:09
zeddiiheh. unfortunately all these images have a hard blacklist on busybox. Full command line tools only. So I'll have to dig into some runtime tests now.17:09
zeddiior carry my own recipe and see what security or incompatibilities I'm opening myself up to.17:10
mcfriskhas anyone ported meta-imx to dunfell yet?17:18
gsalazarHi, is there a way to encrypt a yocto image with openssl? Directly from the build?17:18
Yatekiihey folks, I am seing this: and what is very weird is that there is several directories created in the source dir, which contain python code in their names ...17:22
Yatekiithis is with trying to update to dunfell. with thud this was working just fine. none of the receipe & underlying git repo has been changed :/17:23
*** zandrey <zandrey!> has joined #yocto17:23
Yatekii this is the corresponding receipe17:23
*** mckoan is now known as mckoan|away17:23
zandreymcfrisk: check the meta-freescale layer, it does have dunfell compatibility. meta-imx is *internal* "vendor BSP" from NXP, and they have their own pace so it might be quite some time till they release it publicly17:25
qschulzYatekii: you're using git stuff with a sourc efetched via HTTP17:26
qschulzYatekii: SRC_URI = "git://;protocol=https;branch=rolling" would be better I assume?17:26
smurraymcfrisk: unless you're working directly with NXP support, meta-imx is bad news IMO, try very hard to make meta-freescale work instead17:27
mcfrisksmurray zandrey: sounds like I should not be using meta-imx then at all17:28
zandreymcfrisk: please take a note that meta-imx is maintained by NXP, so in case if you have some detailed technical issues with it - you should report it to NXP. Typical example from couple of days back was the absence of RT kernel in meta-imx. this should be addressed to NXP as meta-imx is maintained by them17:28
smurraymcfrisk: even if you think you need one of the the bits it adds on top of meta-freescale, it'd be better IMO to extract that into your own clean layer vs using meta-imx/meta-* directly17:29
zandreysorry guys, i'm lagging behind a bit :)17:29
*** anonzadas <anonzadas!> has quit IRC17:30
zandreymcfrisk: to assist you here further a bit, RobertBerger had a nice tutorial compiled which you can follow through to get your own custom BSP running with just meta-freescale:
zandreythis is what smurray meant imho17:30
smurrayzandrey: roughly, yes17:32
mcfrisksigh, sounds I need to redo the BSP setup that I got from our vendor..17:32
RobertBerger@mcfrisk: Write down in BIG letters:"Compile the BSP from the vendor once, boot it, erase it"17:33
RobertBerger@mcfrisk: If it does not even boot throw away the board as well.17:33
mcfriskyea, BBMASK 95% away... repeat for each BSP layer until you have what is really needed to boot17:34
RobertBerger@mcfrisk: If the board actually boots - try with upstream components or at least community supported ones ;)17:34
RobertBerger@mcfrisk what are you actually after? Just boot your board?17:34
RobertBerger@mcfrisk: Is it at least close to some eval board?17:34
mcfriskupdate from zeus to dunfell, no eval board anymore..17:35
mcfriskwith zeus we had sumo based BSP, now I saw the BSP update and am pulling hair..17:35
RobertBergerHehe and from from the NXP stuff I guess ;)17:35
neverpanicDidn't know we even had an NXP board.17:36
RobertBergerBeen there - thrown it away and went to meta-freescale plus my own kernel stuff.17:36
RobertBergerPeople out there make some noise to your board/chip vendors when their stuff is too old to be usable.17:37
RobertBergerThe more people are shouting the better chances we have they'll hear us!17:37
mcfriskas usual, it starts with non-optimal commit messages in review.. then snowballs into complete do-the-BSP stuff again from scratch17:37
RobertBerger@mcfrisk: "upstream, mainline,..."17:38
mcfriskyep, we have requirements.. guess what happened to them in contract details ¤#"17:38
*** anonzadas <anonzadas!> has joined #yocto17:39
*** kaspter <kaspter!~Instantbi@> has quit IRC17:44
Yatekiiqschulz: I vaguely remember having heard this already :) however changing to git instead of https results in "fatal: could not read Username for '': No such device or address" which seems odd17:44
*** kaspter <kaspter!~Instantbi@> has joined #yocto17:44
*** King_InuYasha is now known as Conan_Kudo17:45
*** Conan_Kudo is now known as King_InuYasha17:45
*** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/> has quit IRC17:49
*** mischief <mischief!> has joined #yocto17:53
mischiefhi. is there something that documents what is allowed in a recipe version?17:53
Yatekiiok qschulz I guess maybe this is because of the stupid chroot of kas ...18:00
*** goliath <goliath!> has quit IRC18:03
Yatekiiok with git credentials in the store this works18:10
Yatekiibut imo it's just utterly stupid that yocto does whatever randomly when you use https instead of git ... lol18:10
Yatekiiit's a great feat ...18:10
*** goliath <goliath!> has joined #yocto18:15
YatekiiI mean why can't it just ask for my user & pwd18:23
Yatekiiseems stupid :/18:23
*** bsmerbeck <bsmerbeck!> has quit IRC18:28
*** armpit <armpit!~armpit@2601:202:4180:a5c0:3889:a22b:6ae0:235a> has quit IRC18:46
*** Bunio_FH <Bunio_FH!> has quit IRC18:52
*** feddischson <feddischson!> has joined #yocto18:53
*** festercluck <festercluck!~stephen@unaffiliated/stephen> has joined #yocto19:03
*** festercluck <festercluck!~stephen@unaffiliated/stephen> has left #yocto19:03
*** armpit <armpit!~armpit@2601:202:4180:a5c0:3d32:4996:5740:304b> has joined #yocto19:05
khemRP: yes I can see musl/go issue thanks will look into it19:06
khemarmpit: I am seeing this error in kea ideas ?19:07
*** kaspter <kaspter!~Instantbi@> has quit IRC19:31
*** kaspter <kaspter!~Instantbi@> has joined #yocto19:31
*** vineela <vineela!~vtummala@> has quit IRC19:38
derRichardcan devtool produce me a kernel source such that i can work with it *without* yocto/bitbake? e.g. give me a patched source plus usable .config file?19:45
*** vineela <vineela!~vtummala@> has joined #yocto19:45
zandreyderRichard: depends on what you want... if your kernel is configured with -c menuconfig you can do -c savedefconfig to get defconfig back. or you do -c diffconfig to get your fragments back19:54
zandreyprovided you inherit kernel-yocto class19:55
derRichardzandrey: basically what i need (and other kernel developers around me) is a way to "extract" the kernel from yocto to a plain source tree to hack with it *without* yocto. after i'm done with hacking, i can generate diff and install them back to yocto myself. i really love yocto but sometimes to deal with kernel issues it is just a burden19:57
armpitkhem, I have seen that error before but not on kea19:57
RobertBerger@derRichard: I am a bit confused about the question. I don't think devtool will produce any kernel source for you.19:59
derRichardRobertBerger: s/produce/prepare ;)19:59
RobertBerger@derRichard: it will in best case produce a recipe for you when can compile some kernel module.19:59
armpitkhem, rburton redid the update not sure if that will change anything20:00
RobertBerger@derRichard: can you please elaborate a bit more what exactly you are after?20:00
derRichardRobertBerger: all i want i way to get a patched kernel source from a kernel recipe (plus a .config). such that i can work with that kernel sources the way i want.20:02
RobertBergerWait a bit - those are 2 different things20:02
RobertBergerSo one thing you want is a kernel config fragment I guess20:03
RobertBergerAnd the other a kernel patch20:03
zandreyderRichard: then the best would be to check
derRichardRobertBerger: no. i don't want a kernel patch. i want the patched kernel. e.g. kernel sources with all patches applied20:04
zandreyit is pretty good on detailing what you can do with kernel in and outside of Yocto20:04
RobertBergerSo you want to use the Yocto kernel tooling ;)20:04
RobertBergerWhich kernel do you currently use?20:04
*** NiksDev <NiksDev!~NiksDev@> has quit IRC20:04
derRichardRobertBerger: what kernel i use does not matter20:05
derRichardzandrey: let me check :)20:05
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto20:05
RobertBergerIt does not depend which kernel you use, but which kernel RECIPE you use ;)20:05
zandreyderRichard: section 2.9 details on how you can plug-in your own kernel source and have it built with Yocto for example20:06
RobertBergerThis doc does only work if your kernel recipe inherits the yocto kernel class.20:06
derRichardRobertBerger: of course my recipe inherits the yocto kernel class :)20:06
*** beneth <beneth!> has left #yocto20:06
RobertBergerWell that's not of course, if you use e.g. the Ti stuff it does not ;)20:06
zandreyRobertBerger: that is what I wrote above - "provided you inherit kernel-yocto class" :)20:07
RobertBergerOK I think I get it.20:07
RobertBergerSo what you basically want is to watch the presentation about this from ELCN this year.20:08
derRichardzandrey: hmm. 2.9. is the other way around. say $customer has a kernel recipe. all nice and clean. but somethimes me and other kernel developers would like to get from $customer just the kernel sources and a .config. such that we can build it our way (without any yocto tooling).20:08
derRichardso i need two thing from yocto "please fetch kernel sources, apply all patches and give it to me" and "please build the .config file and give it to me too"20:09
derRichardis this possible? :-)20:09
RobertBergerTry this:
RobertBergerAnd this:
RobertBergerAssuming you all that with Yocto this is possible.20:10
RobertBergeryou do all that20:10
derRichardcan you please tell me how? is there a "devtool export linux-recipe" tool? :)20:11
RobertBergerSee the 2 videos I posted20:11
RobertBergerNo why should it export the recipe?20:11
RobertBergerYou have the recipe, why would you export it?20:11
RobertBergerThe kernel recipe is in a meta-layer and you need this layer.20:12
derRichardRobertBerger: i want to export the *sources* and the *.config* files20:12
RobertBergerThe kernel sources?20:12
derRichardof couse20:13
derRichardas i wrote before20:13
RobertBergerThere is no Yocto tooling required20:13
derRichardtarball of what?20:13
RobertBergerThe sources + .config20:13
RobertBergerSince this is what you want20:13
derRichardi really think you are kidding me. sorry.20:13
derRichardlet me try again20:14
derRichardlet's assume i have kernel recipe. this recipe contains tons of patches and config fragments. ok so far?20:14
derRichardnow my question20:14
RobertBergerThose patches are applied and config fragments as well20:15
RobertBergerReally watch the 2 videos and do the exercises and you will understand.20:15
RobertBergerIt's not magic.20:15
derRichardis there way from yocto such that a tool can 1. fetch kernel sources 2. apply all patches and 3. build from config fragments a read to use .config and give them to me20:15
RobertBergerYou end up with patched kernel sources and a config20:15
derRichardRobertBerger: i know these videos. this not what i want20:15
RobertBergerbitbake virtual/kernel ;)20:15
derRichardRobertBerger: did you understand my question?20:16
RobertBergerYou want the patched kernel and the config to build it20:16
RobertBergerSo you want it without building the kernel first?20:17
RobertBergerOr someone else building it?20:17
derRichardno. all i want is the kernel source plus the .config. everything else i can do myself20:17
derRichardthis what i do all day. hacking the kernel20:17
RobertBergerbitbake virtual/kernel -c configure20:18
RobertBergerIf you want to stop before building it20:18
derRichardso you suggest i should copy from yocto's tmp directory?20:19
zandreyderRichard: how does your $customer stores the kernel? is it in their git repo? can you clone it yourself?20:19
RobertBergerIf you saw the videos you know where the patched sources and and .config are - yes20:19
derRichardRobertBerger: i know where they are. i though that there is maybe a tool to do this. hence my question. :)20:20
RobertBergerNot one I know of.20:20
derRichardzandrey: na. they use a tarball as base an have a non-trivial kernel recipe which contains tons of patches and config fragments20:21
derRichardRobertBerger: thanks. this is all i wanted to know.20:21
zandreyderRichard: then i guess the only way is what RobertBerger suggested... at least for such a non-trivial setup.20:22
RobertBergerAnyways this has not much to do with kernel tooling.20:23
derRichardzandrey: doing the configure step and going for the tmp folder? no big deal. just wanted to make sure i don't oversee some nice tool20:23
RobertBergerIf that's all you want ;)20:24
derRichardRobertBerger: like i said20:24
RobertBergerYou could get more fancy and e.g. use kernel fragments with Yocto and without Yocto20:24
RobertBergerSame with patches.20:24
RobertBergerBut I am not sure how to use .scc files outside of the Yocto project.20:25
derRichardjust don't ;-)20:25
RobertBergerI guess so ;)20:25
derRichardi *love* yocto but i hate its kernel dev tooling. maybe i'm biased because i work mostly on the kernel and being used to my way of doing things. :-)20:26
derRicharddevtool works super for most of my customers but not for me20:27
RobertBergerThere used to be more kernel tooling, but it was taken out. I still use it ;)20:28
derRichardwhat did the tooling do?20:29
RPJaMa: that is quite interesting20:30
RPJaMa: it explains something I've wondered about for a long time20:30
RPJaMa: the bitbake output for -g is correct, I think we could do with a specialist option/tool to do exactly what you did, disable something, build, see what the error is20:33
*** feddischson <feddischson!> has quit IRC20:36
RPderRichard: keep in mind we do take patches to extend devtool20:36
derRichardRP: so a patch to add a feature like "export recipe sources to tarball" is wanted?20:38
*** awe00_ <awe00_!~awe00@unaffiliated/awe00> has quit IRC20:42
RobertBerger@derRichard: I can not find the docu online anywhere anymore ;)20:44
RobertBergersomething like: yocto-kernel feature create20:45
RobertBergerapply a series of patches - removing some/adding some20:45
RobertBergerand it took care about all the .scc files as well20:45
derRichardhow do you manage your kernel patches?20:45
RobertBergerWith yocto via scc and stuff, without it some custom script apply them20:46
RobertBergerBut I have to say that I don't have "many" patches.20:47
*** armpit <armpit!~armpit@2601:202:4180:a5c0:3d32:4996:5740:304b> has quit IRC20:47
RobertBergerHere is an example of a kernel recipe of mine:
RobertBergerThere are kernel types which pull in config fragments20:48
*** itseris <itseris!~itseris@> has quit IRC20:48
RobertBergerHere are the patches:
*** itseris <itseris!~itseris@> has joined #yocto20:49
derRichardin my case i have 100+ patches. currently $customer is using devtool modify to create these and put them into the recipe.20:49
*** armpit <armpit!~armpit@2601:202:4180:a5c0:f534:593a:c9d7:eb3d> has joined #yocto20:49
RobertBergerHmm also a possibility20:50
derRichardbut i want to give them way to manage them better. e.g. squash them, reorder, etc..20:50
derRichardusually i'd say use quilt/stgit/etc... but i want to give them the "yocto" way :D20:50
RobertBergerI am afraid to post this on this list, but if you want to have look at the old/unmaintained/kernel tooling ;)20:51
RobertBergerBruce will beat me for it ;)20:51
derRicharddoes the old tooling offer a way to manage the patch queue?20:52
RobertBergerYou can add a bunch of patches and remove them one by one if you like.20:52
RobertBergerNot sure about reordering.20:53
*** rcw <rcw!~rcw@> has quit IRC20:54
derRichardreordering and squashing is needed20:54
*** rcw <rcw!~rcw@> has joined #yocto20:54
derRichardto turn patch sub series like 0001-add-foo.patch, 0003-fix-foo.path, 0023-fix-foo-for-real.path into a single patch20:55
RobertBergerWell I do that with stg20:58
derRichardbut stg has no idea of yocto recipes20:59
RPderRichard: It could be worth starting a discussion about whether such an export feature would be useful, I personally think people might want/use it21:00
derRichardok :)21:01
RobertBergeryep stg does not know about yocto recipes21:01
derRichardRobertBerger: you see the problem? ;-)21:02
RobertBergerLook at this:
RobertBergerIf you start maintenance - and add the feature you need. I am definitely a customer ;)21:03
derRicharda paying customer? :P21:04
*** Konsgnx <Konsgnx!> has quit IRC21:04
RobertBergerHehe depends ;)21:04
RobertBergerWe are talking now over an hour - how much should I charge ?;)21:05
derRichardsince i didn't sign any offer ... ;-)21:05
RPRobertBerger: can I charge? :)21:06
derRichardwhen i do devtool modify linux; edits.. ; devtool finish ...21:07
RobertBerger@RP you NOT21:07
derRichardwhy can't devtool reuse upon next modify the source tree?21:07
RobertBergerdevtool does not even really create the patches for you21:07
RobertBergerYou need to add/commit with git and then it takes it from there.21:08
derRichardof course21:08
derRichardthis was not my question21:08
RobertBergerWell if you modify something it will use the modification21:09
derRichardmy question is. why can't devtool reuse the source dir from a previous devtool modify "session"?21:09
derRichardrunning devtool modify linux takes ages21:09
frayAre you using NFS?21:10
frayI know it's a lot of code, so it can take longer then regular non-kernel recipes.. but on non NFS I hadn't seen it be excessively slow..21:11
derRichardwell, it has to unpack/fetch the sources. do the checkout, run the config stuff...21:11
RobertBergerTo be honest I have a totally differently workflow.21:12
*** Glenn <Glenn!> has joined #yocto21:12
RobertBergerI hack the kernel with an SDK - no yocto involved.21:12
RobertBergerOnce it works as I want it I add the changes to my recipes.21:12
RobertBergerI mean why would  want my kernel hacker to use devtool? Let the kernel hack hack the kernel ;)21:13
derRichardand how do you manage all these patches?21:13
fraythe fetch of the source shoudl already be there..21:13
fraybut the unpack will take a while, depending on how complex it is21:13
frayfor people who don't wnat to manage patches, use externalsrc21:14
derRichardfray: e.g. do_kernel_checkout() is cpu bound. git takes 100% for a minute or two21:14
RobertBergerThe patches are either meta-data and applied as patches (in the Yocto world)21:14
RobertBergerOr through my bash scripts in the non yocto world21:14
frayget the kernel people to use a git repository and externalsrc. that is the optimization 'bridge'21:14
RobertBergerOr you can apply them to some git branch (like many people do) and treat them just as another kernel branch.21:15
RobertBergerLook at the various chip and board manufacturer trees out there.21:15
RobertBergerThey rarely use meta data for patches.21:15
frayyes -- and IMHO they're broken by design..21:15
derRichardfray: i'd like to force them using patch queues to avoid a mess in git. if you give them a git repo they will just push things into it21:15
GlennI noticed that the  Yocto kernel-devicetree.bbclass does NOT build the base device tree with symbols (-@ option for dtc). This makes it impossible in u-boot to "fdt apply" an overlay to the base device tree. Is there a known workaround to force the base device tree to be built with symbols. I'm working on the dunfell branch with TI's linux kernel21:15
Glennfor a Beaglebone Black.21:15
RobertBergerThe "yocto" way is to have the meta data in kernel branches.21:16
frayreal end users don't often build for ONE board, ONE architecture..  but that is how the semi's build their kernels21:16
derRichardfray: devtool modify linux21:16
derRichardreal    4m28.938s21:16
derRicharduser    0m1.944s21:16
derRichardsys     0m1.718s21:16
fraylast time I ran it real was about 1 minute21:16
fraybut I don't do kernel development using devtool -- I do it directly wit hthe recipes and git repositories21:16
derRichardalso one minute is too long IMHO21:16
derRichardthis is interesting. so not much guys are using devtool for kernel dev. hmm. maybe i should also drop it21:17
frayagain this is the purpose of externalsrc  you just have a git tree with your changes already applied and do_fetch, do_patch is skipped21:17
frayI'm not a "kernel guy".. I'm an OS guy21:18
RobertBerger@Glenn: As far as I know device tree overlays are not supported with the upstream kernel - No idea if the TI kernel supports them.21:18
frayI integrate software..  so for me working in the recipe context makes the most sense21:18
RobertBerger@derRichard can you run it with strace to see what it does?21:19
derRichardRobertBerger: no21:19
fraystrace won't help.. there are ways to instrument this stuff -- but it's primarily the git application of the components.. the checkout of the kernel is time consuming itself, then all of the feature merges happen and take more time21:19
derRichardif i was in profiling mood --> perf21:20
fraywhen I clone a tree, it takes me (after the download) 35-60 seconds to just popualte the tree21:20
fraythis is just git overhead processing the tree itself21:20
derRichardfray: thanks for the externalsrc pointer. i need to dig into that21:20
Glenn@RobertBerger TI kernel supports them fine. Used all the time with different BegleBone capes. The problem is that Yocto builds the devicetree (for the kernel) without symbols. It does it properly in the devicetree.bbclass but not in kernel-devicetree.bbclass.21:20
*** pohly <pohly!> has quit IRC21:20
derRichardin the long run i look for ways for my customer to deal with their kernel patches21:21
RobertBergerOK I see.21:21
RobertBergerI somehow managed to build device tree overlays for some imx8mm board and the raspberrypi 4. Let me check who built them.21:22
Glenn@RobertBerger - so it's a Yocto build problem rather than a kernel problem. Can't figure out a good way to sneak in the -@ option to the dtc compiler in the kernel bbclass. Wasn't sure if there is an existing hook to do this.21:23
RobertBergerI see21:23
RobertBergerWait let me see - I remember something.21:24
GlennBuilding the overlay isn't a problem. It's the "base" DTB built by the kernel .bbclass. It has to export symbols so you can apply the overlay in u-boot.21:25
RobertBergerYou means something like that?
Glenn@RobertBerger - yes, I think that may help. Let me look some more. Thanks21:25
derRichardfray: even "devtool status" takes here 2 seconds. feels like java cli tools ;-)21:29
frayI don't know enough about the DTB generation toc omment, other then I know people are working on overlays and other things for DTB in the general case..21:29
frayit has to load a LOT of data to give you status.. thats hte real issue21:29
frayI had a discussion with someone about devtool earlier today.  From my view, my problem with it is I don't have clear understanding of the workflows that ARE integrated (so I can say if they are working properly or not), which also means I don't have a way to spot bugs, feature enhancements, or optimizations..21:30
*** havok101 <havok101!~havok101@2601:241:8a00:46e0:cde8:5f14:a800:d56b> has joined #yocto21:30
havok101khem: so I launched chromium with --use-gl=desktop on the rpi3 and it sayd hardware acceleration enabled but not with egl which is the default21:32
derRichardfray: what i "force" my customers to deal with patch masses is this workflow: devtool modify linux, edit sources and do commits or git rebase -i devtool-base (to manage the patch queue) followed by devtool finish21:32
derRichardthis works rather well except that each "devtool modify linux" run takes ages and they have to rm -rf the sources every time...21:32
frayIf you can document for me the actual workflow you (or your customers are follow)... the specific commands and what you expect, I would LOVE to see it..21:34
frayI've got some people investigating this workflow where I work, but I can't make any promises of improving it yet.. but trying to just have a documented workflow is causing me pain21:35
frayif you can send me something, also if something works as expected.. please tell me.. that is important information..21:35
derRichardok. i can try to rework some of my notes. (i need to remove all customer references first, etc...)21:36
frayyup, I expect that.. simple set of comamdns I can run, and what YOU expect of them would be a huge help..21:37
derRichardok :)21:37
fraythen if I get different behavior I can report back -- or I can learn from it and pass on my findings to the people here doing work on this stuff..21:37
RPJPEW: did you have any further thoughts?21:39
RobertBerger@derRichard: Once you have such a doc you might also want to join one of the OE/YP virtual meetings to discuss it.21:39
RobertBerger@derRichard: Or throw it on the mailing list for review21:40
derRichardok :)21:40
RobertBergerMaybe we can come up with some useful workflows and can try yo adjust some tools for them.21:41
RobertBergerTo honest I don't use it for my kernel stuff.21:42
derRichardfor *my* stuff i also don't use it. but i need a decent and kind of easy way for $customers21:42
RobertBergerBut I can understand that customers might need some tooling.21:42
derRichardfor most of them stg/quilt and other stuff is too hardcore21:43
derRichardand if i give them a git repo to directly commit into they make a huge mess21:43
RobertBergerI see your problem.21:43
RobertBergerBut stg and quilt to hard core? They are developers writing code. So I guess they could use such tools.21:44
RobertBergerHow do they use gcc?21:44
derRichardand sadly our kernel trees are not trivial. we use ipipe on arm and x86. plus tons of patches :(21:44
RobertBergeripipe will soon go away ;)21:44
derRichardby definition of soon21:44
khemarmpit: ok I think there is something still wrong21:44
derRichardi hope xenomai will run "soon" on dovetail. but....21:45
RobertBergerYep that's what I meant21:45
derRichardRobertBerger: regarding "gcc", most of them just click the "play button" in eclipse cde :P21:45
RobertBergerOMG - also Eclipse ;)21:45
RPJPEW: wondering if the parent needs to .close() to avoid the read() blocking21:45
* RP will experiment tomorrow21:45
RobertBergerNow I see what kind of customers are those.21:46
derRichardRobertBerger: just kidding. they are skilled and can compile. but for quilt/stg they are not ready.21:46
derRichardand they pay me to keep their stuff sane21:46
RobertBergerInteresting job description ;)21:47
RobertBergerCan I also pay you to keep my stuff sane? ;)21:47
* derRichard is not cheap21:47
derRichardactually my job description is kindergärtner und feuerlöscher ;-)21:48
RobertBergerYes but I guess it's impossible as well ;)21:48
derRichardsorry for the german joke21:48
RobertBergerI am a kind of native German speaker so for me it's fine21:48
RPderRichard: Do you also start the fires though? ;-)21:49
RobertBergerNo fires.21:49
RobertBergerAlthough I got an emergency notification today, that tomorrow is a high chance for fires - well today actually ;)21:50
RobertBergerNot joking21:50
*** rcw <rcw!~rcw@> has quit IRC21:50
frayyup.. I think we're all in a similar situation.. we aren't the right customers for this code, our customers are.. BUT we need a standard way to tell our customers21:50
RPRobertBerger: they are a serious problem, I shouldn't joke about that :(21:50
derRichardRP: yes. happens often. i dig into some "interesting" code and start asking questions ;-)21:51
RobertBergerNo joke21:51
*** rcw <rcw!~rcw@> has joined #yocto21:51
RPRobertBerger: on the weekend I was enjoying some nice campfires to keep the midges under control. Scotland is a bit more damp though...21:52
RPderRichard: I know that feeling :)21:52
RobertBergerWell here in Greece the laws are like - You are not allowed to build here, but in case it burns,...21:52
kergothargh, i hate making changes that need to be applied across like 12 layers in tons of files, so error prone21:53
RobertBergerRP: Here it's now like 1 in the morning an we have 28 Celsius ...21:54
derRichardRobertBerger: so your location is .gr?21:55
*** maudat <maudat!~moda@> has quit IRC21:56
RPRobertBerger: I'd simply not survive ;-)21:56
RobertBerger@derRichard: An Austrian who is 20+ yrs in Athens.21:57
derRichardRobertBerger: i'm austrian too but still in austria :D21:57
frayRP -- air conditioning is the only survival technique21:58
RobertBergerWithout Covid I am more in Germany/Austria/Switzerland than in Greece ;)21:58
*** kiwi_29 <kiwi_29!> has joined #yocto21:58
*** maudat <maudat!> has joined #yocto21:58
RobertBergerWhere from in Austria?21:58
frayI melt above 22C (when the sun is out)21:58
RobertBergerIch bin ein Steirer ;)21:58
RobertBerger@fray - it's all a matter of getting used to.21:58
RobertBergerNow with only 28C I have the AC off.21:59
RobertBergerWhen it's on I cool down to 26C21:59
frayI live where the temps are -40C to 38C..  I've never gotten used to avove 22C.. :P21:59
frayI can handle up to about 24C, above that my body is not happy21:59
frayI'd rather -40C then 38C21:59
RobertBergerIt took me 2 yrs to get used21:59
RobertBergerThe problem e.g. in Austria with 22C is humidity.22:00
fraynot unusual for me to be in an unheated garage working at -10C22:00
RobertBerger35 without humidity is better than 22 with humidity22:00
*** vineela <vineela!~vtummala@> has quit IRC22:00
frayeven -18C isn't bad22:00
derRichardRobertBerger: i'm from tyrol22:01
frayYa, we have humidity here22:01
RobertBerger@derRichard: So it's better we communicate in English ;)22:01
fray(I have 50k BTU worth of window air conditioners for my house, about 3kWh to run them..22:02
RobertBerger@derRichard Not sure if you talk to your friend in Tyrol and I'm standing beside I can get the subject ;)22:02
fraybut I've automated them.. since they're WiFi enabled..22:02
RobertBerger@fray well if I add the 4 ACs on the appartment I guess it's more than 50k BTU ;)22:03
frayya, depends on how big they are, my 50k BTW is two large window units, and 1 small one.. ;)22:03
frayyikes.. coworker was just saying they're going to a place that is 45C this weekend22:04
kiwi_29Hello. I created a custom machine.conf for running the generated kernel/rootfs on qemu and named it customqemux86-64.conf.  The first line of this file is "require conf/machine/qemux86-64.conf" . However when I execute "MACHINE=customqemux86-64" bitbake mydistro" get this error ERROR: ParseError at <PATH TO MY LAYER>/conf/machine/customqemux86-64.conf:1: Could not include required file conf/machine/include/qemux86-64.conf22:05
fray45C, I don't care about the humitiy anymore.. that's just hot22:05
kiwi_29any thoughts22:05
RobertBerger@fray: I tend to agree22:06
RobertBergerThat is hot22:06
fraykiwi_29 you have a typo..22:06
frayreq should be: conf/machine/qemux86-64.conf  the error added '/include'22:06
RobertBergerHere it's only 32 over the weekend ;)22:06
kiwi_29oh boy..this is embarassing :(22:07
fraycoworkers were also say it was supposed to be about 37C in the San Jose (CA) area this weekend.. even that is horribly hot22:07
kiwi_29many thanks fray !22:07
kiwi_29removing include solved it22:07
fraykiwi_29 no problem.. I do this all the time, and when you type it -- it's ahrd to see the mistake22:07
*** havok101 <havok101!~havok101@2601:241:8a00:46e0:cde8:5f14:a800:d56b> has quit IRC22:11
*** kiwi_29 <kiwi_29!> has quit IRC22:12
*** kiwi_29 <kiwi_29!> has joined #yocto22:15
*** leon-anavi <leon-anavi!~Leon@> has quit IRC22:20
*** ilkappe <ilkappe!c65a42b1@> has quit IRC22:20
*** Glenn <Glenn!> has quit IRC22:23
*** denix <denix!> has quit IRC22:24
*** denix <denix!> has joined #yocto22:25
*** goliath <goliath!> has quit IRC22:41
*** denix <denix!> has quit IRC22:46
*** denix0 <denix0!> has joined #yocto22:46
*** denix0 is now known as denix22:46
*** maudat <maudat!> has quit IRC22:53
*** kiwi_29 <kiwi_29!> has quit IRC22:59
armpitkhem, I have not tried with the update yet so I wont be much help today. I am limited on resources @ home23:00
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC23:07
*** ericch <ericch!> has quit IRC23:08
*** yann <yann!> has quit IRC23:12
*** kiwi_29 <kiwi_29!> has joined #yocto23:14
armpitkhem, the v2 hit master-next 2 hours ago and running on the AB23:33
armpithmm, the wiki build logs are blank.. I hope that is on purpose not not an issue.23:36
*** kiwi_29 <kiwi_29!> has quit IRC23:37
*** agust <agust!> has quit IRC23:50

Generated by 2.17.2 by Marius Gedminas - find it at!