Tuesday, 2023-10-17

*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Ping timeout: 245 seconds)00:21
khemok, which image are you building ? and whats spec of your system ( is it using faster storage )00:28
*** xmn <xmn!~xmn@2600:4040:9390:8c00:608d:a289:89bf:d3b3> has quit IRC (Ping timeout: 260 seconds)00:34
*** xmn <xmn!~xmn@2600:4040:9390:8c00:2e:856c:d949:aa7> has joined #yocto00:37
PhoenixMagekhem: Did you see my message re zsh modules?00:38
PhoenixMageI have had no luck trying to work out why they arent compiling00:38
mischiefkhem: all custom of course00:43
mischiefwe're on 16 core ec2 instances with gp2 EBS volumes00:44
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 255 seconds)01:03
*** davidinux <davidinux!~davidinux@host-62-211-16-200.pool62211.interbusiness.it> has joined #yocto01:05
*** Alexwarrior <Alexwarrior!~Alexwarri@> has joined #yocto01:19
khemPhoenixMage: I have not looked into details01:46
*** ablu <ablu!~m-bfyrfh@pc19f0bf9.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 255 seconds)01:53
*** ablu <ablu!~m-bfyrfh@p54b3c291.dip0.t-ipconnect.de> has joined #yocto01:54
*** jclsn <jclsn!~jclsn@2a04:4540:6524:e900:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 260 seconds)02:05
*** jclsn <jclsn!~jclsn@2a04:4540:650c:5800:2ce:39ff:fecf:efcd> has joined #yocto02:07
*** sakman <sakman!~sakman@> has joined #yocto02:59
PhoenixMagekhem: no worries03:50
*** Alexwarrior <Alexwarrior!~Alexwarri@> has quit IRC (Ping timeout: 245 seconds)04:14
*** davidinux <davidinux!~davidinux@host-62-211-16-200.pool62211.interbusiness.it> has quit IRC (Ping timeout: 255 seconds)05:21
*** davidinux <davidinux!~davidinux@> has joined #yocto05:21
*** ptsneves <ptsneves!~Thunderbi@031011128011.dynamic-3-poz-k-0-2-0.vectranet.pl> has joined #yocto05:23
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto05:31
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Remote host closed the connection)05:35
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto05:36
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Client Quit)05:40
*** camus <camus!~Instantbi@> has quit IRC (Quit: camus)05:50
*** camus <camus!~Instantbi@> has joined #yocto05:51
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto06:00
*** alessioigor <alessioigor!~alessioig@> has joined #yocto06:08
*** linfax_ <linfax_!~linfax@eumail.topcon.com> has joined #yocto06:14
*** rfuentess <rfuentess!~rfuentess@2001:861:208:5b0:1b73:e1ff:eda0:9d36> has joined #yocto06:24
*** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto06:26
*** mckoan|away is now known as mckoan06:37
*** goliath <goliath!~goliath@user/goliath> has joined #yocto06:43
*** frieder <frieder!~frieder@i577B91FE.versanet.de> has joined #yocto06:48
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto06:55
*** silbe <silbe!~silbe@2a03:4000:20:16f:96de:80ff:fe22:1aaa> has quit IRC (Ping timeout: 240 seconds)06:56
*** danlor <danlor!~danlor@60.red-83-35-13.dynamicip.rima-tde.net> has joined #yocto06:59
*** zpfvo <zpfvo!~fvo@> has joined #yocto07:09
*** Kubu_work <Kubu_work!~kubu@arennes-654-1-262-155.w2-13.abo.wanadoo.fr> has joined #yocto07:10
*** mvlad <mvlad!~mvlad@2a02:2f05:810c:2f00:7656:3cff:fe3f:7ce9> has joined #yocto07:18
*** emdevt <emdevt!~emdevt@85-76-104-119-nat.elisa-mobile.fi> has quit IRC (Quit: Leaving)07:24
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)07:28
*** alessioigor <alessioigor!~alessioig@> has joined #yocto07:28
*** mrnuke <mrnuke!~mrnuke@c-98-197-58-203.hsd1.tx.comcast.net> has quit IRC (Ping timeout: 240 seconds)07:32
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:32
*** danlor <danlor!~danlor@60.red-83-35-13.dynamicip.rima-tde.net> has quit IRC (Ping timeout: 245 seconds)07:33
*** mrnuke <mrnuke!~mrnuke@c-98-197-58-203.hsd1.tx.comcast.net> has joined #yocto07:33
*** danlor <danlor!~danlor@> has joined #yocto07:39
*** varjag <varjag!~user@> has joined #yocto07:41
*** florian_kc <florian_kc!~florian@dynamic-093-132-095-131.93.132.pool.telefonica.de> has joined #yocto07:49
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 255 seconds)07:56
*** brrm <brrm!~brrm@ip-078-043-203-234.um18.pools.vodafone-ip.de> has quit IRC (Ping timeout: 240 seconds)08:00
*** florian_kc <florian_kc!~florian@dynamic-093-132-095-131.93.132.pool.telefonica.de> has quit IRC (Ping timeout: 248 seconds)08:05
*** brrm <brrm!~brrm@ip-078-043-203-234.um18.pools.vodafone-ip.de> has joined #yocto08:09
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto08:09
*** zpfvo <zpfvo!~fvo@> has joined #yocto08:11
*** camus <camus!~Instantbi@> has quit IRC (Read error: Connection reset by peer)08:37
*** camus1 <camus1!~Instantbi@> has joined #yocto08:37
*** camus1 is now known as camus08:39
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto08:40
*** ptsneves <ptsneves!~Thunderbi@031011128011.dynamic-3-poz-k-0-2-0.vectranet.pl> has quit IRC (Ping timeout: 240 seconds)08:41
*** mbulut <mbulut!~mbulut@ip1f120fbc.dynamic.kabel-deutschland.de> has joined #yocto08:50
rburtonmischief: a build from sstate won't touch autoconf08:57
*** florian_kc is now known as florian08:57
rburtonmischief: if you're not building an image from sstate in single-digit numbers then either the image is huge, you've some slow postinst tasks, or some recipes are not being pulled from sstate08:58
rburton(my personal record is <30s on a ryzen with nvme for core-image-sato from sstate)08:59
*** danlor <danlor!~danlor@> has quit IRC (Quit: Client closed)09:01
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto09:09
*** ptsneves <ptsneves!~Thunderbi@> has joined #yocto09:11
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 258 seconds)09:13
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Remote host closed the connection)09:27
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto09:27
*** zpfvo <zpfvo!~fvo@> has joined #yocto09:27
kanavinI suspect a large chunk of those 10 minutes is in do_rootfs09:29
kanavinevery sometimes I wish for a package manager that can parallelize installation of packages, but alas it does not exist09:30
kanavinit's a 'for p in packages:' affair for all of them09:30
rburtoni wonder if apk is faster09:34
*** xmn <xmn!~xmn@2600:4040:9390:8c00:2e:856c:d949:aa7> has quit IRC (Ping timeout: 260 seconds)09:37
JaMaIMAGE_FSTYPES can also take a while especially if you're building many09:39
*** danlor <danlor!~danlor@> has joined #yocto09:55
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)09:58
*** alessioigor <alessioigor!~alessioig@> has joined #yocto09:58
abluiirc there was some way to specify in a .wks.in file to put the content of a certain folder into a partition... But I cannot figure out how that worked again... Does anyone have a pointer?10:13
abluI think it was something like "--use-this-folder=$ROOTFS_DIR/usr/"...10:13
*** danlor <danlor!~danlor@> has quit IRC (Quit: Client closed)10:17
*** danlor <danlor!~danlor@> has joined #yocto10:17
ptsnevesablu: I would do that with the deploy task and then use that deploy's contents10:18
ptsnevesthe rootfs filesystem is nothing about folders.10:19
abluptsneves: Hm. What I am looking for is the syntax for the .wks.in file to specify that folders.10:21
abluMaybe I built an image when I last did it... My brain starts failling.10:21
abluIn the end I only want to include everything under "/usr/" in a specific partition.10:22
ablu"--rootfs-dir=${IMAGE_ROOTFS}/usr" looks promising10:35
PhoenixMageIf I add a package to RDEPEND of a recipe that is included in my image shouldnt that RDEPENDS package get added to the image automatically?10:44
*** silbe <silbe!~silbe@2a03:4000:20:16f:96de:80ff:fe22:1aaa> has joined #yocto10:47
danlorPhoenixMage yes, it should10:47
danlorI've been fiddling with the package classes and checking do_rootfs task logs. The pkg_postinst scriptlets are handled in a different way if deb or rpm package class is used. The postinst runs just after pacakage installation if rpm but, if deb, the postinst are executed in alphabetical order after all packages have been installed. This could break10:49
danlorsome packages where the postinst execution order matters or that share configs or mechanisms when using package-deb as the package class, couldn't it?10:49
rburtondon't rely on execution order10:51
danlorYep, I always try to follow that recommendation. But I'm experiencing some troubles with the ca-certificates and ca-certificates-java packages for example. The first one is rdepended by the latter. Both have their own pkg_postinst scripts.10:54
danlorThe java one installs a cert update hook and rely on the update mechanism of the ca-certificates package.10:55
rburtondoes the java one just install the hook, or also invoke the update?10:55
*** manuel1985 <manuel1985!~manuel198@> has joined #yocto10:56
danlorIt just installs the hook, but creates its trust store in its pkg_postinst10:57
danlorHence, when the ca-certificates invokes the update in its pkg_postinst, the java hook is already there10:58
danlorBut not ready10:58
danlorTo be executed10:59
rburtonthe hook should handle that case then10:59
rburtonjust make it print a message that its skipping so its obvious to someone debugging it later :)11:03
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 240 seconds)11:04
*** ptsneves <ptsneves!~Thunderbi@> has quit IRC (Ping timeout: 248 seconds)11:04
danlorYes, I'll do that. Ty!11:09
*** zpfvo <zpfvo!~fvo@> has joined #yocto11:18
*** danlor <danlor!~danlor@> has quit IRC (Quit: Client closed)11:25
*** Net147 <Net147!~Net147@user/net147> has quit IRC (Quit: Quit)11:26
*** manuel_ <manuel_!~manuel198@> has joined #yocto11:31
*** manuel1985 <manuel1985!~manuel198@> has quit IRC (Ping timeout: 255 seconds)11:34
*** danlor <danlor!~danlor@> has joined #yocto11:37
PhoenixMageWhy would a package not show up in the image manifest? Its definitely installed on the image...11:42
*** mbulut <mbulut!~mbulut@ip1f120fbc.dynamic.kabel-deutschland.de> has quit IRC (Remote host closed the connection)11:47
*** mbulut <mbulut!~mbulut@ip1f120fbc.dynamic.kabel-deutschland.de> has joined #yocto11:49
*** sng_ <sng_!~quassel@> has joined #yocto11:50
*** sng <sng!~quassel@> has quit IRC (Read error: Connection reset by peer)11:50
*** Net147 <Net147!~Net147@167-179-157-192.a7b39d.syd.nbn.aussiebb.net> has joined #yocto11:57
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 255 seconds)12:03
*** zpfvo <zpfvo!~fvo@> has joined #yocto12:03
*** Net147 <Net147!~Net147@user/net147> has quit IRC (Quit: Quit)12:05
*** Net147 <Net147!~Net147@167-179-157-192.a7b39d.syd.nbn.aussiebb.net> has joined #yocto12:07
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 255 seconds)12:08
*** zpfvo <zpfvo!~fvo@> has joined #yocto12:08
*** bhstalel <bhstalel!~bhstalel@> has joined #yocto12:16
*** bhstalel <bhstalel!~bhstalel@> has quit IRC (Quit: Client closed)12:28
*** Tyaku <Tyaku!~Tyaku@lfbn-orl-1-202-97.w92-152.abo.wanadoo.fr> has joined #yocto12:31
*** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has quit IRC (Remote host closed the connection)12:36
*** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has joined #yocto12:39
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed)12:41
*** jholtom <jholtom!~saguaro@user/jholtom> has left #yocto (http://quassel-irc.org - Chat comfortably. Anywhere.)12:45
*** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto12:54
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)12:56
*** Marmottus <Marmottus!~marmottus@2001:bc8:1820:2715::1> has quit IRC (Quit: The Lounge - https://thelounge.chat)13:13
*** Marmottus <Marmottus!~marmottus@2001:bc8:1820:2715::1> has joined #yocto13:15
*** ptsneves <ptsneves!~Thunderbi@031011128011.dynamic-3-poz-k-0-2-0.vectranet.pl> has joined #yocto13:24
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto13:35
*** danlor <danlor!~danlor@> has quit IRC (Quit: Client closed)13:54
*** Tyaku <Tyaku!~Tyaku@lfbn-orl-1-202-97.w92-152.abo.wanadoo.fr> has quit IRC (Quit: Lost terminal)13:55
*** rfuentess <rfuentess!~rfuentess@2001:861:208:5b0:1b73:e1ff:eda0:9d36> has quit IRC (Remote host closed the connection)13:55
*** Xagen <Xagen!~Xagen@rrcs-98-6-114-13.sw.biz.rr.com> has joined #yocto14:09
*** xmn <xmn!~xmn@2600:4040:9390:8c00:1c25:e65e:1c10:5d7c> has joined #yocto14:12
*** grma <grma!~gruberm@89-41-133-247.static.kufnet.at> has quit IRC (Ping timeout: 258 seconds)14:17
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)14:33
*** Xagen <Xagen!~Xagen@rrcs-98-6-114-13.sw.biz.rr.com> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)14:40
*** Xagen <Xagen!~Xagen@rrcs-98-6-114-13.sw.biz.rr.com> has joined #yocto14:41
*** sng_ <sng_!~quassel@> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)14:46
*** sng <sng!~quassel@> has joined #yocto14:48
*** Estrella___ <Estrella___!~quassel@2603-8080-d700-7495-f820-c3dd-e3a8-92d0.res6.spectrum.com> has quit IRC (Remote host closed the connection)14:56
*** Estrella_ <Estrella_!~quassel@> has joined #yocto14:56
*** varjag <varjag!~user@> has quit IRC (Quit: ERC (IRC client for Emacs 27.1))14:57
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 255 seconds)15:02
*** zpfvo <zpfvo!~fvo@> has joined #yocto15:03
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 255 seconds)15:08
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection)15:08
*** zpfvo <zpfvo!~fvo@> has joined #yocto15:09
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed)15:10
*** Rich_1234 <Rich_1234!~Rich_1234@> has quit IRC (Quit: Connection closed)15:16
*** Rich_1234 <Rich_1234!~Rich_1234@> has joined #yocto15:18
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto15:21
*** mbulut <mbulut!~mbulut@ip1f120fbc.dynamic.kabel-deutschland.de> has quit IRC (Quit: Leaving)15:22
*** bhstalel <bhstalel!~bhstalel@> has joined #yocto15:38
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)15:41
*** linfax_ <linfax_!~linfax@eumail.topcon.com> has quit IRC (Ping timeout: 260 seconds)15:41
*** goliath <goliath!~goliath@user/goliath> has joined #yocto15:44
*** paulg <paulg!~paulg@198-84-237-91.cpe.teksavvy.com> has joined #yocto15:48
*** danlor <danlor!~danlor@> has joined #yocto15:54
*** Danct12 <Danct12!~danct12@user/danct12> has quit IRC (Read error: Connection reset by peer)16:02
*** Perflosopher <Perflosopher!~perflosop@> has quit IRC (Read error: Connection reset by peer)16:04
*** Perflosopher <Perflosopher!~perflosop@> has joined #yocto16:05
*** danlor <danlor!~danlor@> has quit IRC (Quit: Client closed)16:06
*** frieder <frieder!~frieder@i577B91FE.versanet.de> has quit IRC (Remote host closed the connection)16:06
*** ptsneves <ptsneves!~Thunderbi@031011128011.dynamic-3-poz-k-0-2-0.vectranet.pl> has quit IRC (Ping timeout: 258 seconds)16:10
*** Danct12 <Danct12!~danct12@user/danct12> has joined #yocto16:11
*** Guest21 <Guest21!~Guest21@host-80-41-77-253.as13285.net> has joined #yocto16:29
Guest21Strange “nothing  RPROVIDES image-name” error  when bitbake image-name and image-name.bb exists in meta-layername/recipes-core/images16:32
Guest21What am I missing here ?16:32
Guest21image-name is a copy of image-dev-name which lives in the same directory and works perfectly …16:34
Guest21Both .bb obviously16:34
rburtonthe error says *R*PROVIDES?16:34
rburtonthat's a bug in your recipe16:34
Guest21Sorry no PROVIDES16:35
*** mckoan is now known as mckoan|away16:35
rburtontried bitbake-layers show-recipes16:37
Guest21rburton: At the moment  image-name.bb is a prefect copy of image-dev-name.bb which works16:37
rburtondoes it do something like setting PN explictly to change the recipe name?16:38
*** Danct12 <Danct12!~danct12@user/danct12> has quit IRC (Quit: A-lined: This user has been AVIVA-lined!)16:38
Guest21rburton: bitbake-layers show recipes image-name returns an empty string however image-dev-name works16:39
*** Guest21 <Guest21!~Guest21@host-80-41-77-253.as13285.net> has quit IRC (Quit: Client closed)16:40
*** Guest21 <Guest21!~Guest21@host-80-41-77-253.as13285.net> has joined #yocto16:40
rburtonyour layer.conf might be using very strict globs so excluding the recipe, or the recipe sets PN and changes its name16:40
Guest21rburton sorry got disconnected16:40
rburtonyour layer.conf might be using very strict globs so excluding the recipe, or the recipe sets PN and changes its name16:41
bhstalelMaybe image-name is not in PROVIDES ? PN is default of PROVIDES, so PN may be changed in the recipe, check: "bitbake -e image-name | grep ^PN=" and "bitbake -e image-name | grep ^PROVIDES="16:42
*** zpfvo <zpfvo!~fvo@> has quit IRC (Remote host closed the connection)16:42
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)16:44
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 260 seconds)16:44
*** alessioigor <alessioigor!~alessioig@> has joined #yocto16:44
*** Danct12 <Danct12!~danct12@user/danct12> has joined #yocto16:46
Guest21First command returns PN=image-dev-name for bitbake -e image-dev name and error nothing provide image-name for image-name16:51
Guest21Bitbake-getvar -r image-name PN returns an error as well16:52
rburtonnone of the commands will work if bitbak can't see your recipe16:54
rburtonso as i said, check your layer.conf doesn't do something stupid, and then check the recipe doesn't set PN to change the recipe name16:55
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)17:04
Guest21neither the recipe or layer.conf modify anything17:05
Guest21What else could stop the recipe being seen by bitbake?17:05
rburtonempty the recipe and see what happens17:07
Guest21Empty recipe with just a DESCRIPTION line still not detected17:09
rburtonwhat does the layer.conf set BBFILES to?17:10
*** Guest33 <Guest33!~Guest62@host-80-41-77-253.as13285.net> has joined #yocto17:12
Guest33rburton on my computer now17:12
Guest33one second17:12
Guest33BBFILES += "${LAYERDIR}/recipes-postinst/*/*.bb \17:13
Guest33                  ${LAYERDIR}/recipes-kernel/*/*.bb \17:13
Guest33                  ${LAYERDIR}/recipes-core/*/*.bb \17:13
Guest33                  ${LAYERDIR}/recipes-containers/*/*.bb \17:13
Guest33                  ${LAYERDIR}/recipes-extended/*/*.bb \17:13
Guest33                  ${LAYERDIR}/recipes-gnome/*/*.bb \17:13
Guest33                  ${LAYERDIR}/recipes-devtools/*.bb \17:13
Guest33                  ${LAYERDIR}/recipes-devtools/*/*.bb \17:13
Guest33                  ${LAYERDIR}/recipes-devtools/*/*.bbappend \17:13
Guest33                  ${LAYERDIR}/recipes-multimedia/*/*.bb \17:13
Guest33                  ${LAYERDIR}/recipes-filesystems/*/*.bb \17:13
Guest33                  ${LAYERDIR}/recipes-support/*/*.bb \17:13
Guest33                  ${LAYERDIR}/recipes-bsp/*/*.bb \17:13
Guest33                  ${LAYERDIR}/recipes-bsp/*/*.bbappend \17:13
Guest33                  ${LAYERDIR}/recipes-*/*/*.bbappend"17:13
rburtonthat's overkill, BBFILES += "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend" works and is more concise17:14
rburtonand what's the path to the image?17:14
Guest21The image is in recipes-core/images/17:14
bhstalelGuest21 what is name of image-name bb file ? image-name.bb ?17:16
Guest33specs-client-image.bb  specs-dev-image.bb17:19
Guest33the one that works is the dev variant17:19
khemRP:  you might wanna take https://patchwork.yoctoproject.org/project/oe-core/patch/20231015152844.2574302-1-raj.khem@gmail.com/ it was reporting a high CVE last week17:19
khemlocally ptest image runs show no issues for me17:20
*** Guest21 <Guest21!~Guest21@host-80-41-77-253.as13285.net> has quit IRC (Quit: Client closed)17:25
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)17:25
*** Guest21 <Guest21!~Guest21@host-80-41-77-253.as13285.net> has joined #yocto17:35
Guest21Got disconnected did I miss any suggestion?17:35
Guest21Apparently not :-(17:36
*** Guest21 <Guest21!~Guest21@host-80-41-77-253.as13285.net> has quit IRC (Quit: Client closed)17:45
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto18:06
*** goliath <goliath!~goliath@user/goliath> has joined #yocto18:18
*** PhoenixMage <PhoenixMage!~phoenix@> has quit IRC (Ping timeout: 255 seconds)18:35
*** PhoenixMage <PhoenixMage!~phoenix@> has joined #yocto18:37
rburtonGuest33: can you share the image recipe itself?18:39
mischiefhm. i checked the buildstats thingy with the pybootchartgui. shows 142s for do_rootfs18:44
mischiefi suppose apt is a bit slow18:44
khemmischief:  yeah try with opkg backend18:44
mischiefis there a way to prevent split packages we won't need? can we just remove the PACKAGES somehow?18:51
rburtonthey won't be installed so it's just a one-off hit when the recipe is actually built18:51
rburtonunless the component takes forever to build or has big dependencies, in which case ideally add a PACKAGECONFIG.  changing PACKAGES won't do anything apart from move files or error out with files not being packaged.18:52
mischiefsome are built quite often18:52
mischiefand some of the -dbg packages are up to 50M :-)18:52
rburtonsure, but you're only installing them when required, and 50M is nothing18:53
mischiefit's time spent to actually do the packaging18:53
rburtonnow piglit had a 2GB debug package of 99.9% identical generated code, so i turned off debug for that18:53
mischiefwe don't actually save packages from the deploy dir anywhere so they are reconstructed from sstate every build18:53
rburtonpackages come from sstate18:54
rburtonDEBUG_FLAGS="" will remove all debug flags and you'll build no debug symbols at all, so there'll be nothing to strip.  asserting that you'll never need symbols is a strong move, but would save a small amount of time/io.18:55
rburtonin case i wasn't clear, if you build an image from sstate then the packages are taken from sstate and the image built from those18:56
rburtondeploy is in tmp, therefore transient and generated18:56
mischiefin the future we might proceed with PACKAGE_MINIDEBUGINFO18:56
mischieftoday we don't use -dbg at all anywhere18:56
bhstalelIs there a plan to support DEPLOY_DIR_TAR ? I mean support generating tar files from recipes ? Maybe creating package_tar class ?18:58
rburtonbhstalel: how would it contain dependencies between packages?18:58
rburtonbhstalel: see 90ce19122802a16e6067f3a2ce3447acf1070fe5 :)18:58
bhstalelWhat project is 90ce19122802a16e6067f3a2ce3447acf1070fe5 in ?18:59
bhstalelmeta-openembedded ?19:00
rburtonno, openembedded-core19:00
bhstalelNow I see, I did not know it was tried before, but I think some clean is needed, because DEPLOY_DIR_TAR is still defined in bitbake.conf19:02
bhstalelI think I should send a patch19:02
rburtonplease do19:02
rburtonfor the use case of "i need this package in a plain tarball for <reasons> which don't involve an image", package_tar mostly worked.  but nobody used it because it was broken for years at a time, so we removed it.19:03
SaurRP: Would you accept a patch such as https://pastebin.com/2qNCAAE1? After a colleague pointed out that we cannot enable 64 bit timeval for 32 bit products yet in our platform, I realized that we are probably not alone in that regard. And since there is no `uninclude`, having time64.inc included unconditionally from defaultsetup.conf makes it a bit involved to undo it.19:03
bhstalelrburton I am curious but how did you get the commit ID so fast ? hhh19:04
rburtonbhstalel: git log --grep package_tar19:05
*** florian_kc <florian_kc!~florian@dynamic-093-132-095-131.93.132.pool.telefonica.de> has joined #yocto19:05
bhstalelAha 😃19:05
bhstalelCheck the map that I sent in docs19:06
mischiefah, well. i guess no quick wins by removing debugging. trying ipk instead of deb now19:08
rburtonmischief: i was about to say, my test of turning off debugging for systemd changed the numbers _slightly_19:09
rburton  systemd    do_package              -6.5s   -22.2%      29.4s -> 22.9s19:09
rburton  systemd    do_compile              -4.6s    -9.7%      47.4s -> 42.8s19:09
mischiefyou're removing -g from the compiler invocation or something?19:09
rburtonas i said, setting DEBUG_FLAGS=""19:09
rburtontested for just systemd by putting it in the recipe, but you could do it in the distro config and get no debug symbols anywhere19:10
rburtonmarginal gains and won't change rootfs generation in the slightest19:10
mischiefis there a way to keep DEBUG_FLAGS so that PACKAGE_MINIDEBUGINFO would work, but skip the strip/package split for -dbg?19:11
mischief20% gain in packaging seems pretty good19:11
rburtonpackage minidebuginfo does the same split surely19:11
rburtonin fact its probably slower to build19:12
mischiefrburton: minidebuginfo is injected as a section into the original binary19:12
mischiefit is not split, which is why we are interested in using it19:12
rburtonnot sure i want to know why split matters ;)19:13
rburtonno idea how the minidebuginfo code _actually_ works and if it makes rash assumptions about where files ended up19:14
*** bhstalel <bhstalel!~bhstalel@> has quit IRC (Ping timeout: 245 seconds)19:15
*** Haxxa <Haxxa!~Haxxa@202-65-68-206.ip4.superloop.au> has quit IRC (Quit: Haxxa flies away.)19:15
mischiefmy reading of package.bbclass says that it will not work if INHIBIT_PACKAGE_DEBUG_SPLIT is set since it uses the split-off .debug files19:18
*** Haxxa <Haxxa!~Haxxa@> has joined #yocto19:18
rburtonas we've discovered, the splitting process isn't exactly slow19:19
mischief66 seconds to package python3 with ipk :)19:20
*** tgamblin <tgamblin!~tgamblin@d72-39-239-122.home1.cgocable.net> has quit IRC (Remote host closed the connection)19:21
*** tgamblin <tgamblin!~tgamblin@2001:1970:5b1f:ab00:71eb:b8e9:8589:9ca5> has joined #yocto19:21
mischiefi will check the rootfs time once all this crap builds19:21
*** Kubu_work <Kubu_work!~kubu@arennes-654-1-262-155.w2-13.abo.wanadoo.fr> has quit IRC (Quit: Leaving.)19:22
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 252 seconds)19:29
mischief40 seconds faster for ipk :-)19:48
mischiefis there any functional impact from changing from deb to ipk?19:49
rburtonyou can't use apt on target19:49
rburtonif you're not using package management on target there's literally no difference19:49
rburtoncan i ask why you chose deb? it's not the default19:50
rburton(and the worst supported of the backends)19:50
mischiefi have no recollection of why i picked that N years ago for this project19:51
mischiefwe don't use packaging on target, we're shipping dm-verity protected images anyway19:51
rburtonyeah just use ipkg19:51
rburtonits faster and the end result should be identical19:52
*** bhstalel <bhstalel!~bhstalel@> has joined #yocto19:56
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (Quit: Chaser)20:07
*** bhstalel <bhstalel!~bhstalel@> has quit IRC (Quit: Client closed)20:07
*** bhstalel <bhstalel!~bhstalel@> has joined #yocto20:07
JaMaSaur: I think you can add empty time64.inc in your DISTRO layer to avoid using it, right?20:08
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Killed (NickServ (GHOST command used by florian_kc!~florian@dynamic-093-132-095-131.93.132.pool.telefonica.de)))20:08
*** florian_kc is now known as florian20:08
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto20:09
SaurJaMa: Sure, but that is not too obvious to everyone. And it also relies on that the layers are specified in the correct order in BBLAYERS...20:09
JaManon-existing timedefault.inc doesn't seem much more obvious to everyone20:10
SaurAnd yes, I have created a time64.inc wrapper that does basically what the patch above does. So I will manage.20:10
SaurWell, my idea was that you can set TIME_MODE to anything but "64" to disable the forced use of 64 bit time_t...20:11
SaurObviously, if a variable like that is added, it should be documented.20:12
Saur(Off to pick up my kid from floorball practice.)20:13
zeddiitell me you are in Sweden without telling me you are in Sweden!20:14
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)20:26
*** olani- <olani-!~olani@31-208-215-161.cust.bredband2.com> has joined #yocto20:29
*** olani- <olani-!~olani@31-208-215-161.cust.bredband2.com> has quit IRC (Remote host closed the connection)20:30
*** olani- <olani-!~olani@31-208-215-161.cust.bredband2.com> has joined #yocto20:31
*** olani- <olani-!~olani@31-208-215-161.cust.bredband2.com> has quit IRC (Remote host closed the connection)20:33
*** olani- <olani-!~olani@31-208-215-161.cust.bredband2.com> has joined #yocto20:33
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)20:43
*** shakta <shakta!~shakta@2601:441:8081:6220:8d2:25cd:458:ac8e> has joined #yocto20:50
*** rber__ <rber__!~rber|res@089144200221.atnat0009.highway.a1.net> has joined #yocto21:07
*** tgamblin <tgamblin!~tgamblin@2001:1970:5b1f:ab00:71eb:b8e9:8589:9ca5> has quit IRC (Remote host closed the connection)21:08
*** tgamblin <tgamblin!~tgamblin@2001:1970:5b1f:ab00:d875:6297:4e81:e577> has joined #yocto21:08
*** RobertBerger <RobertBerger!~rber|res@089144208243.atnat0017.highway.a1.net> has quit IRC (Ping timeout: 258 seconds)21:09
sudipI am now past the cmake error while trying to upgrade rpm, now at a python error, hopefully the last error21:25
sudipany idea what might be causing "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)" ?21:28
sudipI should not need to specify 32 or 64bit architecture in recipes21:28
shaktaI have a bitbake recipe that builds and installs a simple C application. I also want to install a file containing the signature of the application binary. I tried adding a task after compile, before install that generate the signature file. I also extended the install step to install the signature file. The problem is....the application binary that21:34
shaktagets deployed is different than the one I signed. Do I need to move the signature creation task after package task or maybe even after deploy task then?21:34
mischiefthe program probably got stripped during packaging21:38
*** Xagen <Xagen!~Xagen@rrcs-98-6-114-13.sw.biz.rr.com> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)21:39
shaktaYup, the binary is the same from compile and in staging. But after packaging it's size has decreased.21:40
*** mvlad <mvlad!~mvlad@2a02:2f05:810c:2f00:7656:3cff:fe3f:7ce9> has quit IRC (Remote host closed the connection)21:46
shaktaThis means I need to create & install the signature after packaging. Since packaging happens after install, it seems this can not be done by simply extending the applications recipe.21:47
mischiefthere's been some attempts at this kind of thing in the past, like elfsign and signelf21:50
mischiefdunno your use case but you might be better served by dm-verity or dm-integrity if you control the fs images21:51
shaktaUse case: verify signature of a handful of files on R/W file system from initramfs21:53
shaktadm-verity is no go because needs read only fs (IIRC)21:53
*** zhmylove <zhmylove!~zhmylove@> has joined #yocto21:54
shaktaHaven't looked into dm-integrity or IMA/EVM21:56
*** kevinrowland <kevinrowland!~kevinrowl@> has joined #yocto21:56
shaktaA manual signing/verify solution seems like the simplest solution to meet use case22:03
RPSaur: you can touch a file in your layer to replace the core one? I'd rather not make it too easy22:04
kevinrowlandIs it possible to write a python script that, given a build directory, parses all recipes in BBLAYERS and then lets me basically.. inspect the datastore? Like what bitbake does when it checks that all dependencies of the target recipe are buildable (it will yell at you if one recipe DEPENDs on another recipe that doesn't exist). I assume it's22:04
kevinrowlandpossible, but wondering if there are any examples floating around.22:04
RPkevinrowland: the tinfoil api is what you want, there are a few tools using tinfoil of differing levels of complexity22:05
kevinrowlandFor some reason I thought there was a purpose-built python module to do stuff like this, but I'm having no luck googling and grepping22:06
kevinrowlandtinfoil! that's the one22:06
kevinrowlandRP: thanks very much, IO'22:06
kevinrowlandI'll poke around*22:06
RPbitbake-getvar is a really simple one. devtool/recipetool are much more complex users22:06
*** bhstalel <bhstalel!~bhstalel@> has quit IRC (Ping timeout: 245 seconds)22:18
*** olani- <olani-!~olani@31-208-215-161.cust.bredband2.com> has quit IRC (Ping timeout: 260 seconds)22:23
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto22:37
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Client Quit)22:38
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto22:52
*** paulg <paulg!~paulg@198-84-237-91.cpe.teksavvy.com> has quit IRC (Ping timeout: 240 seconds)23:05
*** sveinse <sveinse!~sveinse@2a01:799:557:ec00:1466:6aff:fe8a:220e> has quit IRC (Quit: leaving)23:13
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)23:16
*** paulg <paulg!~paulg@23-233-30-231.cpe.pppoe.ca> has joined #yocto23:17
*** zelgomer <zelgomer!~jake@gateway/tor-sasl/zelgomer> has quit IRC (Ping timeout: 252 seconds)23:44
*** florian <florian!~florian@dynamic-093-132-095-131.93.132.pool.telefonica.de> has quit IRC (Ping timeout: 260 seconds)23:45
*** zelgomer <zelgomer!~jake@gateway/tor-sasl/zelgomer> has joined #yocto23:46

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!