Friday, 2024-04-26

*** ederibaucourt <ederibaucourt!~ederibauc@lmontsouris-657-1-69-118.w80-15.abo.wanadoo.fr> has quit IRC (Ping timeout: 264 seconds)00:27
*** florian <florian!~florian@dynamic-080-171-064-076.80.171.pool.telefonica.de> has quit IRC (Ping timeout: 260 seconds)00:34
*** ederibaucourt <ederibaucourt!~ederibauc@lmontsouris-657-1-69-118.w80-15.abo.wanadoo.fr> has joined #yocto00:46
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)00:47
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)00:51
*** davidinux <davidinux!~davidinux@194.34.233.32> has quit IRC (Ping timeout: 260 seconds)01:04
tlwoernerJPEW: moto-timo: in one of my early commits i thought i removed all references to the infradead mailing list, it's obviously dead and has been for a long time01:04
*** davidinux <davidinux!~davidinux@194.34.233.32> has joined #yocto01:10
*** starblue <starblue!~juergen@87.122.38.212> has quit IRC (Ping timeout: 256 seconds)01:15
*** starblue <starblue!~juergen@87.122.36.56> has joined #yocto01:17
*** jclsn <jclsn!~jclsn@2a04:4540:6501:6400:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 272 seconds)01:43
*** jclsn <jclsn!~jclsn@2a04:4540:6520:0:2ce:39ff:fecf:efcd> has joined #yocto01:45
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto02:25
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)02:58
*** amitk <amitk!~amit@58.84.60.75> has joined #yocto02:58
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto03:04
*** |Xagen <|Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto03:04
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Ping timeout: 245 seconds)03:08
*** sakman <sakman!~sakman@208.111.77.233> has joined #yocto03:39
*** Abp <Abp!~Abp@84-107-6-196.cable.dynamic.v4.ziggo.nl> has quit IRC (Ping timeout: 252 seconds)03:45
*** Guest78 <Guest78!~Guest78@unknown-252-42.windriver.com> has joined #yocto04:09
*** Guest78 <Guest78!~Guest78@unknown-252-42.windriver.com> has quit IRC (Client Quit)04:09
*** changqing <changqing!~Guest90@user/changqing> has joined #yocto04:28
*** changqing <changqing!~Guest90@user/changqing> has quit IRC (Quit: Client closed)04:29
*** sakoman <sakoman!~sakoman-l@209.237.67.158> has quit IRC (Ping timeout: 246 seconds)05:13
*** sakoman <sakoman!~sakoman-l@209.237.67.158> has joined #yocto05:14
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Ping timeout: 268 seconds)05:14
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto05:21
*** Abp <Abp!~Abp@84-107-6-196.cable.dynamic.v4.ziggo.nl> has joined #yocto05:24
*** alessioigor <alessioigor!~alessioig@185.178.95.238> has joined #yocto06:15
*** rfuentess <rfuentess!~rfuentess@lfbn-lyo-1-1566-5.w90-52.abo.wanadoo.fr> has joined #yocto06:19
*** Abp <Abp!~Abp@84-107-6-196.cable.dynamic.v4.ziggo.nl> has quit IRC (Ping timeout: 252 seconds)06:23
*** Abp <Abp!~Abp@188-206-111-192.mobile.kpn.net> has joined #yocto06:23
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto06:25
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto06:28
*** legraps <legraps!~anaumann@ipb21bd56e.dynamic.kabel-deutschland.de> has joined #yocto06:31
*** ehussain <ehussain!~Thunderbi@2400:adc5:122:ef00:3c0a:77c2:5ecc:b4c8> has joined #yocto06:43
*** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has joined #yocto06:44
*** xmn <xmn!~xmn@pool-108-46-142-76.nycmny.fios.verizon.net> has quit IRC (Ping timeout: 245 seconds)06:47
*** Jones42 <Jones42!~Jones42@i577BF1A1.versanet.de> has joined #yocto07:00
*** Jones42 <Jones42!~Jones42@i577BF1A1.versanet.de> has quit IRC (Client Quit)07:00
*** Jones42Jones42 <Jones42Jones42!~Jones42Jo@i577BF1A1.versanet.de> has joined #yocto07:02
*** Jones42Jones42 <Jones42Jones42!~Jones42Jo@i577BF1A1.versanet.de> has quit IRC (Client Quit)07:02
*** Jones42 <Jones42!~Jones42@i577BF1A1.versanet.de> has joined #yocto07:02
*** Jones62 <Jones62!~Jones42@user/Jones42> has joined #yocto07:03
*** Jones62 <Jones62!~Jones42@user/Jones42> has quit IRC (Client Quit)07:05
*** Jones42 <Jones42!~Jones42@i577BF1A1.versanet.de> has quit IRC (Client Quit)07:05
*** Kubu_work <Kubu_work!~kubu@lfbn-nan-1-335-137.w82-120.abo.wanadoo.fr> has joined #yocto07:07
*** zwelch <zwelch!~zwelch@fluffy.mandolincreekfarm.com> has quit IRC (Ping timeout: 245 seconds)07:16
*** michalk0 <michalk0!~michalk0@ovg179.internetdsl.tpnet.pl> has joined #yocto07:25
*** zwelch <zwelch!~zwelch@fluffy.mandolincreekfarm.com> has joined #yocto07:26
michalk0Hi, I have one recipe that fetch internal git repo and build application, and I need to prepare second recipe that will use this same repo but in different way - second recipe will generate update packages by using scripts that are placed in this same repo. I am thinking about separated recipe, because these update files should not be placed in07:31
michalk0origin image. Do you recommend something specific for that case? I was thinking about preparing class file and inherit in two recipes, or prepare one directory with include and two recipes. Second way is more "clean" for me, but I am not sure how it should be done in best way07:31
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection)07:31
mcfrisk_michalk0: a single recipe (source package) can produce multiple output binary packaged (libs, bins, scripts, examples, docs, plugins, adons)07:34
mcfrisk_/packaged/packages/ ---> more coffee07:34
*** michalk0 <michalk0!~michalk0@ovg179.internetdsl.tpnet.pl> has quit IRC (Quit: Client closed)07:46
*** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has quit IRC (Ping timeout: 260 seconds)07:47
*** michalk0 <michalk0!~michalk0@ovg179.internetdsl.tpnet.pl> has joined #yocto07:49
*** locutusofborg <locutusofborg!~locutusof@151.58.174.15> has quit IRC (Ping timeout: 264 seconds)07:51
*** LocutusOfBorg <LocutusOfBorg!~locutusof@93-45-38-101.ip100.fastwebnet.it> has joined #yocto07:54
michalk0mcfrisk_: about /packaged/packages - you mean path in build/tmp/work folder?07:58
*** ablu <ablu!~m-bfyrfh@user/Ablu> has quit IRC (Read error: Connection reset by peer)08:00
*** locutusofborg_ <locutusofborg_!~locutusof@151.58.174.15> has joined #yocto08:02
*** michalk0 <michalk0!~michalk0@ovg179.internetdsl.tpnet.pl> has quit IRC (Quit: Client closed)08:03
*** LocutusOfBorg <LocutusOfBorg!~locutusof@93-45-38-101.ip100.fastwebnet.it> has quit IRC (Ping timeout: 252 seconds)08:03
*** ablu <ablu!~m-bfyrfh@user/Ablu> has joined #yocto08:06
*** michalk0 <michalk0!~michalk0@ovg179.internetdsl.tpnet.pl> has joined #yocto08:07
*** vladest <vladest!~Thunderbi@217.192.139.41> has joined #yocto08:07
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto08:10
*** Jones42 <Jones42!~Jones42@i577BF1A1.versanet.de> has joined #yocto08:15
*** Guest76 <Guest76!~Guest76@212.121.145.6> has joined #yocto08:17
*** Guest76 is now known as cgeye08:19
mcfrisk_michalk0: a recipe is like Debian source package, it produces multiple binary packages. See https://docs.yoctoproject.org/dev/singleindex.html#term-PACKAGES https://docs.yoctoproject.org/dev/singleindex.html#term-FILES https://docs.yoctoproject.org/dev/singleindex.html#ref-tasks-install08:24
mcfrisk_michalk0: images are created using binary packages. recipes build source trees to produce those binary packages. A source tree can produce a lot of things which get packaged to different binary packages. Yes, multiple recipes can be built from a single source tree (SRC_URI) but also a single recipe can produce multiple output binary packages for different purposes08:26
*** arielmrmx <arielmrmx!~quassel@189.164.10.228> has quit IRC (Ping timeout: 255 seconds)08:28
*** michalk0 <michalk0!~michalk0@ovg179.internetdsl.tpnet.pl> has quit IRC (Quit: Client closed)08:29
*** michalk0 <michalk0!~michalk0@ovg179.internetdsl.tpnet.pl> has joined #yocto08:29
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto08:38
*** michalk0 <michalk0!~michalk0@ovg179.internetdsl.tpnet.pl> has quit IRC (Ping timeout: 250 seconds)08:43
*** c-thaler <c-thaler!~c-thaler@213.221.121.44> has joined #yocto08:44
*** michalk0 <michalk0!~michalk0@ovg179.internetdsl.tpnet.pl> has joined #yocto08:44
rburtonrfs613: so if its _task_ errors then that's nothing to do with packages in the rootfs, and all my suggestions were about packages in the rootfs.  can you share the actual error log?08:48
michalk0mcfrisk_: thanks for the explanation :)08:49
*** Jones42 <Jones42!~Jones42@i577BF1A1.versanet.de> has quit IRC (Quit: Client closed)08:51
*** Kubu_work <Kubu_work!~kubu@lfbn-nan-1-335-137.w82-120.abo.wanadoo.fr> has quit IRC (Remote host closed the connection)08:55
*** AdrianF <AdrianF!~adrianf@212-51-147-138.fiber7.init7.net> has quit IRC (Ping timeout: 256 seconds)08:56
*** Kubu_work <Kubu_work!~kubu@2a01cb05949d5800e3ef2d7a4131071f.ipv6.abo.wanadoo.fr> has joined #yocto08:56
*** michalk0 <michalk0!~michalk0@ovg179.internetdsl.tpnet.pl> has quit IRC (Quit: Client closed)09:00
*** sakoman <sakoman!~sakoman-l@209.237.67.158> has quit IRC (Read error: Connection reset by peer)09:05
*** sakoman <sakoman!~sakoman-l@209.237.67.158> has joined #yocto09:06
*** michalk0 <michalk0!~michalk0@ovg179.internetdsl.tpnet.pl> has joined #yocto09:54
*** starblue <starblue!~juergen@87.122.36.56> has quit IRC (Ping timeout: 268 seconds)09:57
*** starblue <starblue!~juergen@87.122.36.56> has joined #yocto09:58
*** michalk0 <michalk0!~michalk0@ovg179.internetdsl.tpnet.pl> has quit IRC (Quit: Client closed)10:04
*** c-thaler <c-thaler!~c-thaler@213.221.121.44> has quit IRC (Quit: Client closed)10:17
*** amitk_ <amitk_!~amit@58.84.62.197> has joined #yocto10:19
*** amitk <amitk!~amit@58.84.60.75> has quit IRC (Ping timeout: 256 seconds)10:23
*** sakoman <sakoman!~sakoman-l@209.237.67.158> has quit IRC (Ping timeout: 260 seconds)10:36
rfs613rburton: I reached the same conclusion... studied the logs (with -v -DD) and found a few red herrings... then finally decide to look at the code.10:39
rfs613rburton: the error i'm seeing is from https://github.com/openembedded/openembedded-core/blob/master/meta/classes-global/staging.bbclass#L58310:39
rburtonrfs613: seeing the log would let me help a lot more but I guess you end up building u-boot twice which deploys u-boot twice and they both ship the same filename10:40
rfs613rburton: it's looking at manifests from sstate-control. ANd indeed I can see a difference in those manifests between kirkstone & scarthgap.10:40
rfs613rburton: yep, we have to recipes for u-boot, both are built, and indeed they install files in do_deploy() to $DEPLOYDIR10:41
rfs613it is those files which are appearing in the sstate-control manifest, but only in scarthgap.10:42
rfs613on kirkstone the same manifest only has sysroot-providers/u-boot-foobar10:43
rfs613(but no actual filenames)10:43
LetoThe2ndRP: taking a skim read on your friend-making mail, my perspective is that now its the perfect point in time to do things like that.10:47
RPLetoThe2nd: right, this is definitely the time to do this kind of thing10:48
rfs613rburton: so, I think the warning is corret - both do_deploy() really are placing the same u-boot.bin into DEPLOYDOR, the second one overwrites the first.10:49
LetoThe2ndRP: also a good time to blast https://youtu.be/1jCwBC1TKIM10:50
LetoThe2ndexcept rburton - you get https://youtu.be/HCBPmxiVMKk10:51
*** sakoman <sakoman!~sakoman-l@209.237.67.158> has joined #yocto10:51
rfs613rburton: it's just that we got away with it previously (we also copy the file into a subdir with a different name, so the main u-boot.bin was of no concern)10:53
RPLetoThe2nd: we're allowed chainsaws? :)10:58
LetoThe2ndRP: we are.10:58
* RP suspects that is against an LF policy 10:58
* LetoThe2nd is pretty sure that LF has no policy regarding yard or wood work.10:59
*** sakoman <sakoman!~sakoman-l@209.237.67.158> has quit IRC (Ping timeout: 268 seconds)11:00
*** mvlad <mvlad!~mvlad@2a02:2f05:8211:1c00:e88e:21ff:fe65:be18> has joined #yocto11:05
*** Jones42 <Jones42!~Jones42@i577BF1A1.versanet.de> has joined #yocto11:06
*** ehussain <ehussain!~Thunderbi@2400:adc5:122:ef00:3c0a:77c2:5ecc:b4c8> has quit IRC (Ping timeout: 260 seconds)11:09
*** alessioigor <alessioigor!~alessioig@185.178.95.238> has quit IRC (Remote host closed the connection)11:16
*** cgeye <cgeye!~Guest76@212.121.145.6> has quit IRC (Quit: Client closed)11:16
rfs613rburton: alright, I got it now. U-boot has a do_install (stock one) as well as our custom do_deploy().  Since we have two copies of the recipe, the same do_install happens in each, and that causes the error.  When i stub out do_install in one of our recipes, the error goes away.11:31
rfs613rburton: but I guess the interesting bit is that yocto is recording files during do_install, and reporting conflicts based on those, even when the packages are not being installed into rootfs. Which seems a bit odd?11:32
rburtonits not. its recording the contents of the sysroots.11:34
RPrfs613: the issue is conflicts in the sysroots, not the target image11:37
RPDEPENDS = "a b" and a and b have overlapping files in the sysroot so the system errors and asks you which you want. Similar to that11:38
rfs613okay, but why are these (target binaries) going into sysroots? I though that was for sharing stuff (headers, libs) between recipes?11:39
* rfs613 will be back in a few hours11:44
rburtonrfs613: again, without seeing the logs its very hard to help.  they're probab;y both deploying to the same place11:48
*** goliath <goliath!~goliath@user/goliath> has joined #yocto11:52
*** enok71 <enok71!~Thunderbi@2a02:aa1:1041:8f44:ffdf:5f1e:7292:c249> has joined #yocto11:53
*** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has quit IRC (Ping timeout: 264 seconds)11:55
*** enok71 is now known as enok11:55
*** enok71 <enok71!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has joined #yocto11:58
*** enok <enok!~Thunderbi@2a02:aa1:1041:8f44:ffdf:5f1e:7292:c249> has quit IRC (Ping timeout: 256 seconds)12:02
*** enok71 is now known as enok12:02
*** pbiel <pbiel!~bielpa@89-70-29-32.dynamic.chello.pl> has joined #yocto12:19
pbielHi, I've got a question regarding scarthgap release, gcc version in particular. It seems that in the release the gcc 13.2 is included, however I'm not sure how to understand the following comment form "Notes" section: "GCC 14 scheduled after YP"12:20
*** lthadeus_away <lthadeus_away!~lthadeus@2401:4900:1f25:4656:a569:e04e:22c6:74e2> has joined #yocto12:20
pbielfrom*12:21
*** lthadeus_away <lthadeus_away!~lthadeus@2401:4900:1f25:4656:a569:e04e:22c6:74e2> has quit IRC (Client Quit)12:21
pbielDoes it mean that GCC version for scarthgap will lifted to gcc 14, after the gcc release?12:22
rburtonno, it means master will get 14.x12:26
rburtonscarthgap may well get 13.312:26
RPyes, scarthgap will remain on 13 but update down the stable series there most likely12:41
*** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has quit IRC (Quit: enok)12:45
*** enok71 <enok71!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has joined #yocto12:45
*** fabatera <fabatera!~fabatera@ip5f5af47e.dynamic.kabel-deutschland.de> has joined #yocto12:46
*** sakoman <sakoman!~sakoman-l@209.237.67.158> has joined #yocto12:47
fabateraHi, how can I set the LICENSE when it's proprietary and the license file is inside the package being fetched/built?12:47
fabateraOne idea is to set LICENSE = "Proprietary" and use LIC_FILES_CHKSUM ="path_to_the_unpacked_package_file"12:47
fabatera12:1212:47
fabateraNot sure this is the proper way of doing it12:47
rburtonset LICENSE=CLOSED and you won't need to set LIC_FILES_CHKSUM, if you're not distributing the recipes12:47
*** enok71 is now known as enok12:48
rburtonif its a recipe that will be distributed then yeah, LIC_FILES_CHKSUM should point to the license text inside the tarball or whatever12:48
RPyocton: I've merged some patches to improve the patch metrics graphs for oe-core. I'm wondering if we want to copy those changes for meta-oe's graphs?12:52
* RP will probably get to it eventually but I'm open to help if anyone is interested :)12:53
yoctonRP: most likely. Improvement on OE-Core graphs would surely benefit meta-oe graphs12:53
RPyocton: the oe-core ones aren't quite right yet but getting there12:55
yoctonI'll send this to my padawan. He may find this interresting :)12:56
*** mkazantsev <mkazantsev!~mkazantse@mail.orangedata.ru> has joined #yocto12:56
RPyocton: I wondered, thanks :)12:56
*** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has quit IRC (Ping timeout: 268 seconds)13:03
*** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has joined #yocto13:14
*** dmoseley <dmoseley!~dmoseley@d4-50-177-189.evv.wideopenwest.com> has quit IRC (Quit: ZNC 1.9.0 - https://znc.in)13:18
*** dmoseley <dmoseley!~dmoseley@d4-50-177-189.evv.wideopenwest.com> has joined #yocto13:20
*** vladest <vladest!~Thunderbi@217.192.139.41> has quit IRC (Ping timeout: 268 seconds)13:22
*** joekale <joekale!~quassel@140.141.144.30> has joined #yocto13:24
*** dmoseley <dmoseley!~dmoseley@d4-50-177-189.evv.wideopenwest.com> has quit IRC (Quit: ZNC 1.9.0 - https://znc.in)13:26
*** dmoseley <dmoseley!~dmoseley@d4-50-177-189.evv.wideopenwest.com> has joined #yocto13:28
*** Jones42 <Jones42!~Jones42@user/Jones42> has quit IRC (Quit: Client closed)13:34
*** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has quit IRC (Ping timeout: 252 seconds)13:36
*** Abp <Abp!~Abp@188-206-111-192.mobile.kpn.net> has quit IRC (Read error: Connection reset by peer)13:39
*** Abp <Abp!~Abp@84-107-6-196.cable.dynamic.v4.ziggo.nl> has joined #yocto13:39
*** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has joined #yocto13:48
*** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has joined #yocto13:51
*** Guest28 <Guest28!~Guest28@p200300f1c708b800a07e3f1e3675e79d.dip0.t-ipconnect.de> has joined #yocto13:51
*** Guest28 <Guest28!~Guest28@p200300f1c708b800a07e3f1e3675e79d.dip0.t-ipconnect.de> has quit IRC (Client Quit)13:52
*** ehussain <ehussain!~Thunderbi@2400:adc5:122:ef00:3c0a:77c2:5ecc:b4c8> has joined #yocto13:56
*** fabatera <fabatera!~fabatera@ip5f5af47e.dynamic.kabel-deutschland.de> has quit IRC (Quit: Client closed)13:59
*** fabatera <fabatera!~fabatera@ip5f5af47e.dynamic.kabel-deutschland.de> has joined #yocto14:06
*** locutusofborg_ is now known as locutusofborg14:10
*** pbsds <pbsds!~pbsds@84.20.102.94> has quit IRC (Ping timeout: 252 seconds)14:11
*** pbsds3 <pbsds3!~pbsds@84.20.102.94> has joined #yocto14:12
*** fabatera <fabatera!~fabatera@ip5f5af47e.dynamic.kabel-deutschland.de> has quit IRC (Quit: Leaving)14:13
*** fabatera <fabatera!~fabatera@ip5f5af47e.dynamic.kabel-deutschland.de> has joined #yocto14:15
*** fabatera <fabatera!~fabatera@ip5f5af47e.dynamic.kabel-deutschland.de> has quit IRC (Client Quit)14:15
*** sakoman <sakoman!~sakoman-l@209.237.67.158> has quit IRC (Ping timeout: 268 seconds)14:17
*** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has quit IRC (Remote host closed the connection)14:21
*** mkazantsev <mkazantsev!~mkazantse@mail.orangedata.ru> has quit IRC (Remote host closed the connection)14:24
*** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has joined #yocto14:27
*** Abp <Abp!~Abp@84-107-6-196.cable.dynamic.v4.ziggo.nl> has quit IRC (Ping timeout: 268 seconds)14:43
*** Abp <Abp!~Abp@188-206-111-13.mobile.kpn.net> has joined #yocto14:44
*** yudjinn <yudjinn!~yudjinn@c-73-153-47-71.hsd1.co.comcast.net> has joined #yocto14:50
*** Marmottus11 <Marmottus11!~marmottus@2001:bc8:1820:2715::1> has quit IRC (Quit: The Lounge - https://thelounge.chat)14:56
*** Abp <Abp!~Abp@188-206-111-13.mobile.kpn.net> has quit IRC (Read error: Connection reset by peer)14:56
*** Marmottus11 <Marmottus11!~marmottus@2001:bc8:1820:2715::1> has joined #yocto14:57
*** Abp <Abp!~Abp@84-107-6-196.cable.dynamic.v4.ziggo.nl> has joined #yocto14:57
*** davidinux <davidinux!~davidinux@194.34.233.32> has quit IRC (Quit: WeeChat 3.5)14:59
*** rfuentess <rfuentess!~rfuentess@lfbn-lyo-1-1566-5.w90-52.abo.wanadoo.fr> has quit IRC (Remote host closed the connection)15:03
*** sotaoverride is now known as Guest406915:05
*** Guest4069 <Guest4069!~ctraven@139.68.81.2> has quit IRC (Killed (cadmium.libera.chat (Nickname regained by services)))15:05
*** xmn <xmn!~xmn@pool-108-46-142-76.nycmny.fios.verizon.net> has joined #yocto15:09
*** ctraven <ctraven!~ctraven@139.68.81.2> has joined #yocto15:11
*** Abp <Abp!~Abp@84-107-6-196.cable.dynamic.v4.ziggo.nl> has quit IRC (Ping timeout: 246 seconds)15:19
*** Abp <Abp!~Abp@188-206-111-13.mobile.kpn.net> has joined #yocto15:20
*** AdrianF <AdrianF!~adrianf@212-51-147-160.fiber7.init7.net> has joined #yocto15:36
*** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has quit IRC (Ping timeout: 268 seconds)15:37
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 245 seconds)15:42
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat)15:45
*** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Ping timeout: 252 seconds)15:47
*** Kubu_work <Kubu_work!~kubu@2a01cb05949d5800e3ef2d7a4131071f.ipv6.abo.wanadoo.fr> has quit IRC (Quit: Leaving.)15:55
*** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has joined #yocto16:00
rfs613rburton: RP: ERROR: test-image-1.0-r0 do_image_complete: The file /boot/u-boot.bin is installed by both u-boot-rzn1 and u-boot-rzn1-spkg, aborting16:06
rburtonwell, there you go16:08
rburtonyou're definitely installing two u-boot packages into your image16:09
rfs613no, the error is misleading16:11
rburtonoh thats the sysroot validation.16:12
rburtonyou're depending on both and they both ship the same file16:12
rburtonjust make your image depend on the right bootloader?16:13
rfs613there are indeed two u-boot packages, and they both have a do_install, which indeed installs the same files into $DEPLOYDIR16:13
rburtonand they're both being depended by your image16:15
rfs613neither of the u-boot packages produces a .deb (intentionaly). We have a do_deploy() in each package, which copies the file to another name/location.16:16
rfs613but we are inheriting the default do_install from u-boot recipe in oe-core.  If I declare my own do_install to override that, problem goes away.16:17
rfs613IMAGE_INSTALL does not include either of the u-boot recipes.16:19
rfs613they onluy get build due to EXTRA_IMAGEDEPENDS16:19
rburtonright16:19
rfs613so I am wondering now, why is do_install being called... i guess there's a dependency chain16:19
rburtonthat says "when building these images, also deploy these other recipes"16:20
rburtonand you're deploying two u-boot recipes that ship the same file16:20
rburtonjust stop the image depending on _both_ u-boots16:20
RPrfs613: the problem isn't do_install, it is do_deploy16:20
rfs613ah but we want two u-boots to be built (but not installed into the image)16:20
RPah, probably not. That is probably do_install16:21
rburtonrfs613: whats the point of building two if one of them isn't being used?16:21
rfs613rburton: building in CI for multiple configurations/boards.16:21
RPrfs613: recipes-bsp/u-boot/u-boot.inc:SYSROOT_DIRS += "/boot"16:22
RPrfs613: that says "please ensure the files in /boot" go into the sysroot16:22
rfs613RP: thanks, I was starging to look at those SYSROOT settings.16:22
rburtonrfs613: i'd build two images, each with the uboot you care about.  build testing is only half testing, after all.16:22
RPyou have files that overlap so it errors16:22
rfs613rburton: that would take forever ;-)16:23
rburtonremoving /boot from SYSROOT_DIRS in a bbappend would likely work, if you don't pull uboot from the sysroot16:23
rfs613RP: the default SYSROOT_DIRS in the documentation only mentioned bin sbin ... so i was surprised that /boot would be included.16:23
rburtonits not a default, its a uboot addition16:24
rfs613and probalby this was added in scarthgap?16:24
rburtonbecause sometimes its a lot easier to construct larger images via pulling pieces from sysroot instead of deploydir16:24
rburtonnanbield, iirc16:24
rburtonhttps://git.yoctoproject.org/poky/commit/meta/recipes-bsp/u-boot/u-boot.inc?id=c4790644f980e68b1577df4788053efc0c317b1416:25
rfs613yep, its' not present in my kirkstone branch... so that likely explains why we "got away" with this16:29
rfs613instead of having two recipes for u-boot, I should probably make use of UBOOT_MACHINE and UBOOT_CONFIG options in the stock recipe. But it's a little unclear to me, how to support config fragments in addition to multiple configs.16:35
*** khem <khem!khem@2600:3c02::f03c:93ff:fe83:edf2> has joined #yocto16:44
khemRP: I would like to run few gcc-14 branch runs is AB bandwidth available ? I know we are close on scarthgap release so dont want to create more variability since it will create quite a lot of new sstate objects16:45
rburtonkhem: i did a side project with it and it worked lovely, so thanks for the branch16:47
rburtonintegrated the Guard Control Stack patchbombs, if you're interested see https://git.yoctoproject.org/meta-arm/log/?h=testing/gcs16:48
dvergatalhmmm why setVar in one task does not make the change visible for another task of the same recipe?16:49
dvergatalif i do the same but with python __anonymous() {} than the change is visible...16:50
rburtoniirc each task runs in its own copy of the data store, so you can't just bubble changes between tasks like that16:51
dvergatalrburton: aha and it is not possible?16:51
rburton(rp correct me if i'm wrong)16:52
rburtonnot between entirely independent tasks, no16:52
rburtonyou could re-run the later tasks, and bitbake would need to somehow know what those other data values were16:53
dvergatalaha I can do a prefunc16:53
rburtonyeah they work, same context16:53
dvergatalok got it16:53
dvergatalrburton: thx16:53
*** sakoman <sakoman!~sakoman-l@209.237.67.158> has joined #yocto16:54
RPkhem: we're ok from a scarthgap perpective but the autobuilder is below capacity at the moment for reasons. You can probably go ahead but carefully. Are you wanting a-full or targetted things?16:56
RPrburton: you are not wrong :)16:56
RPkhem: I also have a heavy build running atm :(16:57
*** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has joined #yocto16:59
marexrfs613: u-boot should be working perfectly, what's up ?17:05
*** florian_kc <florian_kc!~florian@dynamic-080-171-044-055.80.171.pool.telefonica.de> has joined #yocto17:06
rfs613marex: oh, this is a vendor created complexity, that broke on upgrade to scarthgap.17:13
rfs613but I am thinking whether we can eliminate it and just use the oe-core u-boot recipe17:13
khemRP: I plan to run it over weekend, I am still traveling17:13
marexrfs613: or by using mainline U-Boot ? :)17:14
rfs613the thing I'm not clear about, is: we want to generate two u-boot binaries, each with the same basic _defconfig, but a config fragment to adjust some settings.17:14
khemrfs613:look how meta-ti does it17:14
* rfs613 looks17:16
marexrfs613: why do you need two u-boot builds per one OE build btw ?17:16
marexrfs613: isnt it possible to generate single u-boot binary ?17:16
rfs613marex: for a variety of reasons, we want to build multiple u-boots as part of the same OE build.17:17
marexhum17:19
rfs613marex: so the obvious one is secure vs non-secure boot.17:19
marexrfs613: you mean signed vs. unsigned ? On some SoCs that is possible with single binary :)17:22
marexrfs613: I generally try to stick to single multi-purpose binary because it is easier for users to decide which binary to install on their system ; if there is only one, the choice is easy17:22
rfs613marex: I mean stuff like CONFIG_ARMV7_NONSEC17:25
rfs613eg. which "world" are we executing in, and does u-boot switch worlds upon hand-off?17:26
marexrfs613: bootm_boot_mode env var can toggle between the two, can it not ?17:26
marexrfs613: my recollection may be fuzzy tho, and maybe this is better discussed in #u-boot17:27
rfs613some of this affects very early boot code, so it wuold be difficult to chang at runtime17:27
rfs613indeed, i'm not trying to fix uboot here, I was just trying to understand why we have problems building our recipes under scartgap... and I now know why that is ;-)17:27
marexrfs613: ack17:28
rfs613khem: the TI u-boot recipe is interesting, esp the u-boot-mergeconfig.inc  ... they add a new variable for the fragments, instead of pickign them out of SRC_URI... which I like better, but I didn't even consider it before, as I didn't want to "swim upstream"17:30
rfs613(that was probably not the right phrase... I mean that the oe-core handles fragments by looking for *.config in SRC_URI... so I assumed this was the "correct" way... even though separate variable makes more sense to me!)17:32
*** davidinux <davidinux!~davidinux@45.11.82.93> has joined #yocto17:34
denixrfs613, khem: u-boot recipe looks for *.cfg in SRC_URI for config fragments, correct. but it handles them out of order, unfortunately, as U-boot itself has the concept of config fragments with in-tree *.confg files. there's no way to apply OE out-of-tree *.cfg *AFTER* in-tree *.config, hence meta-ti had to add that extra handling...17:42
rfs613denix: ah yes, the *.config is in u-boot itself... whereas yocto uses *.cfg17:48
rfs613denix: i did not realize they are not handled in order... that could be problematic, resulting in differnent .config in the end17:49
denixindeed17:53
rfs613do you know if it happens for just *.cfg in the SRC_URI alone?17:54
khemrfs613: I did not suggest it for config fragments but how it runs multiple builds and generates multiple u-boots binaries17:59
khemmerge config is pretty much handled by cml1 class anyway18:01
*** khem <khem!khem@2600:3c02::f03c:93ff:fe83:edf2> has quit IRC (Quit: WeeChat 4.2.2)18:03
denixrfs613: for multiple builds of u-boot use UBOOT_CONFIG - see e.g. https://git.yoctoproject.org/meta-ti/tree/meta-ti-bsp/conf/machine/am335x-hs-evm.conf18:12
rfs613yes I was just looking at https://docs.yoctoproject.org/ref-manual/variables.html#term-UBOOT_CONFIG18:12
rfs613the example there shows several different _defconfigs being used18:13
rfs613in my case, I would like the same _defconfig, but wiht additional *.cfg for each build.18:13
rfs613(the idea being to avoid maintaining several almost-identical _defconfig in the uboot tree)18:15
*** khem <khem!khem@2600:3c02::f03c:93ff:fe83:edf2> has joined #yocto18:20
*** legraps <legraps!~anaumann@ipb21bd56e.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 256 seconds)18:26
*** pbiel <pbiel!~bielpa@89-70-29-32.dynamic.chello.pl> has quit IRC (Quit: Leaving)18:30
denixrfs613: yeah, I don't think that use case is covered...18:35
*** amitk_ <amitk_!~amit@58.84.62.197> has quit IRC (Ping timeout: 252 seconds)18:47
*** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has quit IRC (Quit: vladest)18:47
*** Jones42 <Jones42!~Jones42@i577BF1A1.versanet.de> has joined #yocto19:11
*** Abp <Abp!~Abp@188-206-111-13.mobile.kpn.net> has quit IRC (Read error: Connection reset by peer)19:26
*** Abp <Abp!~Abp@84-107-6-196.cable.dynamic.v4.ziggo.nl> has joined #yocto19:27
*** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has joined #yocto19:37
*** mvlad <mvlad!~mvlad@2a02:2f05:8211:1c00:e88e:21ff:fe65:be18> has quit IRC (Remote host closed the connection)20:00
*** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5381:8b40:ff96:1c37:5a97:d24f> has quit IRC (Ping timeout: 255 seconds)20:33
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving)20:37
*** legraps <legraps!~anaumann@ipb21bd56e.dynamic.kabel-deutschland.de> has joined #yocto20:44
*** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5381:8b40:6b33:40ba:56bd:2cc3> has joined #yocto20:46
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto20:48
*** legraps <legraps!~anaumann@ipb21bd56e.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 252 seconds)21:08
*** olani- <olani-!~olani@66.159.215.7> has joined #yocto21:11
*** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has quit IRC (Quit: enok)21:15
*** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has joined #yocto21:15
*** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has quit IRC (Client Quit)21:17
*** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has joined #yocto21:18
*** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has quit IRC (Remote host closed the connection)21:18
*** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has joined #yocto21:19
*** Abp <Abp!~Abp@84-107-6-196.cable.dynamic.v4.ziggo.nl> has quit IRC (Ping timeout: 264 seconds)21:39
*** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Ping timeout: 272 seconds)21:52
*** nerdboy <nerdboy!~nerdboy@47.143.129.152> has joined #yocto22:05
*** Abp <Abp!~Abp@84-107-6-196.cable.dynamic.v4.ziggo.nl> has joined #yocto22:15
*** Abp <Abp!~Abp@84-107-6-196.cable.dynamic.v4.ziggo.nl> has quit IRC (Ping timeout: 240 seconds)22:19
*** olani- <olani-!~olani@66.159.215.7> has quit IRC (Ping timeout: 272 seconds)22:29
moto-timorfs613: you might be able to use *.diff or *.patch files in SRC_URI:append:<machine override> instead of *.cfg fragments. Hinted at by https://stackoverflow.com/questions/47047209/how-to-change-the-config-of-u-boot-in-yocto22:33
moto-timorfs613: the mechanism with *.cfg fragments for the linux kernel is not (yet) implemented for u-boot.22:34
rfs613moto-timo: I've used patch files for this in the past, but they are a headache anytime you change the base config.22:37
moto-timorfs613: that is the mechanism you have at this time.22:38
moto-timohas anybody done Yocto builds on Ubuntu 24.04 yet? Trying to create the crops container libegl1-mesa is no longer available, so I am not sure if it should be dropped or replaced with libegl1-mesa-dev22:47
moto-timohttps://github.com/crops/yocto-dockerfiles/actions/runs/8853986259/job/2431602555622:49
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)22:54
*** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has quit IRC (Ping timeout: 268 seconds)23:23

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