Wednesday, 2022-04-06

*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving)00:08
*** TundraMan <TundraMan!~masselst@198-84-181-245.cpe.teksavvy.com> has joined #oe00:15
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.)00:21
*** TundraMan <TundraMan!~masselst@198-84-181-245.cpe.teksavvy.com> has quit IRC (Ping timeout: 246 seconds)00:37
*** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has quit IRC (Ping timeout: 248 seconds)00:50
*** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has joined #oe01:05
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #oe01:07
*** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has quit IRC (Ping timeout: 248 seconds)01:20
*** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has joined #oe01:27
*** mru <mru!~troll@hotblack.mansr.com> has quit IRC (Ping timeout: 245 seconds)01:41
*** mru <mru!~troll@hotblack.mansr.com> has joined #oe01:48
*** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has quit IRC (Ping timeout: 260 seconds)01:51
*** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has joined #oe02:09
*** TundraMan <TundraMan!~masselst@198-84-181-245.cpe.teksavvy.com> has joined #oe02:11
*** darkapex <darkapex!~darkapex@user/darkapex> has joined #oe02:48
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.)03:12
*** TundraMan <TundraMan!~masselst@198-84-181-245.cpe.teksavvy.com> has quit IRC (Ping timeout: 268 seconds)03:21
*** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has quit IRC (Ping timeout: 268 seconds)03:25
*** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has joined #oe03:36
*** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has quit IRC (Ping timeout: 240 seconds)04:31
*** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has joined #oe04:48
*** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has joined #oe05:34
*** rob_w <rob_w!~rob@2001:a61:60c9:601:2dae:3828:a9e3:5e84> has joined #oe06:01
*** darkapex <darkapex!~darkapex@user/darkapex> has quit IRC (Ping timeout: 246 seconds)06:06
*** darkapex <darkapex!~darkapex@user/darkapex> has joined #oe06:09
*** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has joined #oe06:40
*** mckoan|away is now known as mckoan06:47
mckoangood morning06:47
*** frieder <frieder!~frieder@i59F72634.versanet.de> has joined #oe07:07
*** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has joined #oe07:37
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #oe07:41
*** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC (Quit: leaving)07:59
*** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #oe07:59
*** mort7 <mort7!~mort@188.166.114.29> has joined #oe08:23
*** mort <mort!~mort@188.166.114.29> has quit IRC (Ping timeout: 245 seconds)08:25
*** mort7 is now known as mort08:25
*** dos1 <dos1!~dos@dosowisko.net> has joined #oe08:27
*** dos <dos!~dos@dosowisko.net> has quit IRC (Remote host closed the connection)08:27
*** mvlad_ <mvlad_!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has joined #oe08:28
*** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)08:28
*** dos1 is now known as dos08:29
*** dl9pf[m] <dl9pf[m]!~dl9pfmatr@2001:470:69fc:105::9a8> has quit IRC (Quit: You have been kicked for being idle)09:00
*** extor <extor!~xtor@192.99.217.240> has quit IRC (Ping timeout: 248 seconds)09:02
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #oe09:10
*** Emantor_ <Emantor_!~Emantor@magratgarlick.emantor.de> has quit IRC (Quit: ZNC - http://znc.in)09:14
*** Emantor <Emantor!~Emantor@magratgarlick.emantor.de> has joined #oe09:15
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #oe09:17
*** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has quit IRC (Ping timeout: 246 seconds)10:56
*** LocutusOfBorg <LocutusOfBorg!~locutusof@93-50-192-18.ip153.fastwebnet.it> has quit IRC (Quit: ZNC 1.8.2+deb1 - https://znc.in)10:58
*** LocutusOfBorg <LocutusOfBorg!~locutusof@93-50-192-18.ip153.fastwebnet.it> has joined #oe11:01
*** maelcum <maelcum!~horst@2001:9e8:255:ae00:e188:2707:7886:144b> has joined #oe11:02
*** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has joined #oe11:11
*** Tyaku <Tyaku!~Tyaku@lfbn-orl-1-19-210.w92-152.abo.wanadoo.fr> has joined #oe11:31
*** ar__ <ar__!~akiCA@user/akica> has joined #oe13:19
*** codavi <codavi!~akiCA@user/akica> has joined #oe13:21
*** ar__ <ar__!~akiCA@user/akica> has quit IRC (Ping timeout: 268 seconds)13:24
*** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has quit IRC (Quit: Leaving)13:26
mortbitbake's dependency tracking seems to be a bit wonky?13:44
*** dl9pf[m] <dl9pf[m]!~dl9pfmatr@2001:470:69fc:105::9a8> has joined #oe13:45
mortI have a package A which provides a static library, and I have a package B which uses the static library in A; when I change A's do_compile() to make it build the library with different flags, I expected B to get recompiled, but it doesn't seem to13:45
rburtondoes B depend on A?13:53
mortyes13:53
rburtondid you bitbake B?13:53
mortyes13:53
rburtonif you can reproduce that on demand then that's interesting, and see if you can minimise the test case13:54
rburtonits possible that it can't see the changes you're making to the compile for some reason (some variable usage doesn't get watched automatically)13:54
morthmm that would be weird though, since it's a change in the commands run in do_compile() for A13:55
mortand A gets recompiled when I bitbake B13:55
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #oe13:57
mortdoes bitbake try to be clever and notice that B links against A and thus needs to recompile? If so, maybe bitbake doesn't handle static libraries that well?14:00
mortit would never see that relationship by analyzing any generated elf file after all14:00
bencohso it's not an explicit dep?14:02
mortI don't know what you mean14:03
mortA is listed in B's DEPENDS variable if that's what you're asking14:04
bencohyeah ... weird then14:04
*** davidlt <davidlt!~davidlt@78-63-27-146.static.zebra.lt> has joined #oe14:06
mortI can reproduce it easily it turns out with dummy recipes14:07
morthttps://p.mort.coffee/zWq14:08
mortif I run `bitbake test-b`, then first test-a:do_compile runs for 10 seconds, then test-b:do_compile runs for 10 seconds14:09
mortif I then change test-a to sleep for 5 seconds instead, then run `bitbake test-b`, then test-a:do_compile runs for 5 seconds, then nothing more happens14:09
mortso dependency tracking is definitely broken14:09
bencohmeaning that it knows it has to rebuild A though14:10
mortyeah, but doesn't know that means it has to rebuild B14:10
bencohwhich is odd14:10
mortmy guess is that it analyzes generated elf files to find dependencies and if analyzing B's generated elfs doesn't show that it depends on A, bitbake assumes B doesn't have to be regenerated14:11
mortbut that's the wrong model14:11
rburtonoh, a recent release?14:24
rburtonits looking at the binary output and seeing they're identical14:24
rburtonchange test-a to write a number to the sysroot instead14:24
rburtonoutput hasn't changed -> no need to rebuild stuff14:25
rburtonreally nice when you touch something like glibc but the change doesn't impact the target build, and it doesn't feel the need to rebuild the world14:25
Saur[m]mort: bitbake only uses its metadata (i.e., what's in the recipes) to determine what needs to be rebuild. However, if you have the hash equivalence support enabled, it will compare the output of a given task with the output from previous runs of the same task, and if they are identical, then it will consider the tasks equivalent. I.e., if you run task A and it produces some output, and then change task A and rerun it and it still produces the same14:27
Saur[m]output, then bitbake will use the sstate for subsequent tasks.14:27
mortok, test-a now writes 1 to lol in do_compile and installs lol to ${D}/lol in do_install, and has FILES_${PN} = "/lol". I run `bitbake -c cleansstate test-a test-b` to make sure everything's fresh. I run `bitbake test-b`, both test-a and test-b's do_compile runs ofc14:33
mortI change test-a's do_compile to write 2 instead, then `bitbake test-b`, test-a:do_compile and test-a:do_install runs, but test-b:do_compile doesn't run.14:33
morteven though now test-a has changed the content of the file it installs14:33
morthttps://p.mort.coffee/sfy14:35
mortchanging that number in the `echo 2 > lol` and running `bitbake test-b` causes test-a:do_compile and test-a:do_install to re-run, but doesn't do anything with test-b14:35
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Remote host closed the connection)14:48
*** Tyaku <Tyaku!~Tyaku@lfbn-orl-1-19-210.w92-152.abo.wanadoo.fr> has quit IRC (Quit: Lost terminal)15:01
*** mckoan is now known as mckoan|away15:04
kergothmort: that file isn't installed to the sysroot, so the other recipe won't be affected by it15:12
kergothmort: not everything installed to ${D} is available to other recipes that depend on you15:12
kergothonly a specific list of paths, or those you add to that list15:12
kergothi.e. includedir15:12
mortkergoth: but the problem isn't that stuff isn't available to other recipes15:16
mortB links against the library installed by A, and that works perfectly fine15:16
mortI suppose it affects the test case I made15:16
mortit shouldn't affect the real example though15:17
kergothyes, it does. you'r emodifying an unused file, which won't affect checksums :)15:17
kergothtrue15:17
kergothi'd suggest a different test case. install it to ${D}${includedir} at least15:17
mortcould just treat yocto as buildroot and do a clean rebuild every time I do anything15:17
morthave a 2 hour development cycle15:17
mortthere's quite a few of these painful rebuild gotchas in yocto15:18
mortI'd much prefer if it was too eager than the current situation where it's too lax15:18
mortit shouldn't be that hard, if any of recipe R's dependencies have changed, rebuild recipe R15:19
mortanyways, I'll try to make a more realistic small test case tomorrow, my yocto setup is currently busy doing a clean rebuild15:19
kergothit is generally too eager, i don't htink i've ever heard anyone report it being too lax on rebuilds15:20
mortBy the way, what's FILES_${PN} supposed to be used for, runtime files or both runtime and built-time files? (And which manual is this mentioned in? I didn't find anything in the bitbake user manual)15:29
kergothThat controls runtime packaging. What files go into the package named ${PN}15:34
kergothassuming ${PN} is in the PACKAGES variable, which lists the packages to be created, of course15:35
kergothwhich is the default15:35
mortRight, makes sense15:41
kergothThe FILES variable is an oe-ism, not bitbake15:42
mortWell, build-time stuff would be part of the -dev package, so I suppose headers and static libs should be included in FILES15:42
kergoththere are packaging variables which affect bitbake, but only the dependency ones, as those affect what tasks ar erun15:42
kergoththe rest is oe/yocto, not bitbake15:42
kergoththey're in FILES_${PN}-dev, yeah15:42
mortaha15:43
kergothhttps://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#runtime-dependencies15:43
mortit can be hard to know whether to look to bitbake, openembedded or poky15:43
kergothhttps://docs.yoctoproject.org/overview-manual/concepts.html#package-splitting15:44
kergothhttps://docs.yoctoproject.org/ref-manual/variables.html#term-FILES15:44
kergothpoky is just a packaging of bitbake and oe-core along with meta-yocto and the poky reference distribution15:44
kergothit's still bitbake and oe15:44
rburtonfwiw, the debian packaging guidelines are well written and basically cover the same packaging basics15:44
kergothgood point15:45
kergothiirc we referenced that when we got started15:45
kergothhttps://docs.yoctoproject.org/ref-manual/classes.html#package-bbclass15:45
rburtonyeah, there's a lot of debianisms in the guts15:45
*** dl9pf[m] <dl9pf[m]!~dl9pfmatr@2001:470:69fc:105::9a8> has quit IRC (Quit: You have been kicked for being idle)16:00
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.)16:05
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #oe16:09
mortkergoth: https://p.mort.coffee/neO -- this should be correct, right? 'lol' is installed to /usr/bin, which should be part of list of paths installed to B's sysroot16:13
*** dl9pf[m] <dl9pf[m]!~dl9pfmatr@2001:470:69fc:105::9a8> has joined #oe16:13
mortyet it has the same behavior, changing the number in test-a:do_compile causes test-a to be recompiled, but does nothing with test-b16:13
mortwell no, /usr/bin wouldn't make sense, /usr/lib would16:15
mortand indeed, when using /usr/lib it does work as expected16:16
kergothyeah, usr/bin won't be populated unless it's a native recipe16:18
kergothas then we'd be able to run such binaries16:18
kergothfgor a target one, wouldnt' make sense16:18
mortyeah16:18
morthypothesis: when a dependency changes, it runs do_compile but without deleting and re-unpacking, so make gets run but my makefile isn't clever enough to know that the library changes16:22
rburtonyeah it won't re-unpack if it just needs to recompile16:37
rburtonthis is why out-of-tree builds are Good, so configure can wipe the build tree away16:37
rburtonif your makefile has a clean target, it will delete things16:37
rburtonerm, if your makefile has a clean target, it will run it16:37
rburtonbut use a proper build system instead16:38
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat)16:58
*** frieder <frieder!~frieder@i59F72634.versanet.de> has quit IRC (Remote host closed the connection)17:07
*** TundraMan <TundraMan!~masselst@198-84-181-245.cpe.teksavvy.com> has joined #oe17:13
*** mvlad_ <mvlad_!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)18:56
*** davidlt <davidlt!~davidlt@78-63-27-146.static.zebra.lt> has quit IRC (Ping timeout: 260 seconds)19:40
*** TundraMan <TundraMan!~masselst@198-84-181-245.cpe.teksavvy.com> has quit IRC (Quit: Konversation terminated!)20:08
*** mrnuke <mrnuke!~mrnuke@2601:2c1:8501:182d::c66> has quit IRC (Ping timeout: 260 seconds)20:17
*** mrnuke <mrnuke!~mrnuke@c-98-195-139-126.hsd1.tx.comcast.net> has joined #oe20:24
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Remote host closed the connection)20:33
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.)21:07
*** rob_w <rob_w!~rob@2001:a61:60c9:601:2dae:3828:a9e3:5e84> has quit IRC (Quit: Leaving)21:10
mortI would love to use a proper build system but all of them suck21:47
*** camus1 <camus1!~Instantbi@2409:8a1e:911c:7f00:704b:4b0d:8dc4:7c21> has joined #oe21:57
*** camus <camus!~Instantbi@2409:8a1e:9115:e190:704b:4b0d:8dc4:7c21> has quit IRC (Ping timeout: 268 seconds)22:00
*** camus1 is now known as camus22:00
*** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 246 seconds)22:04
*** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has quit IRC (Quit: Konversation terminated!)22:49
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #oe22:54
*** bonalais <bonalais!uid502939@id-502939.tinside.irccloud.com> has joined #oe23:41

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