Tuesday, 2022-02-15

*** sgw <sgw!~swold_loc@user/sgw> has quit IRC (Remote host closed the connection)00:03
*** sgw <sgw!~swold_loc@user/sgw> has joined #yocto00:13
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto00:14
*** superdupond <superdupond!~Kev@2a01cb0400149f0020a63845738b1ffd.ipv6.abo.wanadoo.fr> has quit IRC (Ping timeout: 252 seconds)00:21
*** chrfle <chrfle!~chrfle@217-209-195-249-no206.tbcn.telia.com> has joined #yocto00:23
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Ping timeout: 272 seconds)00:29
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto00:30
*** dev1990 <dev1990!~dev@> has quit IRC (Quit: Konversation terminated!)00:51
*** kanavin_ <kanavin_!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has joined #yocto01:07
*** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has quit IRC (Ping timeout: 256 seconds)01:10
*** jclsn7 <jclsn7!~jclsn@> has quit IRC (Ping timeout: 250 seconds)01:12
*** jclsn7 <jclsn7!~jclsn@> has joined #yocto01:18
*** jclsn7 <jclsn7!~jclsn@> has quit IRC (Ping timeout: 252 seconds)01:24
*** jclsn7 <jclsn7!~jclsn@> has joined #yocto01:30
*** jclsn7 <jclsn7!~jclsn@> has quit IRC (Ping timeout: 252 seconds)01:36
*** jclsn7 <jclsn7!~jclsn@> has joined #yocto01:43
*** jclsn7 <jclsn7!~jclsn@> has quit IRC (Ping timeout: 252 seconds)01:56
*** jclsn7 <jclsn7!~jclsn@> has joined #yocto01:57
*** jclsn7 <jclsn7!~jclsn@> has quit IRC (Client Quit)02:02
*** jclsn7 <jclsn7!~jclsn@> has joined #yocto02:02
*** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Quit: Thorn)02:02
*** jclsn7 <jclsn7!~jclsn@> has quit IRC (Ping timeout: 252 seconds)02:07
*** jclsn7 <jclsn7!~jclsn@> has joined #yocto02:13
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)02:16
*** jclsn7 <jclsn7!~jclsn@> has quit IRC (Ping timeout: 252 seconds)02:21
*** jclsn7 <jclsn7!~jclsn@> has joined #yocto02:21
*** jclsn7 <jclsn7!~jclsn@> has quit IRC (Ping timeout: 252 seconds)02:26
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto02:27
*** jclsn7 <jclsn7!~jclsn@> has joined #yocto02:29
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Client Quit)02:30
*** rber|res <rber|res!~rber|res@ppp-2-86-184-111.home.otenet.gr> has joined #yocto02:32
*** RobertBerger <RobertBerger!~rber|res@ppp-2-86-184-111.home.otenet.gr> has quit IRC (Ping timeout: 240 seconds)02:34
*** jclsn7 <jclsn7!~jclsn@> has quit IRC (Ping timeout: 252 seconds)02:41
*** jclsn7 <jclsn7!~jclsn@> has joined #yocto02:47
*** jclsn7 <jclsn7!~jclsn@> has quit IRC (Ping timeout: 252 seconds)02:58
*** jclsn7 <jclsn7!~jclsn@> has joined #yocto03:05
*** jclsn76 <jclsn76!~jclsn@> has joined #yocto03:08
*** jclsn7 <jclsn7!~jclsn@> has quit IRC (Ping timeout: 272 seconds)03:10
*** jclsn76 is now known as jclsn703:10
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 252 seconds)03:13
*** camus <camus!~Instantbi@> has joined #yocto03:13
*** TurBoss <TurBoss!~turboss@2001:470:69fc:105::eae> has joined #yocto03:29
*** jclsn7 <jclsn7!~jclsn@> has quit IRC (Ping timeout: 272 seconds)03:36
*** camus1 <camus1!~Instantbi@> has joined #yocto03:41
*** jclsn7 <jclsn7!~jclsn@> has joined #yocto03:41
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 252 seconds)03:42
*** camus1 is now known as camus03:42
*** jclsn7 <jclsn7!~jclsn@> has quit IRC (Quit: Ping timeout (120 seconds))03:49
*** jclsn7 <jclsn7!~jclsn@> has joined #yocto03:49
*** jclsn7 <jclsn7!~jclsn@> has quit IRC (Ping timeout: 252 seconds)04:01
*** jclsn7 <jclsn7!~jclsn@> has joined #yocto04:09
*** Lcvette[m] <Lcvette[m]!~lcvettema@2001:470:69fc:105::e43> has joined #yocto04:15
Lcvette[m]how do we have ps at configure time with autotools?04:19
Lcvette[m]getting an error ps not found04:19
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.)04:34
*** amitk <amitk!~amit@> has joined #yocto04:39
TurBossLcvette: I could finally join!04:45
TurBossthanks for asking for me04:45
TurBossthis is my recipe https://github.com/TurBoss/meta-qtpyvcp/blob/honister/recipes-linuxcnc/linuxcnc/linuxcnc_2.9.bb#L2204:46
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 240 seconds)06:16
*** Etheryon <Etheryon!~Etheryon@> has joined #yocto06:52
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto07:15
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:15
*** ekathva_ <ekathva_!~ekathva@n3k06ap29nlro92ao-1.v6.elisa-mobile.fi> has joined #yocto07:19
*** ekathva_ <ekathva_!~ekathva@n3k06ap29nlro92ao-1.v6.elisa-mobile.fi> has quit IRC (Remote host closed the connection)07:19
*** frieder <frieder!~frieder@mue-88-130-78-041.dsl.tropolys.de> has joined #yocto07:20
LetoThe2ndyo dudX07:27
*** superdupond <superdupond!~Kev@2a01cb0400149f0020a63845738b1ffd.ipv6.abo.wanadoo.fr> has joined #yocto07:28
*** goliath <goliath!~goliath@user/goliath> has joined #yocto07:31
*** GillesM <GillesM!~gilles@> has joined #yocto07:35
*** GillesMM <GillesMM!~gilles@> has joined #yocto07:36
*** GillesMM <GillesMM!~gilles@> has quit IRC (Remote host closed the connection)07:36
*** superdupond <superdupond!~Kev@2a01cb0400149f0020a63845738b1ffd.ipv6.abo.wanadoo.fr> has quit IRC (Ping timeout: 252 seconds)07:36
*** mckoan|away is now known as mckoan07:43
mckoangood morning07:44
*** zpfvo <zpfvo!~fvo@> has joined #yocto07:46
*** ex-bugsbunny <ex-bugsbunny!~Harry@p2e5302a8.dip0.t-ipconnect.de> has joined #yocto07:52
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 250 seconds)07:55
*** zpfvo <zpfvo!~fvo@> has joined #yocto07:55
*** dev1990 <dev1990!~dev@> has joined #yocto07:59
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 250 seconds)08:00
*** zpfvo <zpfvo!~fvo@> has joined #yocto08:01
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)08:18
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto08:22
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 252 seconds)08:31
*** zpfvo <zpfvo!~fvo@> has joined #yocto08:31
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)08:50
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:bf13:d847:c69:16ff> has joined #yocto09:10
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto09:11
*** goliath <goliath!~goliath@user/goliath> has joined #yocto09:15
*** jsandman <jsandman!~jsandman@> has quit IRC (Quit: Ping timeout (120 seconds))09:18
*** jsandman9 <jsandman9!~jsandman@> has joined #yocto09:18
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 252 seconds)09:34
*** zpfvo <zpfvo!~fvo@> has joined #yocto09:35
frosteyesMorning from DK09:35
frosteyeswho *09:37
*** StayLearning[m] <StayLearning[m]!~staylearn@2001:470:69fc:105::1:bf3f> has joined #yocto09:39
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 250 seconds)09:39
*** zpfvo <zpfvo!~fvo@> has joined #yocto09:39
frosteyesHey folks. I am working on an apollo lake based platform, where I would like to run the latest 4.19 kernel with the patches from intel - https://github.com/intel/iotg-yocto-bsp-public/tree/e3900/master/meta-intel-leafhill09:45
frosteyesUnfortunately it seems to use an ipu firmware - i can't find anywhere09:46
frosteyesThe last patch in the series is 0011-isys-psys-package-lib2600b0-for-commit-id-fec284b.patch where it is upgraded to a ipu firmware 0x2020092209:47
frosteyesI can find earlier version in clearlinux - but can't seem to find this anywhere.09:48
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 272 seconds)09:50
*** zpfvo <zpfvo!~fvo@> has joined #yocto09:51
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto09:53
*** Etheryon <Etheryon!~Etheryon@> has quit IRC (Quit: Client closed)09:57
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 252 seconds)09:59
*** zpfvo <zpfvo!~fvo@> has joined #yocto09:59
*** tnovotny <tnovotny!~tnovotny@ip-78-45-97-113.net.upcbroadband.cz> has joined #yocto10:23
*** smsm <smsm!~smsm@eth1-fw1-nbg6.eb.noris.de> has joined #yocto10:26
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 272 seconds)10:35
*** zpfvo <zpfvo!~fvo@> has joined #yocto10:36
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto10:38
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 272 seconds)10:40
*** davidinux <davidinux!~davidinux@> has joined #yocto10:41
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…)10:44
*** Etheryon <Etheryon!~Etheryon@> has joined #yocto10:49
EtheryonHi all, I'm trying to copy over some files to my image but I'm having some issue. I'm clearly missing some knowledge so any help would be greatly appreciated. Here's my bb recipe file, let me know what I'm doing wrong10:50
EtheryonLICENSE = "CLOSED"10:50
EtheryonPACKAGE_ARCH = "all"10:50
Etheryoninherit externalsrc10:50
EtheryonYOCTOROOT = "${@os.path.abspath(os.path.join("${TOPDIR}", os.pardir))}"10:50
EtheryonEXTERNALSRC = "${YOCTOROOT}/resources/"10:50
Etheryondo_install() {10:50
Etheryon   install -d ${D}${bindir}/resources10:50
Etheryon   install -d -m 0755 ${S} ${D}${bindir}/resources10:50
Etheryoninherit bin_package10:50
qschulzEtheryon: I doubt that install -d -m 0755 ${S} ${D}${bindir}/resources is installing your files10:53
qschulzI think you need a for loop, find exec or cp -r10:53
EtheryonI'm currently getting this error: package_write_rpm not found in ...10:54
Etheryonon do_rootfs: task10:54
EtheryonIs my assumption correct that the files would be located in ${S} ?10:55
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 252 seconds)10:55
*** zpfvo <zpfvo!~fvo@> has joined #yocto10:56
qschulzEtheryon: I think so, you cna always do an ls -l ${S} to check in your do_install and check the install logs in ${WORKDIR}/temp/log.do_install10:56
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 272 seconds)11:00
*** zpfvo <zpfvo!~fvo@> has joined #yocto11:01
RPI'm torn on how to implement the variable rename warnings :/11:03
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 252 seconds)11:04
*** camus <camus!~Instantbi@> has joined #yocto11:05
qschulzRP: anything to suggest so we can share our opinion? or is it somewhere on the ML?11:08
*** Etheryon <Etheryon!~Etheryon@> has quit IRC (Quit: Client closed)11:10
RPqschulz: no, this has all been left so late we now likely can't do that kind of discussion :(11:15
* RP will try and send something out11:16
qschulzRP: I'm surprised there hasn't been any patch except the PN_BLACKLIST one11:17
qschulzis there some non-yet-sent patches somewhere (e.g. contrib repo/branches) or has everything stalled hard11:17
qschulzI was asking for suggestions on the warnings since it seems you're "torn on how to implement [it]"11:18
ziga_@mckoan I added details regarding the distribution in the Stackoverflow as well.11:19
RPqschulz: Right, it comes down to https://git.yoctoproject.org/poky-contrib/commit/?h=rpurdie/t222&id=1cf65b3ce501e7927c6d319b7a4b422f44542a8e or https://git.yoctoproject.org/poky-contrib/commit/?h=rpurdie/t222&id=9e8c7e36cb6c9e06184f94d8670619d3361a0ffc11:20
RPOne gives nice line/file numbers for some cases. "Some" means core conf files bit not recipes11:20
RPbut it is obviously more invasive11:21
*** Etheryon <Etheryon!~Etheryon@> has joined #yocto11:21
RPsadly, these errors don't actually stop the build either11:21
qschulzRP: I assume people are able to do a grep -R with the shown variable and find where it needs to be modified?11:26
RPqschulz: I hope so. There will likely be some script as well11:27
qschulzI would rely more on the migration manual to let people know how to deal with renames than tell them a rename has been made and what's the new name11:28
qschulzI'm also not 100% certain they will ALWAYS be a simple rename?11:28
RPqschulz: none of this automatically renames anything11:28
*** codavi <codavi!~akiCA@user/akica> has joined #yocto11:28
qschulzRP: it does show the new name though11:28
RPqschulz: yes, that seems like something helpful we can do11:28
qschulzthe other question is: is this mechanism supposed to be used later on or just for this specific case of "bulk" renaming?11:29
qschulzmeaning, should we (you :/) spend time crafting something nice that will be ditched in 3.6?11:29
RPqschulz: there is probably a second class of vars which are just obsolete and not used, those could probably have a string value to show11:29
RPqschulz: I suspect this won't be the last time we have this issue so the mechanism will likely stay11:30
qschulzRP: are we supposed to keep compatibility for one release or more for the renames (I remember seeing something like this for PN_BLACKLIST rename)11:32
RPqschulz: depends how you define compatibility11:32
qschulzin which case, we just keep a list of deprecated variables and show a warning to the user and redirect to the docs11:33
RPWhat *really* annoys me is this is the stuff people should have been working out. Change is hard and requires work to make it happen11:33
qschulzand basically do a mapping between the old and newer name11:33
RPwe simply cannot do an automatic conversion11:34
qschulzRP: nope11:34
*** ar__ <ar__!~akiCA@user/akica> has joined #yocto11:34
qschulzRP: I didn't think this would be something we'd look into, I was more into the thought that we 1) do a simple rename with no warning or compatibility 2) have a warning+compatibility implemented for *each* change11:35
qschulzI didn't think we'd go for a global mechanism tbh11:36
qschulz(I was not part of the discussions, just to be clear, this might have been discussed)11:36
qschulzthe issue for my 2 points is that we need to keep track of renames and have the documentation up-to-date11:37
*** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 252 seconds)11:38
qschulzI'm not sure I'm helping or making everything worse here :|11:38
RPqschulz: There is little point in doing this on a case by case basis since we're going to have to have some kind of standard detection/warning mechanism11:39
RPunless we want it done badly several times over11:40
*** superdupond <superdupond!~Kev@2a01cb0400149f0020a63845738b1ffd.ipv6.abo.wanadoo.fr> has joined #yocto11:42
Etheryonso: I found my files in build/tmp/work/all-poky-linux/resources/0.1-r0/image, is this correct?11:43
Etheryonresources/0.1-r0/temp/log.do_install does not contains the output for ls -l11:43
qschulzRP: If I understood correctly, the problem here is that the renamed variables show an error but don't stop the build11:43
qschulzEtheryon: yes this seems about right11:44
Etheryonands that folder would be ${S} ?11:45
qschulzRP: honestly, I'm not sure I would be able to suggest any code implementation so I might be taking some of your time for no real benefit other than roleplaying the rubber duck :/11:45
qschulzEtheryon: no, that's ${D}11:45
RPqschulz: that is one of several issues. I'm going to have to write this up for the list11:48
Etheryonso now I'd need to move them from ${D} to ${D}${bindir}/resources as part of do_install?11:49
Etheryonhow does this translate to where they go on the resulting image?11:51
qschulzlayout in image directory is the layout on the root filesystem11:52
Etheryondo_rootfs is the task that copies them over?11:52
qschulznot really no11:53
qschulzfirst, I'd say you need to inherit bin_package before your do_install11:53
Etheryonso now that they're in ${D} they're basically in / on the resulting image?11:53
qschulzI'm not sure bin_package's custom do_install does not override the do_install you wrote11:54
qschulzso inherit it before you redefine do_install just to be sure (and it's also best practice anyways)11:54
Etheryonok cool11:54
qschulzEtheryon: more or less yes, there's an intermediary step first, the packaging step11:55
Etheryonso I did that, now image has the folder structure I'm expecting, but the files are gone11:55
qschulzwhich splits the content of image directory of your recipe into multiple packages11:55
qschulzthen IF your image recipe pulls a package, the files from the package, respecting the layout in image will be installed11:55
qschulz(technically, it's the layout in package-split/<package> and not image, but they are the same)11:56
qschulzEtheryon: yup, because your install -d ${S} ${D}${bindir} does not do what you think it does11:56
qschulzuse cp -r instead11:56
qschulz(IIRC install -d will just create the directory if it does not exist but not copy its content over)11:57
Etheryonso ${S} is EXTERNALSRC ( did an echo)11:58
Etheryonand I'm now copying from there to D11:58
Etheryonvalue of EXTERNALSRC11:58
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 272 seconds)12:00
*** zpfvo <zpfvo!~fvo@> has joined #yocto12:01
Etheryoncool, so I've got the image folder inside my recipe looking like what I would need. But when I try to build an image I get this error now: package_write_rpm not found in ...12:07
EtheryonI've added the recipe to IMAGE_INSTALL12:07
Etheryonmaybe that's wrong12:07
RPqschulz: I emailed oe-arch with some details12:08
RPI'm sure there are 101 other issues I haven't thought of yet :(12:08
qschulzEtheryon: just a technicality, but you add a *package* to IMAGE_INSTALL and not a recipe (though the name of the main package is the name of the recipe)12:12
qschulzEtheryon: we'll need the whole build log posted in a pastebin somewhere (any website is fine)12:12
qschulzand the full content of the recipe too while we're at it12:13
agherzanWhile talking to a colleague of mine, I think what we have in https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#examples is confusing.12:15
agherzanThe example is:12:15
agherzanOVERRIDES = "foo"12:15
agherzanA = "Z"12:15
agherzanA:foo:append = "X"12:15
*** lucaceresoli <lucaceresoli!~ceresoli@host-79-2-93-196.business.telecomitalia.it> has quit IRC (Quit: Leaving)12:16
agherzanAnd I quote:12:16
agherzanFor this case, A is unconditionally set to “Z” and “X” is unconditionally and immediately appended to the variable A:foo. Because overrides have not been applied yet, A:foo is set to “X” due to the append and A simply equals “Z”.12:16
agherzanThe confusing part (or maybe even wrong) is `“X” is unconditionally and immediately appended to the variable A:foo.`.12:16
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 252 seconds)12:19
RPagherzan: that language isn't brilliant :/. The trouble is people think differently about how this works. I think several people keep changing this to fit how they prefer to think about it12:19
RPmichaelo: ^^^12:19
agherzanThe problem is with `immediately`. Which is not true, is it?12:20
agherzanUnless I'm reading this wrongly.12:20
RPwell, it isn't immediately done but effectively it is as it cannot be undo and would always happen12:21
agherzanOK I see the intentions here.12:21
agherzanThe problem is that it seems to contradict 2 lines above12:21
agherzanWhere it says12:21
agherzan`Recall that an append or prepend operation using “:append” and “:prepend” does not result in an immediate assignment as would “+=”, “.=”, “=+”, or “=.”. `12:21
agherzanWhere this becomes confusing.12:22
qschulzagherzan: I would remove immediately yes12:24
qschulzbut I think we should just rephrase the whole document12:24
agherzanI agree.12:24
agherzanAnd you had a good talk on that matter.12:24
qschulzI've said I'd look into this about a year ago already12:24
agherzanI really think we should prioritize this because it is a constant pain to newcomers.12:25
RPplease someone send patches!12:25
Etheryonqschulz: here is the full error, recipe is what I've posted earlier with the modifications we've talked about12:27
EtheryonERROR: Manifest /mydir/build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-app-resources.package_write_rpm not found in genericx86_64 core2-64 x86_64 allarch x86_64_x86_64-nativesdk (variant '')?12:27
EtheryonI'm guessing it's looking for a package_rpm step, that doesn't happen in the recipe? (because of bin_package?)12:28
qschulzEtheryon: what exactly is the command you're running to get this error?12:28
Etheryonbitbake my-image12:29
Etheryonimage contains  IMAGE_INSTALL += "app-resources"12:29
qschulzI'm surprised it mentions anything about nativesdk12:31
Etheryontask that fails is : my-image.bb:do_rootfs12:31
EtheryonTOOLCHAIN_HOST_TASK += "\12:31
Etheryon    nativesdk-cmake \12:31
Etheryon    nativesdk-meson \12:31
Etheryonthis is the only mention I have of nativesdk in my image12:32
Etheryontbh not sure what this does12:32
EtheryonIf I want that resources recipe to be depended on by another recipe it needs to be an RDEPENDS, right?12:35
qschulzEtheryon: runtime dependency yes, otherwise DEPENDS for build time dependencies (but I assume media files will probably be runtime dependencies, so yes, RDEPENDS)12:36
Etheryonany suggestions what should I start looking into for this package_rpm issue?12:37
*** Guest47 <Guest47!~Guest47@> has joined #yocto12:39
agherzanRP: qschulz I was talking to zyga_ about this the other day and I think that having this done through the eyes of a person new to the project would end up having the best outcome (obviously under and subject to later review). The advantage of this is that a newcomer might end up raising issues that we would miss as implicit. And Zyga is willing to push patches while untangling the syntax and operators in bitbake for his own learning process.12:39
agherzanWhat do you think?12:39
* zyga[m] waves12:39
EtheryonLemme know if I can help, I'm new too12:40
RPagherzan: it is something we used to do and yes, new eyes do tend to spot issues others would not. I'm open to it12:40
qschulzThe issue with that is that the moment he's untangled the syntax and operators, he's not a beginner anymore12:40
qschulzideally, we'd need someone who's never laid eyes on this review patches12:41
qschulzand tell us "this I don't understand first time I read"12:41
qschulzbut maybe I'm pushing it too far already :)12:41
zyga[m]I can share some of the feedback as a relative newcomer12:42
RPqschulz: whilst not perfect, it could be useful to look at that feedback12:42
zyga[m]for the various variable manipulation operators, the difference between += .= and :append is very confusing12:42
agherzanIt's a hard one because those people would not know if it is something that they missed or it is really lack of docs. And as I newcomer you would not be comfortable in clarifying this with an entire community. And yes, while they dig deeper, the quality of having new eyes will dim.12:43
zyga[m]semantics aside, the fact that += and :append do very different things is confusing12:43
agherzanzyga[m]: indeed. And I've given an example above.12:43
*** Guest47 <Guest47!~Guest47@> has quit IRC (Client Quit)12:43
zyga[m]syntax wise I would make += and :append identical and introduce a new keyword: say, "late" to make += behave as :append does now12:43
zyga[m]but apart from me being grumpy sometimes, I think I could help with the docs12:44
qschulzzyga[m]: can't have :late because you also have a :prepend one12:44
RPzyga[m]: There have been a few discussions about the append vs += issue. Sadly it is far from simple12:44
agherzan^ that is not a bad idea at all. My focus though at this point is to make the current state clear in docs. Or clearer. And improvements discussed either in parallel or afterwards.12:45
zyga[m]I'm sure I'm missing a lot, my point was to not overload what reads as a pretty standard operation (concatenation or appending) with extra hidden meaning that is unique to yocto/bitbake - to reduce the surprise factor12:45
qschulzagherzan: I would basically send a new page for review, the diff does not matters much for that12:45
agherzanBut the problem of += and append needs to be improved somehow.12:45
RPzyga[m]: I did start to try and simplify things with the override syntax change and dropping operators with append/prepend (so :append += "" isn't legal now)12:45
zyga[m]RP: I agree it's not simple at all, especially for a well established project12:46
zyga[m]I like that, that's a good step12:46
agherzanqschulz: Agreed. And that can be easily managed in something like GitHub where you can see the entire file.12:46
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 272 seconds)12:46
agherzanSo before doing the ml diff we can have an initial look at the entire document.12:46
qschulzagherzan: I just need to kick my own butt and get started12:46
zyga[m]qschulz: actually append is not bad, it's just that it's quite different from what appending to a list does in other languages that is confusing; in that sense prepend and append are prefectly fine, except for their "late" behavior that is surprising at first12:47
agherzanqschulz: work with zyga[m] on this. He had a lot of good questions while figuring this out.12:47
RPzyga[m]: I'm open to other ideas on syntax improvement but we have to do it in a way with some kind of migration/compatibility12:48
*** zpfvo <zpfvo!~fvo@> has joined #yocto12:48
zyga[m]RP: I agree and understand, while radical on clear design I'm also radical on backwards compatibility12:48
* RP is sad he never got back to trying to work out the next steps12:48
zyga[m]I realize that the feedback is not easy to make practical use of12:49
qschulzzyga[m]: as agherzan stated before, it's hard for us to have better doc because most of us contributing to the docs have some understanding and we forgot about our early struggles. And people starting on Yocto (or any project) usually don't give feedback on their struggles12:50
zyga[m]is there a non-late prepend operator similar to +=?12:50
qschulzzyga[m]: =+12:50
qschulzand -.12:50
zyga[m]so it's possible to have :append and :prepend retain their semantics12:51
qschulzzyga[m]: there is not duplicate behavior right now unfortunately12:51
zyga[m]while introducing something new like: late FOO += ... and late FOO =+ ... - where late would make this identical to :append and :prepend respectively12:51
zyga[m]and couple that with weak deprecation of :append and :prepend - this would leave just one set of operators with either immediate or late semantics12:52
zyga[m]again, my idea is just back-of-the-envelope draft12:52
zyga[m]I'm trying to find a way to reduce overal complexity12:53
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 272 seconds)12:54
Etheryonqschulz: PACKAGE_ARCH = "all" <- this seemed to be the issue - removed it from the resources recipe and everything works now. Thanks a lot for all the help!12:54
*** zpfvo <zpfvo!~fvo@> has joined #yocto12:55
qschulzEtheryon: inherit allarch is probably what you're after12:56
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 272 seconds)13:00
*** zpfvo <zpfvo!~fvo@> has joined #yocto13:00
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 252 seconds)13:04
*** zpfvo <zpfvo!~fvo@> has joined #yocto13:05
agherzanAnother topic - I have a first iteration for CI using GitHub actions for a Yocto BSP. https://github.com/agherzan/meta-raspberrypi/pull/100513:06
agherzanI'm going to test drive this for a while but I'm thinking to turn the most bits into GitHub actions that Yocto-base projects can reuse - for example build configuration through CI yml, yocto layer check, git log linter, DCO/SoB check and so on.13:06
agherzanHappy to hear feedback13:06
LetoThe2ndagherzan: sounds interesting, hopefully can poke it soon (very busy this week)13:07
agherzanI'm yet to do the git log linter - and I want to do it as a wrapper on top of gitlint. Make that an action and based on that create another one with the git log general guidelines for Yocto/OE projects LetoThe2nd13:09
agherzanThe current implementation does DCO check, reuse check (non fatal as the layer is not yet compliant) and matrix based builds.13:09
*** mvlad <mvlad!~mvlad@2a02:2f08:4b12:b100:24d7:51ff:fed6:906d> has joined #yocto13:09
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 250 seconds)13:09
agherzanOh - and yocto script layer check13:10
*** zpfvo <zpfvo!~fvo@> has joined #yocto13:10
*** Etheryon <Etheryon!~Etheryon@> has quit IRC (Quit: Client closed)13:17
*** Etheryon <Etheryon!~Etheryon@> has joined #yocto13:22
Etheryonany way I can avoid having packages-split and image duplicate my files?13:22
qschulzEtheryon: no, that's how Yocto works internally. What's the issue?13:23
*** smsm <smsm!~smsm@eth1-fw1-nbg6.eb.noris.de> has quit IRC (Quit: Client closed)13:24
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed)13:28
Etheryonfiles large - two copies larger13:31
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)13:32
RPagherzan: One the one hand that is all nice and good. On the other, it would be lovely if we could reuse some of our existing checks and get patchtest back to help with core. But nobody seems to want to care/help with that :(13:33
agherzanRP: what existing checks do you refer to? I've included `yocto-layer-check` for example.13:34
RPagherzan: https://git.yoctoproject.org/patchtest-oe/tree/13:35
smurrayRP: is your issue wrt stopping when a renamed variable is seen that it doesn't stop on the first parse error?  If BBHandledException is getting thrown I'm not sure I see how a build would proceed13:36
RPsmurray: where is that being thrown? I do have a local fix which may improve this, was just working on that13:38
agherzanRP: I see. Well - what can I say? I didn't know about that :) But I think that would definitely make more sense13:38
smurrayRP: if I switch to bb.fatal in my tree it does, I'd guessed your erroronce would do so as well13:38
RPsmurray: it doesn't, erroronce shouldn't be fatal as it would only show the first error13:40
RPsmurray: top patches of https://git.yoctoproject.org/poky-contrib/log/?h=rpurdie/t222 revise things a bit (fixes to erroronce, warnonce and others too)13:42
smurrayRP: hrm, if it's not going to halt things then I'd maybe say erroronce seems redundant?13:42
smurrayRP: in the grand scheme of things it almost seems like just going with a check in CookerParser.shutdown like I had to begin with seems easier than worrying about per-file and erroronce even if it's less optimal13:45
RPsmurray: you misunderstand how the errors/exceptions works :/13:45
smurrayRP: I'm willing to believe that, sure13:46
RPsmurray: see the tweaks to ast.py in my branch, I have that working now (show all the errors, stop the build)13:46
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto13:46
RPsmurray: next, to deal with XXX:foo:append where XXX is deprecated13:46
smurrayRP: that's not resolved bythe end of parsing?13:48
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 250 seconds)13:50
*** zpfvo <zpfvo!~fvo@> has joined #yocto13:51
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto13:54
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto13:56
RPsmurray: yes and no. I'd just prefer to tell people about any bad references13:57
smurrayRP: that'd maybe seems like it'd only be useful with option (c) that can get the file/line no, I'm guessing?14:01
RPsmurray: I'd have thought it would be generally useful14:02
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:bf13:d847:c69:16ff> has quit IRC (Remote host closed the connection)14:02
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:bf13:d847:c69:16ff> has joined #yocto14:02
JPEWRP: I had my head stuck in a problem yesterday; I don't know why I didn't offer to just build MinGW binutils to see if it's taking a long time locally. Doing that now :)14:03
RPJPEW: I was thinking I should really just profile a build of it and see what was taking the time.14:04
RPJPEW: my worry was that the change isn't to the parallelism of bintuils, its to the mingw runtime14:04
RPJPEW: so my bug report didn't make sense unless the runtime was taking a long time and I'm not sure it was that, it could have been qemu14:05
RPI then wondered if I knew what I was doing at all (I'm still wondering that)14:05
zeddiiRP: with AMD -> Xilinx yesterday, the day was kind of messed up. But I'm building the binutils -> ppc combo now. Assuming we still need to identify a fix.  I'll do that when I see it go boom (lots of rebuilding right now, it was on an out of date machine of mine).14:07
RPzeddii: I replied to the mails confirming there is the single patch we need14:08
zeddiioh. I must have missed that. I'll go check.14:08
RPzeddii: that fixed the builds at least for my local tests14:08
RPzeddii: I figured you were busy so I just queued stuff14:09
zeddiiahah. I see that now. I didn't even notice it when it came in. I'll send a SRCREV bump in just a few minutes then.14:09
*** Etheryon <Etheryon!~Etheryon@> has quit IRC (Quit: Client closed)14:09
JPEWRP: Ok, I'm doing a build with buildstats. I'll report back what I see14:11
RPJPEW: thanks. I think it may just be a combination of old sstate and loaded autobuilder14:14
RPsmurray: I was curious why in your version you didn't put the calls at the end of finalize() ?14:14
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 252 seconds)14:15
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto14:16
*** davidinux <davidinux!~davidinux@> has joined #yocto14:17
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Ping timeout: 256 seconds)14:17
smurrayRP: when I went and looked at expandKeys it wasn't clear to me if it'd make a difference, and then it was working in my tests so I didn't investigate further14:17
*** Etheryon <Etheryon!~Etheryon@> has joined #yocto14:19
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto14:22
RPsmurray: it could if someone does A = "HASHBASE" then BB_${A}_WHITELIST = "B" :)14:23
RPIf someone did that I would suggest medical attention mind :)14:23
smurrayRP: heh, indeed.  I figured expandKeys was related to that, but wasn't sure if it'd be a real issue or not14:26
RPsmurray: my bigger worry was one of the event handlers setting new things14:27
smurrayRP: to some degree if someone is jumping through hoops like that in an external layer for the variables involved I'm not entirely sympathetic14:33
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto14:35
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 252 seconds)14:39
*** zpfvo <zpfvo!~fvo@> has joined #yocto14:39
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)14:50
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 250 seconds)14:50
*** zpfvo <zpfvo!~fvo@> has joined #yocto14:50
EtheryonHey, I'm back, any easy way of solving "rootfs size is greather than or equal to 4GB" ?14:56
Etheryonnot sure where hddimg comes from14:57
EtheryonI have IMAGE_FSTYPES = " live"14:58
EtheryonI guess from here: DEPLOYABLE_IMAGE_TYPES="hddimg iso"15:04
Etheryonhmm or here? IMAGE_TYPES_MASKED=" live hddimg iso"15:06
RPsmurray: this is the challenge with core API though, it will end up used for things you never considered :/15:07
*** marc2 <marc2!~marc@ipagstaticip-ad9375f2-382c-b511-8ac1-9541f69fe50f.sdsl.bell.ca> has quit IRC (Ping timeout: 250 seconds)15:08
*** marc2 <marc2!~marc@ipagstaticip-ad9375f2-382c-b511-8ac1-9541f69fe50f.sdsl.bell.ca> has joined #yocto15:10
smurrayRP: I think I'm in the "perfect is the enemy of good" camp on this at least wrt getting over this immediate hump with the inclusive language changes finally done15:10
* RP is being called away to small crisis outside work :(15:13
dacavHi.  Is there a way to invalidate the cache of an image recipe without rebuilding the whole universe?15:13
RPStatus report will be delayed, will do my best to make the weekly call15:14
smurrayRP: okay, good luck with whatever is going on15:17
qschulzdacav: what is your issue right now? what are you trying to do that would require invalidating the image sstate-cache?15:20
dacavI'd like to update a busybox configuration, to obtain another utility.  After I changed it, I should be able to rebuild the image with `bitbake myimage`, right? Nope.  The image is not rebuilt.15:22
zyga[m]RP: just thinking about append vs += and other operators, why :append and not .append? Why not treat it more like a typed python object that just renders to a string?15:22
dacavAt this point I spent so much time trying to make sense of this mess of system roots, that I just nuked the whole thing from orbit, got rid of 50 gigabytes and more of builds, and I'll let my computer spin for a few hours.15:23
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 272 seconds)15:24
qschulzdacav: won't work15:25
*** zpfvo <zpfvo!~fvo@> has joined #yocto15:25
qschulzif a bitbake myimage does not trigger a rebuild of your busybox recipe, a clean rebuild won't either15:25
dacavI nuked via `git clean -fxd`. It *will* work :)15:25
dacavYet I'd be curious to know what is the proper way of doing what I'd like, that is, updating a dependency and have the whole change propagated properly15:26
qschulzdacav: it is, so you are doing something wrong15:29
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 250 seconds)15:29
qschulzI would expect a change to busybox config to trigger A LOT of dependency rebuilds15:30
*** zpfvo <zpfvo!~fvo@> has joined #yocto15:30
dacavof course I am.  With that being said, having a system that is not a jungle might help, and I'm working in a quite broken situation to begin with.15:30
dacavStarting clean won't be bad.15:30
dacavMoreover, it works for a colleague, so it is definitely true that something is wrong for me15:31
dacavWhen you've gigabytes of files around, go figure *where* the problem is15:31
qschulzdacav: might be something wrong in your expectations. Didn't mean to be rude sorry15:31
qschulzso.. what did you do? What is happening? What did you expect to happen?15:31
qschulzand "wrong" is a strong word too, not good at picking the right words today :/15:32
dacavNot your fault man.  Actually, you're always very helpful.15:32
dacavStrong or not, it is correct.  There must be something wrong.  Or rather, there was :D15:33
dacavnuke -> there's nothing wrong.15:33
qschulzdacav: if nuking works, something's wrong :D15:35
smurraydacav: usually I'd expect the approach to be to add a .cfg fragment turn on a busybox option to SRC_URI in a bbappend in my own layer, and I would expect that to trigger a rebuild unless there's a typo15:35
dacavqschulz: Interestingly it is also true that if something's wrong, nuking works!15:36
dacav- typically -15:36
smurraydacav: looking at the output of "bitbake -e busybox" to see what the state of SRC_URI (or other variables) is can be useful to help debug15:36
dacavsmurray: in this case the .cfg fragment existed already15:36
smurraydacav: if it's in SRC_URI and you changed its contents in your layer, I'd expect that to be seen and trigger a rebuild15:38
dacavI'll check out later.  Now I'm in the middle of a full rebuild (see above, I nuked the whole thing and started over, out of dispair)15:40
qschulzdacav: usually you can just keep the sstate-cache and downloads directory and ditch the rest15:41
qschulzit's not really a clean build but at least you don't lose hours rebuilding stuff from scratch15:41
dacavActually, I've explicitly nuked also sstate.  In my case I might have the additional burden of two teams working on the same yocto repository, with different ways of working and generating configurations.15:45
dacavI wouldn't be surprised if the oracle told me there was a funny overlapping frustrating my attempts.  I don't know what sstate-cache is caching.15:46
dacavI'll leave it compiling and do something else.  Thanks for your hints and for your time :)15:47
*** tnovotny <tnovotny!~tnovotny@ip-78-45-97-113.net.upcbroadband.cz> has quit IRC (Quit: Leaving)15:59
*** falk0n[m] <falk0n[m]!~falk0nmat@2001:470:69fc:105::ce60> has quit IRC (Quit: You have been kicked for being idle)16:00
*** Etheryon <Etheryon!~Etheryon@> has quit IRC (Quit: Client closed)16:05
*** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto16:06
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed)16:08
*** dsueiro <dsueiro!~dsueiro@> has joined #yocto16:08
*** goliath <goliath!~goliath@user/goliath> has joined #yocto16:10
dsueiroI have a couple of image recipes that depend on specific DISTRO_FEATURES values. I'm making usage of the features_check bbclass and setting REQUIRED_DISTRO_FEATURES and CONFLICT_DISTRO_FEATURES. And it all works as expected. My problem is that whatever I change the DISTRO_FEATURES values, the incompatible image built previously with the expected16:10
dsueiroDISTRO_FEATURES, gets removed from the DEPLOY_DIR_IMAGE. I'm just wondering if there is a way to change this behaviour and prevent bitbake to remove images (skipped via bb.parse.SkipRecipe) from  DEPLOY_DIR_IMAGE.16:10
*** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto16:13
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto16:22
*** camus1 <camus1!~Instantbi@> has joined #yocto16:43
*** camus <camus!~Instantbi@> has quit IRC (Remote host closed the connection)16:44
*** camus1 is now known as camus16:44
*** zpfvo <zpfvo!~fvo@> has quit IRC (Quit: Leaving.)16:54
RPzyga[m]: ":" seemed like the least ambiguous choice for the character, "." didn't look/feel right. ":" also had the advantage that the parser never accepted it previously16:59
zyga[m]I see, that's indeed relevant17:01
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)17:07
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto17:09
*** chep <chep!~chep@82-65-36-115.subs.proxad.net> has quit IRC (Read error: Connection reset by peer)17:15
*** chep <chep!~chep@82-65-36-115.subs.proxad.net> has joined #yocto17:16
*** chep <chep!~chep@82-65-36-115.subs.proxad.net> has quit IRC (Read error: Connection reset by peer)17:22
*** chep <chep!~chep@82-65-36-115.subs.proxad.net> has joined #yocto17:22
*** chep` <chep`!~chep@82-65-36-115.subs.proxad.net> has joined #yocto17:25
*** chep <chep!~chep@82-65-36-115.subs.proxad.net> has quit IRC (Read error: Connection reset by peer)17:27
*** chep` is now known as chep17:27
*** mckoan is now known as mckoan|away17:29
*** huseyinkozan <huseyinkozan!~hk@> has joined #yocto17:33
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC (Remote host closed the connection)17:34
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto17:35
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 240 seconds)17:43
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat)17:46
JPEWRP: nativesdk-mingw-w64-runtime took 251 seconds on my machine with PARALLEL_MAKE="", which doens't seem terribly unreasonable?17:55
*** Etheryon <Etheryon!~Etheryon@> has joined #yocto18:00
RPJPEW: that seems ok18:03
RPJPEW: I wonder if it was just the new binutils causing qemu to rebuild which took ages?18:03
JPEWqemu can be really slow18:03
JPEWanecdotally at least18:04
*** ex-bugsbunny <ex-bugsbunny!~Harry@p2e5302a8.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 240 seconds)18:06
*** Guest20 <Guest20!~Guest20@modemcable211.232-19-135.mc.videotron.ca> has joined #yocto18:16
Guest20Hi, in my pytorch-native.bb recipe, I install the bin mkalias. It appear in build/tmp/work/x86_64-linux/pytorch-native/1.9.1-r0/recipe-sysroot-native/usr/bin/mkrename  But this bin doest not appears in sysroot-native of pytorch.bb. Am I doing something wrong?18:23
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:bf13:d847:c69:16ff> has quit IRC (Quit: Leaving)18:23
*** Guest20 is now known as miki2618:31
*** Etheryon <Etheryon!~Etheryon@> has quit IRC (Quit: Client closed)18:31
*** miki26 <miki26!~Guest20@modemcable211.232-19-135.mc.videotron.ca> has quit IRC (Quit: Connection closed)18:36
*** Guest20 <Guest20!~Guest20@modemcable211.232-19-135.mc.videotron.ca> has joined #yocto18:37
*** miki26 <miki26!~miki26@modemcable211.232-19-135.mc.videotron.ca> has joined #yocto18:49
*** florian_kc <florian_kc!~florian@dynamic-002-244-025-193.2.244.pool.telefonica.de> has joined #yocto18:53
*** camus <camus!~Instantbi@> has quit IRC (Remote host closed the connection)19:09
*** camus <camus!~Instantbi@> has joined #yocto19:09
*** florian_kc <florian_kc!~florian@dynamic-002-244-025-193.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds)19:17
sgwsmurray: RP: I have some additional time to work on the bitbake changes, I will look at RP's email again, let me know where I can help more19:29
smurraysgw: if you are in a position to pick up moving the renamed variable detection along, please do so.19:30
smurraysgw: and if it helps, once that's in a place deemed workable, I've addressed a lot of the variable renames in BitBake, feel free to take from here and do what you will: https://github.com/g-scott-murray/bitbake/tree/smurray/inclusive-fixes19:31
smurraysgw: I didn't entirely grasp where JPEW and RP went with the hybrid checking discussion, but if it gets stalled somehow, please let me know and I can attempt to figure it out, I guess19:33
sgwsmurray: I will take a look at your code also then and see what I can do there, your not alone on some of the discussion.19:33
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 240 seconds)19:34
*** camus <camus!~Instantbi@> has joined #yocto19:35
smurraysgw: for the variable renaming, if you want to test the better option would be RP's improved version he mentioned in his email to oe-arch, rather than my WIP that's the HEAD of that branch19:35
smurraysgw: renamed variable checking, I mean19:35
sgwI am going to look at both so that I can try and understand the ramifications of each.19:39
*** ex-bugsbunny <ex-bugsbunny!~Harry@p2e5302a8.dip0.t-ipconnect.de> has joined #yocto19:47
*** ex-bugsbunny <ex-bugsbunny!~Harry@p2e5302a8.dip0.t-ipconnect.de> has left #yocto19:47
smurraysgw: just note that RP rewrote my WIP, the link into poky-contrib for option (b) in his mail is that19:50
*** s4d <s4d!~s4d@user/s4d> has joined #yocto19:56
*** GillesM <GillesM!~gilles@> has quit IRC (Remote host closed the connection)20:06
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 240 seconds)20:12
*** florian <florian!~florian@dynamic-002-244-025-193.2.244.pool.telefonica.de> has joined #yocto20:20
*** camus <camus!~Instantbi@> has quit IRC (Remote host closed the connection)21:26
*** camus <camus!~Instantbi@> has joined #yocto21:26
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 272 seconds)21:34
*** alimon <alimon!~alimon@2806:10b7:3:4418:2c32:cfff:fe8e:de1f> has quit IRC (Ping timeout: 252 seconds)21:40
*** alimon <alimon!~alimon@> has joined #yocto21:40
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Quit: Leaving)22:00
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC (Ping timeout: 240 seconds)22:13
*** kevinrowland <kevinrowland!~kevinrowl@> has joined #yocto22:14
RPsgw, smurray: Sorry, I'm having a bad day. I'm wondering if people on the call noticed the point I found a scafolding truck blocking the narrow backlane I was driving down to get home. Trying to talk coherently whilst reversing a 4x4 around narrow backlanes whilst coherently talking about bitbake internals was a different experience :)22:20
smurrayRP: ouch22:21
RPWe mentioned the TSC, they've suggested I email the members about the issues so I need to write that email22:21
sgwRP: Well done on multitasking then!22:22
sgwHope all is OK otherwise22:22
RPthe scafolding truck is from all the roofing work being done after storm Arwen. D<something> and Eunice are due tomorrow and Friday22:23
RPsgw: complicated but dealing with the things life sends our way as best we can ;-)22:23
sgwI figured it was related to someone's roof.  Hope you guys are all button'ed up and these new storms dont cause issues.22:23
RPsgw: only 90mph winds forecast this time22:24
RPthe streets are lined with broken slate :/22:24
sgwouch, stay safe.22:28
RPsgw: Storm C<something> did pull some of the rainwater piping off the back of the house, it is proving a fun winter!22:29
sgwRP I am starting to look / understand your changes, but I am still not clear on the overall direction, and did not really follow the discussion you and joshua had.22:29
RPsgw: you can see in my branch I shared there are two different approaches? One is ast.py based and the other is in data_smart.py?22:30
sgwYes, I have a call to take, back in 30 or so.22:30
* RP gives in and powers up his servers to try and work on this a bit more22:30
sgwRP: I know its getting late there, I should be on early in the morning.22:31
RPsgw: I'll poke at things a bit more, see if I can get more coherent patches22:32
* RP notes that according to the libtool list, we do cross compiling all wrong :/22:34
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto22:35
smurrayRP: hrm, I'm not sure I'd be willing to believe that, libtool has been it's own special form of hell whenever I've needed to try to debug an issue22:38
*** mvlad <mvlad!~mvlad@2a02:2f08:4b12:b100:24d7:51ff:fed6:906d> has quit IRC (Quit: Leaving)22:38
RPsmurray: I don't believe it either but they're saying our patches which I cleaned up and submitted are wrong and that we're using libtool incorrectly22:40
RPandroid gets it right of course22:40
* RP will just ignore that for now22:41
RPI mean what do we know about cross compilers22:41
*** huseyinkozan <huseyinkozan!~hk@> has quit IRC (Quit: Konversation terminated!)22:46
*** frieder <frieder!~frieder@mue-88-130-78-041.dsl.tropolys.de> has quit IRC (Remote host closed the connection)22:50
*** s4d <s4d!~s4d@user/s4d> has quit IRC (Quit: s4d)22:58
*** smrtz <smrtz!~smrtz@216-197-64-240.tingfiber.com> has joined #yocto23:01
*** smrtz <smrtz!~smrtz@216-197-64-240.tingfiber.com> has quit IRC (Client Quit)23:01
*** ar__ <ar__!~akiCA@user/akica> has quit IRC (Ping timeout: 252 seconds)23:02
*** marc2 <marc2!~marc@ipagstaticip-ad9375f2-382c-b511-8ac1-9541f69fe50f.sdsl.bell.ca> has quit IRC (Ping timeout: 252 seconds)23:06
*** marc2 <marc2!~marc@ipagstaticip-ad9375f2-382c-b511-8ac1-9541f69fe50f.sdsl.bell.ca> has joined #yocto23:08
RPJPEW: I was just looking at implementing what we talked about earlier. There is a big downside in that it would duplicate messages since one would have file/line numbers and the second pass would not23:11
RPJPEW: I think that rules it out as it would confuse people23:11
JPEWRP: that wasn't my understanding... First pass only checks the base config in a post parsing (e.g ast finalize?). It had line numbers because we include variable tracking. Second pass is after that and hooks getvar, so it has the line numbers?23:17
*** florian <florian!~florian@dynamic-002-244-025-193.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds)23:19
RPJPEW: hmm, right.23:20
RPI'm confusing myself. I do now have the early environment checks at least...23:20
*** davidinux <davidinux!~davidinux@> has quit IRC (*.net *.split)23:21
*** madisox <madisox!sid453692@2a03:5180:f:3::6:ec3c> has quit IRC (*.net *.split)23:21
*** mrnuke <mrnuke!~mrnuke@c-98-195-139-126.hsd1.tx.comcast.net> has quit IRC (*.net *.split)23:21
*** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (*.net *.split)23:21
*** Habbie <Habbie!peter@lorentz.7bits.nl> has quit IRC (*.net *.split)23:21
*** zibri <zibri!zibri@shell.x20.se> has quit IRC (*.net *.split)23:21
*** woky <woky!~woky@li1651-31.members.linode.com> has quit IRC (*.net *.split)23:21
*** marex <marex!~marex@> has quit IRC (*.net *.split)23:21
*** Ch^W_ <Ch^W_!~mouser@> has quit IRC (*.net *.split)23:21
*** ak77_ <ak77_!~ak77@93-103-81-73.static.t-2.net> has quit IRC (*.net *.split)23:21
*** Fanfwe <Fanfwe!~fanfwe@im.goudal.net> has quit IRC (*.net *.split)23:21
*** davidinux <davidinux!~davidinux@> has joined #yocto23:23
*** madisox <madisox!sid453692@2a03:5180:f:3::6:ec3c> has joined #yocto23:23
*** mrnuke <mrnuke!~mrnuke@c-98-195-139-126.hsd1.tx.comcast.net> has joined #yocto23:23
*** shoragan <shoragan!~shoragan@user/shoragan> has joined #yocto23:23
*** Habbie <Habbie!peter@lorentz.7bits.nl> has joined #yocto23:23
*** zibri <zibri!zibri@shell.x20.se> has joined #yocto23:23
*** woky <woky!~woky@li1651-31.members.linode.com> has joined #yocto23:23
*** marex <marex!~marex@> has joined #yocto23:23
*** Ch^W_ <Ch^W_!~mouser@> has joined #yocto23:23
*** ak77_ <ak77_!~ak77@93-103-81-73.static.t-2.net> has joined #yocto23:23
*** Fanfwe <Fanfwe!~fanfwe@im.goudal.net> has joined #yocto23:23
khemzeddii:      linux-yocto is trying to use CONFIG_MAXPHYSMEM_128GB kconfig option perhaps this should be removed ? such option seems to not exist in latest kernel23:26
RPJPEW: it seems the base datastore isn't using history tracking. I could have sworn it did :(23:29
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)23:30
JPEWRP: too good to be true I guess :(23:31
JPEWCan we add tracking of just the line number? I thought history tracked a bunch of other stuff. Not sure what the expensive part is23:32
*** Guest20 <Guest20!~Guest20@modemcable211.232-19-135.mc.videotron.ca> has quit IRC (Ping timeout: 240 seconds)23:33
*** miki26 <miki26!~miki26@modemcable211.232-19-135.mc.videotron.ca> has quit IRC (Ping timeout: 256 seconds)23:33
RPJPEW: I think the behaviour is UI dependent so I may be able to force this23:35
JPEWOr maybe only track history for the free variables that are being renamed? If it's an error to not rename them, does parsing have to be optimally fast?23:38
JPEW*few variables being renamed23:38
RPJPEW: we can't know which ones have a problem with renaming until it is too late23:43
RPJPEW: I think I nearly have it working but now it looks like my erroronce implementation doesn't work23:43
JPEWOk. I'm AFK for the rest of the day, but I'll try to take a look at that tomorrow23:44
RPJPEW: I'll try and put together some kind of example of where it is at23:46
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto23:50
RPsgw, smurray: Ignore the commit log message but have a look at https://git.yoctoproject.org/poky-contrib/commit/?h=rpurdie/t222&id=da1e7adc05e58dd24e9c55abbe7b2570284358f723:52
RPThat does seem to do roughly the right things locally, except for duplicating error messages (which it shouldn't)23:53
RPsgw, smurray: you may have to comment the environment bb.fatal to get anything to parse23:53
*** florian <florian!~florian@dynamic-002-244-025-193.2.244.pool.telefonica.de> has joined #yocto23:54
RPsmurray, sgw: the best use of your time might be to get the renaming patches in place for the bitbake variables and check the errors are showing up before conversion23:54
RPI guess I'll worry about the duplicate errors tomorrow23:54
*** kevinrowland <kevinrowland!~kevinrowl@> has quit IRC (Quit: Client closed)23:57

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