| *** oberstet <oberstet!~oberstet@213.170.219.39> has quit IRC | 00:11 | |
| *** imcleod <imcleod!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has quit IRC | 00:13 | |
| *** ahadi <ahadi!~ahadi@i59F44F3B.versanet.de> has quit IRC | 00:26 | |
| *** ahadi <ahadi!~ahadi@i59F44F3B.versanet.de> has joined #yocto | 00:26 | |
| *** Minjae_Kim <Minjae_Kim!742ab977@gateway/web/cgi-irc/kiwiirc.com/ip.116.42.185.119> has joined #yocto | 00:35 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 00:46 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 00:47 | |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 00:47 | |
| *** dvhart <dvhart!~dvhart@50.39.132.186> has quit IRC | 00:58 | |
| *** dreyna__ <dreyna__!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has joined #yocto | 00:59 | |
| *** dreyna_ <dreyna_!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has quit IRC | 01:03 | |
| *** imcleod <imcleod!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has joined #yocto | 01:16 | |
| linums | Hi guys | 01:23 |
|---|---|---|
| linums | Can you help me how to rebuild after a distro feature addition? | 01:23 |
| linums | Is there any way not to rebuild everything? | 01:23 |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 01:36 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 01:37 | |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 01:44 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 01:44 | |
| *** imcleod <imcleod!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has quit IRC | 01:48 | |
| *** Wouter01000 <Wouter01000!~Wouter010@84-80-174-188.fixed.kpn.net> has quit IRC | 01:53 | |
| *** Wouter01000 <Wouter01000!~Wouter010@84-80-174-188.fixed.kpn.net> has joined #yocto | 01:58 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 02:46 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 02:51 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 03:04 | |
| *** hpsy <hpsy!~hpsy@197.37.224.220> has quit IRC | 03:08 | |
| *** imcleod <imcleod!~imcleod@c-67-165-189-101.hsd1.in.comcast.net> has joined #yocto | 03:11 | |
| *** ahadi <ahadi!~ahadi@i59F44F3B.versanet.de> has quit IRC | 03:19 | |
| *** ahadi <ahadi!~ahadi@i59F44C71.versanet.de> has joined #yocto | 03:19 | |
| *** imcleod <imcleod!~imcleod@c-67-165-189-101.hsd1.in.comcast.net> has quit IRC | 03:26 | |
| *** aquijoule__ <aquijoule__!~richbridg@089144195119.atnat0004.highway.a1.net> has joined #yocto | 03:27 | |
| *** aquijoule_ <aquijoule_!~richbridg@089144208007.atnat0017.highway.a1.net> has quit IRC | 03:29 | |
| *** dreyna__ <dreyna__!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has quit IRC | 03:31 | |
| *** vineela <vineela!~vtummala@134.134.139.74> has quit IRC | 03:37 | |
| *** JosephAntony <JosephAntony!a5e17a73@165.225.122.115> has joined #yocto | 03:38 | |
| *** hpsy <hpsy!~hpsy@197.37.138.43> has joined #yocto | 04:13 | |
| *** Minjae_Kim <Minjae_Kim!742ab977@gateway/web/cgi-irc/kiwiirc.com/ip.116.42.185.119> has quit IRC | 04:14 | |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 04:47 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 04:47 | |
| *** bobo <bobo!~bobo@customer-145-14-101-3.stosn.net> has joined #yocto | 04:48 | |
| *** dreyna__ <dreyna__!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has joined #yocto | 04:51 | |
| *** mattsm <mattsm!~mattsm@104-181-154-57.lightspeed.austtx.sbcglobal.net> has quit IRC | 05:02 | |
| *** vineela <vineela!vtummala@nat/intel/x-vpekvcdytyfenmek> has joined #yocto | 05:20 | |
| *** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto | 05:30 | |
| *** feddischson <feddischson!~feddischs@HSI-KBW-095-208-248-008.hsi5.kabel-badenwuerttemberg.de> has joined #yocto | 05:34 | |
| *** dreyna__ <dreyna__!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has quit IRC | 05:42 | |
| *** bobo <bobo!~bobo@customer-145-14-101-3.stosn.net> has quit IRC | 05:46 | |
| *** vineela <vineela!vtummala@nat/intel/x-vpekvcdytyfenmek> has quit IRC | 05:49 | |
| *** cengiz_io <cengiz_io!~cengiz_io@159.89.7.238> has quit IRC | 06:10 | |
| *** cengiz_io <cengiz_io!~cengiz_io@159.89.7.238> has joined #yocto | 06:13 | |
| iceaway | Good morning everyone | 06:20 |
| *** jobroe <jobroe!~manjaro-u@p579eb806.dip0.t-ipconnect.de> has joined #yocto | 06:21 | |
| iceaway | Yesterday I tried to set up my environment for fixing our kernel patches moving from Yocto 2.5->3.1. In 2.5 I used the devtool to work on the patches, but as I upgraded to 3.1 it said it was unable to find the defconfig, and I was advised to try the "traditional" approach as described in the manual. I'm stuck on the "yocto-kernel-cache" part, as I'm using the kernel from our SoC vendor, and they have no | 06:25 |
| iceaway | such repository. If I try skipping that step, devtool is unhappy. Is the kernel-cache stuff required? | 06:25 |
| iceaway | by devtool I mean bitbake in the second last sentence | 06:26 |
| *** jobroe <jobroe!~manjaro-u@p579eb806.dip0.t-ipconnect.de> has quit IRC | 06:31 | |
| *** jobroe <jobroe!~manjaro-u@p579eb806.dip0.t-ipconnect.de> has joined #yocto | 06:31 | |
| *** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 06:31 | |
| *** AndersD_ <AndersD_!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 06:34 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto | 06:36 | |
| *** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 06:36 | |
| *** bobo <bobo!~bobo@customer-145-14-101-3.stosn.net> has joined #yocto | 06:36 | |
| *** gounaris <gounaris!~quassel@185.183.146.59> has joined #yocto | 06:40 | |
| *** jobroe <jobroe!~manjaro-u@p579eb806.dip0.t-ipconnect.de> has quit IRC | 06:40 | |
| *** jobroe <jobroe!~manjaro-u@p579eb806.dip0.t-ipconnect.de> has joined #yocto | 06:41 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-nvjxemiwugirtihv> has quit IRC | 06:53 | |
| *** oberstet <oberstet!~oberstet@213.170.219.39> has joined #yocto | 06:55 | |
| *** AndersD_ <AndersD_!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 07:00 | |
| *** AndersD_ <AndersD_!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 07:02 | |
| *** AndersD__ <AndersD__!~AndersD@h-17-226.A137.corp.bahnhof.se> has joined #yocto | 07:04 | |
| *** AndersD_ <AndersD_!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 07:07 | |
| *** minimaxwell <minimaxwell!~minimaxwe@apoitiers-259-1-26-122.w90-55.abo.wanadoo.fr> has joined #yocto | 07:10 | |
| *** bobo <bobo!~bobo@customer-145-14-101-3.stosn.net> has quit IRC | 07:16 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-pbuofhlfdfwoeslh> has joined #yocto | 07:28 | |
| LetoThe2nd | yo dudX | 07:28 |
| *** w00die <w00die!~w00die@212.91.255.186> has quit IRC | 07:28 | |
| *** w00die <w00die!~w00die@212.91.255.186> has joined #yocto | 07:30 | |
| *** mckoan|away is now known as mckoan | 07:31 | |
| mckoan | LetoThe2nd: good morning | 07:31 |
| *** rcoote <rcoote!~rcoote@ip-176-198-112-234.hsi05.unitymediagroup.de> has joined #yocto | 07:37 | |
| *** agust <agust!~agust@p5483356f.dip0.t-ipconnect.de> has joined #yocto | 07:48 | |
| *** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/kiwiirc.com/ip.149.90.111.173> has joined #yocto | 07:52 | |
| *** Minjae_Kim <Minjae_Kim!742ab977@gateway/web/cgi-irc/kiwiirc.com/ip.116.42.185.119> has joined #yocto | 07:55 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 07:56 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 08:00 | |
| *** JosephAntony <JosephAntony!a5e17a73@165.225.122.115> has quit IRC | 08:14 | |
| *** Klox <Klox!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has quit IRC | 08:23 | |
| *** Minjae_Kim <Minjae_Kim!742ab977@gateway/web/cgi-irc/kiwiirc.com/ip.116.42.185.119> has quit IRC | 08:25 | |
| *** flash27 <flash27!022d854a@net-2-45-133-74.cust.vodafonedsl.it> has joined #yocto | 08:33 | |
| *** jkjaid349i <jkjaid349i!503d68ac@80-61-104-172.fixed.kpn.net> has joined #yocto | 08:36 | |
| *** flash27 <flash27!022d854a@net-2-45-133-74.cust.vodafonedsl.it> has quit IRC | 08:40 | |
| *** jkjaid349i <jkjaid349i!503d68ac@80-61-104-172.fixed.kpn.net> has quit IRC | 08:41 | |
| *** flash27 <flash27!022d854a@net-2-45-133-74.cust.vodafonedsl.it> has joined #yocto | 08:42 | |
| *** mbulut <mbulut!~nameclash@ip1f121f26.dynamic.kabel-deutschland.de> has joined #yocto | 08:44 | |
| *** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:2413:85cb:bba4:fb22> has joined #yocto | 08:56 | |
| *** asteriusio <asteriusio!~derek@104-179-196-18.lightspeed.brhmal.sbcglobal.net> has quit IRC | 09:00 | |
| *** asteriusio <asteriusio!~derek@104-179-196-18.lightspeed.brhmal.sbcglobal.net> has joined #yocto | 09:00 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 09:08 | |
| *** ahadi <ahadi!~ahadi@i59F44C71.versanet.de> has quit IRC | 09:09 | |
| *** ahadi <ahadi!~ahadi@i59F44C71.versanet.de> has joined #yocto | 09:17 | |
| *** flash27 <flash27!022d854a@net-2-45-133-74.cust.vodafonedsl.it> has quit IRC | 09:17 | |
| *** ahadi <ahadi!~ahadi@i59F44C71.versanet.de> has quit IRC | 09:18 | |
| *** kyanres <kyanres!c3c8aac6@ecascr.ecatou.fr> has quit IRC | 09:21 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 09:22 | |
| *** ahadi <ahadi!~ahadi@i59F44C71.versanet.de> has joined #yocto | 09:22 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 09:22 | |
| kpo_ | Hello, I've got a quick question, because I can't find straightforward answer in docs: is it possible to tell gitsm fetcher to checkout to specific commit hash? As in tag, but using commit hash | 09:28 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 09:33 | |
| *** JungleBoy <JungleBoy!503d68ac@80-61-104-172.fixed.kpn.net> has joined #yocto | 09:35 | |
| JungleBoy | hi I'm JungleBoy | 09:35 |
| LetoThe2nd | kpo_: usually SRCREV does that, no idea if it applies to gitsm too. but thats the best guess. | 09:37 |
| *** intera91 <intera91!521f818d@cpc142184-mcam2-2-0-cust140.18-3.cable.virginm.net> has joined #yocto | 09:41 | |
| intera91 | good morning | 09:42 |
| intera91 | was wondering if anyone has built yocto for a ryzen platform and has met with the AMD graphics driver | 09:42 |
| JungleBoy | intera91 which board? | 09:44 |
| intera91 | basically I have IMAGE_INSTALL_append = " mosquitto libavc1394 cairo zeromq imagemagick glfw libconfig libmosquitto1 ffmpeg strace gdb mosquitto-dev boost gstream | 09:46 |
| intera91 | er1.0-libav vulkan-cts vulkan-headers glm-dev glslang rinicom mesa mesa-demos" in my local.conf and trying to build a core-image-sato for a VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] (rev c6) (prog-if 00 [VGA controller]) | 09:46 |
| intera91 | still no radeonsi gets built and glxinfo states: | 09:47 |
| LetoThe2nd | intera91: that sounds like a totally flawed approach. | 09:47 |
| intera91 | LetoThe2nd: am a newbie at that one | 09:48 |
| LetoThe2nd | intera91: 1) create a custom layer 2) create a custom image 3) make a somewhat sensible dependency chain that allows you to focus on one thing. | 09:48 |
| intera91 | LetoThe2nd: am all ears at what would be the proper way to proceed | 09:48 |
| LetoThe2nd | e.g., your image should INSTALL the application, and the application shall depend on the libs and whatever you need. | 09:48 |
| LetoThe2nd | 4) get sato out of our head | 09:49 |
| intera91 | feels like being so close yet so far | 09:50 |
| LetoThe2nd | 5) accept the possibility that there is no real blueprint for the amd gpu setup you want and that you probably have to invest quite a bit of effort. | 09:50 |
| intera91 | mmh I can see that, that's unfortunate | 09:51 |
| intera91 | here is the problem: glxinfo | grep -i vendor | 09:51 |
| intera91 | libGL error: MESA-LOADER: failed to open radeonsi (search paths /usr/lib/dri) | 09:51 |
| intera91 | libGL error: failed to load driver: radeonsi | 09:51 |
| intera91 | libGL error: MESA-LOADER: failed to open radeonsi (search paths /usr/lib/dri) | 09:51 |
| intera91 | libGL error: failed to load driver: radeonsi | 09:51 |
| intera91 | server glx vendor string: SGI | 09:51 |
| intera91 | client glx vendor string: Mesa Project and SGI | 09:51 |
| intera91 | Vendor: VMware, Inc. (0xffffffff) | 09:51 |
| intera91 | OpenGL vendor string: VMware, Inc. | 09:51 |
| LetoThe2nd | intera91: use a pastebin next time, please. | 09:51 |
| intera91 | sure sorry | 09:51 |
| qschulz | intera91: have you enabled the correct DISTRO_FEATURES and MACHINE_FEATURES for gpu/opengl support? | 09:52 |
| kpo_ | @LetoThe2nd thanks, that's the thing :) | 09:52 |
| intera91 | qschulz: not sure how to do that | 09:52 |
| intera91 | is that in local.conf? | 09:53 |
| LetoThe2nd | intera91: probably you don't have a proper provider for virtual/gl or whatever it takes there. i'm no graphics guy, sorry, but really - stuffing everything into local.conf is a super bad practise and you should get rid of it before it forms a habit! | 09:53 |
| LetoThe2nd | intera91: i suggest watching the videos on creating a layer, a custom image, and the distro/machine/image one :) | 09:53 |
| qschulz | intera91: https://docs.yoctoproject.org/ref-manual/features.html#ref-features-distro | 09:54 |
| *** kyanres <kyanres!c3c8aac6@ecascr.ecatou.fr> has joined #yocto | 10:01 | |
| JungleBoy | LetoThe2nd was searching for that video as well, do you know which # it was? | 10:06 |
| LetoThe2nd | distro/images/machine? not sure, 7, 8 or so. | 10:07 |
| JungleBoy | ok will check it out, thanks | 10:07 |
| *** ahadi <ahadi!~ahadi@i59F44C71.versanet.de> has joined #yocto | 10:12 | |
| *** ahadi <ahadi!~ahadi@i59F44C71.versanet.de> has quit IRC | 10:12 | |
| *** ahadi <ahadi!~ahadi@i59F44C71.versanet.de> has joined #yocto | 10:14 | |
| qschulz | JungleBoy: it's in the title of the Youtube video IIRC | 10:18 |
| *** NiniC0c0 <NiniC0c0!56f67f06@lfbn-idf2-1-417-6.w86-246.abo.wanadoo.fr> has joined #yocto | 10:23 | |
| NiniC0c0 | hello, all I have 2 metas and both need a bbappend on device-tree part. if i put one inside meta-custom-bsp an one inside meta-custom-apps. Can I build an image from meta-custom-bsp without use the bbappend inside meta-custom-apps ? I'm not sure to be clear... sorry for that :) | 10:28 |
| qschulz | NiniC0c0: no | 10:30 |
| qschulz | or maybe with dynamic layers but I've no experience with that | 10:30 |
| qschulz | NiniC0c0: device tree is related to hw configuration, so it is related to your machine configuration file. You should therefore have two machines or two device trees at least. | 10:31 |
| qschulz | in case of two machines, you can have SRC_URI_append_<machine> in your bbappends | 10:32 |
| NiniC0c0 | qschulz as always xD I have 2 meta folders (bsp and apps) with a device-tree_%.bbapend. When I build a bsp image i don't want to use the bbapend from apps folder. maybe BBFILE_PRIORITY is enough ? | 10:32 |
| qschulz | NiniC0c0: no, bbappend applies no matter what | 10:33 |
| qschulz | the priority will just change the order in which they are applied | 10:33 |
| NiniC0c0 | qschulz Ok. it's the same machine i need just to add a node inside | 10:33 |
| qschulz | NiniC0c0: what is this node for? | 10:33 |
| NiniC0c0 | ho ok thx for the info | 10:33 |
| NiniC0c0 | qschulz just to configure custom driver input | 10:34 |
| qschulz | NiniC0c0: you could always use device tree overlays | 10:36 |
| LetoThe2nd | NiniC0c0: tip: just because it is physically the same machine, it doesn't necessarily have to be the same machine configuration. or dt overlays. it "depends" | 10:37 |
| qschulz | apply the overlay in u-boot depending on a conf file that you'll set in your image recipe | 10:37 |
| NiniC0c0 | qschulz LetoThe2nd I'm stupid overlays should do the trick:) thank you for supporting my stupidity.. | 10:38 |
| LetoThe2nd | NiniC0c0: you can always thank us with free beers! | 10:39 |
| qschulz | NiniC0c0: it's not stupidity, sometimes we just forget about things. Don't worry, happy to have helped, that's hthe most important part :) | 10:39 |
| NiniC0c0 | it's a really good community guys<3 | 10:39 |
| kayterina | hello. What could be a good practice for I ran out of free space: should I 'clean' some temporary folder before I 'rsync' whole ~/poky to another drive? Does it keep any absolute path links? | 10:56 |
| RobertBerger | @NiniC0c0: If you want to solve this from a YP/OE point of view you could use dynamic layers, as qchulz pointed out. It's something like: if this layer exists than use that. | 11:02 |
| RobertBerger | Only if the networking layer is in bblayers.conf apply the ntp bbappend: https://gitlab.com/meta-layers/meta-resy/-/tree/master/dynamic-layers/networking-layer/recipes-support/ntp | 11:02 |
| NiniC0c0 | RobertBerger Thx I will alose take a look to dynamic layers | 11:03 |
| LetoThe2nd | kayterina: best practise is to get a disk thats big enough. second best practise is cleaning out sstate (even if only partially). moving the build does not work as easily as you might think, at least tmp has to be recreated from scratch, and probably most of the pathes in local.conf and bblayers.conf have to be checked. | 11:05 |
| kayterina | so if tmp has to be recreated then I just as easily start over in the new disk | 11:06 |
| LetoThe2nd | kayterina: sstate can be moved. tmp cannot. | 11:07 |
| kayterina | a..ok. | 11:08 |
| qschulz | kayterina: you can setup a SSTATE_MIRROR too, this way it's not entirely from scratch | 11:08 |
| qschulz | I think some people also have the sstate cache on an NFS? | 11:08 |
| LetoThe2nd | qschulz: NonFunctionalStorage? | 11:09 |
| qschulz | kayterina: i'm not really sure why you want to rsync whole poky? | 11:09 |
| *** JungleBoy <JungleBoy!503d68ac@80-61-104-172.fixed.kpn.net> has quit IRC | 11:09 | |
| kayterina | perhaps I have a wrong directory structure then. I hae my build in ~/poky/build and my layers in ~/mylayers/meta-blabla so I though I hae to move, so I move everything | 11:10 |
| kayterina | rsync is just what I use to move big files | 11:10 |
| LetoThe2nd | kayterina: s/perhaps/g | 11:10 |
| qschulz | kayterina: what exactly do you want to move and for which usecase? | 11:11 |
| LetoThe2nd | kayterina: instead of wasting time with copying, watch a couple of my videos where i explain how to lay out your project. especially the kas one essentially shows it step by step. | 11:11 |
| LetoThe2nd | qschulz: low disk space. | 11:11 |
| kayterina | LetoThe2nd: link please? | 11:12 |
| LetoThe2nd | *sigh* | 11:12 |
| kayterina | I only found 3 on vimeo | 11:12 |
| qschulz | LetoThe2nd: then INHERIT += "rm_work" and some cleanup of the sstate-cache with find -atime +30 -delete? | 11:12 |
| LetoThe2nd | kayterina: you're really not exactly a prime example of showing initiative and effort, i have to say. https://youtu.be/KJHJlOtTdaE | 11:13 |
| kayterina | aouch. youtube..sorry leto | 11:13 |
| LetoThe2nd | qschulz: i don't like rm_work. cleaning out with a carefully chose atime can make sense, yes. | 11:13 |
| LetoThe2nd | kayterina: we've only been using youtube for one and a half years, so yes, it comes really surprising! ;-) | 11:14 |
| LetoThe2nd | </SCNR> | 11:14 |
| qschulz | LetoThe2nd: we use rm_work for years already :) | 11:18 |
| LetoThe2nd | qschulz: thats why i explicitly chose the wording "i don't like". not claiming my POV matches all others :) | 11:19 |
| *** bps <bps!~bps@87-59-117-59-dynamic.dk.customer.tdc.net> has joined #yocto | 11:20 | |
| linums | Hi | 11:37 |
| linums | Do I have to reboild everything after I add a new distro_feature, or can i just somehow rebuild the related packages | 11:38 |
| rburton | build the image and it will rebuild what is needed | 11:40 |
| LetoThe2nd | "it's magic!" | 11:40 |
| rburton | if you'd turned on hash equiv it will rebuild less | 11:40 |
| *** vijay <vijay!a4a45f09@164.164.95.9> has joined #yocto | 11:43 | |
| RP | kanavin_home: I tried your patch on a -next build. Its interesting as we got numbers of 53, 53, 57, 58 as being different on the different distros | 11:46 |
| linums | It should also work with the distro_features addition? | 11:47 |
| linums | Then I'm in trouble :D | 11:47 |
| linums | Because it thinks it has nothing to do | 11:48 |
| LetoThe2nd | linums: *guess*: you added it in the image recipe. | 11:49 |
| linums | I did | 11:49 |
| linums | Throug an distro_features_append list | 11:49 |
| qschulz | linums: distro feature is to be set in.... distro configruation file :) | 11:49 |
| linums | Yeah, I knew, that it is not the best idea, to add it from an image recipe :D | 11:50 |
| qschulz | linums: well it's not that it's not the best idea, it's just that it won't work | 11:50 |
| linums | Whatever does not work, sounds like a bad idea to me :D | 11:51 |
| LetoThe2nd | anybody, please sing along with yocto chant #1.... | 11:51 |
| qschulz | I think we got some people interested for a Ubuntu meta-deb (meta-rpm like) on the mailing list :D | 11:54 |
| *** vijay <vijay!a4a45f09@164.164.95.9> has quit IRC | 12:10 | |
| LetoThe2nd | qschulz: whenever i read the closing lines there, i really wonder if its the language barrier or it such folks really think its ok to just request/demand | 12:11 |
| linums | Heey, it moving the distro_features to it's proper place worked! Thanks :) | 12:15 |
| *** bps <bps!~bps@87-59-117-59-dynamic.dk.customer.tdc.net> has quit IRC | 12:20 | |
| *** cmg <cmg!~cmg@5.103.15.60.static.fibianet.dk> has joined #yocto | 12:20 | |
| LetoThe2nd | doing something properly works? OMG! | 12:21 |
| cmg | exit | 12:28 |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-vrhbmaimmhbwtius> has joined #yocto | 12:28 | |
| *** tgoodwin <tgoodwin!~tgoodwin@static-96-234-151-198.bltmmd.fios.verizon.net> has joined #yocto | 12:28 | |
| *** cmg <cmg!~cmg@5.103.15.60.static.fibianet.dk> has quit IRC | 12:29 | |
| *** iceaway <iceaway!~pelle@37.233.78.69> has quit IRC | 12:33 | |
| *** pharaon2502 <pharaon2502!~manjaro-u@cpezg-94-253-139-242-cbl.xnet.hr> has quit IRC | 12:37 | |
| *** Minjae_Kim <Minjae_Kim!742ab977@gateway/web/cgi-irc/kiwiirc.com/ip.116.42.185.119> has joined #yocto | 12:39 | |
| *** intera91 <intera91!521f818d@cpc142184-mcam2-2-0-cust140.18-3.cable.virginm.net> has quit IRC | 12:39 | |
| *** jobroe <jobroe!~manjaro-u@p579eb806.dip0.t-ipconnect.de> has quit IRC | 12:44 | |
| *** jobroe <jobroe!~manjaro-u@p579eb806.dip0.t-ipconnect.de> has joined #yocto | 12:45 | |
| *** minimaxwell <minimaxwell!~minimaxwe@apoitiers-259-1-26-122.w90-55.abo.wanadoo.fr> has quit IRC | 12:51 | |
| LetoThe2nd | rburton: the answer is: "i want an ubuntu but all i got from my hw vendor was this yocto bsp layer" :) | 12:52 |
| *** minimaxwell <minimaxwell!~minimaxwe@163.52.205.77.rev.sfr.net> has joined #yocto | 12:53 | |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 12:55 | |
| *** linums <linums!~linums@apn-94-44-226-6.vodafone.hu> has joined #yocto | 12:56 | |
| *** jobroe <jobroe!~manjaro-u@p579eb806.dip0.t-ipconnect.de> has quit IRC | 12:57 | |
| *** jobroe <jobroe!~manjaro-u@p579eb806.dip0.t-ipconnect.de> has joined #yocto | 12:58 | |
| *** iceaway <iceaway!~pelle@37.233.78.69> has joined #yocto | 13:01 | |
| *** linums <linums!~linums@apn-94-44-226-6.vodafone.hu> has quit IRC | 13:04 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 13:05 | |
| *** jobroe <jobroe!~manjaro-u@p579eb806.dip0.t-ipconnect.de> has quit IRC | 13:06 | |
| *** jobroe <jobroe!~manjaro-u@p579eb806.dip0.t-ipconnect.de> has joined #yocto | 13:06 | |
| *** Minjae_Kim <Minjae_Kim!742ab977@gateway/web/cgi-irc/kiwiirc.com/ip.116.42.185.119> has quit IRC | 13:07 | |
| iceaway | I'm trying to build the extensible SDK, but I get some really strange error about do_prepare_recipe_sysroot failing with exit code 'setscene whitelist'. Any ideas? Google did not give me much. | 13:08 |
| *** flash27 <flash27!022d854a@net-2-45-133-74.cust.vodafonedsl.it> has joined #yocto | 13:08 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 13:22 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 13:23 | |
| *** dev1990 <dev1990!~dev@dynamic-81-168-169-170.ssp.dialog.net.pl> has quit IRC | 13:27 | |
| *** imcleod <imcleod!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has joined #yocto | 13:28 | |
| *** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:2413:85cb:bba4:fb22> has quit IRC | 13:34 | |
| *** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:53e8:7f49:1e5f:691> has joined #yocto | 13:35 | |
| *** flash27 <flash27!022d854a@net-2-45-133-74.cust.vodafonedsl.it> has quit IRC | 13:41 | |
| *** ctlnwr__ <ctlnwr__!~catalin@46.97.150.20> has quit IRC | 13:41 | |
| *** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:53e8:7f49:1e5f:691> has quit IRC | 13:42 | |
| *** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:fdee:4ba2:d966:c97a> has joined #yocto | 13:43 | |
| *** minimaxwell <minimaxwell!~minimaxwe@163.52.205.77.rev.sfr.net> has quit IRC | 13:46 | |
| *** minimaxwell <minimaxwell!~minimaxwe@apoitiers-259-1-26-122.w90-55.abo.wanadoo.fr> has joined #yocto | 13:50 | |
| RobertBerger | @LetoThe2nd: and it's even worse if the one who asks is the BSP Layer vendor ;) | 13:52 |
| LetoThe2nd | RobertBerger: gosh didn't realize that. | 13:53 |
| RobertBerger | @iceaway: Which meta-layers did you include? | 13:53 |
| RobertBerger | @LetoThe2nd: I also commented on the mail ;) | 13:53 |
| *** minimaxwell <minimaxwell!~minimaxwe@apoitiers-259-1-26-122.w90-55.abo.wanadoo.fr> has quit IRC | 13:57 | |
| *** minimaxwell <minimaxwell!~minimaxwe@apoitiers-259-1-26-122.w90-55.abo.wanadoo.fr> has joined #yocto | 14:02 | |
| *** flash27 <flash27!022d854a@net-2-45-133-74.cust.vodafonedsl.it> has joined #yocto | 14:03 | |
| *** ctlnwr <ctlnwr!~catalin@46.97.150.20> has joined #yocto | 14:09 | |
| JPEW | The top level LICENSE for gnutls is "GPLv3 & LGPLv2.1+" because some parts are LGPL and some are GPLv3. However, some recent (dunfell?) change made this top level license the one that applies to generated -locale packages | 14:13 |
| marex | LetoThe2nd: the request thing is a language nuance, it is really meant as polite way of asking for help, not in the "demand" sense | 14:14 |
| *** jobroe <jobroe!~manjaro-u@p579eb806.dip0.t-ipconnect.de> has quit IRC | 14:14 | |
| marex | LetoThe2nd: I only figured it out when watching startrek TNG :) | 14:14 |
| JPEW | This makes my images fail because we don't allow GPLv3.... I'm fairly certain that the -locale files don't fall under the GPLv3, but I'm not sure how to tell bitbake that | 14:14 |
| LetoThe2nd | marex: thanks! | 14:15 |
| marex | LetoThe2nd: I think Worf used it there a few times, to ask for a favor | 14:15 |
| marex | LetoThe2nd: when talking to Picard iirc | 14:15 |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 14:17 | |
| marex | RobertBerger: cant you just build custom u-boot/kernel package for ubuntu ,create a ppa , apt install it and done ? | 14:17 |
| marex | the later is I think make deb in linux sources, the former ... look at the debian package for u-boot and add a patch or somesuch | 14:18 |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 14:19 | |
| yann | activating ccache globally in local.conf should not trigger rebuilds by itself, right ? it does that to me in gatesgarth :( | 14:35 |
| JPEW | yann: It's missing some `BB_HASHBASE_WHITELIST` entries | 14:42 |
| JPEW | yann: Basically, since all of the CCACHE_* variables are `export` they will be include in every task hash, which is probably not what you want | 14:43 |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 14:47 | |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 14:48 | |
| RobertBerger | @marex: I guess you could. Not sure if you can use it commercially after and/or call it Ubuntu. You might need to remove all the references to "Ubuntu". | 14:52 |
| marex | RobertBerger: you just dont distribute anything from the official images, just the PPA, that's not called ubuntu, but a custom repo | 15:00 |
| RobertBerger | @marex: We need to know the use case. Even if you don't distribute anything, someone eventually will. | 15:02 |
| marex | RobertBerger: so better do it the OE way, distribute the sources and let others compile them , hehe | 15:06 |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 15:07 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 15:07 | |
| RobertBerger | @marex: Still the same problem once you ship the product. One of my customers actually wanted to compile Ubuntu sources with OE and asked Canonical. They did not allow it ;) | 15:07 |
| marex | RobertBerger: as in what apt source + dpkg-buildpackage does ? how can canonical stop you from doing so with inherently free or opensource software ? | 15:09 |
| marex | RobertBerger: are you sure it wasnt something something about branding ? | 15:10 |
| marex | RobertBerger: it sounds like the firefox/iceweasel situation in debian | 15:10 |
| RobertBerger | @marex: Trademark is for sure an issue. | 15:10 |
| marex | RobertBerger: if you are compiling linux kernel, what does canonical has to do with it ? | 15:12 |
| marex | *have | 15:12 |
| marex | RobertBerger: dtto for u-boot | 15:12 |
| RobertBerger | @marex: Nothing I would say. | 15:13 |
| RobertBerger | @marex: It's more about the rootfs and all the Ubuntu strings in there ;) | 15:13 |
| sakoman | JPEW: re: how to tell bitbake what license a package is for gnutls | 15:13 |
| marex | RobertBerger: wget it from ubuntu.com | 15:13 |
| marex | RobertBerger: there, no problem, canonical is distributing that part | 15:13 |
| sakoman | JPEW: LICENSE_${PN}-xx = "LGPLv2.1+" | 15:13 |
| marex | RobertBerger: you just installed packages from ppa into your debian-derivative distro, that's built into ubuntu, so shrug | 15:14 |
| sakoman | See the gnutls recipe -- this is done for several packages | 15:14 |
| marex | (yes, it is a workaround, and the result would be poor, obviously) | 15:14 |
| RobertBerger | @marex: You mean your end customers know how to build and install packages? That's not how Embedded Systems are usually sold. | 15:15 |
| yann | JPEW: so all that's needed is to list them all in `BB_HASHBASE_WHITELIST`, right ? | 15:17 |
| marex | RobertBerger: we cannot assume that the original poster of that email thread plans to deliver a product | 15:17 |
| RobertBerger | @marex: Oh yes we can ;) | 15:18 |
| marex | RobertBerger: we can ? :) | 15:18 |
| marex | RobertBerger: it could be they are just preparing the building blocks for someone else | 15:18 |
| RobertBerger | @marex: Sure ;) For fun and non profit. | 15:19 |
| RobertBerger | @marex: "Internal use only" | 15:19 |
| JPEW | sakoman: That doesn't appear to work though | 15:23 |
| JPEW | sakoman: If that's supposed to apply to the -locale packages, it appears broken | 15:24 |
| sakoman | JPEW: Oh, no that specific line applies to the gnutls-xx package! | 15:24 |
| sakoman | You would need to add similar -locales that you want changes | 15:25 |
| sakoman | I was just using that as an example :-) | 15:26 |
| JPEW | sakoman: Ah, right... I think the specific problem is that they packages are generated based on the configured locales, so we don't know all the names a priori | 15:27 |
| sakoman | I suspect that we really should be overriding the license on all of the locales | 15:28 |
| sakoman | Since as you say they are probably not intended to be gplv3 | 15:28 |
| RP | JPEW: we probably need some kind of locale license variable | 15:30 |
| RP | JPEW: but I do worry the locales are under GPLv3 | 15:30 |
| RP | or perhaps parts of them :/ | 15:30 |
| JPEW | RP: Ya, I wasn't sure how that would work..... would they have the license of the source file they came from? Are they considered "data"? | 15:31 |
| *** rcw <rcw!~rcwoolley@216.154.64.65> has joined #yocto | 15:32 | |
| *** flash27 <flash27!022d854a@net-2-45-133-74.cust.vodafonedsl.it> has quit IRC | 15:33 | |
| RP | JPEW: does the source actually say? | 15:33 |
| JPEW | Not really: https://gitlab.com/gnutls/gnutls/-/blob/master/po/POTFILES.in | 15:34 |
| *** eduardas <eduardas!~eduardas@82-135-139-249.static.zebra.lt> has joined #yocto | 15:35 | |
| *** bobo <bobo!~bobo@customer-145-14-101-3.stosn.net> has joined #yocto | 15:36 | |
| RP | JPEW: https://translationproject.org/POT-files/gnutls-3.6.8.pot | 15:37 |
| RP | JPEW: in the source it has .po files with "This file is distributed under the same license as the gnutls package." | 15:38 |
| JPEW | RP: Yep, which is a little confusing since the source code has components under difference licenses: https://gitlab.com/gnutls/gnutls/-/blob/master/LICENSE | 15:40 |
| RP | JPEW: right :/ | 15:40 |
| RP | JPEW: I think we may have to ask them | 15:40 |
| JPEW | RP: Will do | 15:42 |
| yann | we can't use something like `INHERIT_append_pn-linux-vanilla = " ccache"` in local.conf, it *has* to be += in a .bbappend, right ? | 15:43 |
| kergoth | yann: INHERIT is processed globally long beroe the recipes are parsed at all | 15:45 |
| kergoth | += in a bbappend will do nothing either | 15:45 |
| kergoth | 'inherit foo' in a bbappend will do fine | 15:45 |
| yann | yeah, looks better already, thx! | 15:47 |
| yann | I've tried adding BB_HASHBASE_WHITELIST += "CCACHE_TOP_DIR CCACHE_BASEDIR CCACHE_COMPILERCHECK CCACHE_CONFIGPATH CCACHE_DIR CCACHE_NOHASHDIR" to my local.conf in the hope to allow reuse | 15:47 |
| yann | of sstate as mentionned by JPEW , but that juste makes the task hashes unstable, can't see why | 15:48 |
| *** mckoan is now known as mckoan|away | 15:48 | |
| JPEW | RP: I asked on their ML. I think I'll also add a "nls" PACKAGECONFIG to disable the translations (I don't *really* care about having them) | 16:13 |
| RP | JPEW: fair enough. Its going to become an increasing problem :/ | 16:14 |
| RP | JPEW: the point of splitting them into packages is so you can ignore them | 16:15 |
| *** gounaris <gounaris!~quassel@185.183.146.59> has quit IRC | 16:24 | |
| *** AndersD__ <AndersD__!~AndersD@h-17-226.A137.corp.bahnhof.se> has quit IRC | 16:24 | |
| JPEW | RP: Hmm, ya. Weirdly, if they weren't split into separate packages, I suspect they would have defaulted to the ${PN} package... | 16:30 |
| JPEW | Which is LGPLv2 | 16:30 |
| * JPEW verifies that assumption | 16:31 | |
| JPEW | Nope, I was wrong. There is a ${PN}-locale package | 16:32 |
| JPEW | But, perhaps the split locale packages should pick their license from LICENSE_${PN}-locale (if set), that way you can at least set the license for all of them without having to know all the generated names first | 16:34 |
| *** Wouter01000 <Wouter01000!~Wouter010@84-80-174-188.fixed.kpn.net> has quit IRC | 16:40 | |
| *** Wouter01000 <Wouter01000!~Wouter010@84-80-174-188.fixed.kpn.net> has joined #yocto | 16:40 | |
| weltling | is there a way to pull a dso from a foreign architecture? currently when including that, the build tries to strip it and to check symbol versions, etc., is there a way to skip it? I checked some steps and related "inhibit" variables but don't seem to find a good solution for that. | 16:41 |
| weltling | say pull an aarch64 dso into a x86 build, etc. | 16:41 |
| JPEW | weltling: Ya, you have to set a few variables to prevent it from doing those things, but it's possible | 16:42 |
| *** bobo <bobo!~bobo@customer-145-14-101-3.stosn.net> has quit IRC | 16:43 | |
| weltling | JPEW, could you help identify those please? my latest status i was setting INHIBIT_PACKAGE_STRIP_FILES, but then dnf tries to look into the symbol versions and obviously libc is a wrong one so it fails | 16:46 |
| weltling | i was looking also at a wiki page about including binary artifacts into the build, that however concerns including artifacts of the same arch | 16:47 |
| JPEW | weltling: Hmm, Can you put the file somewhere other than a standard library search path? | 16:47 |
| weltling | JPEW, it is in a subfolder of /usr/lib, but it wouldn't be found by default i think | 16:48 |
| weltling | dfn finds it because it's listed explicitly in the spec, i think | 16:48 |
| weltling | hmm, perhaps it could be put somewhere else, but i'll need to be available at the exact place then | 16:49 |
| JPEW | weltling: EXCLUDE_FROM_SHLIBS = "1" maybe? | 16:49 |
| JPEW | weltling: Reading through package.bbclass is helpful for these sorts of things | 16:49 |
| *** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC | 16:50 | |
| weltling | JPEW, oh, reading teh doc, perhaps PRIVATE_LIBS could work, gonna try | 16:51 |
| weltling | yeah, read the package.bbclass but obviously overseen these possibilities | 16:51 |
| weltling | otherwise, it won't be possible to exclude all the dso at once, as the package produces also some libs that are from the same arch and are needed | 16:52 |
| weltling | perhaps those of the foreign arch could be separated out, that might be an idea, too, then they could be excluded from shlibs | 16:53 |
| JPEW | weltling: You might try to split them apart if possible | 16:53 |
| weltling | yeah | 16:53 |
| weltling | JPEW, thanks a lot for the help! | 16:53 |
| JPEW | weltling: np | 16:54 |
| *** stephano <stephano!~stephano@73.240.0.134> has joined #yocto | 17:00 | |
| diamondman | I am trying to make a recipe:task that will automatically run the do_test task on every recipe that inherits from a bbclass (the reason why I want this is at the bottom if anyone cares). | 17:05 |
| diamondman | My current idea is to have the bbclass add the do_test task and then add that do_test task as a dependency to company-tests:do_test. That way, you can run | 17:05 |
| diamondman | bitbake company-tests -c do_test | 17:05 |
| diamondman | and that automatically executes recipe1.bb:do_test, recipe2.bb:do_test, etc. | 17:05 |
| diamondman | This solution turns out to be pretty hard to do. I have been digging through the bitbake source code, and I can not find a way to add a dependency to a task from a different recipe. I am using an anonymous python function, so my code runs before tasks start being executed, but I have not figured out how to access the datastores of other tasks. Maybe there is no reliable way to do this since the recipes are not | 17:05 |
| diamondman | necessarily parsed in any specific order. | 17:05 |
| diamondman | I have several other less attractive ideas too, like in company-tests:do_test, scanning all parsed recipes to find ones that inherit from my bbclass and then dynamically those recipe''s do_test task to the scheduler (this would make the count of necessary tasks inaccurate, so I would love a better option). | 17:05 |
| diamondman | Does anyone have any ideas on how to achieve my goal? I am open to all alternatives. Thanks in advance. | 17:05 |
| *** ahadi <ahadi!~ahadi@i59F44C71.versanet.de> has quit IRC | 17:06 | |
| *** dvhart <dvhart!~dvhart@50.39.132.186> has joined #yocto | 17:07 | |
| *** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/kiwiirc.com/ip.149.90.111.173> has quit IRC | 17:10 | |
| *** mbulut <mbulut!~nameclash@ip1f121f26.dynamic.kabel-deutschland.de> has quit IRC | 17:11 | |
| *** ahadi <ahadi!~ahadi@i59F44C71.versanet.de> has joined #yocto | 17:22 | |
| *** dvhart <dvhart!~dvhart@50.39.132.186> has quit IRC | 17:24 | |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 17:28 | |
| *** linums <linums!~linums@apn-94-44-238-144.vodafone.hu> has joined #yocto | 17:29 | |
| *** hpsy <hpsy!~hpsy@197.37.138.43> has quit IRC | 17:37 | |
| *** hpsy <hpsy!~hpsy@197.37.119.202> has joined #yocto | 17:41 | |
| yocton | diamondman: Do you know "bitbake-layers show-recipes -i <bbclass>" ? | 17:45 |
| yocton | (This is the bitbake way of getting all recipes inheriting a class) | 17:46 |
| *** mprokos <mprokos!~mprokos@ec2-52-25-23-41.us-west-2.compute.amazonaws.com> has joined #yocto | 17:46 | |
| *** mprokos is now known as rabbit9911 | 17:46 | |
| rabbit9911 | Anyone seeing python3 core dumps with 3.1.5? Seems to only show up on our epyc server. | 17:47 |
| diamondman | @yocton I can look at how that code works and try to borrow it. | 17:48 |
| yocton | diamondman: I would start from that, process a little then give it to bitbake -ctest ... | 17:48 |
| diamondman | @yocton are you recommending triggering a 2nd run of bitbake after determining which recipes need to be tested? | 17:48 |
| *** manuel1985 <manuel1985!~manuel198@213-147-162-79.nat.highway.bob.at> has joined #yocto | 17:50 | |
| yocton | "recommend" is a stong word ^^ For what I'm suggesting, you'll have one bitbake-layers run (getting the list of recipes) and one bitbake run (running the do_test task on all recipes) | 17:52 |
| yocton | Also, I wonder if "bitbake -c test world" would work | 17:55 |
| *** vineela <vineela!vtummala@nat/intel/x-fdpgizmcjczzktft> has joined #yocto | 17:59 | |
| *** linums <linums!~linums@apn-94-44-238-144.vodafone.hu> has quit IRC | 18:00 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 18:00 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-pbuofhlfdfwoeslh> has quit IRC | 18:03 | |
| *** zkrx <zkrx!~slimshady@adsl-89-217-237-59.adslplus.ch> has quit IRC | 18:03 | |
| *** hpsy <hpsy!~hpsy@197.37.119.202> has quit IRC | 18:04 | |
| *** zkrx <zkrx!~slimshady@adsl-89-217-237-59.adslplus.ch> has joined #yocto | 18:07 | |
| kergoth | yocton: you'd probably need --runall=test if you want a task run on all the dependencies of the specified target, not just the target. | 18:10 |
| * kergoth yawns | 18:10 | |
| kergoth | that's only if the task exists everywhere, of course. | 18:10 |
| *** feddischson <feddischson!~feddischs@HSI-KBW-095-208-248-008.hsi5.kabel-badenwuerttemberg.de> has quit IRC | 18:15 | |
| *** feddischson <feddischson!~feddischs@HSI-KBW-095-208-248-008.hsi5.kabel-badenwuerttemberg.de> has joined #yocto | 18:16 | |
| *** hpsy <hpsy!~hpsy@197.37.119.202> has joined #yocto | 18:19 | |
| *** dreyna <dreyna!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has joined #yocto | 18:23 | |
| *** dreyna_ <dreyna_!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has joined #yocto | 18:24 | |
| *** zkrx <zkrx!~slimshady@adsl-89-217-237-59.adslplus.ch> has quit IRC | 18:27 | |
| *** dreyna <dreyna!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has quit IRC | 18:27 | |
| *** zkrx <zkrx!~slimshady@adsl-89-217-237-59.adslplus.ch> has joined #yocto | 18:34 | |
| *** kyanres <kyanres!c3c8aac6@ecascr.ecatou.fr> has quit IRC | 18:39 | |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 18:48 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 18:48 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 18:53 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 18:54 | |
| *** zkrx <zkrx!~slimshady@adsl-89-217-237-59.adslplus.ch> has quit IRC | 18:57 | |
| *** zkrx <zkrx!~slimshady@adsl-89-217-237-59.adslplus.ch> has joined #yocto | 19:02 | |
| *** vdl <vdl!~vivien@modemcable249.105-163-184.mc.videotron.ca> has quit IRC | 19:04 | |
| *** sakoman <sakoman!~steve@72.173.249.164> has quit IRC | 19:16 | |
| *** JaBen <JaBen!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has joined #yocto | 19:22 | |
| kanavin_home | RP: I'll send a better patch in a moment | 19:25 |
| *** eduardas <eduardas!~eduardas@82-135-139-249.static.zebra.lt> has quit IRC | 19:26 | |
| kanavin_home | the one that directly prints: | 19:26 |
| kanavin_home | 2021-02-12 00:54:44,402 - oe-selftest - INFO - Reproducibility summary for ipk: same=11252 different=0 different_excluded=71 missing=0 total=11323 | 19:26 |
| kanavin_home | unused_exclusions={'quilt-ptest', 'valgrind-ptest', 'vim', 'meson', 'kernel-devsrc', 'git', 'groff', 'watchdog', 'ruby', 'dtc'} | 19:26 |
| *** sakoman <sakoman!~steve@72.173.249.164> has joined #yocto | 19:31 | |
| *** w00die <w00die!~w00die@212.91.255.186> has quit IRC | 19:35 | |
| *** sakoman <sakoman!~steve@72.173.249.164> has quit IRC | 19:36 | |
| *** vineela <vineela!vtummala@nat/intel/x-fdpgizmcjczzktft> has quit IRC | 19:36 | |
| *** sakoman <sakoman!~steve@72.173.249.164> has joined #yocto | 19:36 | |
| *** w00die <w00die!~w00die@212.91.255.186> has joined #yocto | 19:37 | |
| *** zkrx <zkrx!~slimshady@adsl-89-217-237-59.adslplus.ch> has quit IRC | 19:37 | |
| *** zkrx <zkrx!~slimshady@adsl-89-217-237-59.adslplus.ch> has joined #yocto | 19:39 | |
| *** vdl <vdl!~vivien@modemcable249.105-163-184.mc.videotron.ca> has joined #yocto | 19:41 | |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has quit IRC | 19:44 | |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has joined #yocto | 19:44 | |
| *** vineela <vineela!~vtummala@134.134.139.74> has joined #yocto | 20:04 | |
| rabbit9911 | It looks like python3-native is broken on 3.1.5 on epyc servers.. (still looking) | 20:04 |
| *** hpsy <hpsy!~hpsy@197.37.119.202> has quit IRC | 20:28 | |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 20:31 | |
| *** linums <linums!~linums@apn-94-44-234-44.vodafone.hu> has joined #yocto | 20:32 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 20:34 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC | 20:42 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 20:48 | |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 20:48 | |
| *** mcc_ <mcc_!~mccc@c-73-221-142-119.hsd1.wa.comcast.net> has quit IRC | 20:49 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 20:52 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 21:14 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 21:33 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 21:33 | |
| *** tgoodwin <tgoodwin!~tgoodwin@static-96-234-151-198.bltmmd.fios.verizon.net> has quit IRC | 21:35 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 21:39 | |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 21:39 | |
| *** linums <linums!~linums@apn-94-44-230-36.vodafone.hu> has joined #yocto | 21:40 | |
| *** vineela <vineela!~vtummala@134.134.139.74> has quit IRC | 21:43 | |
| *** feddischson <feddischson!~feddischs@HSI-KBW-095-208-248-008.hsi5.kabel-badenwuerttemberg.de> has quit IRC | 21:46 | |
| *** manuel1985 <manuel1985!~manuel198@213-147-162-79.nat.highway.bob.at> has quit IRC | 21:47 | |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 21:47 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 21:48 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 21:49 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 21:58 | |
| *** linums <linums!~linums@apn-94-44-230-36.vodafone.hu> has quit IRC | 21:59 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 22:00 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 22:06 | |
| *** bobo <bobo!~bobo@customer-145-14-101-3.stosn.net> has joined #yocto | 22:09 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 22:12 | |
| *** JaBen <JaBen!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has joined #yocto | 22:13 | |
| *** JaBen <JaBen!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has quit IRC | 22:14 | |
| vdl | It seems that setting VOLATILE_LOG_DIR = "no" recompiles everything :) | 22:17 |
| *** adelcast <adelcast!~adelcast@2603-8080-1e08-7cd8-fd30-b045-70ef-c7f1.res6.spectrum.com> has joined #yocto | 22:22 | |
| vdl | why though :/ | 22:33 |
| *** vineela <vineela!~vtummala@134.134.139.74> has joined #yocto | 22:36 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 22:48 | |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 22:48 | |
| moto-timo | JPEW: we need to have a call some day about icecream in a tekton context. It seems to me that a commodity device cluster could be running _many_ iceccd nodes. Ideally that would be containers running on k8s nodes. | 22:50 |
| moto-timo | JPEW: that might also be the path to scaling in the cloud (since passing sstate around is somewhat meh). | 22:51 |
| moto-timo | JPEW: also, do you have a public repo for the Dockerfiles from your docker hub images? | 22:51 |
| *** NiniC0c0 <NiniC0c0!56f67f06@lfbn-idf2-1-417-6.w86-246.abo.wanadoo.fr> has quit IRC | 23:04 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 23:05 | |
| JPEW | moto-timo: Ya. Using icecream would heavily depend on your usecase... I think more parallel builds (even with meh sstate) is probably always going to beat icecream | 23:07 |
| JPEW | But if you have a small number of mega builds that take forever, then it would make more sense | 23:07 |
| JPEW | I have not published my Dockerfiles... most of them are just modifications of the upstream ones (labgrid, crops); I've been a little tardy publishing them (and, I'm not sure if upstream can really take the changes anyway) | 23:09 |
| JPEW | Out of curosity, what's the meh part of sstate? | 23:10 |
| RP | kanavin_home: excellent, that sound great :) | 23:13 |
| moto-timo | true cloud: e.g. s3 storage of sstate has been reported to be entirely too slow to be useful. Instead people recommend passing tarballs around. | 23:13 |
| moto-timo | JPEW: I have no actual experience yet. | 23:13 |
| JPEW | moto-timo: I think S3 is the wrong backend to use. You want an NFS server backed with a reasonable disk | 23:14 |
| JPEW | I think you can get away with running an NFS server in a container backed by a persistentVolumeClaim | 23:15 |
| JPEW | (if you don't have access to a NFS server) | 23:15 |
| moto-timo | JPEW: I think NFS in the cloud starts to get us rapidly out of reasonably priced? | 23:15 |
| moto-timo | JPEW: I have two goals: local cluster (including a bunch of rpi4s, AWS/GCE/Azure/DigitalOcean/CloudDuJour | 23:16 |
| JPEW | It depends on how you do it.... for example if you use the "hosted" NFS servers like AWS EFS (which is probably really fast) that can be expensive | 23:17 |
| moto-timo | JPEW: that is what I meant from my limited knowledge | 23:18 |
| JPEW | But, if you just buy a e.g. 1TB block device and mount it as the backing to a container running an NFS server its pretty reasonable | 23:18 |
| JPEW | Not as cheap as S3, but not too bad | 23:18 |
| RP | I would love to actually set up an autobuilder in the cloud like that, have a set of the needed images ready on the shelf | 23:20 |
| JPEW | Also depends on what you classify as "expensive" | 23:20 |
| JPEW | RP: You're going to love my talk :) | 23:21 |
| neverpanic | Recently ran across our colo bill. I think we could buy a reasonable chunk of cloud for that price, too. | 23:21 |
| neverpanic | But yes, mounted NFS for download and sstate cache is what we use, works well. | 23:22 |
| JPEW | moto-timo: I priced out a 1TB sstate cache on Azure at ~$2000/yr. If you're doing cloud builds, that a pitance compared to what you pay to actually *do* any meaningful amount of builds | 23:22 |
| JPEW | And, that's using their hosted NFS "files" instead of a block device + NFS in Kubernetes... suprisingly it comes out cheaper until you start to get to larger sstate sizes | 23:24 |
| JPEW | And, that price assumes that your using the full 1TB for a whole year, when it's really pay-for-what-you-use | 23:25 |
| moto-timo | https://github.com/madisongh/tegra-test-distro/wiki/Using-AWS-S3-for-sstate-and-downloads-mirrors | 23:25 |
| *** dvhart <dvhart!~dvhart@50.39.132.186> has joined #yocto | 23:25 | |
| neverpanic | I doubt you need a TB of sstate. We do "turn the last build's sstate cache into an sstate mirror for the next build, delete everything that's not used". | 23:26 |
| moto-timo | matt had some changes to the "s3" fetcher... I have not tried it | 23:26 |
| neverpanic | sstate is < 100G | 23:26 |
| JPEW | neverpanic: Ah, but see if you use an NFS server, you don't need to do that | 23:26 |
| moto-timo | neverpanic: my sstate is bigger than that... lots of layers and configurations and I don't flush it often? | 23:27 |
| JPEW | Your builds directly use NFS as the sstate cache. There is no "upstream mirror" | 23:27 |
| neverpanic | JPEW: you eventually do, unless you want your sstate to grow unbounded. we're running a couple thousand builds a month, so really don't want every single one of those one-off builds to end up in your sstate forever. | 23:27 |
| moto-timo | we need this tribal knowledge to get out of the minds of those that have done it. It is very confusing for folks new to the cloud. | 23:27 |
| neverpanic | sstate-mirror on the same nfs has the advantage of creating symlinks, so its a case of replacing those symlinks with hardlinks after the build, then deleting the old mirror | 23:28 |
| moto-timo | @RP: I agree, an AB in the cloud would be fantastic | 23:28 |
| JPEW | neverpanic: Ah, sure. But you can do that out-of-band of your actually builds | 23:28 |
| RP | neverpanic: I know the autobuilder runs sstate into multiple TBs but the autobuilder workload is unusual | 23:28 |
| RP | and we do run cleanup on that | 23:28 |
| moto-timo | @RP: the AB is more sstate than I normally run, but exactly my point ;) | 23:29 |
| JPEW | neverpanic: And in that cause, S3 makes a lot of sense as an upstream | 23:29 |
| JPEW | But, you don't really want every build to have to figure out whats changed and upload it to S3... it's just slow. They should only read from it | 23:29 |
| JPEW | I know this because at $WORK we *don't* have NFS and have to rsync to a server at the end of every build. *sad trombone* | 23:30 |
| RP | JPEW: :( | 23:31 |
| *** bobo <bobo!~bobo@customer-145-14-101-3.stosn.net> has quit IRC | 23:32 | |
| JPEW | RP: I'm working on it... it just take a while | 23:33 |
| RP | JPEW: I know how companies work :/ | 23:34 |
| moto-timo | @RP or NOT | 23:34 |
| neverpanic | https://at.projects.genivi.org/wiki/download/attachments/16027368/GENIVI_AMM_2018_Achim_Demelt.pdf?version=1&modificationDate=1524099162000&api=v2 pages 4 and 7 have some numbers. apparently we're getting by with 30G of sstate cache. | 23:35 |
| neverpanic | but yeah, the autobuilder isn't exactly our use-case. | 23:35 |
| JPEW | moto-timo: I did a whole price breakdown a while ago for building in Azure, and you could get about 500,000 build-hours/year (with NFS sstate & hash equiv) for about $100,000 | 23:36 |
| neverpanic | that sonuds quite cheap, actually | 23:37 |
| RP | neverpanic: the autobuilder is different as it tests a ton of weird usecases nobody probably cares about as whole, only as some subset and we build all arches/libcs whereas anybody else probably again picks a subset | 23:37 |
| JPEW | neverpanic: Ya, it's not as bad as I though.... it really gives you drive to make builds as fast as possible to save costs. In that regard, NFS sstate pays for itself *really* quick | 23:38 |
| RP | JPEW: any idea how many build-hours we do on the autobuilder in a year? | 23:38 |
| JPEW | RP: I haven't the slightest idea | 23:38 |
| RP | JPEW: what is your definition of a build-hour ? | 23:38 |
| JPEW | One CPU/hour of build time | 23:38 |
| JPEW | build-hours is a bad metric. SHould be CPU-hours | 23:39 |
| RP | JPEW: one virtual cpu core? | 23:39 |
| JPEW | RP: Correct | 23:39 |
| RP | halstead: how many cpu cores do we have in typhoon, roughtly? | 23:40 |
| *** agust <agust!~agust@p5483356f.dip0.t-ipconnect.de> has quit IRC | 23:40 | |
| RP | I could do with a decent illustration that the autobuilder is cost effective :) | 23:40 |
| JPEW | RP: Oh, ya I'm sure the AB is a lot cheaper than the cloud would be... this also doesn't factor in artifact storage which would also cost money | 23:41 |
| RP | JPEW: I'm sure it is too but I'm forever being asked why we do this when cloud is obviously the solution ;-) | 23:42 |
| halstead | RP, On the controller? Just 2. | 23:42 |
| RP | halstead: sorry, I mean overall in the workers as in the overall infrastructure | 23:43 |
| halstead | RP, On the cluster... I can get that quickly. | 23:43 |
| RP | halstead: 56*24 ish? | 23:44 |
| moto-timo | halstead: I know you did an assessment of bare-metal vs. cloud at some point and bare-metal still one (or so I recall RP saying :) | 23:45 |
| halstead | RP, Yes. That's about how many hyperthreaded cores | 23:45 |
| RP | JPEW: so I think we have about 11million cpu-hours/year available | 23:45 |
| RP | halstead: thanks, I was just curious on a rough number, its interesting to see the "price" | 23:46 |
| RP | ($2,200,000 cloud cost) | 23:47 |
| halstead | moto-timo, Yes the colo plus three year hardware refresh was about 1/3 the price of similar capacity in a major cloud provider. Going with someone like Hetzner of OVH we could come close to price parity but there were network capability issues last time I looked. | 23:47 |
| JPEW | RP: Ya, if you were going to go that big you can do "Reserved capacity" where you basically rent a virtual instance permenatly which is usually about a 40% discount, but still | 23:47 |
| halstead | JPEW, We do look at reserved pricing. And we factor in non-profit discounts as well. | 23:48 |
| JPEW | Ah, ya | 23:48 |
| RP | JPEW: sorry, I didn't mean to derail your conversation. I was just curious how we compare with the numbers | 23:51 |
| JPEW | RP: Heh, it's ok. It's supper time anyway. Night all | 23:53 |
| RP | JPEW: 'night! | 23:53 |
| halstead | Good night. | 23:54 |
| *** dvhart <dvhart!~dvhart@50.39.132.186> has quit IRC | 23:55 | |
| * RP should sleep too | 23:56 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!