*** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC (Remote host closed the connection) | 00:32 | |
*** Tokamak <Tokamak!~Tokamak@107.117.203.210> has quit IRC (Ping timeout: 255 seconds) | 00:33 | |
*** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto | 00:34 | |
override | the filesystem layout that wic creates, I can just dd that onto my emmc?? | 00:37 |
---|---|---|
*** robbawebba <robbawebba!~rob@12.206.203.186> has quit IRC (Quit: WeeChat 3.0.1) | 00:41 | |
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection) | 01:03 | |
*** Tokamak <Tokamak!~Tokamak@107.117.203.177> has joined #yocto | 01:03 | |
*** RobertBerger <RobertBerger!~rber|res@athedsl-4432950.home.otenet.gr> has joined #yocto | 01:32 | |
*** rber|res <rber|res!~rber|res@athedsl-4432950.home.otenet.gr> has quit IRC (Ping timeout: 268 seconds) | 01:34 | |
*** steve__ <steve__!~steve@24.16.44.202> has quit IRC (Ping timeout: 255 seconds) | 01:42 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 01:52 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.) | 02:44 | |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 02:53 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 252 seconds) | 02:55 | |
*** camus1 is now known as camus | 02:55 | |
*** Tokamak <Tokamak!~Tokamak@107.117.203.177> has quit IRC (Ping timeout: 258 seconds) | 02:57 | |
*** Lihis <Lihis!~Lihis@ns3006753.ip-151-80-42.eu> has quit IRC (Quit: Quitting) | 03:27 | |
*** paulg <paulg!~Paul@104-195-159-20.cpe.teksavvy.com> has quit IRC (Ping timeout: 265 seconds) | 03:28 | |
*** Lihis <Lihis!~Lihis@2001:41d0:e:f34::1> has joined #yocto | 03:29 | |
*** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has quit IRC (Ping timeout: 258 seconds) | 03:47 | |
*** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has joined #yocto | 03:48 | |
*** Lihis <Lihis!~Lihis@2001:41d0:e:f34::1> has quit IRC (Ping timeout: 246 seconds) | 04:02 | |
*** Lihis <Lihis!~Lihis@ns3006753.ip-151-80-42.eu> has joined #yocto | 04:03 | |
*** eFfeM <eFfeM!~eFfeM@a97014.upc-a.chello.nl> has joined #yocto | 04:59 | |
*** eFfeM <eFfeM!~eFfeM@a97014.upc-a.chello.nl> has quit IRC (Remote host closed the connection) | 05:01 | |
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Read error: Connection reset by peer) | 05:26 | |
*** ecdhe <ecdhe!~ecdhe@mms-rf-support.com> has joined #yocto | 05:26 | |
*** ant__ <ant__!~ant@host-87-8-132-196.retail.telecomitalia.it> has quit IRC (Ping timeout: 255 seconds) | 05:46 | |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 05:49 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer) | 05:50 | |
*** camus1 is now known as camus | 05:50 | |
*** roussinm <roussinm!~mroussin@184.145.222.193> has quit IRC (Ping timeout: 252 seconds) | 06:20 | |
*** frieder <frieder!~frieder@i59f727aa.versanet.de> has joined #yocto | 06:27 | |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 06:41 | |
*** zyga <zyga!~zyga@31.0.173.147> has joined #yocto | 06:54 | |
*** zpfvo <zpfvo!~fvo@88.130.217.97> has joined #yocto | 06:56 | |
*** Net147 <Net147!~Net147@user/net147> has quit IRC (Ping timeout: 268 seconds) | 07:02 | |
*** Net147 <Net147!~Net147@167-179-157-192.a7b39d.syd.nbn.aussiebb.net> has joined #yocto | 07:03 | |
*** mckoan|away is now known as mckoan | 07:08 | |
mckoan | good morning | 07:08 |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 07:30 | |
*** davidinux <davidinux!~davidinux@217.138.197.52> has quit IRC (Ping timeout: 265 seconds) | 07:30 | |
*** davidinux <davidinux!~davidinux@217.138.197.52> has joined #yocto | 07:31 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…) | 07:51 | |
*** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 07:54 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 255 seconds) | 07:55 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 07:55 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 07:55 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 07:58 | |
*** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has joined #yocto | 08:03 | |
LetoThe2nd | yo dudx | 08:03 |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Remote host closed the connection) | 08:14 | |
*** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto | 08:17 | |
mihai | yo | 08:27 |
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 08:38 | |
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Client closed) | 08:39 | |
*** wing0_ <wing0_!~wing0@2804:431:c7ed:6171:bb13:7508:2998:4a1b> has joined #yocto | 08:46 | |
*** wing0_ <wing0_!~wing0@2804:431:c7ed:6171:bb13:7508:2998:4a1b> has quit IRC (Client Quit) | 08:47 | |
*** wing0 <wing0!~wing0@2804:431:c7ed:6171:bb13:7508:2998:4a1b> has joined #yocto | 08:50 | |
*** wing0 <wing0!~wing0@2804:431:c7ed:6171:bb13:7508:2998:4a1b> has quit IRC (Client Quit) | 08:50 | |
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 08:50 | |
*** wing0 <wing0!~wing0@2804:431:c7ed:6171:bb13:7508:2998:4a1b> has joined #yocto | 08:55 | |
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 258 seconds) | 08:57 | |
*** wing0 <wing0!~wing0@2804:431:c7ed:6171:bb13:7508:2998:4a1b> has quit IRC (Client Quit) | 08:58 | |
*** creich <creich!~creich@p200300f6af354710000000000000039b.dip0.t-ipconnect.de> has quit IRC (Remote host closed the connection) | 09:03 | |
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 09:04 | |
*** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC (Remote host closed the connection) | 09:13 | |
rburton | override: depends on what wic file you used, what your target is, and what the medium is, but that's the intention yes | 09:43 |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 09:52 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer) | 09:53 | |
*** camus1 is now known as camus | 09:53 | |
*** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Read error: Connection reset by peer) | 10:14 | |
*** tnovotny_ <tnovotny_!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 10:14 | |
*** linums <linums!~linums@84.198.214.27> has joined #yocto | 10:17 | |
*** creich <creich!~creich@p200300f6af354710000000000000039b.dip0.t-ipconnect.de> has joined #yocto | 10:18 | |
wyre | do you recommend to do a different recipe for a systemd application? | 10:32 |
wyre | I mean, for a systemd service of an application? | 10:32 |
mckoan | wyre: as the YoctoJester chants "it depends" | 10:36 |
rburton | wyre: in the application recipe would make a lot of sense | 10:39 |
rburton | so you can't have one without the other | 10:39 |
* LetoThe2nd shuffles off into lunch break, humming "ebony and ivory"... | 10:41 | |
* LetoThe2nd ponders throwing something really sharp and pointy rburtons way | 10:41 | |
wyre | also I'm trying to create a recipe for a python module so ... I should install it in /usr/lib/python3.7/site-packages, but could I do this directly? | 10:42 |
rburton | wyre: does the module support distutils/setup.py? | 10:42 |
rburton | is it on pypi already? | 10:42 |
wyre | nope, it's not on pypi | 10:43 |
wyre | and it won't be in there unfortunately | 10:43 |
wyre | it's a local module | 10:43 |
rburton | assuming it's sensible and uses setup.py then just use distutils3.bbclass | 10:46 |
OutBackDingo | anyone knows what branch/release gcc 9 was last in ? dunfell ? | 10:46 |
OutBackDingo | seems its dunfell | 10:48 |
wyre | rburton, could you provide me some example? | 10:58 |
wyre | I mena, I've done the setup.py, how should I use distutils3 ? | 11:04 |
wyre | in the recipe? | 11:04 |
wyre | I mena, I'd appreciate some example to create my recipe | 11:06 |
OutBackDingo | ok, so did something change in guthub ? alot of fetches failing, no master branches, now main ? | 11:11 |
*** dvorkindmitry <dvorkindmitry!~dvorkindm@5.167.98.73> has quit IRC (Ping timeout: 268 seconds) | 11:12 | |
*** dvorkindmitry <dvorkindmitry!~dvorkindm@5.167.98.73> has joined #yocto | 11:13 | |
*** lukma <lukma!~lukma@85-222-111-42.dynamic.chello.pl> has quit IRC (Quit: leaving) | 11:24 | |
*** lukma <lukma!~lukma@85-222-111-42.dynamic.chello.pl> has joined #yocto | 11:25 | |
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto | 11:28 | |
wyre | why it says it cannot find setup.py when it's in the workdir? https://bpa.st/ARSQ rburton | 11:31 |
wyre | setup.py is in the working directory, so ... why it cannot found it? | 11:33 |
rburton | wyre: you didn't set S and you're fetching from git? | 11:36 |
rburton | easier for you to debug than me, that log tells you what S *is*, and you can see what it actually unpacked too, not me | 11:36 |
wyre | rburton, http://ix.io/3tBb that's the recipe | 11:37 |
wyre | the log contains the very same I've just pasted | 11:38 |
wyre | and I can't see there what S is | 11:38 |
rburton | ls tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/python3-dp1642gw-api/1.0-r0/dp1642gw-dev/ <-- that is not what you set as S | 11:38 |
wyre | however, in the recipe I'm setting S as ${WORKDIR} | 11:39 |
rburton | the unpacker is mirroring the local file structure | 11:39 |
rburton | your local files are in a directory so it copies the structure | 11:39 |
rburton | and if your setup.py installs properly then you can just get rid of most of that install_append | 11:40 |
wyre | rburton, apparently the setup.py is working but it generates an .egg file | 11:49 |
wyre | so I cannot see what's actually installing | 11:50 |
* LetoThe2nd bites keyboard | 11:50 | |
LetoThe2nd | must... not... type... pun.... | 11:50 |
*** thekappe <thekappe!~user@198.90.66.177> has quit IRC (Quit: WeeChat 1.9.1) | 11:51 | |
*** woky <woky!~woky@li1651-31.members.linode.com> has quit IRC (Quit: Nothing in this world is hopeless!) | 12:05 | |
*** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto | 12:10 | |
rburton | wyre: a properly written setup.py will install properly anyway, as the class tells it to | 12:14 |
override | Can we only dd a disk image, or can we dd just the rootfs as well? To further elaborate what I'm trying to figure: The disk layout shown here https://github.com/Freescale/meta-freescale/blob/master/wic/imx-imx-boot-bootpart.wks.in, lets say I ive added another blocks of rootfs to it. Any updates to my board's rootfs, Id try to write to this additional rootfs partition I added. Im trying to see if thats | 12:14 |
override | even possible. Can we dd a rootfs (an ext4 file), or does it have to be a complete wic image. If its the latter, then on my emmc would the two partitions look something like this |{imx-boot boot rootfs}| |{imx-boot boot rootfs}|? | 12:14 |
rburton | with ext4 in IMAGE_FSTYPES you get just a bare ext4 if that's what you want | 12:14 |
rburton | you could manually dd that into the right partition | 12:15 |
*** zyga_ <zyga_!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 12:17 | |
dv_ | I've seen command lines that try to set the build's nice level by calling "nice bitbake", and other setups that use BB_TASK_NICE_LEVEL in local.conf instead | 12:18 |
dv_ | it is my impression that the second approach is better, but I don't know the details | 12:19 |
dv_ | anybody knows more? | 12:19 |
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Ping timeout: 265 seconds) | 12:20 | |
*** zyga <zyga!~zyga@31.0.173.147> has quit IRC (Ping timeout: 256 seconds) | 12:21 | |
override | rburton: that's partly what's confusing me right now. I was given the impression that complete disk images are wis. when I set IMAGE_FSTYPES to ext4 id get a complete disk image in ext4 format some how? It would include everything {imx-boot boot rootfs}, and not just the rootfs? why's ext4 usually just associated with root file systems then? why can IMAGE_FSTYPES be set to wic, when wic is considered to | 12:21 |
override | be a disk image? | 12:21 |
*** zyga_ <zyga_!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has quit IRC (Ping timeout: 268 seconds) | 12:22 | |
rburton | if you set image fstypes to ext4 then the image you ask for is put in an ext4 file system. a wic takes the root filesystem (when its just a directory) and makes partition tables, pulls in other files such as bootloaders, etc. | 12:22 |
rburton | a ext4 isn't a disk image, its just a partition | 12:22 |
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 12:23 | |
*** woky <woky!~woky@li1651-31.members.linode.com> has joined #yocto | 12:23 | |
override | rburton: so let me ask you this why are we able to set IMAGE_FSTYPES to wic or ext4 when only ext4 is an file system type and not wic? | 12:26 |
rburton | wic is a tool that takes instruction (the wks file) to build a disk image from root filesystems | 12:27 |
rburton | the main root filesystem being the image you built in the first place | 12:27 |
JPEW | override: you have 2 separate cases: first you need to create the initial flash image with two partitions, for which wic is an option. Second, you need to update one of the partitions, which you can do by dd'ing the ext4 image into the partition | 12:30 |
override | rburton: feel free to link me some stackoverflow or something if you feel like im just going around in circles. Would it be correct to say that when we set IMAGE_FSTYPE to ext4 we wont really get a disk image at all? we are just getting a partition with the file system in it? | 12:31 |
override | JPEW: Im losing my mind here just understanding why is that we call a partition with the ext4 rootfs an image? like you just said the "ext4 image into the partition", wouldnt that just be the rootfs and not the entire disk image??? | 12:33 |
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection) | 12:34 | |
rburton | yes, IMAGE_FSTYPES never promised to be a "disk image" | 12:34 |
rburton | input is an image, which is a filesystem tree on disk. output is... something. | 12:34 |
rburton | set IMAGE_FSTTYPES to tar.gz and you get a tarball | 12:34 |
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Ping timeout: 255 seconds) | 12:35 | |
rburton | ext4 and you get a ext4 file system on disk which contains that tree | 12:35 |
rburton | wic will invoke the wic tool which uses the kickstart file you specify to do further operations, like making a partition tables, pulling in a bootloader, etc | 12:35 |
rburton | the problem is that 'image' is a somewhat overloaded term | 12:36 |
rburton | a full disk image includes the partition table, which obviously isn't part of an ext4 | 12:37 |
override | thanks for patiently explaining me all this, think I get it now. | 12:38 |
rburton | basically, do_image is input: directory tree as defined by the image recipe, output: whatever you tell it in IMAGE_FSTYPES | 12:39 |
rburton | you can do anything in an image fstype: ext4.md5 will write a md5 checksum file for your ext4 | 12:39 |
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto | 12:40 | |
override | Im also trying to understand where exactly the partion tables at? if the wks were to look like this https://github.com/Freescale/meta-freescale/blob/master/wic/imx-imx-boot-bootpart.wks.in | 12:40 |
rburton | --ptable msdos says to create a classic doc partition table | 12:42 |
rburton | anoyingly thats not in the docs | 12:43 |
override | im guessing its a thing to have no partition table at all? I dont see any --ptable msdos in the wks in looking at. Ive definitely come across that term in my bed time reading on file systems, wic, and all things related.. | 12:45 |
override | maybe --no-table means no partition table? | 12:46 |
rburton | yeah | 12:46 |
override | is the partition table usually defined in the u-boot partition? | 12:46 |
rburton | how can the partition table be defined inside a partition? :) | 12:48 |
rburton | i believe what that imx one is doing is putting the uboot at the beginning of the disk, then a partition table and the partitions | 12:48 |
override | what do you even call that contraption that has the partion table | 12:50 |
override | if its not a partition | 12:50 |
rburton | its just a bit of the disk | 12:50 |
override | rburton: thanks youve been immensely helpful this morning | 12:51 |
override | JPEW: so I didnt have my logs turned on till this morning, and you prolly told me this before, but can you link me to some wks that creates an initial flash image with two partitions? | 12:52 |
rburton | no idea if its the same board but https://www.nxp.com/docs/en/user-guide/IMX_LINUX_USERS_GUIDE.pdf page 14 documents the disk layout the imx is after | 12:53 |
JPEW | override: I don't have an example of that, sorry | 12:53 |
override | we would call those two partions rootfs im thinking? | 12:53 |
override | swap out the rootfs and youd get all the new python modules and stuff? | 12:54 |
JPEW | override: I think so. If you play around with the wks file for a while I think you can get it figured out | 12:54 |
override | I just wana get my ducks in a row before I start playing around. With the chip shortage going on my entire company's only got a handful of these eval kits from toradex. If I brick it, I wont hear the end of it. | 12:55 |
JPEW | override: Will it boot from an SD card? | 12:57 |
override | for now I could have it boot from an sd card even | 12:57 |
override | for like a POC thing | 12:57 |
JPEW | override: That's what I would do until you have the bootloader working | 12:57 |
override | eventually, i think what I want to do is set eveything up on sd card then dd it to the eMMC on the board | 12:58 |
JPEW | override: Yep, that's what we do on our factory assembly line | 12:58 |
qschulz | override: I believe most iMX SoCs have a USB boot mode via USB OTG and the uuu tool when there's nothing on any boot storage media | 12:58 |
qschulz | I've seen that on i.mx6, 7 and 8 | 12:58 |
qschulz | and since it boots via something uploaded to volatile memory, no risk of bricking it | 12:59 |
*** _franck_ <_franck_!~fjullien@70.5.9.93.rev.sfr.net> has joined #yocto | 12:59 | |
angolini | I don't think you will get to brick a toradex board only by copying images to the emmc or sdcard. And yes, uuu is always an alternative | 13:00 |
override | yeah, ive used the uuu. the uuu thing was what got me doing this a/b scheme for updating stuff to beging with (I will use it later to for in field updates and all) the uuu just doesnt work on macs, so Im doing this now.. | 13:01 |
override | but yeah, its good to know I wont brick anything | 13:01 |
angolini | I don't know which toradex board you're using, but probably it can be used with uuu | 13:01 |
override | im using the verdin, so yeah im familiar with uuu and all | 13:01 |
angolini | we used to have a sdcard image type on meta-freescale... I mean, on the past | 13:02 |
angolini | maybe this is something you want to play with | 13:02 |
angolini | it was a bbclass | 13:02 |
override | you got a link for its wks? I can checkout the meta-freescale repo too | 13:03 |
override | Thanks for the help guys. I better take the plunge now and just start trying out different wks files i guess | 13:04 |
_franck_ | hi, I'm using "devtool modify" to work on a project. I can build the recipe with "devtool build $MYPROJECT". However, when I build my image, it seems like it uses the other recipe (the original one, not in /workspace) and do_populate_lic crashes | 13:04 |
_franck_ | do I miss a step ? | 13:04 |
override | _franck_ do a bitbake reset <recipe> on the one you dont want no more? | 13:05 |
_franck_ | it will reset the one not in ./workspace ? | 13:05 |
override | should reset whereever the recipe you give it is at I think?! | 13:06 |
_franck_ | is "bitbake reset" a thing ? | 13:07 |
override | think its devtool reset | 13:11 |
override | and not bitbake, sorry. | 13:11 |
qschulz | angolini: sdcard images were replaced by wic in most cases IIRRC | 13:11 |
qschulz | meta-raspberrypi still hasn't migrated though: https://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/classes/sdcard_image-rpi.bbclass | 13:13 |
qschulz | _franck_: look at the layer priority of the layer holding the original recipe and devtool's | 13:16 |
qschulz | bitbake-layers show-layers or something like that should give you the info you want | 13:16 |
_franck_ | qschulz: sounds good, let me see | 13:17 |
_franck_ | workspace is at the very end of the list | 13:18 |
_franck_ | nedd to find how to change that | 13:18 |
qschulz | _franck_: it does not matter much, the layer priority (it's a variable in layer.conf) matters first | 13:18 |
qschulz | then among layers of the same priority, the order in which they are listed in BBLAYERS in bblayers.conf matters | 13:19 |
_franck_ | ah yes, the number at the end of each lines. workspace = 99 | 13:19 |
qschulz | then it should have priority | 13:21 |
qschulz | I think youmight find interesting log if you do bitbake -DDD <recipe> | 13:22 |
qschulz | and then check the reasons why a recipe was taken and not the other | 13:22 |
qschulz | but it seems like something broken in your layers/devtool becauyse devtool modify basically just creates a bbappend for the original recipe | 13:22 |
_franck_ | ok thanks you, I'll dig this up and come back | 13:23 |
qschulz | so except if the bbappend is ignored for some reason, or its content overriden from another bbappend (which is unlikely because its priority is 99, probably the highest of all yours) | 13:23 |
qschulz | I don't see why it wouldn't be used | 13:23 |
qschulz | can you tell us exactly what you're seeing and what makes you think bitbake isn' | 13:24 |
qschulz | t using the devtool'ed recipe? | 13:24 |
_franck_ | I'll try with -DDD | 13:24 |
*** paulg <paulg!~Paul@104-195-159-20.cpe.teksavvy.com> has joined #yocto | 13:27 | |
_franck_ | it parses the main bb file -> OK, it appends the .bbappend file -> OK then it does do_populate_lic from the build dir, from a directory that doesn't exist: WARNING: kernel-module-esp32sdio-0.1-r0 do_populate_lic: Could not copy license file ..../kernel-module-esp32sdio/0.1-r0/git/.... | 13:35 |
_franck_ | I don't have this git directory | 13:35 |
angolini | yes, @qschulz, a long time ago | 13:40 |
smurray | RP JPEW: I need a bigger build machine, oom killer kicked in overnight when I tried generating load with oe-selftest -j 4 ;) | 13:46 |
*** rcw <rcw!~rcwoolley@45.72.203.103> has joined #yocto | 13:47 | |
paulbarker | smurray: That's exactly what happened to me. On my machine running oe-selftest with parallelism munched through 64GB RAM, 8GB swap and then died | 13:51 |
*** Tokamak <Tokamak!~Tokamak@mobile-166-170-32-150.mycingular.net> has joined #yocto | 13:52 | |
smurray | paulbarker: it looks like I have enough swap to get through with -j 2, but it takes quite a while | 13:55 |
*** roussinm <roussinm!~mroussin@184.145.222.193> has joined #yocto | 13:59 | |
*** Tokamak <Tokamak!~Tokamak@mobile-166-170-32-150.mycingular.net> has quit IRC (Read error: Connection reset by peer) | 13:59 | |
*** Tokamak <Tokamak!~Tokamak@107.117.203.18> has joined #yocto | 14:11 | |
*** ecdhe <ecdhe!~ecdhe@mms-rf-support.com> has quit IRC (Ping timeout: 258 seconds) | 14:13 | |
*** ecdhe <ecdhe!~ecdhe@mms-rf-support.com> has joined #yocto | 14:15 | |
paulg | did the oom killer identify something with an unreasonable RSS, or did it do the usual circular firing squad thing? | 14:17 |
* paulg has no idea what lives inside oe-selftest. | 14:17 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 14:19 | |
*** zyga <zyga!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 14:19 | |
paulg | speaking of parallel - can we revert meta-yocto f83319541 ?? Hiding the parallel options in the extended sample means they aren't copied to the autogenerated default (as commented out) local.conf | 14:32 |
paulg | And then when starting with a new build or project, one has to go hunting for them to ensure one has the names correct vs. simply just uncommenting them. | 14:32 |
paulg | I can't imagine I'm the only one who would rather manually set parallelism values fairly regularly. | 14:34 |
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 14:35 | |
fray | I don't screw with them often, but honestly it's always a pain when I'm on a shared machine and need to look up the right variables to set.. I'd love to have them back in the same file, but shorten the explanation leaving the default value in the bitbake.conf | 14:36 |
fray | (yes I know they're in the sample.extended, but nobody ever looks there because that file doesn't end up in the build directory like local.conf does) | 14:37 |
paulg | **exactly** | 14:37 |
paulg | the referenced commit moved them from the sample to sample.extended | 14:37 |
Xagen | when a build is started with bitbake, which mechanism is used to determine which packages are already built that it can pull from for dependencies? | 14:37 |
fray | (there is a third setting which was never in the documented references to control the paralleization of the parsing as well. I also need to look that one up in bitbake) | 14:37 |
paulg | and I don't want to look at sample.extended since I know it isn't used by default and worry it may contain bitrot. | 14:38 |
fray | on a tangently related topic, I've been fighting people using rm_work on shared machines recently and the disk I/O is REALLY bad with a ton of people trying to rm at the same time across teh shared disks.. | 14:39 |
paulg | whee, I can only imagine. | 14:40 |
fray | I'm wondering of do_rm_work[number_threads] = "1" (or some similar small number) might actually speed up disk I/O for everyone and real-world times.. | 14:40 |
fray | hadn't considered trying that until just now | 14:40 |
paulg | do_rm_work[12 hours from now] | 14:41 |
fray | unfortunately that won't work in my situation.. :P These shared machines have criminally small amounts of storage on them shared between 20 and 30 users.. | 14:41 |
paulg | doesn't help if you have people from all time zones on the machine either. | 14:41 |
fray | timed a build yesterday, and 95% of the execution time was spent on sstate-cache extraction and rm_work.. | 14:42 |
paulg | that had to be blindingly fast. :-( | 14:42 |
fray | 25 minutes (real-clock) time for equivalent for bitbake core-image-minimal when most of sstate-cache was used.. | 14:43 |
fray | (note the 'most' not all) | 14:43 |
fray | listed 'system time' as 95 seconds.. | 14:43 |
wyre | rburton, the setup.py works as expected, however I'm still having the same issue with bitbake, it cannot open the file | 14:47 |
rburton | wyre: because your S isn't where the files are unpacking | 14:47 |
rburton | the fetcher is mirroring the directory structure, so your setup.py is not in WORKDIR, but a subdirectory of it | 14:48 |
wyre | rburton, so should I set S to the directory containing setup.py? or force the setup.py to be in the working directory? | 14:51 |
rburton | S=${WORKDIR}/whateverthatdirectorywascalled | 14:51 |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 14:57 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 252 seconds) | 14:59 | |
*** camus1 is now known as camus | 14:59 | |
*** Ad0 <Ad0!~Ad0@93.124.245.194> has joined #yocto | 15:00 | |
wyre | rburton, now I have problems with another file install: cannot stat "'dp1642gw_dev/api_dp1642gw.py': No such file or directory" | 15:05 |
rburton | get your setup.py installing on its own, and drop all that | 15:05 |
rburton | thats most likely because you just changed S and now your relative paths are all wrong | 15:06 |
wyre | rburton, well, I'd like to put these scripts in /usr/bin | 15:06 |
wyre | dp1642gw_api.py is in the same folder than setup.py | 15:06 |
rburton | https://docs.python.org/3/distutils/setupscript.html#installing-scripts <-- how to install stuff to /usr/bin with setup.py | 15:07 |
wyre | oh, I see can be because the install statements | 15:07 |
wyre | they have still the folder | 15:07 |
*** Tokamak <Tokamak!~Tokamak@107.117.203.18> has quit IRC (Quit: Textual IRC Client: www.textualapp.com) | 15:13 | |
*** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto | 15:15 | |
wyre | rburton, now I'm having problems with the systemd services, https://bpa.st/VAOQ again the problem about "files were installed but not shipped in any package" | 15:15 |
wyre | oh, I need to set FILES 🤔 | 15:16 |
*** tnovotny_ <tnovotny_!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving) | 15:17 | |
rburton | inherit systemd should do that? | 15:18 |
*** Tokamak <Tokamak!~Tokamak@107.117.203.18> has joined #yocto | 15:19 | |
wyre | rburton, https://wiki.koansoftware.com/index.php/Add_a_systemd_service_file_into_a_Yocto_image | 15:19 |
wyre | here is being done explicitly ... 🤔 | 15:19 |
mckoan | rburton: \o/ | 15:24 |
rburton | wyre: well, many recipes in oe-core don't | 15:25 |
*** rcw <rcw!~rcwoolley@45.72.203.103> has quit IRC (Read error: Connection reset by peer) | 15:28 | |
*** rcw <rcw!~rcwoolley@45.72.203.103> has joined #yocto | 15:29 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Remote host closed the connection) | 16:01 | |
*** zpfvo <zpfvo!~fvo@88.130.217.97> has quit IRC (Remote host closed the connection) | 16:04 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 16:21 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 16:22 | |
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 16:23 | |
*** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has quit IRC (Ping timeout: 252 seconds) | 16:25 | |
*** vd is now known as v2d | 16:28 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Quit: Leaving) | 16:31 | |
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto | 16:33 | |
*** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has joined #yocto | 16:45 | |
*** mckoan is now known as mckoan|away | 16:51 | |
*** steve__ <steve__!~steve@24.16.44.202> has joined #yocto | 17:00 | |
*** Tokamak <Tokamak!~Tokamak@107.117.203.18> has quit IRC (Ping timeout: 255 seconds) | 17:08 | |
*** Tokamak <Tokamak!~Tokamak@107.117.203.82> has joined #yocto | 17:15 | |
*** linums <linums!~linums@84.198.214.27> has quit IRC (Quit: Client closed) | 17:24 | |
*** v2d <v2d!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Client closed) | 17:28 | |
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 17:30 | |
Ad0 | I run dunfell. I completely forgot how I can patch the kernel with bitbake | 17:37 |
Ad0 | I need to reintroduce a kernel function that was removed in a later kernel heh | 17:37 |
*** wing0 <wing0!~wing0@2804:431:c7ed:6171:bb13:7508:2998:4a1b> has joined #yocto | 17:38 | |
Ad0 | "2.4. Using devtool to Patch the Kernel" right? | 17:41 |
*** ncaidin_lf <ncaidin_lf!~ncaidin_l@2605:380:53:794::83> has joined #yocto | 17:42 | |
*** ncaidin_lf <ncaidin_lf!~ncaidin_l@2605:380:53:794::83> has quit IRC (Client Quit) | 17:43 | |
*** frieder <frieder!~frieder@i59f727aa.versanet.de> has quit IRC (Read error: Connection reset by peer) | 17:48 | |
*** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC (Ping timeout: 268 seconds) | 18:01 | |
*** whuang0389 <whuang0389!~whuang038@2607:9880:2d78:22:a043:ef83:5025:ad7c> has joined #yocto | 18:01 | |
*** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 18:02 | |
whuang0389 | so why does Yocto do this? My image builds fine incrementally. When I delete my cache (tmp sstate-cache and deploy), do a full rebuilding (minus the download), the build fails on some recipes | 18:04 |
override | whats the difference between a .wic.gz and wic.bmap? which should I be writing to a sdcard. Can someone also please suggest a dd command for writing to an sdcard? | 18:08 |
kergoth | override: the .bmap is just information for bmaptool to use when writing .wic or .wic.gz or .wic.bz2. | 18:08 |
kergoth | override: you need both | 18:08 |
kergoth | bmaptool is the best way, but dd will do, in which case you woudln't need the .bmap | 18:09 |
rfs613 | whuang0389: by "incrementally" do you mean running bitbake again? If nothing changed, the previous build (from sstate) will be used, it won't rebuild from scratch. | 18:09 |
whuang0389 | incrementally meaning yes, using sstatecache. I would add new recipes to the build and rebuild the image with previous cache. Just now I deleted my cache, tmp, and deploy folder to do a full rebuild and it fails =/ | 18:10 |
override | the .wks that is shown under deploy, is that the one that gets used or something? I didnt put it there, but I somehow see a copy | 18:11 |
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Read error: Connection reset by peer) | 18:11 | |
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto | 18:11 | |
rburton | override: bmaptool optimises writing images which typically have a lot of empty space. the bmap file says where the holes are, and bmaptool just writes the actual content. When you have a 4GB image with 3.8GB of empty space, that makes a huge difference | 18:13 |
rfs613 | whuang0389: okay, i see, so the issue is that your incremental builds are not building everything. So you either have some broken/incompatible recipes, or there are dependencies which are not explicit (so it works when you add one at a time, but not when you ask bitbake to build everything from scratch) | 18:13 |
override | rburton: ok cool. and whats the deal with the .wks under deploy. is that suppose to mean something? | 18:14 |
override | is that bitbakes way of saying what got used for making the .wic image? | 18:14 |
JPEW | override: ^^ correct | 18:15 |
override | cool and this bmptool should come with yocto like those oe-utils or no? | 18:15 |
whuang0389 | yea =/ so is it proper to wipe the cache each time we add a new recipe? | 18:15 |
JPEW | override: It's not an OE tool... you can usually install it from your host distro | 18:16 |
JPEW | override: e.g. http://manpages.ubuntu.com/manpages/focal/man1/bmaptool.1.html | 18:16 |
kergoth | override: .wks is a file used to tell wic how to construct the image. the image build process may well write it to deploy for informational purposes, but its not needed for deployment | 18:18 |
rfs613 | whuang0389: it seems like overkill to me, but I guess it depends where the recipes are coming from. My setup is fairly static, not adding layers or recipes very much, so I don't really notice any problems. | 18:18 |
kergoth | OT, but I had a python task that refused to output anything at all but was erroring, so used https://gist.github.com/kergoth/3f0b24517194d4dd805028dd400bdd04 to inject python function call tracing into the task | 18:18 |
kergoth | proved to be useful in the end | 18:18 |
override | kergoth: for some reason my new .wks isnt getting picked up, or atleast in deploy i keep seeing the old one. do i need to run clean or something? | 18:20 |
kergoth | if WKS_FILE is correct ( run bitbake -e yourimage | grep WKS_FILE=), then it used the right one | 18:20 |
*** wing0 <wing0!~wing0@2804:431:c7ed:6171:bb13:7508:2998:4a1b> has quit IRC (Quit: WeeChat 3.1) | 18:28 | |
*** wing0 <wing0!~wing0@2804:431:c7ed:6171:bb13:7508:2998:4a1b> has joined #yocto | 18:29 | |
override | can I do a lsblk or something on a .wic disk image before writing it to my board? | 18:32 |
override | JPEW: know some command that'll make uboot boot from the wic image from the sd card (when there is already an image loaded on the board at first bootup) | 18:37 |
whuang0389 | https://imxdev.gitlab.io/tutorial/How_to_inspect_OpenEmbedded_kickstart_wic_files/ | 18:38 |
whuang0389 | i think i used that before | 18:38 |
whuang0389 | to inspect contents | 18:38 |
Ad0 | hm https://github.com/agherzan/meta-raspberrypi/issues/794 | 18:38 |
JPEW | override: Not off the top of my head | 18:40 |
override | where would be a good place to look, something thatll set the uboot environment vars to reboot from sd-card | 18:42 |
whuang0389 | boot_targets? (not sure | 18:43 |
*** RobertBerger <RobertBerger!~rber|res@athedsl-4432950.home.otenet.gr> has quit IRC (Read error: Connection reset by peer) | 18:43 | |
rfs613 | override: typically you would use somethign like "fatload mmc 0:1 $loadaddr filename" | 18:44 |
*** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has joined #yocto | 18:45 | |
rfs613 | this is assuming your SD card is using FAT/VFAT formattting... which in turn depends on how the wic.bz2 was constructed. | 18:45 |
override | let me go check what the wks says for formatting | 18:46 |
rfs613 | a common setup is 1st partition is VFAT and contains kernel + devicetree, and possibly a ramdisk. | 18:46 |
override | bootimg-patition does seem to have vfat | 18:46 |
override | the rootfs is in ext4 | 18:46 |
rfs613 | right, so the ext4 is probably the 2nd partition in that case | 18:47 |
override | rfs613: this is what im trying to go for - https://pastebin.ubuntu.com/p/VhHYHBQ95p/ | 18:48 |
rfs613 | override: okay, looks like you've gone one additional partition at the start, for u-boot. So shift the numbers I said by one. | 18:49 |
override | hmm ill checkout that fatload command. trying to see that 0:1 is for | 18:50 |
rfs613 | in your case it will be 0:2.. the first is device number (0 based) and the second is partition (1 based). | 18:51 |
rfs613 | you can also use "fatls mmc 0:2" from u-boot prompt, you should see the contents of your "/boot" partition. | 18:52 |
override | very cool. thanks | 18:52 |
*** Guest26 <Guest26!~Guest26@64.222.164.134> has joined #yocto | 19:03 | |
*** zyga_ <zyga_!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 19:12 | |
*** ant__ <ant__!~ant@host-87-8-132-196.retail.telecomitalia.it> has joined #yocto | 19:13 | |
*** zyga <zyga!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has quit IRC (Ping timeout: 252 seconds) | 19:15 | |
kergoth | override: how to boot your device from sd depends on how the board boots, in some cases there's a multi-level uboot setup, in others it's a dip switch, etc. check your board documentation | 19:24 |
override | i forgot, how can i explicty declare what wks to use. and where was I putting that in? distro.conf or machine.conf? | 19:25 |
*** dev1990 <dev1990!~dev@dynamic-78-8-14-249.ssp.dialog.net.pl> has quit IRC (Remote host closed the connection) | 19:30 | |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 19:30 | |
*** dev1990 <dev1990!~dev@dynamic-78-8-14-249.ssp.dialog.net.pl> has joined #yocto | 19:31 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 258 seconds) | 19:32 | |
*** camus1 is now known as camus | 19:32 | |
Guest26 | I added gles2 to IMAGE_INSTALL_append in my local.conf file but when I build I get ERROR: nothing provides "gles2" I guess I have to add something else? | 19:42 |
whuang0389 | usually the graphic stuff is provided by vendor.. no? | 19:44 |
override | kergoth: ill get to the board boot scheme in a bit, can you rmind me where and how I can explicity define what .wks to use? | 19:47 |
*** steve__ <steve__!~steve@24.16.44.202> has quit IRC (Ping timeout: 252 seconds) | 19:47 | |
Guest26 | I'm using meta-qt I thought it would be in that? I'm new to yocto. I also added PACKAGECONFIG+="gles2" in my new recipies-qt/qt5/qtbase_git.bbappend file | 19:47 |
LetoThe2nd | Guest26: i don't think there's a package for that, maybe you want virtual/gles2 or something like that? (just guessing, no graphics guy) | 19:47 |
LetoThe2nd | i'd expect it to be indirectly provided by mesa | 19:48 |
override | kergoth: I made changes to my default one, but im trying to explicity name a wks in my image recipe or something. just so that everything stays in the meta i got access to | 19:49 |
Guest26 | Oh mesa, I'll see it that is turned on. | 19:49 |
whuang0389 | you should probably do bitbake -vn virtual/gles2 (i think it's that command) | 19:51 |
LetoThe2nd | Guest26: don't randomly try and install stuff. 1) IMAGE_INSTALL doesn't belong into local.conf. 2) try to understand what you need, and where you get it. if in doubt, look at demo images/distros by your vendor. | 19:51 |
*** florian <florian!~florian@dynamic-093-131-064-163.93.131.pool.telefonica.de> has joined #yocto | 19:53 | |
override | JPEW: I forgot what var lets you explictly defien the name for a .wks file. remeber you telling me once, but ofcourse my logging wasnt on then... | 19:55 |
override | not sure if https://docs.yoctoproject.org/ref-manual/kickstart.html talks about .wks name variable | 19:56 |
JPEW | override: WKS_FILE | 19:57 |
override | thanks, and I should be defining that in image recipe? | 19:58 |
Guest26 | LetoThe2nd: Yeah I'm working on a project someone who left here a year ago setup and all the bitbake stuff runs from Cmake. I am kinda hacking around, we are using a Kontron board but NXP bsp. | 19:59 |
JPEW | usually in machine.conf | 19:59 |
override | ok cool. thanks | 20:00 |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 258 seconds) | 20:00 | |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 20:01 | |
LetoThe2nd | Guest26: unfortunately thats a classic story "i just inherited and am trying to beat it into shape". start small. put the target aside. learn the basics of distro vs. image vs. machine. create a layer, create an image, create a handful of testing recipes. then come back to the original task. | 20:01 |
*** camus1 is now known as camus | 20:03 | |
Guest26 | LetoThe2nd: Thanks, good advice, I should have found this IRC channel 2 weeks ago! | 20:06 |
*** whuang0389 <whuang0389!~whuang038@2607:9880:2d78:22:a043:ef83:5025:ad7c> has quit IRC (Quit: Client closed) | 20:06 | |
*** hpsy <hpsy!~hpsy@85.203.15.24> has joined #yocto | 20:07 | |
LetoThe2nd | Guest26: i'd suggest to find yourself a drink and bingewatch https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj | 20:07 |
*** Guest26 <Guest26!~Guest26@64.222.164.134> has quit IRC (Quit: Client closed) | 20:10 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 20:11 | |
*** Tokamak <Tokamak!~Tokamak@107.117.203.82> has quit IRC (Ping timeout: 252 seconds) | 20:12 | |
*** Tokamak <Tokamak!~Tokamak@107.117.203.82> has joined #yocto | 20:16 | |
*** Guest26 <Guest26!~Guest26@64.222.164.134> has joined #yocto | 20:25 | |
*** amitk <amitk!~amit@103.208.69.73> has quit IRC (Ping timeout: 252 seconds) | 20:34 | |
*** steve__ <steve__!~steve@24.16.44.202> has joined #yocto | 20:41 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 20:41 | |
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Client closed) | 20:48 | |
*** yannd <yannd!~yann@88.120.44.86> has joined #yocto | 21:05 | |
*** Ad0 <Ad0!~Ad0@93.124.245.194> has quit IRC (Ping timeout: 255 seconds) | 21:13 | |
*** dev1990 <dev1990!~dev@dynamic-78-8-14-249.ssp.dialog.net.pl> has quit IRC (Quit: Konversation terminated!) | 21:18 | |
*** Ad0 <Ad0!~Ad0@93.124.245.194> has joined #yocto | 21:18 | |
*** dvorkindmitry <dvorkindmitry!~dvorkindm@5.167.98.73> has quit IRC (Remote host closed the connection) | 21:30 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 256 seconds) | 21:30 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 21:31 | |
*** wing0 <wing0!~wing0@2804:431:c7ed:6171:bb13:7508:2998:4a1b> has quit IRC (Quit: WeeChat 3.1) | 21:32 | |
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 21:49 | |
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection) | 22:04 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 252 seconds) | 22:06 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 22:06 | |
*** hpsy <hpsy!~hpsy@85.203.15.24> has quit IRC (Ping timeout: 258 seconds) | 22:09 | |
*** ecdhe <ecdhe!~ecdhe@mms-rf-support.com> has quit IRC (Read error: Connection reset by peer) | 22:13 | |
*** ecdhe <ecdhe!~ecdhe@mms-rf-support.com> has joined #yocto | 22:14 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.) | 22:18 | |
*** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 22:22 | |
*** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has quit IRC (Ping timeout: 272 seconds) | 22:24 | |
*** steve__ <steve__!~steve@24.16.44.202> has quit IRC (Ping timeout: 258 seconds) | 22:28 | |
*** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has joined #yocto | 22:29 | |
*** jsandman <jsandman!~jsandman@95.179.203.88> has quit IRC (Quit: Ping timeout (120 seconds)) | 23:06 | |
*** jsandman <jsandman!~jsandman@95.179.203.88> has joined #yocto | 23:07 | |
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 23:07 | |
*** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Quit: Leaving) | 23:14 | |
*** nerdboy <nerdboy!~nerdboy@47.143.129.253> has joined #yocto | 23:15 | |
*** Tokamak <Tokamak!~Tokamak@107.117.203.82> has quit IRC (Ping timeout: 255 seconds) | 23:19 | |
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto | 23:23 | |
*** florian <florian!~florian@dynamic-093-131-064-163.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 23:42 | |
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection) | 23:44 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 23:50 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!