| *** psj <psj!~psj@h184-60-26-81.mdtnwi.broadband.dynamic.tds.net> has joined #yocto | 00:34 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 00:43 | |
| *** psj <psj!~psj@h184-60-26-81.mdtnwi.broadband.dynamic.tds.net> has quit IRC (Remote host closed the connection) | 00:52 | |
| *** florian <florian!~florian@dynamic-078-048-160-009.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 260 seconds) | 01:03 | |
| *** kscherer <kscherer!~kscherer@bras-base-otwaon1146w-grc-21-184-147-79-201.dsl.bell.ca> has quit IRC (Quit: Konversation terminated!) | 01:40 | |
| *** davidinux <davidinux!~davidinux@92.118.62.172> has quit IRC (Ping timeout: 256 seconds) | 02:04 | |
| *** davidinux <davidinux!~davidinux@37.120.201.204> has joined #yocto | 02:05 | |
| *** m4ho <m4ho!~m4ho@p5098be52.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 260 seconds) | 02:15 | |
| *** Tokamak <Tokamak!~Tokamak@166.205.152.50> has joined #yocto | 02:16 | |
| *** Tokamak_ <Tokamak_!~Tokamak@172.58.236.139> has quit IRC (Ping timeout: 256 seconds) | 02:16 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 02:17 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 02:28 | |
| *** starblue <starblue!~juergen@dslb-178-006-091-196.178.006.pools.vodafone-ip.de> has quit IRC (Ping timeout: 260 seconds) | 02:33 | |
| *** starblue <starblue!~juergen@dslb-094-221-185-161.094.221.pools.vodafone-ip.de> has joined #yocto | 02:35 | |
| *** m4ho <m4ho!~m4ho@p5098be52.dip0.t-ipconnect.de> has joined #yocto | 02:47 | |
| *** ptsneves <ptsneves!~Thunderbi@031011128073.dynamic-3-poz-k-0-2-0.vectranet.pl> has joined #yocto | 03:32 | |
| *** amitk <amitk!~amit@103.208.71.104> has joined #yocto | 03:35 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:652c:e900:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 252 seconds) | 03:36 | |
| *** ptsneves <ptsneves!~Thunderbi@031011128073.dynamic-3-poz-k-0-2-0.vectranet.pl> has quit IRC (Ping timeout: 260 seconds) | 03:36 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:6526:c600:2ce:39ff:fecf:efcd> has joined #yocto | 03:38 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 260 seconds) | 03:46 | |
| *** m4ho <m4ho!~m4ho@p5098be52.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 256 seconds) | 04:02 | |
| *** Tokamak_ <Tokamak_!~Tokamak@172.58.227.116> has joined #yocto | 04:10 | |
| *** Tokamak <Tokamak!~Tokamak@166.205.152.50> has quit IRC (Ping timeout: 260 seconds) | 04:13 | |
| *** m4ho <m4ho!~m4ho@p5098be52.dip0.t-ipconnect.de> has joined #yocto | 04:16 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 04:45 | |
| *** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 268 seconds) | 05:09 | |
| *** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 05:10 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 05:11 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 05:12 | |
| *** amitk_ <amitk_!~amit@103.59.74.88> has joined #yocto | 05:48 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 05:51 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Client Quit) | 05:52 | |
| *** tor <tor!~tor@user/tor> has joined #yocto | 06:18 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 06:21 | |
| *** tor <tor!~tor@user/tor> has quit IRC (Quit: Leaving) | 06:52 | |
| *** tor <tor!~tor@user/tor> has joined #yocto | 06:54 | |
| *** tomzy_0 <tomzy_0!~tomzy_0@84-10-27-202.static.chello.pl> has joined #yocto | 07:06 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 07:27 | |
| *** manuel <manuel!~manuel198@2a02:1748:dd5c:f290:c553:9012:6082:a89a> has quit IRC (*.net *.split) | 07:33 | |
| *** manuel <manuel!~manuel198@2a02:1748:dd5c:f290:c553:9012:6082:a89a> has joined #yocto | 07:34 | |
| *** risca <risca!~quassel@h-155-4-197-151.A980.priv.bahnhof.se> has quit IRC (Ping timeout: 248 seconds) | 07:36 | |
| *** Circuitsoft <Circuitsoft!uid393878@id-393878.lymington.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 07:39 | |
| *** mckoan|away <mckoan|away!~marco@host-79-3-92-72.business.telecomitalia.it> has quit IRC (Ping timeout: 256 seconds) | 07:41 | |
| *** iokill <iokill!~dave@static.16.105.130.94.clients.your-server.de> has quit IRC (*.net *.split) | 07:44 | |
| *** ernstp <ernstp!sid168075@2a03:5180:f:4::2:908b> has quit IRC (*.net *.split) | 07:44 | |
| *** georgem <georgem!sid210681@2a03:5180:f::3:36f9> has quit IRC (*.net *.split) | 07:44 | |
| *** KanjiMonster <KanjiMonster!~KanjiMons@dslb-002-205-021-059.002.205.pools.vodafone-ip.de> has quit IRC (*.net *.split) | 07:44 | |
| *** Zappan <Zappan!~zappan@zap.one> has quit IRC (*.net *.split) | 07:44 | |
| *** polprog <polprog!~ath0@user/polprog> has quit IRC (*.net *.split) | 07:44 | |
| *** iokill <iokill!~dave@static.16.105.130.94.clients.your-server.de> has joined #yocto | 07:44 | |
| *** georgem <georgem!sid210681@id-210681.tinside.irccloud.com> has joined #yocto | 07:45 | |
| *** ernstp <ernstp!sid168075@id-168075.hampstead.irccloud.com> has joined #yocto | 07:45 | |
| *** Zappan <Zappan!~zappan@zap.one> has joined #yocto | 07:45 | |
| *** polprog <polprog!~ath0@user/polprog> has joined #yocto | 07:45 | |
| *** KanjiMonster <KanjiMonster!~KanjiMons@dslb-002-205-021-059.002.205.pools.vodafone-ip.de> has joined #yocto | 07:45 | |
| hmw[m] | how do i overwrite the default do configure? | 07:49 |
|---|---|---|
| *** manuel1985 <manuel1985!~manuel198@185.68.248.44> has joined #yocto | 07:52 | |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4503:c400:24d7:51ff:fed6:906d> has joined #yocto | 08:08 | |
| *** zpfvo <zpfvo!~fvo@i59F5CCB0.versanet.de> has joined #yocto | 08:12 | |
| *** gho <gho!~gho@i59F5CCB0.versanet.de> has joined #yocto | 08:17 | |
| *** payam <payam!~payam@c83-250-236-236.bredband.tele2.se> has quit IRC (Remote host closed the connection) | 08:23 | |
| *** vladest <vladest!~Thunderbi@6.174.199.178.dynamic.wline.res.cust.swisscom.ch> has joined #yocto | 08:23 | |
| *** derRichard <derRichard!~derRichar@static.16.105.130.94.clients.your-server.de> has joined #yocto | 08:30 | |
| derRichard | hey! | 08:31 |
| derRichard | is there a reason why this fix is not in dunfell yet? https://git.yoctoproject.org/yocto-kernel-tools/commit/?id=64bdfc4ca221cf181af7790e862d26f87a9ea881 | 08:32 |
| tomzy_0 | Hi | 08:39 |
| tomzy_0 | is there someone who successfully compiled xorg-xserver 21.1.3 provided since kirkstone? | 08:39 |
| *** d-fens <d-fens!~d-fens@5.10.7.173> has joined #yocto | 08:40 | |
| jclsn | Morning | 08:58 |
| jclsn | How can I get the return value from a bash function in a Bitbake script. I tried automatically setting PARALLEL_MAKE = "-j ${nproc}", but that throws an error | 08:59 |
| *** kiwi_29_[m] <kiwi_29_[m]!~msgboardp@2001:470:69fc:105::1:6699> has quit IRC (Quit: You have been kicked for being idle) | 09:00 | |
| LetoThe2nd | yo dudX | 09:00 |
| *** kiwi_29_[m] <kiwi_29_[m]!~msgboardp@2001:470:69fc:105::1:6699> has joined #yocto | 09:00 | |
| *** kiwi_29_[m] <kiwi_29_[m]!~msgboardp@2001:470:69fc:105::1:6699> has left #yocto | 09:00 | |
| jclsn | It seems you can't define Bitbake functions in local.conf either | 09:02 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 09:14 | |
| LetoThe2nd | jclsn: yeah AFAIK functions cannot go into .conf files? | 09:15 |
| jclsn | LetoThe2nd: Pity, so only fixed values are possible for PARALLEL_MAKE | 09:17 |
| *** zpfvo <zpfvo!~fvo@i59F5CCB0.versanet.de> has quit IRC (Ping timeout: 268 seconds) | 09:19 | |
| jclsn | Well, I guess the default is nproc, so I could just work with that and divide it by two or something | 09:19 |
| LetoThe2nd | jclsn: well you can always override those in a specific recipe or class | 09:21 |
| jclsn | LetoThe2nd: I want to globally override them though. I want to see if keeping the load average lower will improve performance. So something like PARALLEL_MAKE = "${PARALLEL_MAKE}/${BB_NUMBER_THREADS}" | 09:23 |
| jclsn | Per recipe doesn't make sense | 09:23 |
| *** d-fens <d-fens!~d-fens@5.10.7.173> has quit IRC (Quit: Client closed) | 09:23 | |
| LetoThe2nd | jclsn: well globally should not be that much of a problem. just look at how they are assigned in the first place and then patch/modify | 09:25 |
| jclsn | But you can't do arithmetic calculations inside the variables | 09:26 |
| jclsn | Typisation would come in handy here | 09:27 |
| jclsn | Ah well I guess I will just leave it | 09:28 |
| qschulz | jclsn: you could set the variable in the local environment and use the environment variable in your local.conf | 09:28 |
| qschulz | otherwise, it supports in-line python | 09:29 |
| qschulz | so something like PARALLEL_MAKE = "${@os.cpucount()}" ? | 09:30 |
| *** manuel1985 <manuel1985!~manuel198@185.68.248.44> has quit IRC (Ping timeout: 260 seconds) | 09:32 | |
| *** zpfvo <zpfvo!~fvo@i59F5CCB0.versanet.de> has joined #yocto | 09:33 | |
| jclsn | qschulz: cpucount is in multiprocessing. How can I do an import statement before that? | 09:36 |
| jclsn | I tried "${@import multiprocessi}${@multiprocessing.cpucount()} | 09:36 |
| jclsn | ah os.cpu_count() works it seems | 09:38 |
| *** mckoan|away <mckoan|away!~marco@host-95-229-48-41.business.telecomitalia.it> has joined #yocto | 09:40 | |
| jclsn | Ah but now I have PARALLEL_MAKE="24/2" ^^ | 09:40 |
| qschulz | jclsn: why? | 09:42 |
| qschulz | do PARALLEL_MAKE = "${@os.cpucount() / 2}" | 09:42 |
| qschulz | and I think you need -j in front? | 09:42 |
| qschulz | so PARALLEL_MAKE = "-j ${@os.cpucount() / 2}" ? | 09:42 |
| jclsn | If I put "${@os.cpu_count/${BB_NUMBER_THREADS}}" I get 12.0 | 09:42 |
| jclsn | Ah yes | 09:42 |
| jclsn | Let met try | 09:42 |
| qschulz | jclsn: then // | 09:42 |
| qschulz | that's just python | 09:42 |
| mcfrisk | what about enabling kernel module signing by default in poky master branch? maybe via config snippet and PACKAGECONFIG. it's not the default in x86_64 in upstream but I think it should be. and it would show the stripping failure earlier too (still investigating, disabling stripping fixes this) | 09:43 |
| jclsn | Yeah but make don't take floats bra | 09:43 |
| qschulz | jclsn: hence the // | 09:43 |
| jclsn | ok | 09:44 |
| jclsn | Yep | 09:46 |
| jclsn | But it's not maxing out the core now ^^ | 09:46 |
| jclsn | Guess going with the default is the best | 09:46 |
| qschulz | jclsn: what are you trying to do | 09:47 |
| jclsn | qschulz: Our devops guy was complaining that our load average is too high. So like 4 times the number of physical core. He said to optimize efficiency I should adjust those settings properly | 09:48 |
| jclsn | Bitbake seems to have a lot of processes waiting for IO | 09:48 |
| LetoThe2nd | why is that a problem? | 09:48 |
| jclsn | Because our Devops guy is a nerd | 09:48 |
| jclsn | He said we would waste performance | 09:49 |
| *** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Read error: Connection reset by peer) | 09:49 | |
| LetoThe2nd | the build will eventually finish, why does $DEVOPS guy have to tell you how to run the builc? if it affects other stuff, he shall give you a quota. rest is not of his concern, IMHO | 09:49 |
| jclsn | Actually the kernel should handle all of these things imo | 09:49 |
| *** OnkelUlla <OnkelUlla!~user@dude03.red.stw.pengutronix.de> has quit IRC (Read error: Connection reset by peer) | 09:49 | |
| *** mckoan|away <mckoan|away!~marco@host-95-229-48-41.business.telecomitalia.it> has quit IRC (Ping timeout: 264 seconds) | 09:49 | |
| qschulz | the only worry you should have is not running out of memory | 09:50 |
| qschulz | I remember reading somewhere that anything above 20 threads isn't going to help anyway so you can limit it to that | 09:51 |
| LetoThe2nd | qschulz: yup. give or take a few, but somewhere above 24-32 you're not gaining anything anymore. | 09:51 |
| jclsn | LetoThe2nd: Yeah true, as long as we don't have problems why fix it. I am just curious to make a few experiments too. I didn't even know what the load everage meant before that. So at least I learnt something | 09:52 |
| *** shoragan <shoragan!~shoragan@user/shoragan> has joined #yocto | 09:58 | |
| Saur[m] | jclsn: If you are using Kirkstone or later, you might want to look inte to the new BB_PRESSURE_* variables too. | 10:01 |
| *** davidinux <davidinux!~davidinux@37.120.201.204> has quit IRC (Ping timeout: 248 seconds) | 10:04 | |
| jclsn | Saur[m]: I wouldn't know how to find the right pressure values | 10:05 |
| jclsn | Ah will just let it be for now. It is not so important really | 10:07 |
| jclsn | Thanks for showing me those variables though. Maybe in the future I will make use of them | 10:08 |
| *** mckoan|away <mckoan|away!~marco@host-95-229-48-41.business.telecomitalia.it> has joined #yocto | 10:12 | |
| *** mckoan|away is now known as mckoan | 10:13 | |
| *** d-fens <d-fens!~d-fens@5.10.7.173> has joined #yocto | 10:30 | |
| jclsn | If BB_SRCREV_POLICY = "cache" will that not break AUTOREV? | 10:30 |
| *** amitk_ <amitk_!~amit@103.59.74.88> has quit IRC (Ping timeout: 268 seconds) | 10:31 | |
| jclsn | If it doesn't check the repo every time it builds, it can't be up-to-date really | 10:31 |
| *** OnkelUlla <OnkelUlla!~user@dude03.red.stw.pengutronix.de> has joined #yocto | 10:33 | |
| jclsn | Seems like it does unfortunately | 10:42 |
| *** gsalazar <gsalazar!~gsalazar@139.0.166.178.rev.vodafone.pt> has quit IRC (Ping timeout: 248 seconds) | 10:49 | |
| RP | jclsn: devops people don't always think about builds in the right way. bitbake tends to queue up everything it can, it then leaves it to the kernel to work out what it can do with the resources available. The kernel tends to be much better at that than userspace can be | 10:50 |
| d-fens | hi, fetching some python deps on kirkstone i was looking for bitbake -s | grep ^python3-git which resulted in 3.1.27-r0 and then tried https://layers.openembedded.org/layerindex/branch/master/recipes/?q=python+git and was given https://layers.openembedded.org/layerindex/recipe/51298/ but the latest version is 3.1.29 (not 27) - question: why | 10:53 |
| d-fens | don't i see the 29 file that does live in http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/python/python3-git_3.1.29.bb while 27 doesn't xist ? is the layerindex not updated regularly and what am i doing wrong? | 10:53 |
| LetoThe2nd | d-fens: let`s say the layerindex is not exactly well maintained at the moment. | 10:54 |
| *** gsalazar <gsalazar!~gsalazar@139.0.166.178.rev.vodafone.pt> has joined #yocto | 10:54 | |
| *** Saur <Saur!~pkj@nebula.axis.com> has quit IRC (Ping timeout: 260 seconds) | 11:00 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 11:01 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 11:02 | |
| JaMa | jclsn: you can see some benchmarks in https://github.com/shr-project/test-oe-build-time | 11:02 |
| *** starblue <starblue!~juergen@dslb-094-221-185-161.094.221.pools.vodafone-ip.de> has quit IRC (Ping timeout: 260 seconds) | 11:06 | |
| *** Notgnoshi <Notgnoshi!~quassel@184-83-95-131-dynamic.midco.net> has quit IRC (Ping timeout: 255 seconds) | 11:07 | |
| *** starblue <starblue!~juergen@dslb-094-221-185-161.094.221.pools.vodafone-ip.de> has joined #yocto | 11:08 | |
| d-fens | LetoThe2nd i see, so the poky layer is my oe-core layer, where only .27 exists for kirkstone; how should i handle the .29 requirement while staying on kirkstone? | 11:10 |
| d-fens | copy the python3-git_3.1.29.bb to my distro layer? | 11:11 |
| *** Saur <Saur!~pkj@nebula.axis.com> has joined #yocto | 11:14 | |
| *** gsalazar <gsalazar!~gsalazar@139.0.166.178.rev.vodafone.pt> has quit IRC (Ping timeout: 265 seconds) | 11:15 | |
| mcfrisk | linux-yocto in poky has some neat config stuff, but sadly I haven't seen any BSP layer using it... | 11:16 |
| LetoThe2nd | d-fens: rather the application layer, but basically yes. | 11:16 |
| *** gsalazar <gsalazar!~gsalazar@139.0.166.178.rev.vodafone.pt> has joined #yocto | 11:21 | |
| jclsn | RP: Yeah I also think that thinking that you are able to handle things better than the kernel is a bit presumptuous | 11:26 |
| rburton | mcfrisk: meta-arm does for some BSPs | 11:27 |
| mcfrisk | rburton: cool, sadly vendor kernels weren't using them.. | 11:29 |
| RP | jclsn: I've tried before in bitbake and usually we just made performance worse | 11:31 |
| jclsn | Same for me | 11:31 |
| RP | It is a balance, which is why we have PARALLEL_MAKE and BB_NUMBER_THREADS but anything finer grained doesn't usually help | 11:31 |
| *** d-fens <d-fens!~d-fens@5.10.7.173> has quit IRC (Ping timeout: 260 seconds) | 11:32 | |
| jclsn | RP: I am just looking at this bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=14918 which was caused by one of your patches | 11:32 |
| RP | jclsn: right, I fixed several problems and caused some others :( | 11:33 |
| jclsn | I tried to workaround by using BB_SRCREV_POLICY = "cache", but that breaks AUTOREV it seems | 11:33 |
| jclsn | RP: Happens to the best of us ;) | 11:33 |
| jclsn | Well, I guess you have no idea how to fix it or did you just have no time to look at it? | 11:34 |
| jclsn | I am trying to understand the code | 11:34 |
| RP | jclsn: I haven't had the time to dig in and understand what is going wrong | 11:34 |
| jclsn | Alright | 11:34 |
| jclsn | No worries. I will use fixed SRCREV for now | 11:35 |
| jclsn | Maybe I will have a look at it myself | 11:35 |
| RP | help in fixing it would be very welcome, I just don't have the bandwidth to do it :( | 11:36 |
| Saur[m] | jclsn: If you use BB_SRCREV_POLICY = "cache", which we do, then as you have noticed, you can not use ${AUTOREV, which means that devtool not supporting ${AUTOREV} is no longer a problem. ;) | 11:36 |
| *** d-fens <d-fens!~d-fens@5.10.7.173> has joined #yocto | 11:37 | |
| mcfrisk | for CPU usage kernel is good, same for virtual memory/RAM, but for IO, things are different. By default, background writing of things tmp will happen way too fast. Tuning of VM parameters is needed to keep things in RAM so that rm_work can remove them before flush to disk happens.. | 11:37 |
| mcfrisk | building on full tmpfs is nice but it's rare to have so much RAM available for full build/tmp | 11:38 |
| * RP really doesn't like rm_work :( | 11:38 | |
| jclsn | Saur[m]: Great workaround :D | 11:39 |
| jclsn | I got used to AUTOREV though. So convenient | 11:39 |
| RP | Saur[m]: can't you manually clear the cache with BB_SRCREV_POLICY = "cache" to trigger autorev? | 11:39 |
| mcfrisk | RP: any non-trivial build env must use rm_work, otherwise tmp/work* will be too big | 11:39 |
| RP | mcfrisk: thanks, clearly I only ever do trivial stuff | 11:40 |
| mcfrisk | I only had 3 Tb disks/nvme/ssd's on the big machines, that was enoug for 3-4 project builds with download and sstate caches shared. A single build with rm_work was easily 150 Gb on disk. Can't even imagine how big those would have been without rm_work... | 11:42 |
| * RP notes the autobuilders are also trivial | 11:43 | |
| mcfrisk | only core-image-minimal? without systemd? | 11:44 |
| RP | what worries me about rm_work is that it was hacked on top of everything, not designed in properly and is extremely fragile. It integrates with the task graph particularly poorly and has a poor story around debugging failures. | 11:44 |
| RP | Despite it being used heavily, nobody actually cares about fixing any of that, just patching it to make it mostly work | 11:44 |
| mcfrisk | for me it works, can't remember ever having problems with it | 11:44 |
| RP | mcfrisk: you don't get the bug reports when it breaks :( | 11:45 |
| mcfrisk | true, sorry about that | 11:46 |
| RP | mcfrisk: trying to change other parts of the system to improve them whilst ensuring it keeps working is also frustrating given everything else | 11:46 |
| qschulz | mcfrisk: I remove everything between CI builds except sstate cache and dl dir, no need for rm_work in that scenrario? | 11:46 |
| mcfrisk | but it does help a lot to keep the amount of IO lower during builds and to keep fs buffers in RAM | 11:47 |
| qschulz | (though yes, I only build very small images) | 11:47 |
| RP | anyway, like I said, I just personally really don't like it. I know people use it and why which is why it does continue to exist | 11:47 |
| mcfrisk | qschulz: check how much writes your build does.. | 11:47 |
| mcfrisk | i used pcp to monitor CPU, RAM, IO read/write bytes, network bytes | 11:47 |
| RP | qschulz: you might see some speed up if rm_work can trigger before the data makes it out the cache and onto disk | 11:48 |
| RP | if your build isn't io bound, it won't actually matter | 11:48 |
| mcfrisk | there I could see the effect of Linux vm background writes going to real IO, and once disabled running low on fs buffers on RAM also triggering useless writes which rm_work helped to get rid of | 11:48 |
| mcfrisk | it's a good idea to monitor full cache rebuilds to see how developers broke download and sstate caching: nothing should download anything from network if caches full, nothing should get recompiled if sstate cache uptodate and no changes... | 11:50 |
| qschulz | RP: mcfrisk: thanks, will try to remember this the day we need to go for bigger builds (maybe never? only BSP products on Yocto right now) | 11:50 |
| mcfrisk | some of the breakage I saw came from BSPs... | 11:50 |
| qschulz | mcfrisk: I don't get your last sentence | 11:51 |
| mcfrisk | RP: +KERNEL_FEATURES:append = " features/module-signing/force-signing.scc" in meta/recipes-kernel/linux/linux-yocto.inc results in runtime failure "Loading of unsigned module is rejected" on yocto master.. kernel modules are getting stripped of signing data | 11:52 |
| mcfrisk | qschulz: I saw BSP layers breaking download and sstate caching | 11:52 |
| qschulz | mcfrisk: ah yes, a layer is a layer, people can do many kind of crazy things in there :) | 11:54 |
| qschulz | what I meant is as a BSP vendor, I have very little to build right now to test my layer/boards, so no use yet for rm_work | 11:54 |
| mcfrisk | yea, that's good for you, but checking that download and sstate caching isn't broken is a good idea. For downoad caching, debuild without network access with full download cache | 11:56 |
| mcfrisk | /debuild/rebuild/ | 11:56 |
| mcfrisk | for sstate cache test, rebuild with full cache and check that no do_compile tasks got executed | 11:57 |
| RP | mcfrisk: I'm not surprised, I thought there was an open bug around this | 11:59 |
| mcfrisk | would be nice to device a test for this, it's so easy for various layers and recipes and developers to accidently break things | 12:00 |
| *** amitk_ <amitk_!~amit@103.59.74.88> has joined #yocto | 12:03 | |
| *** davidinux <davidinux!~davidinux@host-87-9-203-223.retail.telecomitalia.it> has joined #yocto | 12:04 | |
| *** manuel1985 <manuel1985!~manuel198@mobiledyn-62-240-134-40.mrsn.at> has joined #yocto | 12:09 | |
| RP | mcfrisk: The maze of kernel options does need more tests, one would be very welcome | 12:10 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 12:11 | |
| RP | mcfrisk: we are slowly improving as we notice cases like this, document and add tests | 12:11 |
| *** payam <payam!~Payam@c83-250-236-236.bredband.tele2.se> has joined #yocto | 12:21 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 12:37 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 12:55 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 12:56 | |
| *** mckoan <mckoan!~marco@host-95-229-48-41.business.telecomitalia.it> has quit IRC (Ping timeout: 264 seconds) | 12:56 | |
| *** manuel1985 <manuel1985!~manuel198@mobiledyn-62-240-134-40.mrsn.at> has quit IRC (Ping timeout: 264 seconds) | 13:08 | |
| *** amitk_ <amitk_!~amit@103.59.74.88> has quit IRC (Ping timeout: 265 seconds) | 13:10 | |
| ldericher | how do I define a multiline string in a bitbake recipe? | 13:12 |
| rburton | backslash-escape the newline | 13:12 |
| ldericher | So I want a string like BAZ = "foo\nbar" with a literal newline in between. Can I `BAZ = \[NL]"foo\[NL]bar"` where [NL] is a newline in my bbfile? | 13:18 |
| *** payam <payam!~Payam@c83-250-236-236.bredband.tele2.se> has quit IRC (Remote host closed the connection) | 13:18 | |
| rburton | oh you want a literal newline? i guess \\n might do it | 13:20 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 13:21 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 13:21 | |
| ldericher | rburton, well I think so … maybe it'd be clearer to use an array of lines though. Possible? | 13:22 |
| rburton | no | 13:24 |
| rburton | bitbake variables are strings | 13:24 |
| ldericher | so finally, I'm writing a ROOTFS_POSTPROCESS_COMMAND in my image recipe that generates an /etc/issue file for me. | 13:25 |
| ldericher | in there, I want (multiline) ASCII art, exposed as a bitbake var | 13:25 |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 13:25 | |
| rburton | is it literally just copying the file from the var to the rootfs? | 13:26 |
| rburton | or do you process it in some way | 13:26 |
| ldericher | it is processed - "issue" needs escaped backslashes | 13:27 |
| ldericher | also I want to add some stuff like distro name | 13:27 |
| rburton | if thats all your doing just create a bbappend for base-files and put an issue file alongside | 13:27 |
| rburton | base-files will install it for you | 13:28 |
| rburton | well its a bit more complex than that for this specific file, but a postprocess hook is overcomplicating things | 13:28 |
| ldericher | rburton, well yes but actually no, I need it to pull in the correct ASCII art for the image that's to be built. | 13:29 |
| rburton | so there is processing: you have per-image artwork | 13:29 |
| ldericher | yes | 13:29 |
| rburton | i'd still write a recipe that emits lots of packages for each of your images | 13:30 |
| rburton | easier to write the ascii art in a text editor instead of faffing with it being in a variable | 13:30 |
| ldericher | I'm really rusty tbh, can you help with the "emit lots of packages" part? | 13:31 |
| rburton | something like write a recipe which installs /etc/issue.(name) files for each of your image types and then symlink the right one to /etc/issue | 13:32 |
| *** manuel1985 <manuel1985!~manuel198@mobiledyn-62-240-134-40.mrsn.at> has joined #yocto | 13:33 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 264 seconds) | 13:36 | |
| ldericher | oooh that's clever! | 13:36 |
| *** davidinux <davidinux!~davidinux@host-87-9-203-223.retail.telecomitalia.it> has quit IRC (Quit: WeeChat 3.5) | 13:37 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 13:38 | |
| rburton | if you're feeling really clever, use alternatives to provide /etc/issue and then you just install the right issue-foo package and the symlink is made for you | 13:39 |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Ping timeout: 260 seconds) | 13:43 | |
| *** manuel1985 <manuel1985!~manuel198@mobiledyn-62-240-134-40.mrsn.at> has quit IRC (Ping timeout: 268 seconds) | 13:47 | |
| *** manuel1985 <manuel1985!~manuel198@mobiledyn-62-240-134-40.mrsn.at> has joined #yocto | 13:48 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 13:53 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 13:55 | |
| ldericher | when the image is built, where can I find the resulting sysroot, again? | 13:58 |
| *** davidinux <davidinux!~davidinux@92.118.62.63> has joined #yocto | 14:08 | |
| *** d-fens <d-fens!~d-fens@5.10.7.173> has quit IRC (Ping timeout: 260 seconds) | 14:13 | |
| *** Net147 <Net147!~Net147@user/net147> has quit IRC (Read error: Connection reset by peer) | 14:17 | |
| OnkelUlla | otavio: Hi Otavio! Is there a chance that you perhaps could have a look at https://lists.openembedded.org/g/openembedded-devel/message/99426 ("[meta-java][PATCH] layer.conf: Mark as compatible with langdale")? | 14:20 |
| OnkelUlla | I sent it together with https://lists.openembedded.org/g/openembedded-devel/message/99425 ("[meta-java][PATCH] openjdk-8: refresh patches") some weeks ago and did not get any feedback up to now. | 14:20 |
| *** Net147 <Net147!~Net147@167-179-157-192.a7b39d.syd.nbn.aussiebb.net> has joined #yocto | 14:20 | |
| *** d-fens <d-fens!~d-fens@5.10.7.173> has joined #yocto | 14:39 | |
| *** manuel1985 <manuel1985!~manuel198@mobiledyn-62-240-134-40.mrsn.at> has quit IRC (Remote host closed the connection) | 14:50 | |
| *** mckoan <mckoan!~marco@host-95-229-48-41.business.telecomitalia.it> has joined #yocto | 14:50 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 14:53 | |
| *** zpfvo <zpfvo!~fvo@i59F5CCB0.versanet.de> has quit IRC (Ping timeout: 265 seconds) | 15:01 | |
| *** risca <risca!~quassel@h-155-4-197-151.A980.priv.bahnhof.se> has joined #yocto | 15:14 | |
| *** zpfvo <zpfvo!~fvo@i59F5CCB0.versanet.de> has joined #yocto | 15:15 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Ping timeout: 260 seconds) | 15:15 | |
| d-fens | it seems to be a stupid idea to delete the contents o build\tmp-glibc\deploy\images ... how can i trigger a rebuild of bootfiles and dtb's ? | 15:22 |
| qschulz | d-fens: remove everything in your build/tmp-glibc and rebuild it's the easiest | 15:23 |
| qschulz | otherwise I know rburton has some bitbake magic command somewhere up his sleeve | 15:24 |
| d-fens | thx! | 15:24 |
| ldericher | ROOTFS_POSTPROCESS_COMMAND must be in an image recipe? | 15:24 |
| *** Notgnoshi <Notgnoshi!~quassel@184-83-95-131-dynamic.midco.net> has joined #yocto | 15:25 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 15:27 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection) | 15:27 | |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto | 15:29 | |
| vvn | ldericher: yes. If you want to share some code between image recipes, write a foo.bbclass, add your ROOTFS_POSTPROCESS_COMMAND += "foo;" in there with a foo () { } function and make your images inherit foo | 15:32 |
| vvn | qschulz: btw do you need to remove TOPDIR as well or remove TMPDIR is enough to trigger a "fresh" build? | 15:34 |
| vvn | in other words, is the content of TOPDIR (except TMPDIR) reusable/sharable? | 15:34 |
| *** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 248 seconds) | 15:43 | |
| *** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 15:44 | |
| *** mthenault <mthenault!~mthenault@ip-091-089-130-004.um28.pools.vodafone-ip.de> has joined #yocto | 15:46 | |
| *** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 265 seconds) | 15:48 | |
| *** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 15:48 | |
| rburton | d-fens: just delete tmp | 15:54 |
| rburton | vvn: the cache/ is not relocatable | 15:55 |
| rburton | sstate and downloads are | 15:55 |
| d-fens | rburton did that and it worked, it's actually tmp-glibc , no idea why the output path changed from tmp a few days ago | 15:57 |
| rburton | tmp/ is a pokyism | 15:59 |
| rburton | default is tmp-(libc name) for... reasons | 15:59 |
| *** michaelo[m] <michaelo[m]!~michael-o@2001:470:69fc:105::be7c> has quit IRC (Quit: You have been kicked for being idle) | 16:00 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 16:00 | |
| *** mkorpershoek <mkorpershoek!sid537056@id-537056.uxbridge.irccloud.com> has left #yocto | 16:08 | |
| vvn | rburton: this means that TOPDIR is specific to the build machine, but you can reuse it for other fresh builds as long as you don't move it to another location, am I correct? | 16:11 |
| rburton | vvn: well, you can always share sstate and downloads. tmp and cache just wipe and they'll regenerate. so then all that is left is conf. | 16:14 |
| vvn | and bitbake.lock and bitbake.sock (as well as a daemon log) | 16:15 |
| rburton | the former are specific to a running bitbake and will be deleted once it quits | 16:15 |
| vvn | I should've said the content of TOPDIR, except TMPDIR, DL_DIR and SSTATE_DIR | 16:15 |
| *** d-fens <d-fens!~d-fens@5.10.7.173> has quit IRC (Ping timeout: 260 seconds) | 16:16 | |
| vvn | rburton: bitbake.conf says that PERSISTENT_DIR (${TOPDIR}/cache) "should be shared by all builds" | 16:20 |
| otavio | OnkelUlla: I can look, for sure. Can you send an email so I don't forget? otavio.salvador@ossystems.com.br | 16:20 |
| vvn | So one only needs to wipe TMPDIR for a fresh build I guess, no need to wip cache | 16:20 |
| vvn | wipe* | 16:20 |
| rburton | vvn: we talked about that earlier in the week here. the bitbake parser cache goes into tmp/cache explicitly, and that very much shouldn't be shared | 16:20 |
| rburton | RP: i say bitbake's caches should go into tmp/cache not topdir/cache | 16:21 |
| *** tor <tor!~tor@user/tor> has quit IRC (Remote host closed the connection) | 16:22 | |
| JaMa | rburton: PRSERV is in PERSISTNT_DIR, right? so that needs to stay in topdir like hashserve | 16:25 |
| rburton | yeah | 16:26 |
| rburton | i should be able to put persistant_dir alongside my shared sstate and downloads, right? the parser cache being in there means i can't do that. | 16:26 |
| OnkelUlla | otavio: Thanks, I'll resend them! You've been on CC, but perhaps the address found in meta-java's README (Otavio Salvador <otavio@ossystems.com.br>) is not in active use anymore. | 16:27 |
| otavio | it is the same; just resend. | 16:27 |
| RP | rburton: depends which cache you mean | 16:28 |
| rburton | codeparser.dat? | 16:29 |
| RP | rburton: that is from codeparser rather than recipe parsing. If you had two TMPDIRs, you could share the code parser between them | 16:30 |
| JaMa | RP: was this a NAK? https://lists.openembedded.org/g/bitbake-devel/message/14056 or should I send v2 accepting only '1' as value? | 16:31 |
| rburton | RP: so it could sit in a central location alongside a shared sstate and different builds of different branches wouldn't argue over it? | 16:31 |
| RP | JaMa: Oddly enough I was staring a the export and unexport flags today with the same issue and was thinking about the network flag | 16:31 |
| RP | JaMa: we should probably put a bb.utils.to_boolean() around it (and merge the local patch I have to make bb.utils.to_boolean() handle int values | 16:32 |
| JaMa | it's a bit unfortunate that inheritting icecc.bbclass now enables network everywhere | 16:32 |
| RP | rburton: depends what central location means. It isn't as sharable as sstate/dl_dir but does offer a speed up to builds and is about as safe as the the bb persist data there | 16:33 |
| RP | JaMa: yes :( | 16:33 |
| JaMa | ok, I'll resend it with bb.utils.to_boolean once the local patch is merged, I didn't want to add more than bare-minimum processing as you said earlier that this is in hot path | 16:34 |
| RP | JaMa: I'm worried that should we change the network flag, the export/unexport flags work differently | 16:34 |
| RP | JaMa: If I change export/unexport to match we take a 4% parsing speed hit | 16:34 |
| RP | perhaps I should just stop caring | 16:35 |
| RP | rburton: codeparser basically says "python fragment X has dependencies on functions Y and variables Z" | 16:36 |
| RP | rburton: it is versioned and the version could change depending on the version of bitbake | 16:36 |
| RP | rburton: it isn't as simple as "this is sharable" | 16:36 |
| *** mthenault <mthenault!~mthenault@ip-091-089-130-004.um28.pools.vodafone-ip.de> has quit IRC (Ping timeout: 265 seconds) | 16:37 | |
| JaMa | FWIW: in rare cases I've seen codeparser cache getting corrupted when bitbake was killed in some unfortunate moment | 16:37 |
| *** amitk_ <amitk_!~amit@103.208.71.104> has joined #yocto | 16:39 | |
| RP | JaMa: I'm not entirely surprised since each parser thread writes out a copy of it's cache and then a thread merges them all together in the background | 16:39 |
| RP | JaMa: in theory it should just throw it all away in case of problems and start again | 16:39 |
| JaMa | I think in some rare cases it didn't throw it automatically and I had to delete it, but never found any reproducer and it was very rare (and possibly fixed since then) | 16:42 |
| *** kscherer <kscherer!~kscherer@bras-base-otwaon1146w-grc-21-184-147-79-201.dsl.bell.ca> has joined #yocto | 16:42 | |
| *** olani <olani!~olani@66.159.215.7> has joined #yocto | 16:45 | |
| JPEW | RP: I had an epiphany about how to efficiently transfer the strings, but won't be able to do anything to implement it until next week | 16:54 |
| *** BrziCo <BrziCo!~BrziCo@79.142.183.177> has joined #yocto | 16:55 | |
| RP | JaMa: if you have a broken file sometime I'd be interested to see what it looks like and the error bitbake gives | 16:57 |
| RP | JPEW: any hints on what you're thinking or you're going to keep me in suspense? | 16:58 |
| * RP suspects he will be getting told off by the conference organisers for distracting JPEW soon | 16:58 | |
| BrziCo | Hello everyone, | 17:03 |
| BrziCo | I'm currently learning about Yocto project, and I'm trying to create Linux image for Raspberry Pi 3. I cloned the BSP layer (https://meta-raspberrypi.readthedocs.io) and I added desired variables in local.conf (e.g. ENABLE_UART = "1" ... ) and it works just fine. Now, I'm trying to move those variables away from local.conf to my own layer, so i | 17:03 |
| BrziCo | created my machine (raspberrypi3-my.conf) that just contains this line include conf/machine/raspberrypi3.conf but when I run bitbake i get error saying: "Could not locate BSP definition for raspberrypi3-my/standard and no defconfig was provided". Any help? Thanks :D | 17:03 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 17:07 | |
| RP | BrziCo: the MACHINE value is probably being used as an OVERRIDE in places. MACHINEOVERRIDES =. "raspberrypi3:" might help | 17:07 |
| JaMa | RP: haven't found any in my current TOPDIRs, if I see it again I'll save it (but not doing so many build nowadays, so probability to hit it again is even lower) | 17:07 |
| rburton | BrziCo: it might be better to create a new distro that uses the rpi machine, instead of a whole new machine | 17:08 |
| RP | JaMa: fair enough. Just mentioning what we'd need to try and improve things in case you do run into it :) | 17:08 |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 17:09 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 260 seconds) | 17:11 | |
| *** gho <gho!~gho@i59F5CCB0.versanet.de> has quit IRC (Quit: Leaving.) | 17:12 | |
| *** zpfvo <zpfvo!~fvo@i59F5CCB0.versanet.de> has quit IRC (Quit: Leaving.) | 17:13 | |
| JPEW | RP: getstate returns 2-tuple, first is the list of tuples ((os.getpid() len(cache)), "new string" or frozenset), for every new object added to the cache, the second is the actual dictionary, where the values are replaced with the (os.getpid(), len(cache)) tuple. | 17:16 |
| JPEW | setstate populates the cache with all the new objects seen, then restores the dicts by replacing the tuples via lookup in the cache | 17:17 |
| JPEW | It could even dedup efficiently across multiple worker process | 17:18 |
| JPEW | And neatly, it's all wrapped up in the getstate, setstate, so nothing else needs to know it's happening | 17:19 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 265 seconds) | 17:20 | |
| JPEW | Anyway, the main idea is that the list of new objects makes sure each is only sent once the first time it's seen without needing special cases in the actual value dictionaries | 17:21 |
| RP | JPEW: right, that makes sense. It was along the lines I was thinking but I was just doing to hack the state dictonary :) | 17:25 |
| RP | going | 17:26 |
| *** mckoan is now known as mckoan|away | 17:26 | |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC (Ping timeout: 264 seconds) | 17:36 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 17:46 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 17:47 | |
| *** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto | 17:59 | |
| *** Tokamak_ <Tokamak_!~Tokamak@172.58.227.116> has quit IRC (Ping timeout: 256 seconds) | 18:01 | |
| *** Tokamak <Tokamak!~Tokamak@107.116.82.19> has joined #yocto | 18:01 | |
| RP | do we need to move to #quecto? | 18:01 |
| JaMa | lets discuss trivial builds in #quecto and non-trivial in #quetta to make things simpler :) | 18:03 |
| * JaMa just run out of 2+2TB nvme again | 18:05 | |
| *** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 260 seconds) | 18:09 | |
| *** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 18:10 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 18:13 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Remote host closed the connection) | 18:13 | |
| BrziCo | RP thanks MACHINEOVERRIDES = "raspberrypi3:${MACHINE}" helped | 18:20 |
| *** tokamak[m] <tokamak[m]!~tokamakma@2001:470:69fc:105::c4df> has joined #yocto | 18:36 | |
| *** BrziCo <BrziCo!~BrziCo@79.142.183.177> has quit IRC (Quit: Client closed) | 18:43 | |
| *** Tokamak_ <Tokamak_!~Tokamak@107.116.82.19> has joined #yocto | 18:58 | |
| *** Tokamak <Tokamak!~Tokamak@107.116.82.19> has quit IRC (Ping timeout: 248 seconds) | 19:00 | |
| *** florian_kc <florian_kc!~florian@dynamic-078-048-033-068.78.48.pool.telefonica.de> has joined #yocto | 19:12 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Ping timeout: 260 seconds) | 19:14 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC (Remote host closed the connection) | 19:26 | |
| *** invalidopcode <invalidopcode!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has joined #yocto | 19:28 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto | 19:29 | |
| *** gsalazar_ <gsalazar_!~gsalazar@139.0.166.178.rev.vodafone.pt> has joined #yocto | 19:36 | |
| *** gsalazar <gsalazar!~gsalazar@139.0.166.178.rev.vodafone.pt> has quit IRC (Ping timeout: 264 seconds) | 19:38 | |
| *** amitk_ <amitk_!~amit@103.208.71.104> has quit IRC (Remote host closed the connection) | 19:38 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 19:46 | |
| *** amitk <amitk!~amit@103.208.71.104> has quit IRC (Ping timeout: 268 seconds) | 20:19 | |
| *** florian_kc <florian_kc!~florian@dynamic-078-048-033-068.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 260 seconds) | 20:32 | |
| *** gsalazar_ <gsalazar_!~gsalazar@139.0.166.178.rev.vodafone.pt> has quit IRC (Ping timeout: 265 seconds) | 20:37 | |
| *** Tamis <Tamis!~Tamis@178-147-122-163.haap.nym.cosmote.net> has joined #yocto | 20:40 | |
| *** gsalazar_ <gsalazar_!~gsalazar@isep.wan.ipp.pt> has joined #yocto | 20:52 | |
| *** Tamis17 <Tamis17!~Tamis@5-203-172-125.pat.nym.cosmote.net> has joined #yocto | 21:01 | |
| *** Tamis <Tamis!~Tamis@178-147-122-163.haap.nym.cosmote.net> has quit IRC (Ping timeout: 260 seconds) | 21:02 | |
| *** gsalazar_ <gsalazar_!~gsalazar@isep.wan.ipp.pt> has quit IRC (Remote host closed the connection) | 21:14 | |
| *** gsalazar_ <gsalazar_!~gsalazar@isep.wan.ipp.pt> has joined #yocto | 21:15 | |
| *** jlf` <jlf`!~jlf`@user/jlf> has joined #yocto | 21:24 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 21:41 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 21:42 | |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4503:c400:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection) | 21:46 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 21:54 | |
| *** Tamis17 <Tamis17!~Tamis@5-203-172-125.pat.nym.cosmote.net> has quit IRC (Ping timeout: 260 seconds) | 21:55 | |
| *** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection) | 21:59 | |
| *** gsalazar_ <gsalazar_!~gsalazar@isep.wan.ipp.pt> has quit IRC (Remote host closed the connection) | 22:00 | |
| *** gsalazar_ <gsalazar_!~gsalazar@isep.wan.ipp.pt> has joined #yocto | 22:00 | |
| *** florian_kc <florian_kc!~florian@dynamic-078-048-033-068.78.48.pool.telefonica.de> has joined #yocto | 22:10 | |
| *** Tokamak <Tokamak!~Tokamak@172.58.227.152> has joined #yocto | 22:11 | |
| *** Tokamak_ <Tokamak_!~Tokamak@107.116.82.19> has quit IRC (Ping timeout: 260 seconds) | 22:12 | |
| *** olani <olani!~olani@66.159.215.7> has quit IRC (Ping timeout: 260 seconds) | 22:26 | |
| *** gsalazar_ <gsalazar_!~gsalazar@isep.wan.ipp.pt> has quit IRC (Ping timeout: 265 seconds) | 22:29 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!