| *** vineela <vineela!vtummala@nat/intel/x-gzbfpddbvmaoignc> has quit IRC | 00:05 | |
| *** vineela <vineela!~vtummala@134.134.137.75> has joined #yocto | 00:06 | |
| *** vineela <vineela!~vtummala@134.134.137.75> has quit IRC | 00:06 | |
| *** awe00__ <awe00__!~awe00@unaffiliated/awe00> has quit IRC | 00:12 | |
| *** dev1990 <dev1990!~dev@dynamic-62-87-247-41.ssp.dialog.net.pl> has quit IRC | 00:51 | |
| *** JaMa <JaMa!~martin@ip-109-238-218-228.aim-net.cz> has quit IRC | 00:52 | |
| *** vineela <vineela!~vtummala@134.134.139.83> has joined #yocto | 00:55 | |
| *** khem <khem!~khem@unaffiliated/khem> has quit IRC | 02:06 | |
| *** hpsy <hpsy!~hpsy@92.118.12.38> has quit IRC | 02:06 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 02:07 | |
| *** hpsy <hpsy!~hpsy@92.118.12.80> has joined #yocto | 02:07 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 02:07 | |
| *** camus1 is now known as kaspter | 02:07 | |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 02:14 | |
| *** khem <khem!~khem@unaffiliated/khem> has quit IRC | 02:16 | |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 02:16 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 03:24 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 04:31 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 04:36 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-kbstzzznwmevbxlx> has quit IRC | 04:39 | |
| *** jonmason <jonmason!sid36602@gateway/web/irccloud.com/x-nqmjapbqbdjqohqv> has quit IRC | 04:39 | |
| *** jonmason <jonmason!sid36602@gateway/web/irccloud.com/x-lsedyatjevbkdrrj> has joined #yocto | 04:39 | |
| *** bradfa <bradfa!sid297668@gateway/web/irccloud.com/x-squoorldndaiuqhs> has quit IRC | 04:40 | |
| *** bradfa <bradfa!sid297668@gateway/web/irccloud.com/x-rfphktmxemxwhcmy> has joined #yocto | 04:41 | |
| *** itseris <itseris!~itseris@23.16.138.134> has quit IRC | 04:46 | |
| *** itseris <itseris!~itseris@23.16.138.134> has joined #yocto | 04:47 | |
| *** ThomasD13 <ThomasD13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 04:53 | |
| *** feddischson <feddischson!~feddischs@HSI-KBW-095-208-248-124.hsi5.kabel-badenwuerttemberg.de> has joined #yocto | 05:02 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 05:46 | |
| *** vineela <vineela!~vtummala@134.134.139.83> has quit IRC | 05:46 | |
| *** pohly <pohly!~pohly@p54849295.dip0.t-ipconnect.de> has joined #yocto | 05:55 | |
| *** zandrey <zandrey!~zandrey@cable-static2-2-7.rsnweb.ch> has quit IRC | 05:59 | |
| *** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto | 06:00 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-qwouakcncmajdnvg> has joined #yocto | 06:08 | |
| LetoThe2nd | happy coffee ingestion time, fellow yoctizens | 06:08 |
|---|---|---|
| ThomasD13 | I hope it tastes good! | 06:09 |
| khem | ENOCOFFEEYET | 06:16 |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has joined #yocto | 06:16 | |
| *** frsc <frsc!~frsc@i59F72560.versanet.de> has joined #yocto | 06:16 | |
| LetoThe2nd | khem: get out of my timezone, summer is over!!!! | 06:16 |
| *** simonpe^^ <simonpe^^!~starlord@c80-217-45-68.bredband.comhem.se> has joined #yocto | 06:17 | |
| khem | khem->sleep() | 06:18 |
| 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}/.config | 06:19 |
| simonpe^^ | file is correct (it has my fragments) but before the configure stage my fragments aren't visible in the file anymore | 06: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 triggered | 06:20 |
| simonpe^^ | I've spent a full dag on this NXP crap now, its driving me nuts | 06:21 |
| LetoThe2nd | simonpe^^: set the nxp config mechanism on fire, and nail the kernel down with a defconfig you can control. my$.02 | 06:22 |
| simonpe^^ | Is it known that NXP's attempt at this sucks? | 06:22 |
| LetoThe2nd | if you ask me, all attempts at this suck. | 06:23 |
| simonpe^^ | lol | 06:23 |
| LetoThe2nd | plus, nxp has been known to have some peculiar approaches | 06: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 risk | 06:24 |
| LetoThe2nd | you 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.gz | 06:24 |
| LetoThe2nd | you don't have to ditch their sources, that would be counter productive. | 06:25 |
| simonpe^^ | Okay man, this makes me happy! Thanks for the help | 06:25 |
| LetoThe2nd | hace fun. that would at least be my approach. | 06:26 |
| *** mckoan|away is now known as mckoan | 06:30 | |
| mckoan | good morning | 06:32 |
| *** fl0v0 <fl0v0!~fvo@i5E86AFC2.versanet.de> has joined #yocto | 06:33 | |
| *** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has joined #yocto | 06:40 | |
| mcfrisk | one zeus to dunfell update done, at least two to go | 06:41 |
| *** wooosaiiii <wooosaiiii!~wooo@89-212-21-243.static.t-2.net> has quit IRC | 06:42 | |
| * LetoThe2nd sings "one down, one to go, just another bullet in the chamber..." (alice cooper, love's a loaded gun) | 06:43 | |
| mcfrisk | LetoThe2nd: hahaha | 06:43 |
| mckoan | LetoThe2nd: LOL | 06:43 |
| mckoan | LetoThe2nd: nice to find you in a good mood today :-D | 06:44 |
| *** seebs <seebs!~seebs@24.196.59.174> has quit IRC | 06:44 | |
| PaowZ | isn't it usually the case ? | 06:44 |
| mcfrisk | note 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 | |
| LetoThe2nd | https://youtu.be/jcEzx5HLYEw?t=71 | 06:46 |
| LetoThe2nd | in case you want to join in | 06:46 |
| LetoThe2nd | mckoan: hehe | 06:46 |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 06:48 | |
| mcfrisk | LetoThe2nd: 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 |
| LetoThe2nd | mcfrisk: i know | 06:50 |
| LetoThe2nd | i keep telling folks that there is so much wisdom in hard rock i nheavy metal, but alas, nobody ever listens | 06:50 |
| LetoThe2nd | *hard rock and heavy metal | 06:50 |
| *** seebs <seebs!~seebs@24.196.59.174> has joined #yocto | 06:52 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 06:53 | |
| * mcfrisk plays Ozzy and Crazy train, will not comment further... | 06:54 | |
| PaowZ | xD | 06:55 |
| *** pbergin <pbergin!~pbergin@h-79-136-99-68.NA.cust.bahnhof.se> has joined #yocto | 06:56 | |
| LetoThe2nd | mcfrisk: recommends the Pat Boone version for additional enlightenment | 06:57 |
| * mcfrisk throws over the fence and ducks: https://www.youtube.com/watch?v=IaeEiDrGyRo | 07:00 | |
| *** hpsy <hpsy!~hpsy@92.118.12.80> has quit IRC | 07:02 | |
| *** hpsy <hpsy!~hpsy@92.118.12.80> has joined #yocto | 07:03 | |
| *** ilkappe <ilkappe!c65a42b1@198.90.66.177> has joined #yocto | 07:05 | |
| LetoThe2nd | <3 | 07:05 |
| LetoThe2nd | now i want a martini | 07:05 |
| LetoThe2nd | mcfrisk but given my local timzone its probably more advisable to start blasting https://youtu.be/0JrlKcoD1Qw | 07:09 |
| *** yann <yann!~yann@91-170-159-152.subs.proxad.net> has joined #yocto | 07:09 | |
| *** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has joined #yocto | 07:13 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 07:14 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 07:15 | |
| *** camus1 is now known as kaspter | 07:16 | |
| ilkappe | Hello 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 in | 07: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 the | 07:18 |
| ilkappe | Makefile. 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 |
| ilkappe | I 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 compiled | 07:19 |
| *** ryder32 <ryder32!7458c728@116.88.199.40> has joined #yocto | 07:19 | |
| ilkappe | but if I run $ find <kernel-build-path> -name ADR.ko no file is found | 07:19 |
| *** chris_ber <chris_ber!~quassel@213.138.44.181> has joined #yocto | 07:21 | |
| ykrons | Hi all | 07:25 |
| ykrons | ilkappe: 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 it | 07: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 path | 07:29 |
| ykrons | When 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 |
| ykrons | ilkappe: sorry ... too early for me ... I read again your question ... you can forgot my reply | 07:32 |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 07:36 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 07:36 | |
| ilkappe | @ykronos no problem ! | 07:39 |
| *** dev1990 <dev1990!~dev@dynamic-62-87-247-41.ssp.dialog.net.pl> has joined #yocto | 07:42 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 07:50 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC | 07:50 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto | 07:51 | |
| *** PaowZ__ <PaowZ__!~Vince@193.252.149.222> has joined #yocto | 07:57 | |
| ilkappe | kayterina, 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-m | 07:59 |
| ilkappe | Is this probably why no .ko file is gneerated ? | 08:00 |
| *** PaowZ_ <PaowZ_!~Vince@193.252.149.222> has quit IRC | 08:00 | |
| kayterina | I don't know that,sorry. | 08:04 |
| kayterina | just from what I read here: https://www.kernel.org/doc/Documentation/kbuild/modules.txt | 08:05 |
| *** sstiller <sstiller!~sstiller@b2b-94-79-174-114.unitymedia.biz> has joined #yocto | 08:05 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 08:07 | |
| *** zandrey <zandrey!~zandrey@193.8.40.126> has joined #yocto | 08:11 | |
| ykrons | ilkappe: 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 |
| ryder32 | I 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 |
| ryder32 | Here is the ifconfig output: https://pastebin.pl/view/f5df792e | 08:15 |
| ryder32 | dmesg shows the driver and it seems fine: https://pastebin.pl/view/c767d88d | 08:15 |
| ryder32 | Any suggestions? Pre-built images supplied by the vendor work fine :| | 08:15 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 08: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 |
| ilkappe | so I expect that when this Makefile is parsed it will add the Makefile in drivers/iio/adc/adr | 08:18 |
| ilkappe | the 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 |
| ilkappe | kernel.org docs states that: $(obj-m) specifies object files which are built as loadable kernel modules. | 08:21 |
| *** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto | 08:21 | |
| ilkappe | so probably it's why the .ko is not generated | 08:22 |
| *** sinseman44 <sinseman44!a5e14d32@165.225.77.50> has joined #yocto | 08:23 | |
| ilkappe | also it's not clear to me if it is ture that every =y module has an entry in /lib/modules/(uname-r)/ module.builtin | 08:25 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 08:27 | |
| cengiz_io | how 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@145.253.222.69> has joined #yocto | 08:33 | |
| *** PaowZ__ <PaowZ__!~Vince@193.252.149.222> has quit IRC | 08:38 | |
| *** PaowZ_ <PaowZ_!~Vince@193.252.149.222> has joined #yocto | 08:38 | |
| *** awe00__ <awe00__!~awe00@unaffiliated/awe00> has joined #yocto | 08:49 | |
| *** fbre <fbre!91fdde45@145.253.222.69> has quit IRC | 08:49 | |
| *** sinseman44 <sinseman44!a5e14d32@165.225.77.50> has quit IRC | 08:53 | |
| *** sinseman44 <sinseman44!a5e14d32@165.225.77.50> has joined #yocto | 08:59 | |
| kanavin_home | RP: seems like all ok with the version updates? I guess there's just Khem's go 1.15 update left. | 08:59 |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC | 09:01 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto | 09:04 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 09:04 | |
| *** simonpe^^ <simonpe^^!~starlord@c80-217-45-68.bredband.comhem.se> has quit IRC | 09:10 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 09:16 | |
| *** simonpe^^ <simonpe^^!~starlord@c80-217-45-68.bredband.comhem.se> has joined #yocto | 09:16 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 09:24 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 09:24 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 09:26 | |
| RobertBerger | @cengiz_io: you most likely need a more up to date version of lttng | 09:28 |
| RobertBerger | maybe something like this: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-kernel/lttng | 09:29 |
| ryder32 | Okay 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@145.253.222.69> has joined #yocto | 09:35 | |
| *** zandrey_ <zandrey_!~zandrey@193.8.40.126> has joined #yocto | 09:37 | |
| *** ryder32 <ryder32!7458c728@116.88.199.40> has quit IRC | 09:38 | |
| RP | kanavin_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@193.8.40.126> has quit IRC | 09:41 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 09:52 | |
| kanavin_home | RP: what is Randy McLeod's nickname here? I'd like to ask about the current situation with his rust work. | 09:56 |
| kanavin_home | there has lately been serious movement towards allowing rust code in the kernel, so we should be prepared for that future | 09:57 |
| dev1990 | interesting news https://www.phoronix.com/scan.php?page=news_item&px=GCC-Auto-Parallel-Compilation | 09:59 |
| LetoThe2nd | kanavin_home: vmeson | 10:02 |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-nvbutzurtwgynhye> has joined #yocto | 10:03 | |
| kanavin_home | vmeson: ^^^ | 10:06 |
| *** ilkappe <ilkappe!c65a42b1@198.90.66.177> has quit IRC | 10:12 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 10:28 | |
| *** silkoman <silkoman!b2c9812e@ip-178-201-129-46.hsi08.unitymediagroup.de> has joined #yocto | 10:33 | |
| rburton | RP armpit: kea patches sent. feel free to ignore the upgrade if you want. | 10:47 |
| LetoThe2nd | rburton: can't wait for apple to fork it into i-kea! | 10:49 |
| rburton | <groan> | 10:49 |
| LetoThe2nd | badum-tsh! | 10:49 |
| RP | rburton: thanks, M3 isn't done yet so I'll queue/test | 10:51 |
| RP | Does anyone have knowledge of python's multiprocessing and deadlocks? | 10:51 |
| rburton | there's one guy i know, richard something | 10:51 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 10:51 | |
| qschulz | RP: 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@134.191.221.74> has quit IRC | 10:56 | |
| RP | rburton: I'm trying to work out what cancel_join_thread() does which deadlocks other processes using that queue :/ | 10:59 |
| *** hpsy <hpsy!~hpsy@92.118.12.80> has quit IRC | 11:03 | |
| qschulz | RP: 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@134.191.221.74> has joined #yocto | 11:06 | |
| *** ilkappe <ilkappe!c65a42b1@198.90.66.177> has joined #yocto | 11:08 | |
| ilkappe | RobertBerger, yes, still fighting and no, it's not public yet. | 11:09 |
| ilkappe | I'm running out of options.. | 11:09 |
| RP | qschulz: that is my worry | 11:10 |
| ilkappe | At 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 -v | 11:10 |
| ilkappe | maybe 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 recompiling | 11:12 |
| ilkappe | it's a long day.. | 11:14 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 11:19 | |
| *** angery <angery!~dave@d66-183-215-121.bchsia.telus.net> has quit IRC | 11:20 | |
| *** awe00__ <awe00__!~awe00@unaffiliated/awe00> has quit IRC | 11:21 | |
| LetoThe2nd | i think you got it wrong. | 11:24 |
| *** silkoman <silkoman!b2c9812e@ip-178-201-129-46.hsi08.unitymediagroup.de> has quit IRC | 11:25 | |
| LetoThe2nd | the citation is "its a long way to the top (if you wanna rock n roll)" | 11:25 |
| ilkappe | LetoThe2nd just rolling for now.. not sure in which direction | 11:26 |
| ilkappe | '=D | 11:26 |
| *** fbre <fbre!91fdde45@145.253.222.69> has quit IRC | 11:37 | |
| *** fbre <fbre!91fdde45@145.253.222.69> has joined #yocto | 11:37 | |
| *** berton <berton!~berton@181.220.78.182> has joined #yocto | 11:40 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 11:42 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 11:43 | |
| *** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC | 11:44 | |
| *** eduardas <eduardas!~eduardas@85.254.96.13> has joined #yocto | 11:59 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-qixpategddontnxe> has joined #yocto | 12:08 | |
| *** emrius <emrius!5840fa9b@dslb-088-064-250-155.088.064.pools.vodafone-ip.de> has joined #yocto | 12:16 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 12:17 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 12:19 | |
| *** camus1 is now known as kaspter | 12:19 | |
| emrius | Hello, 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 cyclic | 12:20 |
| emrius | dependency with `journald` as described in this bug report: https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1725023.html | 12:20 |
| emrius | Is 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 |
| emrius | I'm on dunfell with that issue. The initial problem didn't hit me on warrior. | 12:22 |
| emrius | So, if anyone has any thought on that I'm happy for any hint :) | 12:22 |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has quit IRC | 12:35 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 12:41 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 12:42 | |
| *** camus1 is now known as kaspter | 12:42 | |
| *** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has quit IRC | 12:45 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 12:47 | |
| *** maudat <maudat!~moda@bras-vprn-mtrlpq2848w-lp130-10-174-92-198-55.dsl.bell.ca> has joined #yocto | 12:49 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-nvbutzurtwgynhye> has quit IRC | 12:58 | |
| *** rcoote <rcoote!~rcoote@ip-109-40-131-28.web.vodafone.de> has joined #yocto | 13:00 | |
| RP | emrius: 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 quality | 13:01 |
| RP | emrius: 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 there | 13:01 |
| emrius | RP =D good to know as a background. | 13:02 |
| *** rcoote <rcoote!~rcoote@ip-109-40-131-28.web.vodafone.de> has quit IRC | 13:07 | |
| *** newb_dev <newb_dev!bb14930d@187.20.147.13> has joined #yocto | 13:09 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 13:10 | |
| rburton | emrius: if you're lucky, your SoC has a hardware RNG that you can enable | 13:11 |
| rburton | dig out the reference and see if there's one you can use | 13:11 |
| rburton | many boards have one but the kernel driver doesn't know to use it for entropy | 13:11 |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 13:11 | |
| *** camus1 is now known as kaspter | 13:11 | |
| emrius | rburton Ok, I;ll have a look right away. Thanks!! Oh that is also a great hint! | 13:12 |
| rburton | http://main.lv/writeup/kernel_dev_hwrng.md is useful background | 13:14 |
| emrius | Looks promising! | 13:15 |
| *** sstiller <sstiller!~sstiller@b2b-94-79-174-114.unitymedia.biz> has quit IRC | 13:17 | |
| *** jkridner|pd <jkridner|pd!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 13:18 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 13:20 | |
| *** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/kiwiirc.com/ip.94.61.189.107> has quit IRC | 13:27 | |
| *** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/kiwiirc.com/ip.94.61.189.107> has joined #yocto | 13:28 | |
| emrius | While 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@58.246.136.202> has quit IRC | 13:31 | |
| emrius | Or would that be rather put into the upcoming oe release? | 13:32 |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 13:32 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 13:37 | |
| *** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has quit IRC | 13:37 | |
| *** grembeter <grembeter!c108287e@193.8.40.126> has joined #yocto | 13:38 | |
| *** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has joined #yocto | 13: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!~user@69-165-165-189.dsl.teksavvy.com> has joined #yocto | 13:50 | |
| RobertBerger | To 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 |
| RobertBerger | This 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 |
| RP | RobertBerger: there isn't anything in bitbake that forces that | 13:53 |
| *** awe00_ <awe00_!~awe00@unaffiliated/awe00> has joined #yocto | 13:54 | |
| RobertBerger | @RP You mean it's a bug and not a feature? | 13:54 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 13:56 | |
| *** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has joined #yocto | 13:58 | |
| *** ThomasD13 <ThomasD13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC | 14: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 |
| RobertBerger | So 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 -dbg | 14:07 |
| grembeter | I think it controls by PACKAGEGROUP_DISABLE_COMPLEMENTARY | 14: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!~thecomet@212-51-148-26.fiber7.init7.net> has quit IRC | 14:09 | |
| grembeter | ah, 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 groups | 14:13 |
| zandrey_ | :) | 14:13 |
| *** ollie123 <ollie123!d445ba28@212.69.186.40> has joined #yocto | 14:14 | |
| ollie123 | hi. 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 |
| armpit | rburton, thanks for sending | 14:17 |
| *** emrius <emrius!5840fa9b@dslb-088-064-250-155.088.064.pools.vodafone-ip.de> has quit IRC | 14:18 | |
| rburton | np | 14:18 |
| mcfrisk | does anyone know URL to meta-imx git tree? can't find it with google | 14:21 |
| *** diego_r <diego_r!~diego@mob-176-247-160-75.net.vodafone.it> has quit IRC | 14:22 | |
| RP | rburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/2380 and all the other world builds are failing :( | 14:23 |
| RP | khem: go upgrade fails on musl: https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/2401 | 14:23 |
| rburton | RP: argh | 14:24 |
| rburton | kea's crazy library handling no doubt | 14:25 |
| rburton | ok will do a ML build | 14:25 |
| RP | rburton: also failed in no-x11 | 14:26 |
| RP | rburton: and musl | 14:26 |
| *** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has joined #yocto | 14:26 | |
| RP | rburton: I've emailed | 14:26 |
| rburton | huh | 14:26 |
| armpit | rburton, quick open a bug and get it assigned to the maintainer | 14:26 |
| armpit | YPBT: armpit is on | 14:27 |
| rburton | haha | 14:27 |
| armpit | mcfrisk, isn't imx TI ? if so see meta-ti | 14:28 |
| sgw | Morning all, YPBT: sgw is on | 14:30 |
| *** JaMa <JaMa!~martin@ip-109-238-218-228.aim-net.cz> has joined #yocto | 14:30 | |
| fbre | mcfrisk: https://source.codeaurora.org/external/imx/meta-imx | 14:33 |
| *** shan1 <shan1!866661de@dhcp-222.biba.uni-bremen.de> has joined #yocto | 14:37 | |
| *** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has quit IRC | 14:41 | |
| *** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has joined #yocto | 14:43 | |
| qschulz | armpit: it's NXP/Freescale | 14:45 |
| ollie123 | can 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 IRC | 14:46 | |
| rburton | ollie123: DEPENDS=alsa-lib | 14:47 |
| ollie123 | already have that. and include <alsa/asoundlib.h> in my C file | 14:47 |
| ollie123 | still getting undefined references for functions such as "snd_mixer_open", or any really | 14:48 |
| *** awe00_ <awe00_!~awe00@unaffiliated/awe00> has joined #yocto | 14:48 | |
| qschulz | ollie123: check you have this file in $WORKDIR/recipe-sysroot | 14:48 |
| qschulz | then check the path to where it is is included when compiling | 14:48 |
| rburton | ollie123: you're probably not linking right | 14:48 |
| rburton | hand written makefile or something proper like autotools/meson/etc | 14:49 |
| qschulz | probably CFLAGS/LDFLAGS whatever that is incorrectly set (or not taken from Yocto) | 14:49 |
| ollie123 | unfortunately no alsa files are being pulled into the work dir | 14:49 |
| qschulz | ollie123: then your DEPENDS is wrong | 14:49 |
| *** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has quit IRC | 14:49 | |
| qschulz | ollie123: bitbake myrecipe -e | grep -e "^DEPENDS=", what's in that? | 14:49 |
| ollie123 | exactly how you have written it | 14:50 |
| ollie123 | DEPENDS="alsa-lib" | 14:50 |
| qschulz | bitbake -e and then we debug from there | 14:50 |
| *** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has joined #yocto | 14:50 | |
| ollie123 | thank you for your help | 14:50 |
| qschulz | ollie123: no worries, I suspect DEPENDS is overridden some time later, so please run bitbake -e and check if alsa-lib is in there | 14:51 |
| ollie123 | i do see it in the DEPENDS list in the -e output | 14:52 |
| ollie123 | DEPENDS=" virtual/arm-poky-linux-gnueabi-gcc virtual/arm-poky-linux-gnueabi-compilerlibs virtual/libc alsa-lib" | 14:52 |
| qschulz | ollie123: ok, that's one thing out of the list of things that could have gone wrong | 14:53 |
| qschulz | ollie123: go into WORKDIR/recipe-sysroot (take WORKDIR from bitbake my-recipe -e | grep -e "^WORKDIR=") | 14:53 |
| qschulz | and do a `find` for any alsa header file there | 14:54 |
| ollie123 | did n done. nothing | 14:54 |
| ollie123 | interestingly it doesnt complain about the asound.h header. | 14:54 |
| qschulz | ollie123: did you run `bitbake my-recipe` alone :D? | 14:55 |
| ollie123 | also no "recipe-sysroot" folder in the workdir | 14:55 |
| ollie123 | ? what else would i run | 14:55 |
| qschulz | ollie123: people have imagination :) | 14:56 |
| rburton | you're looking in the wrong place if there's no recipe-sysroot | 14:56 |
| *** shan1 <shan1!866661de@dhcp-222.biba.uni-bremen.de> has quit IRC | 14:56 | |
| ollie123 | not sure what to tell you. my binary is generated successfully in this workdir (with the alsa calls removed of course) | 14:56 |
| ollie123 | this is where it is | 14:56 |
| rburton | but isn't asound.h part of the kernel headers and not alsa-lib? | 14:57 |
| ollie123 | ./1.1.0-r0/alsa-lib-1.1.0/include/sound/asound.h | 14:57 |
| rburton | why is there no /usr/ in there | 14:58 |
| ollie123 | ortexa9hf-neon-mx6qdl-poky-linux-gnueabi/alsa-lib | 14:58 |
| ollie123 | the build process is able to find the asoundlib.h file, and when i purposefully mess the name up (asoundllllib.h) I of course get errors | 15:00 |
| ollie123 | so that is working | 15:00 |
| ollie123 | but i cannot compile against the libraries for some reason to use the functions | 15:00 |
| rburton | compile or link failure | 15:00 |
| rburton | if you're using a hand-written makefile, you're probably missing a bit because its hard to write a proper one | 15:00 |
| *** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC | 15:00 | |
| ollie123 | compile | 15:01 |
| *** grma <grma!~gruberm@80.93.38.128> has quit IRC | 15:01 | |
| *** berton <berton!~berton@181.220.78.182> has quit IRC | 15:01 | |
| ollie123 | I 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 it | 15:01 |
| rburton | then your compile call is probably missing something | 15:02 |
| rburton | what did you put? | 15:02 |
| ollie123 | quite literally just | 15:03 |
| *** otavio <otavio!~otavio@181.220.78.182> has joined #yocto | 15:03 | |
| *** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto | 15:03 | |
| *** fbre <fbre!91fdde45@145.253.222.69> has quit IRC | 15:03 | |
| ollie123 | ${CC} program.c program | 15:03 |
| ollie123 | -o | 15:03 |
| rburton | You forgot to link to the library | 15:03 |
| ollie123 | adding -lasound did the trick | 15:05 |
| ollie123 | sorry that was silly | 15:05 |
| ollie123 | thank you for walking me through it | 15:05 |
| rburton | RP: kea breaks locally, not sure how it worked last night as I distinctly remember sitting around waiting for the build to finish | 15:07 |
| *** feddischson <feddischson!~feddischs@HSI-KBW-095-208-248-124.hsi5.kabel-badenwuerttemberg.de> has quit IRC | 15:10 | |
| *** eduardas <eduardas!~eduardas@85.254.96.13> has quit IRC | 15:12 | |
| *** feddischson <feddischson!~feddischs@HSI-KBW-095-208-248-124.hsi5.kabel-badenwuerttemberg.de> has joined #yocto | 15:13 | |
| armpit | rburton, you went to bed IIRC | 15:17 |
| rburton | I definitely sat waiting for compile to finish as my wife was glaring at me reminding me of the time | 15:17 |
| *** feddischson <feddischson!~feddischs@HSI-KBW-095-208-248-124.hsi5.kabel-badenwuerttemberg.de> has quit IRC | 15:18 | |
| JaMa | RP: 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 task-depends.dot at all, see https://patchwork.openembedded.org/patch/176019/ | 15:19 |
| *** ollie123 <ollie123!d445ba28@212.69.186.40> has quit IRC | 15:19 | |
| JaMa | moto-timo: ^ please check 2 pending patches for meta-python2 | 15:20 |
| *** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has quit IRC | 15:23 | |
| *** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has joined #yocto | 15:25 | |
| *** grembeter <grembeter!c108287e@193.8.40.126> has quit IRC | 15:25 | |
| *** fl0v0 <fl0v0!~fvo@i5E86AFC2.versanet.de> has quit IRC | 15:32 | |
| rburton | RP: fired a quick to test just the kea patches, should be over soon | 15:41 |
| *** sinseman44 <sinseman44!a5e14d32@165.225.77.50> has quit IRC | 15:43 | |
| armpit | ELCe schedule is out | 15:45 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 15:46 | |
| *** maudat <maudat!~moda@bras-vprn-mtrlpq2848w-lp130-10-174-92-198-55.dsl.bell.ca> has quit IRC | 15:50 | |
| *** maudat <maudat!~moda@64.18.88.250> has joined #yocto | 15:51 | |
| *** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has quit IRC | 16:12 | |
| *** wmills <wmills!~bill@2601:144:4100:fd1:12bf:48ff:fed7:9537> has quit IRC | 16:13 | |
| *** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has joined #yocto | 16:14 | |
| *** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has quit IRC | 16:18 | |
| *** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:f09f:31f5:4456:2217> has joined #yocto | 16:20 | |
| *** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC | 16:24 | |
| *** otavio <otavio!~otavio@181.220.78.182> has joined #yocto | 16:25 | |
| *** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto | 16:25 | |
| *** RobertBerger <RobertBerger!~rber@128.90.148.161> has quit IRC | 16:26 | |
| *** chris_ber <chris_ber!~quassel@213.138.44.181> has quit IRC | 16:28 | |
| *** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has quit IRC | 16:28 | |
| *** RobertBerger <RobertBerger!~rber@ppp-2-86-237-227.home.otenet.gr> has joined #yocto | 16:30 | |
| *** grma <grma!~gruberm@80.93.38.128> has joined #yocto | 16:33 | |
| *** zandrey_ <zandrey_!~zandrey@193.8.40.126> has quit IRC | 16:35 | |
| *** rcw <rcw!~rcw@45.72.241.84> has joined #yocto | 16:38 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 16:39 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 16:43 | |
| *** frsc <frsc!~frsc@i59F72560.versanet.de> has quit IRC | 16:47 | |
| zeddii | armpit: 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@134.134.137.77> has joined #yocto | 17:01 | |
| *** bsmerbeck <bsmerbeck!4a6132e0@pool-74-97-50-224.prvdri.fios.verizon.net> has joined #yocto | 17:03 | |
| bsmerbeck | hey 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 |
| JaMa | zeddii: there is only 1 binary in dhcpd dhcpcd/9.1.4-r0/image/usr/sbin/dhcpcd | 17:07 |
| zeddii | I 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 |
| zeddii | whether they are right or wrong calls, that's a different question :D | 17:08 |
| JaMa | or use udhcpc from busybox :) | 17:09 |
| zeddii | heh. 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 |
| zeddii | or carry my own recipe and see what security or incompatibilities I'm opening myself up to. | 17:10 |
| mcfrisk | has anyone ported meta-imx to dunfell yet? | 17:18 |
| gsalazar | Hi, is there a way to encrypt a yocto image with openssl? Directly from the build? | 17:18 |
| Yatekii | hey folks, I am seing this: https://gist.github.com/Yatekii/6200360cfc9e4836d5314aeec72619c8 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 |
| Yatekii | this 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!~zandrey@cable-static2-2-7.rsnweb.ch> has joined #yocto | 17:23 | |
| Yatekii | https://gist.github.com/Yatekii/c80e6d2da181fa1cc3ddb44b07416c4e this is the corresponding receipe | 17:23 |
| *** mckoan is now known as mckoan|away | 17:23 | |
| zandrey | mcfrisk: 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 publicly | 17:25 |
| qschulz | Yatekii: you're using git stuff with a sourc efetched via HTTP | 17:26 |
| qschulz | Yatekii: SRC_URI = "git://code.technokrat.ch/raichu-core.git;protocol=https;branch=rolling" would be better I assume? | 17:26 |
| smurray | mcfrisk: unless you're working directly with NXP support, meta-imx is bad news IMO, try very hard to make meta-freescale work instead | 17:27 |
| mcfrisk | smurray zandrey: sounds like I should not be using meta-imx then at all | 17:28 |
| zandrey | mcfrisk: 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 them | 17:28 |
| smurray | mcfrisk: 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-* directly | 17:29 |
| zandrey | sorry guys, i'm lagging behind a bit :) | 17:29 |
| *** anonzadas <anonzadas!~anonzadas@ja.sefod.eu> has quit IRC | 17:30 | |
| zandrey | mcfrisk: 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: http://yoctoproject.blogspot.com/2020/09/how-to-build-core-image-minimal-with.html | 17:30 |
| zandrey | this is what smurray meant imho | 17:30 |
| smurray | zandrey: roughly, yes | 17:32 |
| mcfrisk | sigh, 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 |
| mcfrisk | yea, BBMASK 95% away... repeat for each BSP layer until you have what is really needed to boot | 17: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 |
| mcfrisk | update from zeus to dunfell, no eval board anymore.. | 17:35 |
| mcfrisk | with zeus we had sumo based BSP, now I saw the BSP update and am pulling hair.. | 17:35 |
| RobertBerger | Hehe and from from the NXP stuff I guess ;) | 17:35 |
| neverpanic | Didn't know we even had an NXP board. | 17:36 |
| RobertBerger | Been there - thrown it away and went to meta-freescale plus my own kernel stuff. | 17:36 |
| RobertBerger | People out there make some noise to your board/chip vendors when their stuff is too old to be usable. | 17:37 |
| RobertBerger | The more people are shouting the better chances we have they'll hear us! | 17:37 |
| mcfrisk | as usual, it starts with non-optimal commit messages in review.. then snowballs into complete do-the-BSP stuff again from scratch | 17:37 |
| RobertBerger | @mcfrisk: "upstream, mainline,..." | 17:38 |
| mcfrisk | yep, we have requirements.. guess what happened to them in contract details ¤#" | 17:38 |
| *** anonzadas <anonzadas!~anonzadas@ja.sefod.eu> has joined #yocto | 17:39 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 17:44 | |
| Yatekii | qschulz: I vaguely remember having heard this already :) however changing to git instead of https results in "fatal: could not read Username for 'https://code.technokrat.ch': No such device or address" which seems odd | 17:44 |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 17:44 | |
| *** King_InuYasha is now known as Conan_Kudo | 17:45 | |
| *** Conan_Kudo is now known as King_InuYasha | 17:45 | |
| *** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/kiwiirc.com/ip.94.61.189.107> has quit IRC | 17:49 | |
| *** mischief <mischief!~mischief@wopr.sciops.net> has joined #yocto | 17:53 | |
| mischief | hi. is there something that documents what is allowed in a recipe version? | 17:53 |
| Yatekii | ok qschulz I guess maybe this is because of the stupid chroot of kas ... | 18:00 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 18:03 | |
| Yatekii | ok with git credentials in the store this works | 18:10 |
| Yatekii | but imo it's just utterly stupid that yocto does whatever randomly when you use https instead of git ... lol | 18:10 |
| Yatekii | it's a great feat ... | 18:10 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 18:15 | |
| Yatekii | I mean why can't it just ask for my user & pwd | 18:23 |
| Yatekii | seems stupid :/ | 18:23 |
| *** bsmerbeck <bsmerbeck!4a6132e0@pool-74-97-50-224.prvdri.fios.verizon.net> has quit IRC | 18:28 | |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:3889:a22b:6ae0:235a> has quit IRC | 18:46 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 18:52 | |
| *** feddischson <feddischson!~feddischs@HSI-KBW-095-208-248-124.hsi5.kabel-badenwuerttemberg.de> has joined #yocto | 18:53 | |
| *** festercluck <festercluck!~stephen@unaffiliated/stephen> has joined #yocto | 19:03 | |
| *** festercluck <festercluck!~stephen@unaffiliated/stephen> has left #yocto | 19:03 | |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:3d32:4996:5740:304b> has joined #yocto | 19:05 | |
| khem | RP: yes I can see musl/go issue thanks will look into it | 19:06 |
| khem | armpit: I am seeing this error in kea https://errors.yoctoproject.org/Errors/Details/498432/ ideas ? | 19:07 |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 19:31 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 19:31 | |
| *** vineela <vineela!~vtummala@134.134.137.77> has quit IRC | 19:38 | |
| derRichard | can 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@134.134.137.77> has joined #yocto | 19:45 | |
| zandrey | derRichard: 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 back | 19:54 |
| zandrey | provided you inherit kernel-yocto class | 19:55 |
| derRichard | zandrey: 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 burden | 19:57 |
| armpit | khem, I have seen that error before but not on kea | 19: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 |
| derRichard | RobertBerger: 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 |
| armpit | khem, rburton redid the update not sure if that will change anything | 20:00 |
| RobertBerger | @derRichard: can you please elaborate a bit more what exactly you are after? | 20:00 |
| derRichard | RobertBerger: 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 |
| RobertBerger | Wait a bit - those are 2 different things | 20:02 |
| RobertBerger | So one thing you want is a kernel config fragment I guess | 20:03 |
| RobertBerger | And the other a kernel patch | 20:03 |
| zandrey | derRichard: then the best would be to check https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html | 20:03 |
| derRichard | RobertBerger: no. i don't want a kernel patch. i want the patched kernel. e.g. kernel sources with all patches applied | 20:04 |
| zandrey | it is pretty good on detailing what you can do with kernel in and outside of Yocto | 20:04 |
| RobertBerger | So you want to use the Yocto kernel tooling ;) | 20:04 |
| RobertBerger | Which kernel do you currently use? | 20:04 |
| *** NiksDev <NiksDev!~NiksDev@192.91.101.32> has quit IRC | 20:04 | |
| derRichard | RobertBerger: what kernel i use does not matter | 20:05 |
| derRichard | zandrey: let me check :) | 20:05 |
| *** NiksDev <NiksDev!~NiksDev@192.91.75.30> has joined #yocto | 20:05 | |
| RobertBerger | It does not depend which kernel you use, but which kernel RECIPE you use ;) | 20:05 |
| zandrey | derRichard: section 2.9 details on how you can plug-in your own kernel source and have it built with Yocto for example | 20:06 |
| RobertBerger | This doc does only work if your kernel recipe inherits the yocto kernel class. | 20:06 |
| derRichard | RobertBerger: of course my recipe inherits the yocto kernel class :) | 20:06 |
| *** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto | 20:06 | |
| RobertBerger | Well that's not of course, if you use e.g. the Ti stuff it does not ;) | 20:06 |
| zandrey | RobertBerger: that is what I wrote above - "provided you inherit kernel-yocto class" :) | 20:07 |
| RobertBerger | OK I think I get it. | 20:07 |
| RobertBerger | So what you basically want is to watch the presentation about this from ELCN this year. | 20:08 |
| derRichard | zandrey: 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 |
| derRichard | so 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 |
| derRichard | is this possible? :-) | 20:09 |
| RobertBerger | Try this: https://www.youtube.com/watch?v=lE5Cd06fN2g&list=PLD4M5FoHz-TxzQnVhNXI8OLiaEmNaW2Au&index=3 | 20:09 |
| RobertBerger | And this: https://www.youtube.com/watch?v=j_-7F2JfjAo&list=PLD4M5FoHz-TxzQnVhNXI8OLiaEmNaW2Au&index=4 | 20:09 |
| RobertBerger | Assuming you all that with Yocto this is possible. | 20:10 |
| RobertBerger | you do all that | 20:10 |
| derRichard | can you please tell me how? is there a "devtool export linux-recipe" tool? :) | 20:11 |
| RobertBerger | See the 2 videos I posted | 20:11 |
| RobertBerger | No why should it export the recipe? | 20:11 |
| RobertBerger | You have the recipe, why would you export it? | 20:11 |
| RobertBerger | The kernel recipe is in a meta-layer and you need this layer. | 20:12 |
| derRichard | RobertBerger: i want to export the *sources* and the *.config* files | 20:12 |
| RobertBerger | The kernel sources? | 20:12 |
| derRichard | of couse | 20:13 |
| derRichard | as i wrote before | 20:13 |
| RobertBerger | There is no Yocto tooling required | 20:13 |
| RobertBerger | tarball | 20:13 |
| derRichard | tarball of what? | 20:13 |
| RobertBerger | The sources + .config | 20:13 |
| RobertBerger | Since this is what you want | 20:13 |
| derRichard | i really think you are kidding me. sorry. | 20:13 |
| derRichard | let me try again | 20:14 |
| derRichard | let's assume i have kernel recipe. this recipe contains tons of patches and config fragments. ok so far? | 20:14 |
| RobertBerger | OK | 20:14 |
| derRichard | now my question | 20:14 |
| RobertBerger | Those patches are applied and config fragments as well | 20:15 |
| RobertBerger | Really watch the 2 videos and do the exercises and you will understand. | 20:15 |
| RobertBerger | It's not magic. | 20:15 |
| derRichard | is 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 me | 20:15 |
| RobertBerger | You end up with patched kernel sources and a config | 20:15 |
| derRichard | RobertBerger: i know these videos. this not what i want | 20:15 |
| RobertBerger | bitbake virtual/kernel ;) | 20:15 |
| derRichard | RobertBerger: did you understand my question? | 20:16 |
| RobertBerger | Yes | 20:16 |
| RobertBerger | You want the patched kernel and the config to build it | 20:16 |
| derRichard | exactly | 20:16 |
| RobertBerger | So you want it without building the kernel first? | 20:17 |
| derRichard | exactly | 20:17 |
| RobertBerger | Or someone else building it? | 20:17 |
| derRichard | no. all i want is the kernel source plus the .config. everything else i can do myself | 20:17 |
| derRichard | this what i do all day. hacking the kernel | 20:17 |
| RobertBerger | bitbake virtual/kernel -c configure | 20:18 |
| RobertBerger | If you want to stop before building it | 20:18 |
| derRichard | so you suggest i should copy from yocto's tmp directory? | 20:19 |
| zandrey | derRichard: how does your $customer stores the kernel? is it in their git repo? can you clone it yourself? | 20:19 |
| RobertBerger | If you saw the videos you know where the patched sources and and .config are - yes | 20:19 |
| derRichard | RobertBerger: i know where they are. i though that there is maybe a tool to do this. hence my question. :) | 20:20 |
| RobertBerger | Not one I know of. | 20:20 |
| derRichard | zandrey: na. they use a kernel.org tarball as base an have a non-trivial kernel recipe which contains tons of patches and config fragments | 20:21 |
| derRichard | RobertBerger: thanks. this is all i wanted to know. | 20:21 |
| zandrey | derRichard: then i guess the only way is what RobertBerger suggested... at least for such a non-trivial setup. | 20:22 |
| RobertBerger | Anyways this has not much to do with kernel tooling. | 20:23 |
| derRichard | zandrey: doing the configure step and going for the tmp folder? no big deal. just wanted to make sure i don't oversee some nice tool | 20:23 |
| RobertBerger | If that's all you want ;) | 20:24 |
| derRichard | RobertBerger: like i said | 20:24 |
| RobertBerger | You could get more fancy and e.g. use kernel fragments with Yocto and without Yocto | 20:24 |
| RobertBerger | Same with patches. | 20:24 |
| RobertBerger | But I am not sure how to use .scc files outside of the Yocto project. | 20:25 |
| derRichard | just don't ;-) | 20:25 |
| RobertBerger | I guess so ;) | 20:25 |
| derRichard | i *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 |
| derRichard | devtool works super for most of my customers but not for me | 20:27 |
| RobertBerger | There used to be more kernel tooling, but it was taken out. I still use it ;) | 20:28 |
| derRichard | what did the tooling do? | 20:29 |
| RP | JaMa: that is quite interesting | 20:30 |
| RP | JaMa: it explains something I've wondered about for a long time | 20:30 |
| RP | JaMa: 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 is | 20:33 |
| *** feddischson <feddischson!~feddischs@HSI-KBW-095-208-248-124.hsi5.kabel-badenwuerttemberg.de> has quit IRC | 20:36 | |
| RP | derRichard: keep in mind we do take patches to extend devtool | 20:36 |
| derRichard | RP: so a patch to add a feature like "export recipe sources to tarball" is wanted? | 20:38 |
| *** awe00_ <awe00_!~awe00@unaffiliated/awe00> has quit IRC | 20:42 | |
| RobertBerger | @derRichard: I can not find the docu online anywhere anymore ;) | 20:44 |
| RobertBerger | something like: yocto-kernel feature create | 20:45 |
| RobertBerger | apply a series of patches - removing some/adding some | 20:45 |
| RobertBerger | and it took care about all the .scc files as well | 20:45 |
| derRichard | how do you manage your kernel patches? | 20:45 |
| RobertBerger | With yocto via scc and stuff, without it some custom script apply them | 20:46 |
| RobertBerger | But 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 IRC | 20:47 | |
| RobertBerger | Here is an example of a kernel recipe of mine: https://gitlab.com/meta-layers/meta-multi-v7-ml-bsp/-/tree/dunfell/recipes-kernel/linux | 20:48 |
| RobertBerger | There are kernel types which pull in config fragments | 20:48 |
| *** itseris <itseris!~itseris@23.16.138.134> has quit IRC | 20:48 | |
| RobertBerger | Here are the patches: https://gitlab.com/meta-layers/meta-multi-v7-ml-bsp/-/blob/dunfell/recipes-kernel/linux/patch/5.4.x/multi-v7-ml-user-patches.scc | 20:49 |
| *** itseris <itseris!~itseris@23.16.138.134> has joined #yocto | 20:49 | |
| derRichard | in 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 #yocto | 20:49 | |
| RobertBerger | Hmm also a possibility | 20:50 |
| derRichard | but i want to give them way to manage them better. e.g. squash them, reorder, etc.. | 20:50 |
| derRichard | usually i'd say use quilt/stgit/etc... but i want to give them the "yocto" way :D | 20:50 |
| RobertBerger | I am afraid to post this on this list, but if you want to have look at the old/unmaintained/kernel tooling ;) | 20:51 |
| RobertBerger | Bruce will beat me for it ;) | 20:51 |
| derRichard | does the old tooling offer a way to manage the patch queue? | 20:52 |
| RobertBerger | https://github.com/RobertBerger/poky/commit/d3d80fa6fbf15189f6183a33c95fa90053535ae2 | 20:52 |
| RobertBerger | You can add a bunch of patches and remove them one by one if you like. | 20:52 |
| RobertBerger | Not sure about reordering. | 20:53 |
| *** rcw <rcw!~rcw@45.72.241.84> has quit IRC | 20:54 | |
| derRichard | reordering and squashing is needed | 20:54 |
| *** rcw <rcw!~rcw@45.72.241.84> has joined #yocto | 20:54 | |
| derRichard | to turn patch sub series like 0001-add-foo.patch, 0003-fix-foo.path, 0023-fix-foo-for-real.path into a single patch | 20:55 |
| derRichard | :) | 20:55 |
| RobertBerger | Well I do that with stg | 20:58 |
| derRichard | but stg has no idea of yocto recipes | 20:59 |
| RP | derRichard: It could be worth starting a discussion about whether such an export feature would be useful, I personally think people might want/use it | 21:00 |
| derRichard | ok :) | 21:01 |
| RobertBerger | yep stg does not know about yocto recipes | 21:01 |
| derRichard | RobertBerger: you see the problem? ;-) | 21:02 |
| RobertBerger | Look at this: https://pastebin.com/sNq3Qap1 | 21:02 |
| RobertBerger | If you start maintenance - and add the feature you need. I am definitely a customer ;) | 21:03 |
| derRichard | a paying customer? :P | 21:04 |
| *** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has quit IRC | 21:04 | |
| RobertBerger | Hehe depends ;) | 21:04 |
| RobertBerger | We are talking now over an hour - how much should I charge ?;) | 21:05 |
| derRichard | since i didn't sign any offer ... ;-) | 21:05 |
| RP | RobertBerger: can I charge? :) | 21:06 |
| derRichard | when i do devtool modify linux; edits.. ; devtool finish ... | 21:07 |
| RobertBerger | @RP you NOT | 21:07 |
| derRichard | why can't devtool reuse upon next modify the source tree? | 21:07 |
| RobertBerger | devtool does not even really create the patches for you | 21:07 |
| RobertBerger | You need to add/commit with git and then it takes it from there. | 21:08 |
| derRichard | of course | 21:08 |
| derRichard | this was not my question | 21:08 |
| RobertBerger | Well if you modify something it will use the modification | 21:09 |
| derRichard | my question is. why can't devtool reuse the source dir from a previous devtool modify "session"? | 21:09 |
| derRichard | running devtool modify linux takes ages | 21:09 |
| fray | Are you using NFS? | 21:10 |
| derRichard | no | 21:10 |
| fray | I 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 |
| derRichard | well, it has to unpack/fetch the sources. do the checkout, run the config stuff... | 21:11 |
| RobertBerger | To be honest I have a totally differently workflow. | 21:12 |
| *** Glenn <Glenn!8bb51c22@nat-lmt.mentorg.com> has joined #yocto | 21:12 | |
| RobertBerger | I hack the kernel with an SDK - no yocto involved. | 21:12 |
| RobertBerger | Once it works as I want it I add the changes to my recipes. | 21:12 |
| RobertBerger | I mean why would want my kernel hacker to use devtool? Let the kernel hack hack the kernel ;) | 21:13 |
| derRichard | and how do you manage all these patches? | 21:13 |
| fray | the fetch of the source shoudl already be there.. | 21:13 |
| fray | but the unpack will take a while, depending on how complex it is | 21:13 |
| fray | for people who don't wnat to manage patches, use externalsrc | 21:14 |
| derRichard | fray: e.g. do_kernel_checkout() is cpu bound. git takes 100% for a minute or two | 21:14 |
| RobertBerger | The patches are either meta-data and applied as patches (in the Yocto world) | 21:14 |
| RobertBerger | Or through my bash scripts in the non yocto world | 21:14 |
| fray | get the kernel people to use a git repository and externalsrc. that is the optimization 'bridge' | 21:14 |
| RobertBerger | Or you can apply them to some git branch (like many people do) and treat them just as another kernel branch. | 21:15 |
| RobertBerger | Look at the various chip and board manufacturer trees out there. | 21:15 |
| RobertBerger | They rarely use meta data for patches. | 21:15 |
| fray | yes -- and IMHO they're broken by design.. | 21:15 |
| derRichard | fray: 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 it | 21:15 |
| Glenn | I 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 kernel | 21:15 |
| Glenn | for a Beaglebone Black. | 21:15 |
| RobertBerger | The "yocto" way is to have the meta data in kernel branches. | 21:16 |
| fray | real end users don't often build for ONE board, ONE architecture.. but that is how the semi's build their kernels | 21:16 |
| derRichard | fray: devtool modify linux | 21:16 |
| derRichard | real 4m28.938s | 21:16 |
| derRichard | user 0m1.944s | 21:16 |
| derRichard | sys 0m1.718s | 21:16 |
| fray | last time I ran it real was about 1 minute | 21:16 |
| fray | but I don't do kernel development using devtool -- I do it directly wit hthe recipes and git repositories | 21:16 |
| derRichard | also one minute is too long IMHO | 21:16 |
| derRichard | this is interesting. so not much guys are using devtool for kernel dev. hmm. maybe i should also drop it | 21:17 |
| fray | again this is the purpose of externalsrc you just have a git tree with your changes already applied and do_fetch, do_patch is skipped | 21:17 |
| fray | I'm not a "kernel guy".. I'm an OS guy | 21: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 |
| fray | I integrate software.. so for me working in the recipe context makes the most sense | 21:18 |
| RobertBerger | @derRichard can you run it with strace to see what it does? | 21:19 |
| derRichard | RobertBerger: no | 21:19 |
| fray | strace 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 time | 21:19 |
| derRichard | if i was in profiling mood --> perf | 21:20 |
| fray | when I clone a kernel.org tree, it takes me (after the download) 35-60 seconds to just popualte the tree | 21:20 |
| fray | this is just git overhead processing the tree itself | 21:20 |
| derRichard | fray: thanks for the externalsrc pointer. i need to dig into that | 21: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!~pohly@p54849295.dip0.t-ipconnect.de> has quit IRC | 21:20 | |
| derRichard | in the long run i look for ways for my customer to deal with their kernel patches | 21:21 |
| RobertBerger | OK I see. | 21:21 |
| RobertBerger | I 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 |
| RobertBerger | I see | 21:23 |
| RobertBerger | Wait let me see - I remember something. | 21:24 |
| Glenn | Building 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 |
| RobertBerger | You means something like that? https://gitlab.com/meta-layers/meta-raspberrypi-ml-bsp/-/blob/master/recipes-kernel/linux/linux-yocto-custom_5.8.inc#L12 | 21:25 |
| Glenn | @RobertBerger - yes, I think that may help. Let me look some more. Thanks | 21:25 |
| RobertBerger | Enjoy! | 21:26 |
| derRichard | fray: even "devtool status" takes here 2 seconds. feels like java cli tools ;-) | 21:29 |
| fray | I 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 |
| fray | it has to load a LOT of data to give you status.. thats hte real issue | 21:29 |
| derRichard | yes | 21:30 |
| fray | I 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 #yocto | 21:30 | |
| havok101 | khem: so I launched chromium with --use-gl=desktop on the rpi3 and it sayd hardware acceleration enabled but not with egl which is the default | 21:32 |
| derRichard | fray: 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 finish | 21:32 |
| derRichard | this works rather well except that each "devtool modify linux" run takes ages and they have to rm -rf the sources every time... | 21:32 |
| fray | If 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 |
| fray | I'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 pain | 21:35 |
| fray | if you can send me something, also if something works as expected.. please tell me.. that is important information.. | 21:35 |
| derRichard | ok. i can try to rework some of my notes. (i need to remove all customer references first, etc...) | 21:36 |
| fray | yup, I expect that.. simple set of comamdns I can run, and what YOU expect of them would be a huge help.. | 21:37 |
| derRichard | ok :) | 21:37 |
| fray | then 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 |
| RP | JPEW: 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 review | 21:40 |
| derRichard | ok :) | 21:40 |
| RobertBerger | Maybe we can come up with some useful workflows and can try yo adjust some tools for them. | 21:41 |
| RobertBerger | To honest I don't use it for my kernel stuff. | 21:42 |
| derRichard | for *my* stuff i also don't use it. but i need a decent and kind of easy way for $customers | 21:42 |
| RobertBerger | But I can understand that customers might need some tooling. | 21:42 |
| derRichard | for most of them stg/quilt and other stuff is too hardcore | 21:43 |
| derRichard | and if i give them a git repo to directly commit into they make a huge mess | 21:43 |
| RobertBerger | I see your problem. | 21:43 |
| RobertBerger | But stg and quilt to hard core? They are developers writing code. So I guess they could use such tools. | 21:44 |
| RobertBerger | How do they use gcc? | 21:44 |
| derRichard | and sadly our kernel trees are not trivial. we use ipipe on arm and x86. plus tons of patches :( | 21:44 |
| RobertBerger | ipipe will soon go away ;) | 21:44 |
| derRichard | by definition of soon | 21:44 |
| khem | armpit: ok I think there is something still wrong | 21:44 |
| derRichard | i hope xenomai will run "soon" on dovetail. but.... | 21:45 |
| RobertBerger | Yep that's what I meant | 21:45 |
| derRichard | RobertBerger: regarding "gcc", most of them just click the "play button" in eclipse cde :P | 21:45 |
| RobertBerger | OMG - also Eclipse ;) | 21:45 |
| RP | JPEW: wondering if the parent needs to .close() to avoid the read() blocking | 21:45 |
| * RP will experiment tomorrow | 21:45 | |
| RobertBerger | Now I see what kind of customers are those. | 21:46 |
| derRichard | RobertBerger: just kidding. they are skilled and can compile. but for quilt/stg they are not ready. | 21:46 |
| derRichard | and they pay me to keep their stuff sane | 21:46 |
| RobertBerger | Interesting job description ;) | 21:47 |
| RobertBerger | Can I also pay you to keep my stuff sane? ;) | 21:47 |
| * derRichard is not cheap | 21:47 | |
| derRichard | actually my job description is kindergärtner und feuerlöscher ;-) | 21:48 |
| RobertBerger | Yes but I guess it's impossible as well ;) | 21:48 |
| derRichard | sorry for the german joke | 21:48 |
| RobertBerger | I am a kind of native German speaker so for me it's fine | 21:48 |
| RP | derRichard: Do you also start the fires though? ;-) | 21:49 |
| RobertBerger | No fires. | 21:49 |
| RobertBerger | Although I got an emergency notification today, that tomorrow is a high chance for fires - well today actually ;) | 21:50 |
| RobertBerger | Not joking | 21:50 |
| *** rcw <rcw!~rcw@45.72.241.84> has quit IRC | 21:50 | |
| fray | yup.. 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 customers | 21:50 |
| RP | RobertBerger: they are a serious problem, I shouldn't joke about that :( | 21:50 |
| derRichard | RP: yes. happens often. i dig into some "interesting" code and start asking questions ;-) | 21:51 |
| RobertBerger | https://www.keeptalkinggreece.com/2020/09/03/wildfires-very-high-risk-warning-sept-4-greece/ | 21:51 |
| RobertBerger | No joke | 21:51 |
| *** rcw <rcw!~rcw@45.72.241.84> has joined #yocto | 21:51 | |
| RP | RobertBerger: on the weekend I was enjoying some nice campfires to keep the midges under control. Scotland is a bit more damp though... | 21:52 |
| RP | derRichard: I know that feeling :) | 21:52 |
| RobertBerger | Well here in Greece the laws are like - You are not allowed to build here, but in case it burns,... | 21:52 |
| kergoth | argh, i hate making changes that need to be applied across like 12 layers in tons of files, so error prone | 21:53 |
| RobertBerger | RP: Here it's now like 1 in the morning an we have 28 Celsius ... | 21:54 |
| derRichard | RobertBerger: so your location is .gr? | 21:55 |
| *** maudat <maudat!~moda@64.18.88.250> has quit IRC | 21:56 | |
| RP | RobertBerger: I'd simply not survive ;-) | 21:56 |
| RobertBerger | @derRichard: An Austrian who is 20+ yrs in Athens. | 21:57 |
| derRichard | RobertBerger: i'm austrian too but still in austria :D | 21:57 |
| fray | RP -- air conditioning is the only survival technique | 21:58 |
| RobertBerger | Without Covid I am more in Germany/Austria/Switzerland than in Greece ;) | 21:58 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 21:58 | |
| *** maudat <maudat!~moda@bras-vprn-mtrlpq2848w-lp130-10-174-92-198-55.dsl.bell.ca> has joined #yocto | 21:58 | |
| RobertBerger | Where from in Austria? | 21:58 |
| fray | I melt above 22C (when the sun is out) | 21:58 |
| RobertBerger | Ich bin ein Steirer ;) | 21:58 |
| RobertBerger | @fray - it's all a matter of getting used to. | 21:58 |
| RobertBerger | Now with only 28C I have the AC off. | 21:59 |
| RobertBerger | When it's on I cool down to 26C | 21:59 |
| fray | I live where the temps are -40C to 38C.. I've never gotten used to avove 22C.. :P | 21:59 |
| fray | I can handle up to about 24C, above that my body is not happy | 21:59 |
| fray | I'd rather -40C then 38C | 21:59 |
| RobertBerger | It took me 2 yrs to get used | 21:59 |
| RobertBerger | The problem e.g. in Austria with 22C is humidity. | 22:00 |
| fray | not unusual for me to be in an unheated garage working at -10C | 22:00 |
| RobertBerger | 35 without humidity is better than 22 with humidity | 22:00 |
| *** vineela <vineela!~vtummala@134.134.137.77> has quit IRC | 22:00 | |
| fray | even -18C isn't bad | 22:00 |
| derRichard | RobertBerger: i'm from tyrol | 22:01 |
| fray | Ya, we have humidity here | 22:01 |
| RobertBerger | OK | 22: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 |
| fray | but 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 |
| fray | ya, depends on how big they are, my 50k BTW is two large window units, and 1 small one.. ;) | 22:03 |
| fray | yikes.. coworker was just saying they're going to a place that is 45C this weekend | 22:04 |
| kiwi_29 | Hello. 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.conf | 22:05 |
| fray | 45C, I don't care about the humitiy anymore.. that's just hot | 22:05 |
| kiwi_29 | any thoughts | 22:05 |
| RobertBerger | @fray: I tend to agree | 22:06 |
| RobertBerger | That is hot | 22:06 |
| fray | kiwi_29 you have a typo.. | 22:06 |
| fray | req should be: conf/machine/qemux86-64.conf the error added '/include' | 22:06 |
| RobertBerger | Here it's only 32 over the weekend ;) | 22:06 |
| kiwi_29 | oh boy..this is embarassing :( | 22:07 |
| fray | coworkers were also say it was supposed to be about 37C in the San Jose (CA) area this weekend.. even that is horribly hot | 22:07 |
| kiwi_29 | many thanks fray ! | 22:07 |
| kiwi_29 | removing include solved it | 22:07 |
| fray | kiwi_29 no problem.. I do this all the time, and when you type it -- it's ahrd to see the mistake | 22:07 |
| kiwi_29 | :) | 22:08 |
| *** havok101 <havok101!~havok101@2601:241:8a00:46e0:cde8:5f14:a800:d56b> has quit IRC | 22:11 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 22:12 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 22:15 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 22:20 | |
| *** ilkappe <ilkappe!c65a42b1@198.90.66.177> has quit IRC | 22:20 | |
| *** Glenn <Glenn!8bb51c22@nat-lmt.mentorg.com> has quit IRC | 22:23 | |
| *** denix <denix!~denix@pool-100-15-86-127.washdc.fios.verizon.net> has quit IRC | 22:24 | |
| *** denix <denix!~denix@pool-100-15-86-127.washdc.fios.verizon.net> has joined #yocto | 22:25 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 22:41 | |
| *** denix <denix!~denix@pool-100-15-86-127.washdc.fios.verizon.net> has quit IRC | 22:46 | |
| *** denix0 <denix0!~denix@pool-100-15-86-127.washdc.fios.verizon.net> has joined #yocto | 22:46 | |
| *** denix0 is now known as denix | 22:46 | |
| *** maudat <maudat!~moda@bras-vprn-mtrlpq2848w-lp130-10-174-92-198-55.dsl.bell.ca> has quit IRC | 22:53 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 22:59 | |
| armpit | khem, I have not tried with the update yet so I wont be much help today. I am limited on resources @ home | 23:00 |
| *** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-qwouakcncmajdnvg> has quit IRC | 23:07 | |
| *** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has quit IRC | 23:08 | |
| *** yann <yann!~yann@91-170-159-152.subs.proxad.net> has quit IRC | 23:12 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 23:14 | |
| armpit | khem, the v2 hit master-next 2 hours ago and running on the AB | 23:33 |
| armpit | hmm, the wiki build logs are blank.. I hope that is on purpose not not an issue. | 23:36 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 23:37 | |
| *** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has quit IRC | 23:50 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!