| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 00:24 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 00:29 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 252 seconds) | 00:29 | |
| *** mranostaj <mranostaj!~mranostaj@185.193.126.133> has quit IRC (Ping timeout: 245 seconds) | 00:50 | |
| *** mranostaj <mranostaj!~mranostaj@97-120-53-30.ptld.qwest.net> has joined #yocto | 00:50 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 00:53 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 276 seconds) | 00:58 | |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC (Read error: Connection reset by peer) | 01:17 | |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 01:18 | |
| *** rber|res <rber|res!~rber|res@ppp-2-86-139-252.home.otenet.gr> has joined #yocto | 01:32 | |
| *** RobertBerger <RobertBerger!~rber|res@ppp-2-86-139-252.home.otenet.gr> has quit IRC (Ping timeout: 252 seconds) | 01:34 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 01:54 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 276 seconds) | 01:59 | |
| *** wing0 <wing0!~wing0@2804:431:c7ed:6171:bb13:7508:2998:4a1b> has joined #yocto | 01:59 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 02:25 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 265 seconds) | 02:31 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.) | 02:38 | |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection) | 02:44 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 02:55 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 240 seconds) | 02:59 | |
| *** wing0 <wing0!~wing0@2804:431:c7ed:6171:bb13:7508:2998:4a1b> has quit IRC (Quit: WeeChat 3.1) | 03:01 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 03:26 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Read error: Connection reset by peer) | 03:30 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 03:30 | |
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC (Ping timeout: 268 seconds) | 03:41 | |
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto | 03:47 | |
| *** paulg <paulg!~Paul@104-195-159-20.cpe.teksavvy.com> has quit IRC (Ping timeout: 256 seconds) | 04:10 | |
| *** amitk <amitk!~amit@103.208.71.99> has joined #yocto | 04:24 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 240 seconds) | 04:33 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.81> has quit IRC (Ping timeout: 258 seconds) | 04:34 | |
| *** User523876 <User523876!~User52387@23.81.113.207> has joined #yocto | 04:43 | |
| User523876 | Anyone here know how I would go about changing a rootfs config file for a package in yocto? | 04:44 |
|---|---|---|
| *** User523876-2 <User523876-2!~User52387@23.81.113.207> has joined #yocto | 04:45 | |
| *** User523876 <User523876!~User52387@23.81.113.207> has quit IRC (Client Quit) | 04:45 | |
| *** georgem <georgem!uid210681@id-210681.tinside.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 05:14 | |
| User523876-2 | nobody? | 05:14 |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 05:28 | |
| User523876-2 | welcome to #deadchat | 05:28 |
| User523876-2 | ok bye | 05:46 |
| *** User523876-2 <User523876-2!~User52387@23.81.113.207> has quit IRC (Quit: Client closed) | 05:46 | |
| *** ant__ <ant__!~ant@host-82-54-240-211.retail.telecomitalia.it> has quit IRC (Ping timeout: 240 seconds) | 06:15 | |
| *** ant__ <ant__!~ant@host-79-54-252-190.retail.telecomitalia.it> has joined #yocto | 06:17 | |
| *** ant__ <ant__!~ant@host-79-54-252-190.retail.telecomitalia.it> has quit IRC (Client Quit) | 06:21 | |
| *** frieder <frieder!~frieder@p50937620.dip0.t-ipconnect.de> has joined #yocto | 06:32 | |
| *** sbach <sbach!~sbach@user/sbach> has quit IRC (Read error: Connection reset by peer) | 06:40 | |
| *** sbach <sbach!~sbach@user/sbach> has joined #yocto | 06:40 | |
| *** mckoan|away is now known as mckoan | 06:42 | |
| *** zpfvo <zpfvo!~fvo@i59F44C7D.versanet.de> has joined #yocto | 06:45 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 07:06 | |
| *** alimon <alimon!~alimon@ec2-54-225-101-41.compute-1.amazonaws.com> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 07:25 | |
| *** zyga <zyga!~zyga@31.0.173.147> has joined #yocto | 07:26 | |
| *** eduardas <eduardas!~eduardas@93.93.57.5> has joined #yocto | 07:31 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 07:33 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 07:53 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 07:59 | |
| *** bunk <bunk!~bunk@debian/bunk> has joined #yocto | 08:02 | |
| *** bizulk <bizulk!~bizulk@165.225.20.184> has joined #yocto | 08:08 | |
| *** eduardas <eduardas!~eduardas@93.93.57.5> has quit IRC (Quit: Konversation terminated!) | 08:13 | |
| wyre | why when I build an specific image bitbake is building all recipes in all layers? 🤔 | 08:14 |
| wyre | couldn't I restrict the build process to just the recipes that the image installs and their dependencies? | 08:15 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…) | 08:21 | |
| qschulz | wyre: this is what's done | 08:26 |
| wyre | qschulz, then why bitbake is building things that I don't need (for now they aren't included in my image recipe) like sudo? | 08:26 |
| qschulz | wyre: there are some build time dependencies that you have not explicitly listed in your image recipe | 08:27 |
| qschulz | it's building only what's requested | 08:28 |
| qschulz | nothing more | 08:28 |
| qschulz | so if it's building something you think you don't want/need, you'll need to debug it, because it is very likely an issue on your side | 08:28 |
| qschulz | bitbake -g <image recipe> and reading the .dot files with your favorite text editor should help you a bit | 08:29 |
| qschulz | also, it's not because something is built that it makes it to the target | 08:29 |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 08:43 | |
| *** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto | 08:47 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has joined #yocto | 08:52 | |
| LetoThe2nd | yo dudX | 08:52 |
| * qschulz waves | 08:52 | |
| mckoan | hey | 08:57 |
| alicef | hello, I'm trying to enable BB_GIT_SHALLOW but dosen't metter how I set it up the linux-libc-header git package get downloaded without --depth | 08:58 |
| alicef | mckoan: o/ | 08:58 |
| *** kayterina <kayterina!~kayterina@chios.esd.ece.ntua.gr> has joined #yocto | 08:59 | |
| mckoan | alicef: konnichiwa :-) | 08:59 |
| alicef | mckoan: do you know something about BB_GIT_SHALLOW ? | 09:08 |
| RP | michaelo[m]: I'm thinking about how to handle documenting the overrides change. Are you looking at that or should I try and write something about it to get started? | 09:13 |
| mckoan | alicef: probably Paul Barker | 09:33 |
| mckoan | alicef: or definitely RP | 09:34 |
| * paulbarker ears perk up | 09:35 | |
| mckoan | paulbarker: I didn't rememer your nickname :-) | 09:35 |
| mckoan | *remember | 09:35 |
| paulbarker | `BB_GIT_SHALLOW` probably does need documenting, I understand some of what it does. I only ever use it in combination with `BB_GENERATE_MIRROR_TARBALLS` & `BB_GENERATE_SHALLOW_TARBALLS` | 09:37 |
| paulbarker | In that combination it creates tarballs consisting of just the commit referenced in `SRCREV` instead of the full history | 09:38 |
| paulbarker | The same settings allow those tarballs to be pulled from a mirror | 09:38 |
| paulbarker | Not sure on the behaviour of `BB_GIT_SHALLOW` on its own without re-reading the relevant bitbake sources | 09:38 |
| paulbarker | alicef: The initial download will always be non-shallow | 09:39 |
| paulbarker | That's a limitation of git not of bitbake | 09:39 |
| mckoan | https://www.openembedded.org/pipermail/bitbake-devel/2017-May/008640.html | 09:40 |
| paulbarker | mckoan: Good link. The second paragraph of that commit message explains it perfectly | 09:41 |
| *** camus <camus!~Instantbi@202.168.169.42> has joined #yocto | 09:42 | |
| RP | Is that in the manual? If not, it should be... | 09:43 |
| paulbarker | RP: https://docs.yoctoproject.org/search.html?q=BB_GIT_SHALLOW&check_keywords=yes&area=default | 09:43 |
| RP | I guess I'll write a bug for it | 09:45 |
| RP | https://bugzilla.yoctoproject.org/show_bug.cgi?id=14493 | 09:47 |
| paulbarker | RP: I'll take that one as I have the context here | 09:49 |
| paulbarker | Should be a quick job to add it to the docs | 09:50 |
| RP | paulbarker: ok, thanks! | 09:50 |
| *** camus <camus!~Instantbi@202.168.169.42> has quit IRC (Ping timeout: 276 seconds) | 09:52 | |
| *** jordemort <jordemort!~jordemort@2001:470:69fc:105::2d9> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** cody <cody!~cody@user/cody> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** khem <khem!~khemmatri@2001:470:69fc:105::b81> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** SamuelDolt[m] <SamuelDolt[m]!~samdoltma@2001:470:69fc:105::4898> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** t_unix[m] <t_unix[m]!~tunixmatr@2001:470:69fc:105::9ea> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** barath <barath!~barath@2001:470:69fc:105::21a> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** jwillikers[m] <jwillikers[m]!~jwilliker@2001:470:69fc:105::626a> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** hmw[m] <hmw[m]!~hmwmatrix@2001:470:69fc:105::3c7c> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** kayterina[m] <kayterina[m]!~kayterina@2001:470:69fc:105::960> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** moto_timo[m] <moto_timo[m]!~mototimom@2001:470:69fc:105::c94> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** asus_986_gpu[m] <asus_986_gpu[m]!~asus986gp@2001:470:69fc:105::1014> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** dwagenk <dwagenk!~dwagenk@2001:470:69fc:105::103d> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** PascalBach[m] <PascalBach[m]!~bachpmatr@2001:470:69fc:105::1d3b> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** JonasVautherin[m <JonasVautherin[m!~jonasvaut@2001:470:69fc:105::68d5> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** jonesv[m] <jonesv[m]!~jonesvmat@2001:470:69fc:105::4616> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** Saur[m] <Saur[m]!~saur2000m@2001:470:69fc:105::dce> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** SnowBeast[m] <SnowBeast[m]!~snowbeast@2001:470:69fc:105::b4c8> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** lacouture[m] <lacouture[m]!~lacouture@2001:470:69fc:105::35b7> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** timbert[m] <timbert[m]!~timbertma@2001:470:69fc:105::b533> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** nicolas[m]12 <nicolas[m]12!~nicolasma@2001:470:69fc:105::b5f4> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** Pierre-jeanTexie <Pierre-jeanTexie!~pjtexierm@2001:470:69fc:105::f2f> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** alex88[m] <alex88[m]!~alex88moz@2001:470:69fc:105::ce4> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** keepitsimplejim[ <keepitsimplejim[!~keepitsim@2001:470:69fc:105::3630> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** michaelo[m] <michaelo[m]!~michael-o@2001:470:69fc:105::be7c> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** rodrjassoccom[m] <rodrjassoccom[m]!~rodrjasso@2001:470:69fc:105::4019> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** xicopitz[m] <xicopitz[m]!~xicopitzm@2001:470:69fc:105::4869> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** christophs[m] <christophs[m]!~christo_1@2001:470:69fc:105::b964> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** shoragan|m <shoragan|m!~shoragans@2001:470:69fc:105::c9f> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** Alban[m] <Alban[m]!~albeugaen@2001:470:69fc:105::34b4> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** fabatera[m] <fabatera[m]!~fabateram@2001:470:69fc:105::18d5> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** Spectrejan[m] <Spectrejan[m]!~spectreja@2001:470:69fc:105::1609> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** Emantor[m] <Emantor[m]!~emantorm]@2001:470:69fc:105::8eb> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** lexano[m] <lexano[m]!~lexanomat@2001:470:69fc:105::3110> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** TrevorWoerner[m] <TrevorWoerner[m]!~trevorwoe@2001:470:69fc:105::4e57> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** meck[m] <meck[m]!~meckmeckd@2001:470:69fc:105::3a51> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** m1kr0[m] <m1kr0[m]!~m1kr0matr@2001:470:69fc:105::c827> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** ndec[m] <ndec[m]!~ndecmatri@2001:470:69fc:105::9c0> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** TurtleCrazy[m] <TurtleCrazy[m]!~patronkre@2001:470:69fc:105::bd44> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** tokamak[m] <tokamak[m]!~tokamakma@2001:470:69fc:105::c4df> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** ejoerns[m] <ejoerns[m]!~ejoernsma@2001:470:69fc:105::252> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** AlessandroTaglia <AlessandroTaglia!~al3x88mat@2001:470:69fc:105::ce3> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** behanw[m] <behanw[m]!~behanwmat@2001:470:69fc:105::c96> has quit IRC (Quit: Bridge terminating on SIGTERM) | 10:36 | |
| *** jordemort <jordemort!~jordemort@2001:470:69fc:105::2d9> has joined #yocto | 10:39 | |
| *** frieder <frieder!~frieder@p50937620.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 265 seconds) | 10:39 | |
| *** meck[m] <meck[m]!~meckmeckd@2001:470:69fc:105::3a51> has joined #yocto | 10:39 | |
| *** camus <camus!~Instantbi@120.198.34.172> has joined #yocto | 10:41 | |
| *** kayterina[m] <kayterina[m]!~kayterina@2001:470:69fc:105::960> has joined #yocto | 10:46 | |
| *** Emantor[m] <Emantor[m]!~emantorm]@2001:470:69fc:105::8eb> has joined #yocto | 10:46 | |
| *** Saur[m] <Saur[m]!~saur2000m@2001:470:69fc:105::dce> has joined #yocto | 10:46 | |
| *** khem <khem!~khemmatri@2001:470:69fc:105::b81> has joined #yocto | 10:46 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has joined #yocto | 10:46 | |
| *** cody <cody!~cody@user/cody> has joined #yocto | 10:46 | |
| *** Pierre-jeanTexie <Pierre-jeanTexie!~pjtexierm@2001:470:69fc:105::f2f> has joined #yocto | 10:46 | |
| *** ejoerns[m] <ejoerns[m]!~ejoernsma@2001:470:69fc:105::252> has joined #yocto | 10:46 | |
| *** moto_timo[m] <moto_timo[m]!~mototimom@2001:470:69fc:105::c94> has joined #yocto | 10:46 | |
| *** t_unix[m] <t_unix[m]!~tunixmatr@2001:470:69fc:105::9ea> has joined #yocto | 10:46 | |
| *** hmw[m] <hmw[m]!~hmwmatrix@2001:470:69fc:105::3c7c> has joined #yocto | 10:46 | |
| *** jwillikers[m] <jwillikers[m]!~jwilliker@2001:470:69fc:105::626a> has joined #yocto | 10:46 | |
| *** barath <barath!~barath@2001:470:69fc:105::21a> has joined #yocto | 10:46 | |
| *** TrevorWoerner[m] <TrevorWoerner[m]!~trevorwoe@2001:470:69fc:105::4e57> has joined #yocto | 10:46 | |
| *** SamuelDolt[m] <SamuelDolt[m]!~samdoltma@2001:470:69fc:105::4898> has joined #yocto | 10:46 | |
| *** keepitsimplejim[ <keepitsimplejim[!~keepitsim@2001:470:69fc:105::3630> has joined #yocto | 10:46 | |
| *** lexano[m] <lexano[m]!~lexanomat@2001:470:69fc:105::3110> has joined #yocto | 10:46 | |
| *** Alban[m] <Alban[m]!~albeugaen@2001:470:69fc:105::34b4> has joined #yocto | 10:46 | |
| *** shoragan|m <shoragan|m!~shoragans@2001:470:69fc:105::c9f> has joined #yocto | 10:46 | |
| *** alex88[m] <alex88[m]!~alex88moz@2001:470:69fc:105::ce4> has joined #yocto | 10:46 | |
| *** Spectrejan[m] <Spectrejan[m]!~spectreja@2001:470:69fc:105::1609> has joined #yocto | 10:46 | |
| *** rodrjassoccom[m] <rodrjassoccom[m]!~rodrjasso@2001:470:69fc:105::4019> has joined #yocto | 10:46 | |
| *** AlessandroTaglia <AlessandroTaglia!~al3x88mat@2001:470:69fc:105::ce3> has joined #yocto | 10:46 | |
| *** asus_986_gpu[m] <asus_986_gpu[m]!~asus986gp@2001:470:69fc:105::1014> has joined #yocto | 10:46 | |
| *** xicopitz[m] <xicopitz[m]!~xicopitzm@2001:470:69fc:105::4869> has joined #yocto | 10:46 | |
| *** ndec[m] <ndec[m]!~ndecmatri@2001:470:69fc:105::9c0> has joined #yocto | 10:46 | |
| *** JonasVautherin[m <JonasVautherin[m!~jonasvaut@2001:470:69fc:105::68d5> has joined #yocto | 10:46 | |
| *** m1kr0[m] <m1kr0[m]!~m1kr0matr@2001:470:69fc:105::c827> has joined #yocto | 10:46 | |
| *** PascalBach[m] <PascalBach[m]!~bachpmatr@2001:470:69fc:105::1d3b> has joined #yocto | 10:46 | |
| *** lacouture[m] <lacouture[m]!~lacouture@2001:470:69fc:105::35b7> has joined #yocto | 10:46 | |
| *** behanw[m] <behanw[m]!~behanwmat@2001:470:69fc:105::c96> has joined #yocto | 10:46 | |
| *** christophs[m] <christophs[m]!~christo_1@2001:470:69fc:105::b964> has joined #yocto | 10:46 | |
| *** tokamak[m] <tokamak[m]!~tokamakma@2001:470:69fc:105::c4df> has joined #yocto | 10:46 | |
| *** TurtleCrazy[m] <TurtleCrazy[m]!~patronkre@2001:470:69fc:105::bd44> has joined #yocto | 10:46 | |
| *** michaelo[m] <michaelo[m]!~michael-o@2001:470:69fc:105::be7c> has joined #yocto | 10:46 | |
| *** jonesv[m] <jonesv[m]!~jonesvmat@2001:470:69fc:105::4616> has joined #yocto | 10:46 | |
| *** timbert[m] <timbert[m]!~timbertma@2001:470:69fc:105::b533> has joined #yocto | 10:46 | |
| *** SnowBeast[m] <SnowBeast[m]!~snowbeast@2001:470:69fc:105::b4c8> has joined #yocto | 10:46 | |
| *** fabatera[m] <fabatera[m]!~fabateram@2001:470:69fc:105::18d5> has joined #yocto | 10:46 | |
| *** dwagenk <dwagenk!~dwagenk@2001:470:69fc:105::103d> has joined #yocto | 10:46 | |
| *** nicolas[m]12 <nicolas[m]12!~nicolasma@2001:470:69fc:105::b5f4> has joined #yocto | 10:46 | |
| *** jmiehe1 <jmiehe1!~Thunderbi@user/jmiehe> has joined #yocto | 10:47 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Ping timeout: 268 seconds) | 10:48 | |
| *** jmiehe1 is now known as jmiehe | 10:48 | |
| *** camus <camus!~Instantbi@120.198.34.172> has quit IRC (Ping timeout: 245 seconds) | 10:49 | |
| *** frieder <frieder!~frieder@i4DF677E2.static.tripleplugandplay.com> has joined #yocto | 10:51 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 10:52 | |
| *** camus <camus!~Instantbi@120.198.34.172> has joined #yocto | 11:01 | |
| *** camus <camus!~Instantbi@120.198.34.172> has quit IRC (Read error: Connection reset by peer) | 11:03 | |
| *** camus <camus!~Instantbi@120.198.34.172> has joined #yocto | 11:03 | |
| *** Net147 <Net147!~Net147@user/net147> has quit IRC (Quit: Quit) | 11:06 | |
| *** Net147 <Net147!~Net147@167-179-157-192.a7b39d.syd.nbn.aussiebb.net> has joined #yocto | 11:08 | |
| *** camus <camus!~Instantbi@120.198.34.172> has quit IRC (Ping timeout: 252 seconds) | 11:24 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 11:37 | |
| *** georgem <georgem!uid210681@id-210681.tinside.irccloud.com> has joined #yocto | 11:39 | |
| *** paulg <paulg!~Paul@104-195-159-20.cpe.teksavvy.com> has joined #yocto | 12:12 | |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto | 12:28 | |
| *** argonautx <argonautx!~argonautx@gw.hyperstone.de> has joined #yocto | 12:31 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 12:34 | |
| *** nucatus_ <nucatus_!nucatus@gateway/vpn/protonvpn/nucatus> has joined #yocto | 12:43 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 252 seconds) | 12:45 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 12:53 | |
| *** nucatus_ <nucatus_!nucatus@gateway/vpn/protonvpn/nucatus> has quit IRC (Ping timeout: 268 seconds) | 12:57 | |
| *** alimon <alimon!~alimon@ec2-54-225-101-41.compute-1.amazonaws.com> has joined #yocto | 13:00 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Remote host closed the connection) | 13:10 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 13:11 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Remote host closed the connection) | 13:12 | |
| *** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 13:15 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 252 seconds) | 13:15 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 13:18 | |
| *** buffo <buffo!~madeleine@p509928d0.dip0.t-ipconnect.de> has joined #yocto | 13:31 | |
| *** buffo <buffo!~madeleine@p509928d0.dip0.t-ipconnect.de> has left #yocto | 13:31 | |
| *** nucatus_ <nucatus_!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 13:31 | |
| *** rosa <rosa!~madeleine@p509928d0.dip0.t-ipconnect.de> has joined #yocto | 13:33 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.209> has joined #yocto | 13:34 | |
| *** rosa <rosa!~madeleine@p509928d0.dip0.t-ipconnect.de> has quit IRC (Client Quit) | 13:34 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 272 seconds) | 13:35 | |
| *** nucatus_ <nucatus_!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Read error: Connection reset by peer) | 13:40 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 13:40 | |
| *** rosa <rosa!~madeleine@p509928d0.dip0.t-ipconnect.de> has joined #yocto | 13:41 | |
| *** camus <camus!~Instantbi@113.83.121.13> has joined #yocto | 13:49 | |
| *** kayterina <kayterina!~kayterina@chios.esd.ece.ntua.gr> has quit IRC (Remote host closed the connection) | 13:55 | |
| *** rosa <rosa!~madeleine@p509928d0.dip0.t-ipconnect.de> has quit IRC (Quit: Konversation terminated!) | 14:00 | |
| *** eduardas <eduardas!~eduardas@93.93.57.5> has joined #yocto | 14:06 | |
| *** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-21-184-145-222-193.dsl.bell.ca> has joined #yocto | 14:07 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 14:08 | |
| vd | JPEW in the context of multiple hardware and multiple customers, how do you map this with whisk products and modes? | 14:08 |
| JaMa | RP: looks like icecc_dep_prepend in icecc.bbclass will need similar exception in the scripts/contrib/convert-overrides.py as you already did for base_dep_prepend and autotools_dep_prepend. Or can we use different function names to not look as an override? | 14:12 |
| JPEW | vd: I would make one product per machine-customer pair | 14:15 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 14:15 | |
| vd | I see | 14:16 |
| JPEW | vd: But, you can share a large amount of the configuration through various means :) | 14:17 |
| RP | JaMa: I did think about renaming those. prepend in a function name like that wasn't ever really supported | 14:18 |
| RP | JaMa: I'll fix that one way or another, thanks | 14:18 |
| *** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 265 seconds) | 14:20 | |
| JaMa | RP: thanks, another interesting case might be: | 14:22 |
| JaMa | -def webos_configure_manifest_comment_remover(text): | 14:22 |
| JaMa | +def webos_configure_manifest_comment:remover(text): | 14:22 |
| RP | JaMa: these are going to be the painful part, it is most of the exclusion list in the script :/ | 14:22 |
| JaMa | but I understand that there is a limit of what this script can handle | 14:22 |
| vd | JPEW one cool thing with kas was that using their docker container, I can simply have a wrapper script in the root of the project which calls docker run. No need to prefetch the tool, quite convenient. | 14:24 |
| RP | JaMa: I guess the next step would be to separate out the append/remove/prepend handling and try to exclude anti-patterns from the exclusion | 14:24 |
| JPEW | vd: Ya, the bootstrap in whisk could be better | 14:24 |
| JaMa | good that in this case it causes parsing issue which cannot be overlooked (instead of silenly using "remover" as an override on completely unused variable | 14:24 |
| vd | JPEW other than publishing a container image along with whisk release, I don't see how you could simplify the bootstrap unfortunately. But I understood Pyrex doesn't work quite like a classic container. | 14:26 |
| RP | JaMa: right, it does tend to at least break things visibly :) | 14:26 |
| alicef | paulbarker: why not just use --depth 1 ? | 14:26 |
| JPEW | vd: whisk doesn't run in Pyrex FWIW, and you can have whisk fetch Pyrex with --fetch | 14:26 |
| JPEW | vd: I suspect that the easiest would be to publish whisk as a python module so it can be used with `pip install` | 14:27 |
| JaMa | and any idea why I would see bitbake-server hanging after these parsing issues? I wasn't seeing any hangs recently, but today couple times already with: | 14:27 |
| JaMa | martin 2981210 0.0 0.0 87416 40876 ? S 15:38 0:01 bitbake-server /OE/bitbake/bin/bitbake-server decafbad 3 5 /OE/build/oe-core/bitbake-cookerdaemon.log /OE/build/oe-core/bitbake.lock /OE/build/oe-core/bitbake.sock 0 None 0 | 14:27 |
| vd | JPEW indeed, that's what kas does. It's a python package, and they have a docker container per release containing the yocto build tools and the said package | 14:29 |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 14:30 | |
| JPEW | vd: Ya, it would be difficulty to publish whisk itself in a container, but it can bootstrap pyrex to run actual builds.... would you mind raising an issue in GitHub to publish whisk as a python package? | 14:31 |
| vd | JPEW sure | 14:32 |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.209> has quit IRC (Ping timeout: 240 seconds) | 14:34 | |
| JaMa | RP: also please add print("processing file '%s'" % fn) at the top of processfile() or something similar as on bigger layer this script takes couple minutes without showing any progress | 14:37 |
| vd | JPEW in fact maybe the simpler would be to strongly recommend the usage of submodules with whisk. Like docker containers, they can be the simplest way to fetch the necessary module in an agnostic way (python tools for non pythonistas can really be a PITA) | 14:39 |
| vd | (again, there would be submodules handled by whisk and other managed by the developer itself, might be confusing) | 14:40 |
| JPEW | vd: The way we use it gives us the best of both worlds: developers do `git submodule update --init` and they get everything, but CI does `git submodule update whisk && . init-build-env --fetch` and it only gets the submodules actually required for the build | 14:41 |
| vd | I see | 14:43 |
| *** RobertBerger <RobertBerger!~rber|res@ppp-2-86-128-196.home.otenet.gr> has joined #yocto | 14:43 | |
| *** rber|res <rber|res!~rber|res@ppp-2-86-139-252.home.otenet.gr> has quit IRC (Ping timeout: 250 seconds) | 14:44 | |
| vd | JPEW for info, my repository is a private layer itself, with a kas yaml file in its root along with this wrapper: https://github.com/siemens/kas/issues/22#issuecomment-881065487 | 14:45 |
| vd | The kas config isn't as convenient as whisk (no good abstraction of a product), but the only requirement for the host is docker. | 14:47 |
| JPEW | vd: Ya, I guess with whisk you need git, docker, & python | 14:48 |
| vd | Maybe the project root can be a whisk fork itself :) | 14:50 |
| JPEW | vd: You could do that; you would still need git, docker & python though ;). It would make the bootstrap easier, though | 14:51 |
| JPEW | vd: subtree merge whisk into your project would probably be the best option if you want to avoid the submodule, IMHO | 14:51 |
| vd | yes these are standard tools for a developer, no big deal | 14:52 |
| JPEW | vd: https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt | 14:52 |
| vd | Thanks, I'll continue my quest for the simpler customer/hardware combination builds ;-) | 14:53 |
| vd | Unrelated question: would IMAGE_VERSION_SUFFIX be appropriate to use the build number from the CI environment? | 14:54 |
| JPEW | vd: We set `BUILDNAME` | 14:56 |
| vd | in other words, can IMAGE_VERSION_SUFFIX be set to SOME_JENKINS_ENV_VAR or fallback to a default value? | 14:56 |
| vd | JPEW is BUILDNAME whisk-specific? | 14:56 |
| JPEW | vd: No | 14:56 |
| JPEW | vd: On Jenkins, we do `echo "BUILDNAME = \"${BUILD_TAG}\"" >> local.conf` | 14:57 |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.50> has joined #yocto | 14:58 | |
| vd | oh ok | 14:58 |
| vd | JPEW you might want to use auto.conf for that | 14:58 |
| JPEW | vd: Sure | 14:58 |
| vd | but I get the idea | 14:58 |
| JaMa | vd: we do something similar in webOS builds, that's why I've added those variables to oe-core, but it's still not complete (for how we use it) | 15:00 |
| *** bps <bps!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto | 15:06 | |
| *** frieder <frieder!~frieder@i4DF677E2.static.tripleplugandplay.com> has quit IRC (Ping timeout: 250 seconds) | 15:12 | |
| RP | zeddii: FWIW I was able to reproduce that stap failure with genericx86-64 under qemu | 15:17 |
| JaMa | zeddii: you will need to re-run the conversion script in master-next or fix newly added overrides in recipes-extended/images/xen-image-minimal.bb | 15:17 |
| RP | zeddii: I did fix that PKG_INFO in the conversion script btw | 15:18 |
| JaMa | zeddii: https://github.com/shr-project/meta-virtualization/commit/ffd9d1c6a9ff35e4d2215054ec9e38dbc7a2fe03 | 15:19 |
| *** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 250 seconds) | 15:29 | |
| michaelo[m] | Anything wrong with the Matrix interface? | 15:36 |
| michaelo[m] | Hey | 15:36 |
| michaelo[m] | According to https://www.yoctoproject.org/community/mailing-lists/, this Matrix channel is supposed to mirror the discussions on #yocto on irc.libera.chat. Obviously, it's not the case as https://libera.irclog.whitequark.org/yocto/2021-07-29 has many more messages. | 15:36 |
| *** eduardas <eduardas!~eduardas@93.93.57.5> has quit IRC (Quit: Konversation terminated!) | 15:39 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Remote host closed the connection) | 15:41 | |
| vd | Is there a variable referring to the multiconfig being used? i.e. foo in mc:foo:core-image-minimal? | 15:41 |
| JaMa | BB_CURRENT_MC? | 15:43 |
| vd | JaMa is it documented somewhere? | 15:45 |
| qschulz | michaelo[m]: I assume halstead is taking care of that and is the person to contact but I may be wrong :) | 15:45 |
| JaMa | vd: you can watch JPEW's talk from last summit I think he mentioned it there as well | 15:46 |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 15:46 | |
| JPEW | JaMa: BB_CURRENT_MC.... *except* that it's not correct for the "base" multiconfig (e.g. where no multiconfig is active) | 15:47 |
| JPEW | JaMa: There is has the value "default", but you can't plug that into an `mcdepends` for example | 15:47 |
| * JaMa is lucky enough not to use MC at all :) | 15:47 | |
| JPEW | JaMa: It's actually really nice, I like it a lot :) | 15:48 |
| fleg | michaelo[m], I think this mirroring is done on the Matrix side, so it would be a question to the matrix.org staff | 15:48 |
| JaMa | lucky not to need it :) | 15:48 |
| JPEW | JaMa: Fair, it does get more complicated :) | 15:50 |
| vd | JPEW any specific reason why whisk moves DEPLOY_DIR out of TMPDIR? | 15:51 |
| zeddii | hah. I had just done pass #2 and pushed a separate commit to master-next on the conversion. :D | 15:51 |
| zeddii | RP: aha. that's good. I'm not going to have much for cycles for fixing much until Aug 12th. I'll be reading my opensource email, but am on vacation from now until then, | 15:51 |
| JPEW | vd: No, just our preferred layout. PR to make it configurable (if it's not already) welcome :) | 15:52 |
| zeddii | RP: the stap SRCREV bump was trivial when I did it here, but there wasn't much that looked like it would address the error. | 15:52 |
| halstead | qschulz: michaelo[m]: I'm not running the matrix bridge. I can't recall who is at the moment. Maybe khem knows? | 15:55 |
| RP | zeddii: it looks to be the difference between the kernel asm/pthread.h and the userspace asm/pthread.h | 15:57 |
| *** bizulk <bizulk!~bizulk@165.225.20.184> has quit IRC (Quit: Client closed) | 15:58 | |
| JaMa | RP: FYI: the script doesn't replace RDEPENDS_${PN}-ptest_remove_class-target (which I have quite a few of these) | 15:58 |
| zeddii | RP: yah, this is what always happened with perf as well. We had to capture copes of headers, etc. | 15:58 |
| zeddii | RP: remind me, what is the mix, this is current stap on master with the 5.13 libc-headers ? | 15:59 |
| RP | zeddii: yes. Enjoy the vacation, I'll poke at it a bit more | 15:59 |
| zeddii | and so it only happens on 5.10 and 5.4 ? I could delete those kernels ;) (kidding). | 16:00 |
| RP | zeddii: I think so, not sure yet | 16:00 |
| zeddii | RP: I am around for the next few hours (then packing), but I fired up some builds of genericx86-64, 5.10 kernel preference and systemtap. I'll see if I can make it go boom on the booted target as well. | 16:03 |
| *** mckoan is now known as mckoan|away | 16:05 | |
| RP | zeddii: cd /usr/src/kernel; make scripts prepare; stap --disable-cache -DSTP_NO_VERREL_CHECK /tmp/hello.stp seems to make it happen in short order | 16:06 |
| RP | pulling hello.stp from the meta/lib/oeqa/runtime/files | 16:06 |
| zeddii | yah. that's how I always test stap. I just scp on the bits I need from the tests. so that's good. | 16:07 |
| * paulg tries to think of large patch series to fill zeddii vaca inbox with | 16:07 | |
| * zeddii shakes his fist | 16:08 | |
| vd | TMPDIR *must* be different for every variant of hardware, libc, etc., but is it same to share a common DEPLOY_DIR_IMAGE? | 16:09 |
| JPEW | vd: That would be tricky | 16:09 |
| paulg | RP, I saw today that linux-stable picked up our cgroup/LTP fix for v5.10 and v5.4 and v5.13 ; not that we really care ; zeddii put it where needed already IIRC. | 16:10 |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 16:12 | |
| vd | is it safe* | 16:13 |
| JPEW | vd: Maybe... it would depend on having no multiconfigs that overwrite the same files | 16:14 |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving) | 16:17 | |
| vd | indeed. I *just* need to make sure that filenames are unique for every multiconfig (including the default) | 16:18 |
| JPEW | vd: I think so... one way to make sure they are all unique is to put each in it's own directory ;) | 16:18 |
| *** yates <yates!~user@096-036-098-109.biz.spectrum.com> has joined #yocto | 16:19 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 272 seconds) | 16:20 | |
| vd | indeed. | 16:20 |
| vd | But isn't there a feature of the deploy class or anything to ensure that you're not overriding a file from another recipe? | 16:21 |
| vd | that'd be just perfect. | 16:21 |
| *** creich_ <creich_!~creich@p200300f6af354710000000000000039b.dip0.t-ipconnect.de> has quit IRC (Read error: Connection reset by peer) | 16:22 | |
| *** bps <bps!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto | 16:23 | |
| vd | The thing is I never really understand why DEPLOY_DIR_IMAGE contains ${MACHINE}, if TMPDIR is expected to be different for any machine/libc/distro combinations. Isn't it redundant and useless? | 16:35 |
| fray | tmpdir is distro specific, you can build multiple machines in a distro | 16:35 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Ping timeout: 250 seconds) | 16:36 | |
| vd | fray but you shouldn't share the same TMPDIR for different machines, right? | 16:38 |
| fray | I build multiple machines with the same TMPDIR all the time.. it's the distro configurations (and sdkmachine) that need specific TMPDIR | 16:39 |
| vd | ho | 16:39 |
| vd | fray so you're saying you can safely build a distro for x86 and arm in the same TMPDIR, as long as the distro conf is the same? | 16:40 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 16:40 | |
| kergoth | vd: yes | 16:43 |
| vd | fray this doc says the opposite: you can basically share the TMPDIR for two distros built for the same hardware: https://docs.yoctoproject.org/singleindex.html#setting-up-and-running-a-multiple-configuration-build | 16:43 |
| vd | I might be confused | 16:43 |
| fray | "multiconfig" is different. These need their own TMPDIR because they may be writing tmp files, even for multiple machines.. | 16:44 |
| fray | the TMPDIR sharing between multiple _machines_ is from single (non-multiconfig) builds | 16:44 |
| vd | ho ok | 16:45 |
| vd | I'm having hard time figuring out how to properly separate the config for "a customer build", which is a given hardware (or multiple), a given distro (always the same) and tweaks to the default image recipes. | 16:47 |
| vd | I thought maybe distro conf + auto.conf was enough but I guess multiconfig really is what's needed here | 16:48 |
| *** argonautx <argonautx!~argonautx@gw.hyperstone.de> has quit IRC (Ping timeout: 272 seconds) | 16:48 | |
| kergoth | multiconfig is just a way to kick off multiple builds with differing configuration in a single bitbake command | 16:48 |
| kergoth | well, mostly. you can still build those without it, is the point, just via changing local/auto | 16:48 |
| vd | JaMa: btw is there a way to override "default" in BB_CURRENT_MC? (e.g. if I want "vanilla" instead). | 16:48 |
| kergoth | you dont need to override anything, just where you *use* that variable you'd use inline python if 'default' isn't the value you need | 16:49 |
| vd | kergoth: ok so I must see a multiconfig as a clean way to store a known config, instead of hacking on local/auto | 16:50 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 16:51 | |
| kergoth | yeah, it's a way of encoding that knowledge as well as being able to build them all in one go, without having to encode that knowledge in your CI jobs or something... | 16:51 |
| vd | ( kergoth: it's just that "vanilla" is more obvious than "default" in our company vocabulary, so BB_DEFAULT_MC ?= "vanilla" would be convenient, but inline python is fine ;-) ) | 16:51 |
| kergoth | still, i'd recommend minimizing local config. if you're changing the default images, you probably just want your own images, for example | 16:51 |
| vd | kergoth I figure appending the default images would be cleaner since I have a distro, a few machines, default (vanilla) images, then for each customer there small tweaks to do, like overriding the default root password via EXTRA_USER_PARAMS, embedding custom images via ROOTFS_POSTPROCESS_COMMAND, etc. | 16:55 |
| vd | A multiconfig for each customer combination seemed more appropriate than defining their own image recipes. Would you recommend a different approach? | 16:56 |
| *** zpfvo <zpfvo!~fvo@i59F44C7D.versanet.de> has quit IRC (Quit: Leaving.) | 16:56 | |
| RP | paulg: I saw, nice it made it through. What about the RCU stall thing? :) | 16:56 |
| kergoth | ah, yeah, if there were image hcanges common to all customers itd make sense to create your own images for your distro, but if not what you're doing makes sense | 16:56 |
| RP | paulg: as you say, "we're" kind of sorted now | 16:56 |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Client closed) | 16:58 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 16:59 | |
| vd | kergoth: so I would have a generic distro-image-base recipe, and something like IMAGE_INSTALL_pn-distro-image-base_append = " customer-conf" in a multiconfig. | 17:01 |
| vd | But even though it's not technically correct, a different machine configuration for every customer would be way simpler? | 17:02 |
| paulg | RP, the 406a2f008f2e RCU stall still languishes in -next and not mainline, as paulmck effectively does a two release soak cycle for any given change. | 17:07 |
| paulg | (and linux-stable won't normally touch anything that isn't in mainline yet) | 17:08 |
| RP | zeddii: Adding -DSTAPCONF_X86_UNIREGS to the stap command makes it work | 17:11 |
| RP | paulg: for what is a pretty horrible machine crash, that is a bit sad :( | 17:12 |
| RP | Does anyone know anything about how systemtap sorts these defines? | 17:13 |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 17:13 | |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection) | 17:15 | |
| RP | zeddii: https://sourceware.org/git/?p=systemtap.git;a=commitdiff;h=ef5a8b9eda402e4e96c4e3ce01e7ff95d3e10470 is the fix | 17:16 |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 240 seconds) | 17:17 | |
| *** michaelo <michaelo!~mike@shells.bootlin.com> has joined #yocto | 17:21 | |
| RP | moto-timo: ^^^ - looks like we have the problem identified | 17:21 |
| michaelo | Back on a normal IRC client (instead of Matrix) | 17:22 |
| moto-timo | RP: excellent. I was looking at commits but didn’t get to that one yet | 17:23 |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 17:30 | |
| RP | michaelo: wasn't working out with the notifications? | 17:35 |
| michaelo | RP: if you're talking about the Matrix interface, indeed, I just get a fraction of the messages. Didn't you say you're using Matrix too? | 17:37 |
| *** florian <florian!~florian@dynamic-093-133-144-007.93.133.pool.telefonica.de> has joined #yocto | 17:39 | |
| RP | michaelo: I'm not, I just noticed you were | 17:40 |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 17:41 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 265 seconds) | 17:45 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 17:58 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 252 seconds) | 18:03 | |
| *** ykrons <ykrons!~guillaume@62.192.23.101> has quit IRC (Ping timeout: 265 seconds) | 18:05 | |
| *** ykrons <ykrons!~guillaume@62.192.23.101> has joined #yocto | 18:05 | |
| zeddii | RP: well that's nicely simple. | 18:06 |
| zeddii | I'll kill my build | 18:07 |
| vd | kergoth: JPEW: I think I will start by defining one machine per customer instead of multiconfigs, even though it isn't techically correct (it's the same hardware after all), it will allow me to customize the default images from there while keeping the build simple. | 18:07 |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 18:18 | |
| vd | then I'll need multiconfig to build them, forget what I've said... | 18:18 |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 18:21 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 272 seconds) | 18:23 | |
| jsbronder | vd: Are you trying to use machine so that you can use the override syntax? SOME_VAR_machine = "..." | 18:29 |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 18:32 | |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC (Read error: Connection reset by peer) | 18:32 | |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 18:33 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 18:34 | |
| RP | zeddii: thankfully nothing horrible, thanks for ramping up ready :) | 18:36 |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.50> has quit IRC (Ping timeout: 258 seconds) | 18:38 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 265 seconds) | 18:39 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has joined #yocto | 18:48 | |
| *** LocutusOfBorg <LocutusOfBorg!~locutusof@93-50-192-18.ip153.fastwebnet.it> has quit IRC (Ping timeout: 256 seconds) | 18:58 | |
| *** LocutusOfBorg <LocutusOfBorg!~locutusof@93-50-192-18.ip153.fastwebnet.it> has joined #yocto | 19:00 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Client closed) | 19:00 | |
| *** frieder <frieder!~frieder@mue-88-130-65-149.dsl.tropolys.de> has joined #yocto | 19:00 | |
| *** florian <florian!~florian@dynamic-093-133-144-007.93.133.pool.telefonica.de> has quit IRC (Ping timeout: 265 seconds) | 19:01 | |
| smurray | RP: during local testing with just the prservice selftests I managed to reproduce what looks like the same failure as you saw on the AB yesterday, even with rebasing onto JPEW's rework to move the asyncio loop creation | 19:04 |
| smurray | RP: I think there's maybe a race in the PR export now, I'll need to try to decipher the backtraces | 19:04 |
| *** ochredoke <ochredoke!~ochredoke@user/ochredoke> has quit IRC (Ping timeout: 240 seconds) | 19:05 | |
| *** ochredoke <ochredoke!ochredoke@user/ochredoke> has joined #yocto | 19:06 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 19:07 | |
| *** zyga <zyga!~zyga@31.0.173.147> has quit IRC (Ping timeout: 240 seconds) | 19:09 | |
| RP | smurray: glad you could reproduce! :) | 19:10 |
| smurray | RP: tbh I think it was just luck, I've run it about 20 times in the last 2 days | 19:11 |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 240 seconds) | 19:12 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 19:26 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 276 seconds) | 19:30 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.) | 19:34 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 19:43 | |
| *** frieder <frieder!~frieder@mue-88-130-65-149.dsl.tropolys.de> has quit IRC (Remote host closed the connection) | 19:45 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 252 seconds) | 19:47 | |
| override | so im writing some user space code that would set what rootfs partition to use for next boot cycle. Im using libubootenv for it. does anyone have any other recommendations / stuff theyd want to link me to? | 20:02 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 20:03 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 20:05 | |
| LetoThe2nd | a steady hand and a magnetic needle. | 20:05 |
| LetoThe2nd | or if you | 20:05 |
| LetoThe2nd | if you're really brave, then a handful of butterflies. | 20:05 |
| vd | jsbronder: I was considering one machine configuration per customer profile yes | 20:06 |
| *** florian <florian!~florian@dynamic-093-133-144-007.93.133.pool.telefonica.de> has joined #yocto | 20:08 | |
| vd | At the moment I'm trying multiconfig with IMAGE_BASENAME = "${BB_CURRENT_MC}-${PN}" and TMPDIR = "${TOPDIR}/tmp/${BB_CURRENT_MC}" and see how it does. | 20:08 |
| vd | goes*. | 20:08 |
| jsbronder | vd: If you just want the VARIABLE_customerabc = "some-override" then you can add "customerabc" to OVERRIDES in your multiconfig. https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#conditional-syntax-overrides | 20:09 |
| jsbronder | Then you'd do IMAGE_BASENAME_customerabc = "whatever" | 20:09 |
| jsbronder | which has no affect in all of your other multiconfigs where "customerabc" isn't in OVERRIDES. | 20:10 |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.178> has joined #yocto | 20:12 | |
| vd | jsbronder I thought you we talking about MACHINEOVERRIDES and defining one machine configuration file per customer profile | 20:13 |
| jsbronder | MACHINEOVERRIDES are just included in OVERRIDES. | 20:16 |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 20:16 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Quit: Leaving) | 20:22 | |
| vd | jsbronder is it what you're using? | 20:23 |
| jsbronder | For something similar yes. | 20:23 |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 272 seconds) | 20:25 | |
| jsbronder | I have a number of images I need to build that are >99% the same. For each there's only a few customizations that I put in my recipes/appends themselves. | 20:25 |
| jsbronder | This includes setting IMAGE_BASENAME sometimes or adding a patch in SRC_URI. | 20:26 |
| vd | jsbronder kind of the same for me actually. I have vanilla images, each customer has a different password, a few default images pre-embedded inside of them, etc. | 20:28 |
| vd | I thought about adding the customization inside a multiconfig, but if I understand correctly, you set an OVERRIDES and you add the changes inside the recipe itself. Is that correct? | 20:29 |
| jsbronder | Yes, I like the locality of the customization in the recipe its modifying. If I need a list of all of them it's easy enough to `git grep _customerabc` | 20:31 |
| *** ant__ <ant__!~ant@host-79-54-252-190.retail.telecomitalia.it> has joined #yocto | 20:32 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 20:36 | |
| vd | I think I would prefer to centralize all customization for a customer inside a single file, but your way is actually simple | 20:37 |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 245 seconds) | 20:40 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 20:50 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 20:54 | |
| *** amitk_ <amitk_!~amit@103.208.71.30> has joined #yocto | 20:56 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 276 seconds) | 20:59 | |
| *** amitk <amitk!~amit@103.208.71.99> has quit IRC (Ping timeout: 256 seconds) | 20:59 | |
| *** zyga <zyga!~zyga@31.0.173.147> has joined #yocto | 20:59 | |
| vd | jsbronder so the OVERRIDES mechanism is not only for machines, it can be anything? Hence your approach for customizing recipes | 21:02 |
| *** florian <florian!~florian@dynamic-093-133-144-007.93.133.pool.telefonica.de> has quit IRC (Ping timeout: 272 seconds) | 21:03 | |
| jsbronder | Correct. `bitbake -e my-image | grep -B20 '^OVERRIDES='` | 21:03 |
| *** zyga <zyga!~zyga@31.0.173.147> has quit IRC (Ping timeout: 276 seconds) | 21:05 | |
| vd | jsbronder you could actually lighten up your multiconfig files by setting OVERRIDES .= ":${BB_CURRENT_MC}" in your distro conf for example. It will hold the multiconfig name, or "default" otherwise. | 21:07 |
| jsbronder | huh, good point ;) | 21:08 |
| vd | jsbronder how would you deal with 2 machines for the same customer? 2 multiconfig customer-mach1 and customer-mach2 ? | 21:10 |
| jsbronder | maybe something like OVERRIDES =. "customer:customer-mach1" so you can still do generic stuff for that specific customer. | 21:14 |
| vd | very true. This way I can tweak config packages (with _customer) or machine package like kernel or bootloader (with _customer-mach1) | 21:15 |
| vd | jsbronder do you customize everything in your image recipe, things such as SUMMARY_foo = "My recipe for foo"? | 21:22 |
| vd | jsbronder did you consider doing bbappend for your image in order to split the image customization in another file? | 21:24 |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 21:24 | |
| *** BobPungartnik <BobPungartnik!~Pung@177.41.192.103> has joined #yocto | 21:25 | |
| jsbronder | I don't actually have different customers, my use-case is just somewhat similar to what you were describing. | 21:25 |
| *** creich <creich!~creich@p200300f6af354710000000000000039b.dip0.t-ipconnect.de> has joined #yocto | 21:26 | |
| *** BobPungartnik <BobPungartnik!~Pung@177.41.192.103> has quit IRC (Client Quit) | 21:26 | |
| jsbronder | for instance, I have an x86 image that gets deployed to $very_expensive_hardware_every_dev_cannot_have. | 21:26 |
| jsbronder | So we leverage container images that are also built using the same layers and mostly the same configuration. | 21:27 |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 272 seconds) | 21:29 | |
| *** florian <florian!~florian@dynamic-093-133-144-007.93.133.pool.telefonica.de> has joined #yocto | 21:29 | |
| jsbronder | We also deploy some stuff to our manufacturers in containers. | 21:29 |
| *** risca <risca!~quassel@h-212-85-71-156.A328.priv.bahnhof.se> has quit IRC (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) | 21:35 | |
| RP | JaMa: for your ptest_remove issue, I wonder if adding that to the 'if "ptest_append" in line:' in the script would help | 21:36 |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.178> has quit IRC (Ping timeout: 258 seconds) | 21:37 | |
| RP | JaMa: I think that should be ok so I'll fix the script with that | 21:40 |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 21:40 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 240 seconds) | 21:44 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.17> has joined #yocto | 21:45 | |
| vd | jsbronder I see, thanks. I might add .bbappend file for my generic recipes in some recipes-customer or even a meta-customer layer, but the idea is the same as yours with OVERRIDES. I'm hacking on it rn! | 21:48 |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 21:58 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Client closed) | 22:00 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 22:02 | |
| vd | Can you conditionally enable a recipe bbappend? By the mean of overrides for example? | 22:03 |
| vd | forcing the _override inside of the bbappend recipe seems unnecessarily complex, but it's not a big deal if there's no other choice | 22:04 |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 240 seconds) | 22:05 | |
| vd | Other question, does ${IMAGE_NAME_pn-some-image-recipe} works? I'd like to have a robust way to get an image name from another recipe. | 22:06 |
| vd | s/robust/reliable/ | 22:07 |
| *** risca <risca!~quassel@h-212-85-71-156.A328.priv.bahnhof.se> has joined #yocto | 22:08 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Ping timeout: 256 seconds) | 22:19 | |
| *** ant__ <ant__!~ant@host-79-54-252-190.retail.telecomitalia.it> has quit IRC (Quit: Leaving) | 22:22 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 22:25 | |
| kergoth | vd: only if the variable is defined as that in the global configuration metadata. one recipe can't access variables of another directly by design, only its own and what flows down from the configuration metadata | 22:28 |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 22:30 | |
| vd | I see, so it's a bad idea. It is still better (with the current code) to rely on the formula used for IMAGE_NAME. e.g. ${BB_CURRENT_MC}-${IMAGE_BASENAME}. | 22:30 |
| *** florian <florian!~florian@dynamic-093-133-144-007.93.133.pool.telefonica.de> has quit IRC (Ping timeout: 258 seconds) | 22:30 | |
| vd | The downside is that it's specific to your configuration and not very generic, but well that's for a private layer after all. | 22:31 |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 268 seconds) | 22:36 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Client closed) | 22:38 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 22:41 | |
| vd | how can you conditionally do do_rootfs[depends] += , but dor a given OVERRIDES? | 22:44 |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 22:51 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 22:51 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 265 seconds) | 22:57 | |
| *** yates <yates!~user@096-036-098-109.biz.spectrum.com> has quit IRC (Remote host closed the connection) | 23:02 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 23:10 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 252 seconds) | 23:15 | |
| *** camus <camus!~Instantbi@113.83.121.13> has quit IRC (Quit: camus) | 23:37 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has joined #yocto | 23:51 | |
| *** nucatus <nucatus!~nucatus@lie62-2-78-196-130-58.fbx.proxad.net> has quit IRC (Ping timeout: 240 seconds) | 23:55 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!