Wednesday, 2022-02-23

moto-timokevinrowland: the package manager has a "cache" on target and therefore know what it has installed vs what the "package feed" (at the simplest just a  'python3 httpserver' on the proper directory in deploy)00:00
moto-timothis "package feed" workflow does require a "PR server" to be sane. And you might end up needing to bump "PR" in recipes to make it work. It's not without pain.00:00
moto-timokevinrowland: there are also things in the wiki or TipsNTricks about it... some of that is "write once wiki" and needs updating00:01
kevinrowlandmoto-timo: gotcha. I wonder if the "package feed" thing is a little too heavy weight for us.. especially reading your latest message about ${PR}. I'll take a look either way. At the end of the day I just want to deploy valgrind or similar debug tools when needed00:03
moto-timokevinrowland: it's not as _simple_ people want it to be, but a NFS root/TFPT workflow allows very very rapid developer cycles... but it is far enough from production that I rarely use that tool00:04
moto-timokevinrowland: there is also the eSDK workflow, but it needs a bit of love so I won't go out on a limb on it00:12
moto-timokevinrowland: "eSDK workflow" as implied by
RPhalstead, michaelo: The docs issues are because there is a warning and the docs fail to build on multiple releases00:20
RPref-manual/variables.rst:760: WARNING: term not in glossary: BB_HASHBASE_WHITELIST00:21
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 256 seconds)00:35
moto-timokevinrowland: there might be room for an enhancement to devtool to allow "deploy package"... but no promises00:39
moto-timokevinrowland: we honestly have almost no resources supporting devtool/recipetool and other parts of the infrastructure... sad but true00:40
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto00:41
*** JaMa is now known as Guest214200:44
*** JaMa <JaMa!~martin@> has joined #yocto00:44
kevinrowlandmoto-timo: you mean there's a branch up for that "deploy package" work? Or it's just an idea you're kicking around?00:56
kevinrowlandI did see this earlier today: -- v1 of the patch has some good discussion too01:00
moto-timokevinrowland: Just throwing out a random thought. No attempt at validity or verification.01:00
moto-timokevinrowland: there you go. that is a GoodIdeaTM01:01
moto-timoI do care about this, but it is a bit draining to move forward when we are struggling to get releases out the door. And I apologize for being particularly exhausted as we push for the feature freeze.01:03
moto-timoI am more than willing to help advise technically and move such a feature forward01:03
*** vmeson <vmeson!> has quit IRC (Remote host closed the connection)01:12
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 240 seconds)01:14
*** vmeson <vmeson!> has joined #yocto01:14
*** jclsn7 <jclsn7!> has joined #yocto01:19
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 240 seconds)01:25
*** jclsn7 <jclsn7!> has joined #yocto01:26
*** qschulz <qschulz!> has quit IRC (Remote host closed the connection)01:32
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 256 seconds)01:32
*** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5390:d00:12bf:48ff:feb8:38c8> has quit IRC (Ping timeout: 252 seconds)01:33
*** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5390:d00:12bf:48ff:feb8:38c8> has joined #yocto01:34
*** qschulz <qschulz!> has joined #yocto01:35
*** chep <chep!> has quit IRC (Read error: Connection reset by peer)01:37
*** chep` <chep`!> has joined #yocto01:37
*** chep` is now known as chep01:37
*** jclsn7 <jclsn7!> has joined #yocto01:38
*** prabhakarlad <prabhakarlad!> has quit IRC (Ping timeout: 256 seconds)01:44
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 272 seconds)01:46
*** jclsn7 <jclsn7!> has joined #yocto01:51
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 272 seconds)01:57
*** GillesM <GillesM!> has quit IRC (Remote host closed the connection)01:58
*** bluelightning <bluelightning!~paul@2406:e003:151f:d701:84c0:da9:568e:a3a6> has quit IRC (Ping timeout: 240 seconds)02:01
*** jclsn7 <jclsn7!> has joined #yocto02:02
*** prabhakarlad <prabhakarlad!> has joined #yocto02:06
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 272 seconds)02:08
*** taco___ <taco___!~taco@> has quit IRC (Quit: Client closed)02:10
*** jclsn7 <jclsn7!> has joined #yocto02:14
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 256 seconds)02:18
*** jclsn7 <jclsn7!> has joined #yocto02:24
*** RobertBerger <RobertBerger!~rber|> has joined #yocto02:32
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 256 seconds)02:33
*** rber|res <rber|res!~rber|> has quit IRC (Ping timeout: 245 seconds)02:34
*** jclsn7 <jclsn7!> has joined #yocto02:38
*** gjm <gjm!> has joined #yocto02:41
*** gjm is now known as gmalysa02:42
moto-timo"All" the failures in the current build for python packaging are due to the /usr/bin/nativepython3 overwrite that pip is doing on installing scripts to ${bindir}
moto-timoany help is appreciated to get us across the finishing line02:43
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 240 seconds)02:47
*** sakoman <sakoman!> has joined #yocto02:50
*** jclsn7 <jclsn7!> has joined #yocto02:52
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)02:53
*** jclsn7 <jclsn7!> has quit IRC (Quit: Ping timeout (120 seconds))02:58
*** jclsn7 <jclsn7!> has joined #yocto02:58
*** amitk <amitk!~amit@> has joined #yocto03:02
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 240 seconds)03:04
*** jclsn7 <jclsn7!> has joined #yocto03:09
*** kevinrowland <kevinrowland!~kevinrowl@> has quit IRC (Quit: Client closed)03:17
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 256 seconds)03:20
*** jclsn7 <jclsn7!> has joined #yocto03:26
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 256 seconds)03:32
*** gmalysa <gmalysa!> has quit IRC (Quit: Client closed)03:35
*** jclsn7 <jclsn7!> has joined #yocto03:38
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 256 seconds)03:46
*** jclsn7 <jclsn7!> has joined #yocto03:52
*** jclsn71 <jclsn71!> has joined #yocto03:57
*** pgowda_ <pgowda_!> has joined #yocto03:58
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 272 seconds)04:00
*** jclsn71 is now known as jclsn704:00
*** jclsn7 <jclsn7!> has quit IRC (Ping timeout: 256 seconds)04:05
*** jclsn7 <jclsn7!> has joined #yocto04:11
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)04:57
*** gmalysa <gmalysa!> has joined #yocto05:23
*** rfs613 <rfs613!> has quit IRC (Quit: restart)05:45
*** rfs613 <rfs613!> has joined #yocto05:45
*** fitzsim <fitzsim!> has quit IRC (Read error: Connection reset by peer)06:07
*** gmalysa <gmalysa!> has quit IRC (Quit: Client closed)06:18
*** mrnuke <mrnuke!> has quit IRC (Read error: Connection reset by peer)06:34
*** mrnuke <mrnuke!~mrnuke@2601:2c1:8501:182d::c66> has joined #yocto06:34
*** dmoseley <dmoseley!~dmoseley@> has quit IRC (Ping timeout: 240 seconds)06:41
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto06:42
*** rob_w <rob_w!~rob@2001:a61:6050:d201:e45d:6190:f58a:6c8c> has joined #yocto06:59
*** kroon <kroon!> has joined #yocto07:01
*** kroon <kroon!> has quit IRC (Read error: Connection reset by peer)07:09
*** kroon <kroon!> has joined #yocto07:10
*** goliath <goliath!~goliath@user/goliath> has joined #yocto07:16
*** mvlad <mvlad!~mvlad@2a02:2f08:4b12:b100:24d7:51ff:fed6:906d> has joined #yocto07:19
*** mrnuke <mrnuke!~mrnuke@2601:2c1:8501:182d::c66> has quit IRC (Ping timeout: 250 seconds)07:32
*** osama3 <osama3!> has joined #yocto07:37
*** Etheryon <Etheryon!~textual@> has joined #yocto07:38
*** osama4 <osama4!> has joined #yocto07:38
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection)07:39
*** mckoan|away is now known as mckoan07:41
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto07:41
*** osama3 <osama3!> has quit IRC (Ping timeout: 240 seconds)07:42
*** osama4 <osama4!> has quit IRC (Ping timeout: 272 seconds)07:43
*** frieder <frieder!> has joined #yocto07:44
*** alessioigor <alessioigor!~alessioig@> has joined #yocto07:46
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Client Quit)07:46
*** chbae <chbae!> has joined #yocto07:50
*** tre <tre!> has joined #yocto08:02
*** oobitots <oobitots!> has joined #yocto08:04
jclsn[m]I am getting a lot of errors when using cog. Am I missing some flags?... (full message at
jclsn[m]The UI is also not shown08:06
jclsn[m] * I am getting a lot of errors when using cog. Am I missing some flags?... (full message at
jclsn[m] * I am getting some errors when using cog. Am I missing some flags?... (full message at
*** mrnuke <mrnuke!~mrnuke@2601:2c1:8501:182d::c66> has joined #yocto08:14
*** oobitots <oobitots!> has quit IRC (Quit: Client closed)08:20
*** chbae <chbae!> has quit IRC (Quit: Client closed)08:22
*** Austriker <Austriker!> has joined #yocto08:26
*** ilunev <ilunev!~koolkhel@2a00:8740:2c:5ca1:30bf:76d:19db:2a98> has quit IRC (Ping timeout: 256 seconds)08:27
*** thekappe <thekappe!~thekappe@> has joined #yocto08:29
jclsn[m]There is no documentation08:29
jclsn[m]Seems like a very immature application08:29
*** JaMa <JaMa!~martin@> has quit IRC (Ping timeout: 256 seconds)08:34
*** ilunev <ilunev!~koolkhel@2a00:8740:2c:5ca1:f04f:a7fc:f3f:f7a4> has joined #yocto08:34
*** ilunev <ilunev!~koolkhel@2a00:8740:2c:5ca1:f04f:a7fc:f3f:f7a4> has quit IRC (Ping timeout: 240 seconds)08:39
thekappeHello guys !! I'm trying to bitbake this recipe:
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto08:40
thekappedue to some errors I've already added "glibc" to "DEPENDS" and inherit autotools bash-completion pkgconfig08:41
thekappeNow I'm getting the following error: Exception: FileNotFoundError: [Errno 2] No such file or directory: '/home/user/yocto/build/tmp/sysroots-components/aarch64/gcc-runtime/sysroot-providers/gcc-runtime08:42
thekappeDoes anyone has an idea on how to fix it ?08:42
*** JaMa <JaMa!~martin@> has joined #yocto08:42
*** ilunev <ilunev!~koolkhel@> has joined #yocto08:51
*** ilunev <ilunev!~koolkhel@> has quit IRC (Read error: Connection reset by peer)08:53
*** asconcepcion[m] <asconcepcion[m]!~asconcepc@2001:470:69fc:105::1:73ea> has quit IRC (Quit: You have been kicked for being idle)09:00
*** ilunev <ilunev!~koolkhel@> has joined #yocto09:09
*** ilunev <ilunev!~koolkhel@> has quit IRC (Client Quit)09:10
*** Austriker <Austriker!> has quit IRC (Ping timeout: 256 seconds)09:11
*** osama4 <osama4!> has joined #yocto09:12
*** osama4 <osama4!> has quit IRC (Read error: Connection reset by peer)09:17
qschulzRP: michaelo: halstead: I'm not sure this is actually an issue? The make flags are -W ( and --keep-going ( the build should continue and just exit with non-zero code09:19
*** behanw <behanw!> has quit IRC (Quit: Connection closed for inactivity)09:19
qschulzFWIW, I tested locally, and the index page is generated and I can access it09:20
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has quit IRC (Ping timeout: 256 seconds)09:37
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has joined #yocto09:39
*** osama4 <osama4!> has joined #yocto09:42
*** xmn <xmn!> has quit IRC (Quit: ZZZzzz…)09:47
*** oobitots <oobitots!> has joined #yocto09:47
*** florian <florian!> has joined #yocto09:48
RPqschulz: something isn't working as for example 3.4.1 is missing09:56
qschulzcan we add `set -eu` to this script so we have an idea if an issue arises and stop the script from running?09:57
RPqschulz: probably, I don't know if that will cause any other issues but we could try09:57
qschulzRP: e.g. could simply be some rsync issue? I seem to recall reading somewhere there are intermittent network issues?09:57
RPqschulz: we see clear errors about things being missing before that so whilst that could occasionally be an issue, I'm not convinced09:58
*** otavio <otavio!> has quit IRC (Read error: Connection reset by peer)10:02
*** otavio <otavio!> has joined #yocto10:06
*** Dracos-Carazza_ <Dracos-Carazza_!~Dracos-Ca@> has joined #yocto10:10
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has quit IRC (Ping timeout: 272 seconds)10:12
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto10:13
mcfriskis the some QA check in poky for images to e.g. check that /usr/include doesn't exist, maybe one that can be configured for forbidden content to avoid developers doing silly things10:17
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)10:18
*** JaMa <JaMa!~martin@> has quit IRC (Killed ( (Nickname regained by services)))10:23
*** Guest2142 is now known as JaMa10:23
*** JaMa is now known as Guest674110:23
*** Guest6741 <Guest6741!~martin@> has quit IRC (Killed ( (Nickname regained by services)))10:23
*** JaMa <JaMa!~martin@> has joined #yocto10:23
*** JaMa is now known as Guest615110:23
*** Guest6151 <Guest6151!~martin@> has quit IRC (Killed ( (Nickname regained by services)))10:23
*** JaMa <JaMa!> has joined #yocto10:23
Saur[m]mcfisk. There is, kind of (in master, and once 3.4.2 is released it will work in Honister as well). The check QA check is called "empty-dirs" and is used to validate that a directory is empty. The variable QA_EMPTY_DIRS is used to define the list of directories that are expected to be empty (see insane.bbclass).10:25
RPmcfrisk: no, it could be something we could add though10:27
Saur[m]It can typically be used to make sure that files are not installed into directories that will be used as mount points, or to make sure that files are not being installed into the wrong directories.10:27
RPmcfrisk: I like Saur[m]'s approach10:28
*** JaMa is now known as Guest722310:28
*** JaMa <JaMa!~martin@> has joined #yocto10:28
Saur[m]It also allows to define a message per directory that will be shown in case a file is installed in the directory, so one can give an informative message as to what one should do instead. See QA_EMPTY_DIRS_RECOMMENDATION in insane.bbclass.10:31
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 256 seconds)10:34
mcfriskthanks Saur[m] RP, I'll have a look and possibly cherry-pick to my dunfell tree10:34
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto10:36
qschulzRP: I'm even tempted to set -x in the script10:55
Perceval[m]Hello all, on my yocto distrib I Have the following error regularly10:56
Perceval[m]systemd-journald[3073]: Forwarding to syslog missed 28 messages.10:56
Perceval[m]do you have an idea on where it could come from?10:56
Perceval[m]I know that it is the forwarding from systemd logging system to syslog, but I don't know what service or soft could cause such error10:57
*** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Ping timeout: 256 seconds)10:59
RPqschulz: I was wondering to. We could try a patch?11:02
*** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto11:02
qschulzRP: preparing something yes, will send soon11:03
LetoThe2ndyo dudX11:07
*** florian_kc <florian_kc!> has joined #yocto11:08
*** goliath <goliath!~goliath@user/goliath> has joined #yocto11:11
*** lucaceresoli <lucaceresoli!> has joined #yocto11:18
qschulzRP: mmm set -e isn't a great idea since old branches of the docs might throw warnings and then fail11:25
qschulzI'll send it anyway, so we can start discussing this stuff11:25
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)11:25
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto11:33
*** JaMa is now known as Guest88911:36
*** Guest7223 is now known as JaMa11:36
*** Guest889 <Guest889!~martin@> has quit IRC (Remote host closed the connection)11:36
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 272 seconds)11:43
*** mauro_anjo <mauro_anjo!~quassel@> has joined #yocto11:45
*** tre <tre!> has quit IRC (Ping timeout: 272 seconds)11:51
*** thekappe <thekappe!~thekappe@> has quit IRC (Ping timeout: 256 seconds)12:02
*** tre <tre!> has joined #yocto12:03
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)12:06
*** fitzsim <fitzsim!> has joined #yocto12:11
*** thekappe <thekappe!~thekappe@> has joined #yocto12:16
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto12:16
thekappehello guys, I have to build the A recipe that RDPENDS from the B recipe. The point is that B must be compiled with unicode support (--enable-utf --enable-unicode-properties) there is a way to instruct bitbake to compile B with the proper flag while bitbaking A ?12:16
RPmichaelo: I'm thinking we should apply qschulz's changes quickly?12:32
*** alessioigor <alessioigor!~alessioig@> has joined #yocto12:32
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Remote host closed the connection)12:33
RPkanavin_: your changing TARGET_ARCH in the cross recipes is worrying me12:36
RPkanavin_: The intent, at least for cross canadian was to have one arch compiler which targeted all the different SYS pieces12:37
RPcross is a little bit less clear but in theory the same mapping could apply12:37
kanavin_RP: gcc-cross-arm-none-eabi needs to be configured differently to gcc-cross-arm-poky-linux: "--with-sysroot= --with-headers=no --disable-gcov --disable-threads --enable-multilib --with-multilib-list=rmprofile,aprofile"12:40
kanavin_RP: even then, I wouldn't necessarily trust that --target=arm-poky-linux would produce the same output as --target=arm-none-eabi12:41
kanavin_RP: that said, I reverted that change locally, as I knew it would be tough sell, and I was right ;)12:41
RPkanavin_: why does it need to be configured differently?12:43
kanavin_RP: because it needs to build libgcc pieces in absence of libc12:43
RPkanavin_: libgcc needs to be configured differently, sure12:44
RPwe build gcc-cross and libgcc in separate recipes12:44
kanavin_RP: the way we build libgcc is 'copy preconfigured gcc build tree into $S, run make in libgcc subdir'.12:45
kanavin_there is no separate configuration step for libgcc12:45
RPkanavin_: well, there probably should be as these things aren't that tied together (and aren't in cross-canadian)12:46
kanavin_RP: right, I am now checking how this is done in cross-canadian sdk builds12:46
RPlike a lot of things, I've tried to clean up and separate out the pieces over time but it only gets so far12:46
kanavin_makes one wish for multi-target toolchains like rust ;)12:47
RPkanavin_: cross-canadian doesn't need it's own libgcc so in that sense it can cheat and use the target one we have already12:47
RPkanavin_: but the fact that cross-canadian works with that shows gcc-cross isn't sys specific if you pass the right params in12:47
RPkanavin_: there is no good reason gcc can't be multi target, it just can't do multi arch12:48
kanavin_RP: gcc-cross isn't but libgcc is, and the params you need to pass for libgcc are passed via gcc-cross12:48
kanavin_(see above)12:50
RPkanavin_: Right, I agree that is a problem today :(12:50
RPI was just trying to share the direction I was trying to move things in12:50
RPgcc-cross is meant to only rebuild per arch. Obviously it doesn't quite work right today :(12:51
kanavin_it also shouldn't require target libc to build, but alas, it does12:51
kanavin_for libgcc12:52
kanavin_unless you suppress that with a bunch of not-obvious options12:52
RPkanavin_: it depends. musl doesn't have that issue, glibc does12:52
RPthe dependencies are tweaked accordingly but you'll find it uses the same gcc-cross for both12:53
RPdespite them being different _SYS12:53
kanavin_RP: I wish gcc upstream would better separate the pieces, and not control everything through a top level configure12:54
RPkanavin_: well, yes12:55
kanavin_I understood just enough of it to do what the customer wants, but the whole thing is just short of collapsing under its own complexity12:55
RPkanavin_: I have tried to improve things on several occasions, I keep chipping away at it12:55
RPwhich is why I felt I should warn you that patch didn't look quite right to me12:56
RPbut if you want to tell me I'm wrong, whatever, I have a large queue of problems today :(12:56
kanavin_RP: the patch is already reverted locally12:57
kanavin_I found a way to build additional gcc-cross without changing the confuguration for the main one, but I didn't find a way to decouple libgcc from gcc-cross12:58
RPkanavin_: I would have to go and look at the code again to be able to give useful feedback :(12:59
kanavin_RP: you also would need to look at which is also work in progress and missing latest tweaks13:00
kanavin_RP: maybe it's best to wait until I'm happy with it, and ready to submit for review :)13:00
kanavin_and yes I'm abusing mcextend on a grand scale there, I love how I can avoid writing extra recipes with it :)13:01
RPkanavin_: I'm just worried about you spending a ton of time on something which isn't a direction I'm comfortable with, that was the reason I mention it13:02
RPkanavin_: that was probably more what the standard class extensions were for rather than mcextend :/13:02
*** prabhakarlad <prabhakarlad!> has joined #yocto13:05
RPqschulz: "we probably want to use virtualenv with specific Sphinx versions" - this fills me with dread making this work over all the distros on the autobuilder :(13:05
michaeloRP, qschulz: I agree. This way we know what happens.13:05
kanavin_RP: thanks for the tip, if the standard class extension works, that'd be easy to adjust - much easier than sorting the multi-cross issue13:06
RPmichaelo: I was meaning the docs list fix for basehash13:06
RPthe script changes in helper I'm worried about making work well :/13:06
RPwe probably want the script to run all the different pieces, collect up the exit code and skip the rsync if anything fails?13:06
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 240 seconds)13:08
RPthen the build will fail, the docs website would be ok but we have a list of all the failures13:08
kanavin_RP: if that helps with the worry, I warned the customer there is no certainty in upstreaming the needed tweaks in the time scale they agreed to pay for. It's a problem that might become important in the future as people would want to build things using one part of the target system that is capable of builds for the other part of the system that is too constrained to host a compiler for itself13:09
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto13:18
*** diesUndDas <diesUndDas!> has joined #yocto13:19
diesUndDasHello guys, I am confused.13:20
diesUndDasI would like to create a symlink to a library, in this case it is libsdl2.So I have created a bbappend and set FILE_${PN} to /usr/lib/libSDL2.so13:20
diesUndDasBut it get's removed by do_populate_sysroot :(13:21
rburtonwhat does your bbappend actually contain?13:23
diesUndDasJust two lines:13:24
diesUndDasFILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"13:24
diesUndDasFILES_${PN} += "/usr/lib/"13:24
diesUndDasI have created the bbappend file with the recipetool13:25
rburtonyou don't need to set FILESEXTRAPATHS if you're not adding patches13:27
rburtonI presume this is a libsdl2.bbappend?13:27
michaeloRP: now I understand you're talking about qschulz' doc changes, not his changes to run-docs-build. I'm merging them into master-next and preparing a pull-request.13:28
diesUndDasrburton: okay, I am going to remove it then. Almost, it is a libsdl2_%.bbappend13:30
rburtondiesUndDas: so packaging happens in the order of packages in the PACKAGES variable. PN-dev is before PN, and that contains ${libdir}/*.so, because those symlinks are only needed at build time13:31
rburtondiesUndDas: so if you've something that is dlopen()ing, then it's broken13:31
diesUndDasrburton: Why is it going to be broken? Isn't it referencing the actual libsdl2 shared library anymore? :S13:34
rburtonno distribution will ship the .so on its own unless it also ships the headers and stuff13:34
*** vladest1 <vladest1!~Thunderbi@2001:1715:9d9c:c530:5c77:7106:6f60:1b41> has joined #yocto13:35
diesUndDasAnd how can I tell the buildsystem to create one?13:35
rburtonstep back: why do you need to exist13:35
rburton <-- for example, on debian is only packaged in libsdl2-dev13:36
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:f83a:7917:7f6a:ff7> has quit IRC (Ping timeout: 250 seconds)13:37
*** vladest1 is now known as vladest13:37
diesUndDasrburton: because an application tries to load the library as "". I assume that's not how it should be done? :D13:38
rburtondoes it dlopen() at runtime?13:38
*** ecdhe_ <ecdhe_!~ecdhe@user/ecdhe> has quit IRC (Ping timeout: 260 seconds)13:39
rburtonif so, yes, that's wrong.13:40
rburtonif you *really* need to do this you can remove the .so from FILES:PN-dev so they end up in PN. but the application is the problem.13:40
qschulzRP: sorry was away.. What are the issues you're foreseeing with virtualenv for the docs?13:48
qschulzmichaelo: RP: also re the docs, we probably want to update the renamed variables too. Didn't have the time now but I guess a good starting point is convert-variable-renames script?13:49
*** ldericher <ldericher!> has quit IRC (Quit: ZNC 1.8.2 -
RPqschulz: trying to get that to work reliably on all the different distros/workers on the autobuilder?13:58
qschulzRP: you mean without virtualenv?13:59
qschulzbecause virtualenv is supposed to fix this issue? or maybe I'm overestimating the benefit of using virtualenv over its cost?13:59
RPqschulz: I'm sure it is supposed to fix it but I also somehow doubt it will behave on all the different distros/python versions the same way14:00
*** olani <olani!> has joined #yocto14:02
diesUndDasrburton: The problem  lies in dotnet 6 :(14:04
diesUndDasIf I say "LD_DEBUG=libs dotnet SDL2-Example" on the target, I get:14:04
diesUndDas      1029:     find [0]; searching14:05
diesUndDas      1029:      search cache=/etc/
diesUndDas      1029:      search path=/lib:/usr/lib              (system search path)14:05
diesUndDas      1029:       trying file=/lib/libSDL2.so14:05
diesUndDas      1029:       trying file=/usr/lib/libSDL2.so14:05
diesUndDas      1029:14:05
diesUndDas      1029:     find library=SDL2 [0]; searching14:05
diesUndDas      1029:      search cache=/etc/
diesUndDas      1029:      search path=/lib:/usr/lib              (system search path)14:05
diesUndDas      1029:       trying file=/lib/SDL214:05
diesUndDas      1029:       trying file=/usr/lib/SDL214:05
diesUndDas      1029:14:05
diesUndDas      1029:     find library=libSDL2 [0]; searching14:05
diesUndDas      1029:      search cache=/etc/
diesUndDas      1029:      search path=/lib:/usr/lib              (system search path)                                                                 1029:       trying file=/lib/libSDL214:05
diesUndDas      1029:       trying file=/usr/lib/libSDL214:05
rburtonyeah dotnet is dumb for exactly the same reason14:05
diesUndDasOh man, ...14:05
*** ldericher <ldericher!> has joined #yocto14:06
diesUndDasSo my only option is to do it the wrong way then?14:06
diesUndDasrburton: and how should an application ideally load a shared library? :D14:07
rburtonideally, with the full name14:07
diesUndDasrburton: okay, thank you :)14:08
*** amitk_ <amitk_!~amit@> has joined #yocto14:09
qschulzRP: ok I think I've found the issue with the docs. Do we have automated tests of the docs?14:11
jclsn[m]<diesUndDas> "Oh man, ..." <- dütt un datt!14:12
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 256 seconds)14:13
RPqschulz: no, we just build them14:13
RPrburton: with cve check, what happens if you have two builds in parallel with the same DL_DIR doing a cve_check fetch?14:16
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:27fc:a530:7097:2c60> has joined #yocto14:16
*** diesUndDas <diesUndDas!> has quit IRC (Quit: Client closed)14:17
RPI thought we had a shared lock task flag but we don't, I think there is an sstate specific one14:18
*** mihai <mihai!~mihai@user/mihai> has joined #yocto14:19
jclsn[m]God you really need a 2TB drive when you want to build for multiple boards14:20
qschulzjclsn[m]: INHERIT += "rm_work" is a good friend usually :)14:20
jclsn[m]What does it do?14:21
jclsn[m]qschulz: Will it increase build time?14:23
mihaireusing downloads and sstate directories should also help14:23
rburtonRP: they race on the file i guess14:23
jclsn[m]mihai: That I already do14:24
rburtonRP: well, the lockfile is a filesystem lock right? so if they lock properly, it should work?14:24
qschulzjclsn[m]: I guess it could since it's going to remove files, so it's an additional command during the build14:24
RPrburton: I'm worried that one could be updating the DB whilst another accesses it. The question is whether than level of locking works over NFS14:25
rburtonRP: same question but for two build trees doing a git fetch i guess14:25
RPrburton: yes. Except that bitbake does handle locking on DL_DIR for fetches/unpacks14:26
*** codavi <codavi!~akiCA@user/akica> has joined #yocto14:28
jclsn[m]qschulz: Thanks14:28
*** xmn <xmn!> has joined #yocto14:29
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 250 seconds)14:33
*** sakoman <sakoman!> has joined #yocto14:34
*** ar__ <ar__!~akiCA@user/akica> has joined #yocto14:36
jclsn[m]Where is the switch to use a fixed chromium version btw?14:36
*** thekappe <thekappe!~thekappe@> has quit IRC (Ping timeout: 256 seconds)14:36
jclsn[m]It rebuilds frequently and it takes ages14:36
jclsn[m]Can't find it in the recipe. Should be PV14:36
*** ldericher <ldericher!> has quit IRC (Quit: ZNC 1.8.2 -
*** ldericher <ldericher!> has joined #yocto14:37
*** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 240 seconds)14:39
qschulzjclsn[m]: if any dependency of Chromium gets rebuilt, Chromium will get rebuilt, there's no going around that unfortunately14:43
*** kroon <kroon!> has quit IRC (Quit: Leaving)14:43
jclsn[m]qschulz: Okay, I will ask my boss to reconsider that Threadripper then14:43
*** TundraMan is now known as marka14:44
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:5c77:7106:6f60:1b41> has quit IRC (Quit: vladest)14:46
qschulzRP: michaelo: halstead: pretty sure I fixed the most occurring issue with sphinx docs with the patch I just sent for the autobuilder14:47
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:527b:127a:2d5a:c3c8> has joined #yocto14:47
qschulzRP: I don't know what you think about that but I think it makes sense to set -eux -o pipefail and re-use the same Sphinx version for all doc sbuilding and the day we have an incompatibility we'll rethink about this pipenv/virtualenv stuff?14:49
qschulzRP: michaelo: halstead: don't know about the rsync delete_file permission denied though, c.f.
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto15:01
RPqschulz: I'm happy to set those and worry about the sphinx version later15:02
RPqschulz: We'll need mhalstead later for the rsync issue or I can try and poke at it15:02
*** pgowda_ <pgowda_!> has quit IRC (Quit: Connection closed for inactivity)15:08
RPmoto-timo: I have some changes which may help, still debugging issues though. I've spent the day on this :/15:21
rfs613qschulz, rburton, RP: morning gents, I have a bit more info about the cve-check issue.15:23
rfs613I had noticed it ran slower locally with the lock, but in our CI it was far worse - build that ususally takes 1-2 hours is taking 24 to 48.15:23
rburtonrfs613: i sent a patch this morning you can try15:24
rfs613The lock is in $DL_DIR subdir, and in the case of CI this is shared via NFS (I think)15:24
rfs613rburton: i'15:24
rfs613ll check the list i a moment; I tried a patch yesterday that seemed to help FWIW15:24
rfs613s/i a/in a/15:25
rburtonyeah i don't want to merge a patch which involves copying the database for every recipe15:25
RPrburton: could we just copy into TMPDIR once after updating and do that copy under a DL_DIR lock?15:26
rburtoni'd hope we can avoid copying entirely15:28
rfs613rburton: okay, I see the patch on list, makes sense not to copy, will test it here shortly.15:28
rburtonthe only thing that writes is the cve-update-db recipe, which is a dependent of the reading tasks, so it will happen once early15:28
RPrburton: but not with builds in parallel which worries me :/15:29
rfs613what happens if we run multiple concurrent builds?15:29
zyga[m]rburton: I ran into that issue in oniro15:30
zyga[m]our builds run on top of a shared nfs disk15:30
zyga[m]we ended up moving the database to local storage to avoid long lock waits15:30
zyga[m]otherwise builds would stall as the database lock was held by one task15:30
zyga[m]things worked but were terribly sequential15:30
rfs613we were seeing "NFS reclaim lock" errors, not 100% certain if they are related, but seems likely.15:32
rburtonright,my  patch removes the lock15:32
rburtonrfs613: are you running concurrent builds across the same DL_DIR? can you verify with timestamps that the problem is caused by multiple builds writing to the same sqlite database?15:33
zyga[m]at oniro we use the same DL_DIR and SSTATE_DIR across all builds15:34
rfs613rburton: yes, we share DL_DIR and sstate across builds. Debugging is difficult because I have no shell access, all I can do is add "ls <whatever>" commands to the build recipes, and hope they show up in the logs.15:34
rfs613Also the build runs in container which is destroyed after build...15:34
rburtonyou can look at the build logs and see if the times of cve-update-db-native correlates to failures in other runs15:35
rfs613(but obviously DL_DIR and sstate are outside, via NFS apparently)15:35
michaeloqschulz: great catch! Many thanks15:35
qschulzmichaelo: still, I think the bitbake rsync needs to be modified15:36
rfs613rburton: yep, I can try checking timestamps, but let me get a new build running first, then I'll have time for log grepping15:36
qschulzmichaelo: still, I think the bitbake rsync needs to be modified. I assume15:37
qschulzrsync -irlp --checksum --ignore-times --delete bitbake
qschulzwill actually delete everything under the docs directory on docs.yoctoproject.org15:37
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:27fc:a530:7097:2c60> has quit IRC (Remote host closed the connection)15:38
qschulzso if the yp-docs fail to build and does not reach its own rsync, then the yp-docs won't be available on the website, though bitbake's will15:38
qschulzso I **guess** rsync -irlp --checksum --ignore-times --delete bitbake/*
qschulzmight be a good replacement but I had so many issues with the few rsync scripts I wrote that I don't know if this does anything I want :)15:39
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:27fc:a530:7097:2c60> has joined #yocto15:39
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:27fc:a530:7097:2c60> has quit IRC (Remote host closed the connection)15:40
rburtonRP: again i think bitbake needs shared lock support15:40
rburtona solid fix would be to let the reading tasks shared lock the database15:40
rburtoni guess the tasks can do that lock manually15:41
RPrburton: happy to add it, shouldn't be hard15:42
RPrburton: internally the lock functions already do15:42
RPrburton: I think the sstate code uses it already15:43
RPrburton: I still think for efficiency you'd want a tmpdir local copy of that database15:43
rburtoni really don't think its needed15:43
rburtonwriting is rare15:43
RPrburton: the writer tasks would likely stall out under pressure from cbe check tasks though :/15:44
rburtonthere won't be lots of writer tasks15:44
RPrburton: I was surprised we didn't have shared task locks to be honest15:44
rburtonif the mtime of the database is less than an hour, it doesn't update it15:44
michaeloqschulz: why not directly rsync -irlp --checksum --ignore-times --delete bitbake/ (without the "*")?15:45
michaeloit's true I'm not comfortable with the previous command :-|15:47
qschulzmichaelo: whatever works by deleting only what's in docs/bitbake and not docs/ :)15:47
rfs613rburton: tested your two patches locally, seems fine (no slowdown)15:47
qschulzbut now that I'm reading the last rsync,it's probably just fine? otherwise we'd also be missing the bitbake docs15:47
qschulzmichaelo: never mind, seems like the manpage tells us the rsync commands are just fine. So I can we can "safely" enable set -eu -o pipefail. The side effect being that if nobody monitors the builds, the docs will stay out of date since rsync won't be running if anything fails before15:51
RPqschulz: swat does monitor failures15:54
michaeloqschulz: it sounds right. However, the first rsync command doesn't always do what it's supposed. That's probably safer to submit the change you proposed. I would do that if I were you...15:56
qschulzRP: so the question right now is... do we disable the warning-to-error to pass most builds (and don't see the error about non-existing BB_HASHBASE_WHITELIST variable for example)15:56
RPqschulz: can we get to a point where we're warning free again easily?15:56
qschulzRP: no warning from master + my two patches, didn't check the other branches15:57
qschulzbut if it's what we aim for, then I can check. I would rather keep the fail-on-warning in Sphinx and enable set -eu -o pipefail so that we don't miss stuff15:58
qschulz(note that they aren't exclusive, it's just that set -eu -o pipefail is a bit less useful if you disable the warning-to-error in sphinx builds :) )15:59
michaeloI agree to keep the warnings too16:00
RPqschulz: looks like transition, dunfell and yocto-3.4.1  still fail :(16:00
qschulzRP: transition is because of missing make target, can be easily fixed (since it's a branch)16:02
*** tre <tre!> has quit IRC (Remote host closed the connection)16:03
rfs613hmm, so it seems I cannot .bbappend for a bbclass, correct?16:04
smurrayrfs613: yep16:05
rfs613right, that makes it tricky to test rburton cve-fixes in our CI setup, since I cannot modify poky there.16:06
rfs613any clever ideas for me?16:07
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:27fc:a530:7097:2c60> has joined #yocto16:07
rfs613i guess I could have the build script do "git revert d55fbf47794" which would at least get the build times back down to a few hours...16:09
smurrayrfs613: the typical approach is to just drop the new version of the bbclass in a layer to override16:09
smurrayrfs613: which isn't great for maintainability, but it does work16:10
*** oobitots <oobitots!> has quit IRC (Quit: Client closed)16:10
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)16:10
qschulzRP: yocto-3.3.x and yocto-3.4.x need a patch to use the correct bitbake version for the object.inv from bitbake, but I don't see any specific error in the autobuilder for dunfell branch though? Also, the issue of -W messing up the build only exists since honister branch fro the docs (it was not part of the flags before)16:10
mckoanGenerating an image with 'dunfell' results in the creation of timestamped images which are not deleted but continue to be added in deploy/images. Has anyone had the same problem recently?16:15
michaeloqschulz, RP: will we have to fix 3.4.1 too? I wish we could only generate the docs for each release branch, not for all each individual release :|16:15
rburtonrfs613: we use kas which lets you drop patches onto other layers as part of the setup16:16
*** osama4 <osama4!> has quit IRC (Ping timeout: 256 seconds)16:16
qschulzmichaelo: fcb24deb8b3abb8a77a12baa2cdd5ba5aa976f01 is missing for all tags/branches16:17
qschulzbranches can be fixed, tags needs to be patched16:17
smurraymckoan: specifically dunfell HEAD?  I don't see that with 3.1.14 in AGL here, can rig up a test with HEAD in a bit16:19
michaeloqschulz: right. That's why I'm asking whether we could only generate the docs for each branch, not for each release. What would we miss?16:19
*** user95 <user95!~user95@user/user95> has joined #yocto16:21
RPmichaelo: the idea was to be able to select the docs for each release version in the version selector16:22
michaeloqschulz, RP: by the way is out of date (check the Dunfell release, 3.1.12 instead of 3.1.14). It seems the run-docs-build script is not replicating switchers.js from master but from the latest tag that was processed.16:23
mckoansmurray: thanks. No it is an intermediate version. However the configuration involves some 3rd party laters therefore I am not sure whu's guilty. It's very difficult do figure out where is it and I wanted any useful hint.16:24
mckoandamn dyslexia16:25
tgamblinzeddii: What is the cutoff date for M3 contributions to the kernel (assuming some might need to be made)?16:25
moto-timoRP: do you think the sysconfigdata is what is breaking meson in sdk?16:25
smurraymckoan: maybe look in 'bitbake -e' for oddness wrt changes to the image variables?16:25
zeddiiI'll do bugfix and -stable updates up until release, so no real cutoff. i have some queued changes now, that I'll be sending this week.16:25
mckoansmurray: thx16:26
moto-timoRP: and thank you for figuring out the pip mangling patch16:26
tgamblinzeddii: Alright, thanks16:26
RPqschulz: I merged your changes so now we have
michaeloRP: yes, I understand, but why can't we use the 3.4.2 docs when we're using 3.4.1 (for example)? Shouldn't the latest docs for each branch be always sufficient? Do you expect a case when the docs of 3.x.n+y are incompatible with the 3.x.n release? Just hoping to simplify things if possible...16:27
*** florian_kc <florian_kc!> has joined #yocto16:27
RPmichaelo: we replicated what went before and didn't want to "hide" history from users.16:28
RPthe docs shouldn't be determining the development process16:28
rfs613smurray, rburton: don't trust myself to mess with the BBLAYERs, so I've kludged a "git revert" into my build script... not ideal but we should know in an hour or two if it works.16:29
michaeloRP: this makes perfect sense. What's making perhaps less sense is always regenerating the stuff that was generated successfuly.16:31
RPmichaelo: how else will the deprecation warnings/headers get added and the menus updated?16:31
michaeloRP: oh right, you win :-)16:32
RPmoto-timo: I think nativesdk is being cross compiled so probably needs that16:33
RPmoto-timo: it was meaning my pip mangling patch wasn't working for mason-nativesdk and I thought it should16:34
*** AKN <AKN!~AKN@2409:4072:689:68ab:4cf:b1bc:6e1d:c58> has joined #yocto16:34
moto-timoRP: agreed. Trying to wake up and catch up.16:34
RPmoto-timo: I've stuffed my hacks into master-next and run a build, we'll see what happens16:35
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 250 seconds)16:35
*** Etheryon <Etheryon!~textual@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)16:35
RPmoto-timo: I know some of the fixes helped e.g. python3-pip to build16:35
michaeloqschulz, RP: I can propose a patch to add "make clean" to the "transition" branch.16:35
RPmoto-timo: the wheel install thing is because it tests "python3 -m pip" and then decides it is already installed and tries to remove it16:35
RPmoto-timo: so rather than force-reinstall, we want ignore installed16:36
RPmichaelo: please16:36
RPmichaelo: I think we just have to work through the issues16:36
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto16:36
*** user95 <user95!~user95@user/user95> has quit IRC (Ping timeout: 256 seconds)16:38
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Read error: Connection reset by peer)16:41
qschulzRP: michaelo: yup, needs a clean makefile target for the transition build is required16:41
qschulzthen fcb24deb8b3abb8a77a12baa2cdd5ba5aa976f01 or similar for honister branches/tags16:42
qschulzmichaelo: we already patch 3.3 and 3.4 tags so you can hook up a new patch to the logic without too muhc hassle I think16:42
qschulzFrom what I saw from the logs, this should probably be enough to pass the build16:43
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto16:44
qschulzbut there are fixes required for other branches/tags too which aren't failing the build (warnings only, and since they weren't turned into errors before honister, the build succeeds)16:44
qschulzI cannot have a look at it today, only tmrw, so if michaelo you have time before ~10am tmrw, please do. Oitherwise we can sync tmrw16:44
rfs613rburton: I searched through previous build logs, but don't have any cve-check "read only database" in the last few weeks. Older builds get pruned... So cannot confirm or deny if timestamps align...16:46
moto-timoRP: I was on the fence about ignore-installed. Makes sense I think16:47
michaeloRP: done ( I'll be happy to see what's next :)16:49
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 256 seconds)16:52
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 250 seconds)16:56
RPmichaelo: pushed16:59
*** Tokamak_ <Tokamak_!~Tokamak@> has joined #yocto16:59
*** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto16:59
*** lucaceresoli <lucaceresoli!> has quit IRC (Remote host closed the connection)17:00
*** oobitots <oobitots!> has joined #yocto17:01
*** mckoan is now known as mckoan|away17:03
moto-timoRP: I think that's the first time buildtools job passed?17:04
moto-timoRP: oh nevermind17:04
*** AKN <AKN!~AKN@2409:4072:689:68ab:4cf:b1bc:6e1d:c58> has quit IRC (Ping timeout: 240 seconds)17:05
michaeloqschulz: 3.4.1 looks good to me. It's just that 3.4.2 sets the current version to 3.4.1 instead of 3.4.2. Shall we patch this if we don't want to move the tag?17:09
*** kevinrowland <kevinrowland!~kevinrowl@> has joined #yocto17:11
*** florian_kc <florian_kc!> has joined #yocto17:14
*** oobitots <oobitots!> has quit IRC (Quit: Client closed)17:17
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 240 seconds)17:20
*** florian <florian!> has quit IRC (Quit: Ex-Chat)17:21
RPmoto-timo: key test is the epoxy sdk test. Looks like build-appliance has an issue though. The pip calls there were always dubious17:23
RPmoto-timo: pip3-native isn't installing pip3 anylonger17:24
moto-timoRP: yeah... pip3 not found... is that native? My naïve bootstrapping only unzips the wheel... time to fix the ${bindir} installs17:24
RPmoto-timo: yes, that calls pip3 native17:25
kergothAnyone around that's building container images with bitbake? Wondering about self-hosting in-container oe builds17:25
moto-timoRP: another workaround would be to patch it to call "nativepython3 -m pip" but the right thing is to install to ${bindir} anyway17:26
moto-timoRP: let me hack at the boostrapping17:26
RPmoto-timo: we may just need to inject the right magic file in there as it is probably generated17:35
moto-timoRP: I'm pretty sure we just need to mv ${D}${PYTHON_SITEPACKAGES_DIR}/bin/* ${D}${bindir}/17:36
moto-timoRP: might also need to do that for ${datadir} or ${mandir}17:36
moto-timohacking ${bindir} now17:36
moto-timoERROR: Variable BB_ENV_EXTRAWHITE has been renamed to BB_ENV_PASSTHROUGH_ADDITIONS17:37
moto-timodo i just need to blow away tmp?17:37
RPmoto-timo: no, rebuild your environment most likely17:37
moto-timoRP: ok, thanks17:37
RPmoto-timo: mandir will be irrelevant for -native17:37
RPmoto-timo: good news is testsdk is working this time17:42
moto-timoRP: good point17:43
*** Tokamak_ <Tokamak_!~Tokamak@> has quit IRC (Ping timeout: 256 seconds)17:53
*** frieder <frieder!> has quit IRC (Remote host closed the connection)17:55
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto17:57
RPmichaelo, qschulz: the rsync issue was a protection against breaking the site until the scripts were fixed. That shouldn't be there now so just waiting on a free worker to run another docs build17:58
*** Tokamak_ <Tokamak_!~Tokamak@> has joined #yocto18:01
*** gsalazar <gsalazar!~gsalazar@> has quit IRC (Ping timeout: 245 seconds)18:01
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 256 seconds)18:02
moto-timoRP: well that was wishful thinking... as you suspected it is generated... still working on it18:07
moto-timoRP: we could also use host pip to install, but that feels wrong18:09
RPmoto-timo: I suspect it is just a few lines so maybe just handcode it in?18:13
moto-timoRP: exactly18:13
*** Tokamak_ <Tokamak_!~Tokamak@> has quit IRC (Ping timeout: 256 seconds)18:18
*** gsalazar <gsalazar!~gsalazar@> has joined #yocto18:18
*** goliath <goliath!~goliath@user/goliath> has joined #yocto18:20
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto18:21
*** gsalazar <gsalazar!~gsalazar@> has quit IRC (Ping timeout: 240 seconds)18:23
kergothRP: Would it be possible to put something together about what you and other Yocto tech decision makers would like to see out of the project members? Where would resources best be used/allocated? What's the best way we can help you? Allocate dev time to work on yocto project dev tasks? Etc18:36
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Ping timeout: 250 seconds)18:37
michaeloRP, qschulz: happy to see that the docs are apparently getting generated correctly again.18:39
michaeloand the switchers.js is correct everywhere too!18:40
*** florian_kc <florian_kc!> has joined #yocto18:40
michaeloThanks to this, the out-of-date version warnings are gone too.18:42
*** kevinrowland <kevinrowland!~kevinrowl@> has quit IRC (Quit: Client closed)18:45
*** kevinrowland <kevinrowland!~kevinrowl@> has joined #yocto18:45
kanavin_rburton, I got the meta-arm-none-eabi gcc to the point where it builds and runs
kanavin_rburton, it requires a few patches to oe-core though, and RP mentioned how some things should be improved
kanavin_(the reverted patch is not coming back, I only kept it until I stash it elsewhere for history)18:50
kergothhuh, like cross-canadian, but to run on MACHINE rather than SDKMACHINE?18:52
kanavin_kergoth, YES18:58
moto-timoRP: also fixing the selftest failures like python3-scons-native in and python3-flit-core not having HOMEPAGE18:59
*** Tokamak_ <Tokamak_!~Tokamak@> has joined #yocto18:59
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)19:02
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)19:02
fraykanavin_ what are you doing w/ the gcc-arm-none-eabi?  Baremetal stuff?19:03
kanavin_fray, I hand it over to a client who's paying for Linutronix providing the toolchain :)19:03
fraybut what is it for?  Linux, baremetal, another OS?  With the 'none', I'm assuming baremetal targeting19:04
frayI would like to see a 'baremetal' or 'baremetal-newlib' distro defined in standard Yocto Project..  since I'm seeing a lot of need for this kind of stuff19:05
kanavin_fray, setting up its actual usage is on them, I'm not sure I'm even going to see how they use it, but let me check.19:05
fraybeing able to generate toolchains with meta-toolchain for baremetal is something I do regularly.. targeting newlib (with a request for 'newlib-nano' on the r5), for a9, aarch64 (various), r5 and microblaze19:06
kanavin_fray, I checked, they seem to be using ecos+newlib19:10
*** GillesM <GillesM!> has joined #yocto19:11
frayok.. so effectively newlib based baremetal19:11
kanavin_fray, they say, just give us the toolchain, we'll take care of the sysroot19:12
khemecos uses libgloss + newlib yes19:12
fraytook me a long time to understand this, but there is two parts of newlib.. newlib (the c library) and libgloss [or an alternative] that provide the OS/hardware itnerfaces)19:12
fraySo a proper baremetal + newlib distro would use newlib, libgloss (while allowed alternative providers for libgloss)19:12
khemyou can classify baremetal as semihosted and purely baremetal19:13
kanavin_fray, I briefly looked into building cross-canadian newlib in the context of poky, but as the customer didn't ask for it, I didn't push further.19:13
frayit's pretty easy to configure, but would be better if we had a more standard YP configuration to use for this, IMHO19:13
fraywith outbuilding it, you need to provide the binaries the customer wants or gcc (libgcc) is incomplete19:13
khemits gcc's muddled build architecture, with llvm/clang its quite easy, you build one compiler for all. then you can build rumtimes as a normal target package19:14
kanavin_yes, you can't compile anything useful without libc19:14
kanavin_khem, ack. it's an awful mess of autoconf, and our recipes reflect that :(19:15
kanavin_GSOC proposal: rewrite gcc build system in meson, split the pieces into independent parts!19:16
khemheh yeah, it will be like taking GCCs identify away 🙂 but good idea19:17
khemIMO the build is one part of it, but s/w arch of gcc is also due to overhaul19:18
kanavin_khem, I once suggested meson to GNU gettext maintainer19:18
kanavin_their answer? 'autotools have been around since I was young, meson is only a fad'19:18
khemyes, I am not surprised :).19:19
kanavin_and so we're still stuck with 5 minutes of configure and two minutes of install for something that should take seconds19:19
khemyeah but to be fair I think OE does something unusual too where it runs autoreconf which is mainainer mode operation generally19:21
kanavin_khem, autoreconf is not where the time goes in gettext19:21
kanavin_khem, it's drowned into recursive ./configure, each of which tests everything under the sun19:21
khemyes but it just makes a bad problem worse19:21
kanavin_... serially19:22
RPkergoth: I can try but it is hard to give a very specific list. It is really a question of how the project can cover basic core needs. Recent examples - inclusive language or more specifically, bitbake variable rename support, or the python changes to adopt to packaging changes upstream, or the changes coming to CVE format, or help getting patchtest back online, or.... etc19:22
rburtongettext is my pathological test for autotools, autoreconf is slow but its the execution which takes FOREVER as alex says19:22
rburtonamazingly it does already re-use a config cache between the runs19:23
rburtonimagine how much slower it would be if it didn't!19:23
khemelectricfense guys did a build analysis of cross builds using yocto and I think do_configure averages around 25% of build time19:23
fraythis is the reason we generate and store the site.conf files19:24
RPkergoth: I did try and create the "big ticket" item list with the future directions topics19:24
khemand in do_compile 30% of time was spent in preprocessor19:24
fraywithout that it takes a lot more time for do_configure steps.. it was always intended to add more to the site cache, but nobody ever expanded it19:24
kanavin_rburton, and for what? a target-independent library and some utilities for UI translation?19:25
rburtonthere was an attempt at a minimal gettext clone19:25
rburtoni wonder if that's finished19:25
khemBSDs do the caching stuff for some packages, it needs proper care and feeding otherwise it becomes stale19:25
kanavin_fray, nowadays autotools is pretty much abandoned by everyone except GNU19:26
rburtonkhem: as gettext is five nested configures the first one sets a cache that the others can re-use, so that's safe at least19:26
kanavin_freedesktop and gnome moved to meson, and never looked back19:26
fraykanavin_: people keep saying that, yet everytime someone asked me to integrate something new -- it seems to be autoconf based unless its python based19:26
kanavin_something legacy you mean ;)19:27
frayit all depends on the part of the system you work with.  core-os components still use autoconf a ton..  higher up in the stack (graphics) meson is used more and more19:27
rburtonour firmware is all moving to cmake which i'm in a mixed mood about19:27
rburtoni mean, it's better than bare makefiles of doom19:27
frayI work on base OS integration.  System services, firmware loaders, etc etc..19:27
fraycmake is used a lot at (former) xilinx, I'm not a fan..  it's horribly complex to do simple things19:28
moto-timocmake is just another tool to allow folks to write bad things19:28
rfs613and building cmake itself takes forever19:28
kanavin_cmake is something c++ crowd likes a lot for some unknown reason19:28
moto-timo"works for me on this one machine that I have in the basement"19:28
fraycmake also makes it 'even easier' for people to ignore cross compiling as well..19:28
JaMaand setting CMake policies to keep ti as much backwards compatible -> more complexity19:28
fraythe number of times in the last 2 years I've had to convince people to NOT hard code a magic cross-compiler into their cmake files is mind boggling to me..19:29
khemgn + ninja is best when it comes to speed and use of system resources optimally but it has mind of its own19:29
fraywith GNU make, I have the same argument to make -- but it seems to be "easier" to just fix..19:29
moto-timoRP: flit_core has an update from 3.6.0 to 3.7.1 but I think I am going to hold off on that until we get the current mess sorted19:29
rburtonkhem: gn is the worst of all!19:30
JaMaafter bazel.. :)19:30
rburtonkhem: entirely because the distribution model appears to be 'your source ships a binary of gn'19:30
rburtonJaMa: oh, of course :)19:30
rburtonkhem: whilst you're here, :)19:31
moto-timobazel is truly a piece of work19:31
khemrburton:  look at immense research chromium team has done on existing solutions19:31
* moto-timo wonders if all wheels have _ and never - in the PN19:32
rburtonare you suggesting that chromium is easy to build?19:32
JaMait builds with python3native now, finally some nails in meta-python2 coffin19:33
moto-timothat's a GoodThingTM19:34
*** amitk_ <amitk_!~amit@> has quit IRC (Ping timeout: 240 seconds)19:38
*** rob_w <rob_w!~rob@2001:a61:6050:d201:e45d:6190:f58a:6c8c> has quit IRC (Quit: Leaving)19:41
khemrburton: the change looks good19:41
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 250 seconds)19:42
khemrburton:  re chromium, its not at all easy and that was not the point, it was about building complex s/w without much overhead,19:42
khemfray: for small projects make is ok, ninja really shines with large projects19:43
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:27fc:a530:7097:2c60> has quit IRC (Read error: Connection reset by peer)19:53
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:27fc:a530:7097:2c60> has joined #yocto19:54
RPmoto-timo: you're handling the selftest maintainer issues? so I can sort out my tweaks in -next and post them and between us we should be good for a better test run?20:01
moto-timoRP: exactly20:01
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:27fc:a530:7097:2c60> has quit IRC (Remote host closed the connection)20:02
moto-timoRP: at this point I am creating patches on top of master-next (just waiting for build-appliance-image to finish)20:02
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:27fc:a530:7097:2c60> has joined #yocto20:02
moto-timoRP: I can send the patches now... I'm not clear if the shebang in pip-native should be #!/usr/bin/env python3 or nativepython3.20:03
RPmoto-timo: the later I think20:04
moto-timoRP: ok... I think I am starting to get it20:04
RPmichaelo: qschulz: happy to see the docs did build cleanly again :)20:08
RPmoto-timo: the way to think about it is that the tool needs to use the right python without having the pythonnative inherit20:18
moto-timoRP: and if it is -native that means nativepython320:19
RPmoto-timo: yes, and tools would normally be natives20:19
RPmoto-timo: I only realise this having spent the day arguing with it :)20:20
moto-timoRP: sadly my brain shut down on me yesterday and I'm barely recovering20:25
moto-timotoo many hours in too few days20:25
moto-timonot that I was being efficient20:25
kanavin_khem: I do not think running specific sub-gcc configure scripts, e.g. gcc-source/libgcc/configure, gcc-source/gcc-runtime/configure etc. is correct anymore. If you check the logs, you'll see they all complain about a ton of bogus options that only work with the top level configure. It's a wonder we made it this far :-/ I'll look into using the top level gcc configure in all cases.20:30
kanavin_and because we do cd {B}/libgcc first, these aren't picked up by insane :(20:31
kanavin_(insane looks only at ${B}/config.log20:31
RPkanavin_: that insane check was always a best effort, not built to handle the complex cases20:31
kanavin_RP: for gcc-arm-none-eabi I went back to how it used to be many years ago: let gcc-cross build and install libgcc as well, then change libgcc to handle only the packaging for the target20:32
RPkanavin_: yes, the work put in to stop rebuilding gcc-cross all the time was pretty pointless so it would make sense to rip it out and go back to that20:33
khemthe independent configures are done because gcc has successfully made them build independent20:34
RPkanavin_: if we're not calling the sub configures correct, we should probably look at getting the options to those correctly20:35
khemif you use top level configure, it will take us back to monolithic intertwined  checks and catch-22 situations that we did away with 3 phased gcc builds in past, but if you find it works better all ears for it20:35
kanavin_khem, except it hasn't - if you check you'll see I have to pass some options to top level configure for the sake of building libgcc correctly, that libgcc-specific configure is not recognizing :-/20:36
kanavin_RP: sub-configures are all receiving what is defined here:
khemI guess it will be fine to take a bit of hit to accomodate them if they dont have side effects20:38
kanavin_those are for the top level configure only20:39
RPkanavin_: So great, you found a bug. It is susprising it works but it hasn't seemed to do too badly over the last few years20:39
RPkanavin_: I understand the problem but I'm going to get annoyed if you keep just telling me how broken it all is. You have no idea the work it was to actually get some of this stuff to this point where it does work for most of the current use cases20:40
RPI'd actually love to get back and continue to improve that but instead I get to do other things20:43
*** rsalveti <rsalveti!> has quit IRC (Quit: Connection closed for inactivity)20:43
RPkanavin_: and just to be clear, it isn't actually the same configure options that are passed to top level gcc-cross build, they are different since one is a cross recipe and one is a target recipe. I agree there are some extra options which are passed and which are ignored20:47
RPkanavin_: passing target flags in a cross recipe is actually a big problem and shouldn't be done20:48
RPbut you'll probably find that out later :/20:48
*** florian_kc <florian_kc!> has joined #yocto20:55
*** bluelightning <bluelightning!~paul@2406:e003:151f:d701:25db:74c9:2689:f07d> has joined #yocto20:55
*** kevinrowland <kevinrowland!~kevinrowl@> has quit IRC (Quit: Client closed)21:02
*** osama4 <osama4!> has joined #yocto21:02
bluelightningJPEW: could you please take a look at ? let us know if there's anything further we should do21:03
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto21:03
*** osama <osama!> has joined #yocto21:04
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 240 seconds)21:05
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 272 seconds)21:07
*** osama4 <osama4!> has quit IRC (Ping timeout: 272 seconds)21:07
JPEWbluelightning: ya. AFK right now, will look later21:17
*** GillesM <GillesM!> has quit IRC (Quit: Leaving)21:36
*** mauro_anjo <mauro_anjo!~quassel@> has quit IRC (Ping timeout: 272 seconds)21:39
*** kevinrowland <kevinrowland!~kevinrowl@> has joined #yocto21:47
*** prabhakarlad <prabhakarlad!> has joined #yocto21:59
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection)22:00
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto22:00
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto22:03
RPmoto-timo: if you have those patches I think it might be good to get them into next22:04
moto-timoRP: I just fixed the syntax...22:05
*** ecdhe_ <ecdhe_!~ecdhe@user/ecdhe> has joined #yocto22:06
moto-timoRP: sent... this is assuming on top of master-next22:09
*** wooosaiii <wooosaiii!> has joined #yocto22:09
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Ping timeout: 272 seconds)22:09
*** wooosaiiii <wooosaiiii!> has quit IRC (Ping timeout: 256 seconds)22:10
*** wooosaii <wooosaii!> has quit IRC (Ping timeout: 256 seconds)22:10
*** wooosaiiii <wooosaiiii!> has joined #yocto22:10
*** rsalveti <rsalveti!> has joined #yocto22:16
moto-timoRP: so your --ignore-installed needs to be there22:18
*** osama1 <osama1!> has joined #yocto22:19
*** osama <osama!> has quit IRC (Read error: Connection reset by peer)22:19
*** dvorkindmitry <dvorkindmitry!~dv@> has joined #yocto22:28
RPmoto-timo: thanks22:29
moto-timoRP: let me know if there are any problems in merging... I hope it's ok22:29
RPmoto-timo: you copied that crazy exec header for pip :)22:29
* moto-timo might be a bit tired still22:29
moto-timoRP: thats what I was seeing so... yep22:30
dvorkindmitryhow can I build all qt5 libs as DEPENDS for image for later installation from my repo?22:30
moto-timoRP: I decided to just pretend I was pip22:31
dvorkindmitryis there a line I can write in my file?22:32
RPmoto-timo: fair enough. I've started a build22:33
dvorkindmitryi know about meta-qt5, it looks like I have to write all qt modules one by one in DEPENDS += ""...22:35
moto-timoyou could probably leverage bitbake-layers show-recipes -l meta-qt5 somehow to script that generation into a packagegroup22:44
dvorkindmitrythere are packagegroup with all modules enumerated in qt layer, but they are listed in RDEPEND_ variable22:47
dvorkindmitryhow can I make it "DEPEND" with only one line?22:48
JaMathe list of recipes won't probably change for dead-end meta-qt5, so just list them in DEPENDS manually22:48
moto-timounfortunately, meta-qt6 doesn't follow oe branch naming so it is not in layer index22:50
JaManot sure what is worse, with meta-qt5 I was following the naming and lucklily the release cadence of OE and QT matches, so there is separate branch for each Qt release, but then people are mixing different branches due to that (e.g. using 5.12 from meta-qt5/warrior with dunfell build and so on)22:53
*** osama1 <osama1!> has quit IRC (Ping timeout: 240 seconds)22:53
JaManow with incompatible metadata changes it gets a lot worse from this perspective (so I have jansa/warrior-overrides branch as well to be usable with honister and newer)22:54
JaMabut not going to support every sensible combination of Qt version / yocto release22:54
RPI am worried about how this renaming will work out22:56
JaMaluckily I'm no longer maintaining meta-ros :)23:01
JaMabut compared to overrides syntax, it's at least relatively limited at least in layers I care about23:01
JaMabut with meta-qt6 e.g. 6.2 branch I was able to get overrides syntax change merged (and support for zeus dropped) while with variable renames they would probably need to add some 6.2-kirkstone branch (and who knows how well they will keep it in sync with 6.2)23:04
JaMaor not as only + LAYERSERIES_COMPAT was needed to build it with kirkstone23:05
JaMabut if not-spdx license identifiers are turned to warning soon (even after kirkstone is released) than maybe we should backport all necessary mappings to dunfell (iirc something was missing when I run the conversion script on dunfell branch)23:08
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC (Quit: Leaving)23:09
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 240 seconds)23:11
RPJaMa: I think those changes might not be easily backported to dunfell as it was the "+" handling23:13
RP(vs -or-later)23:14
*** mvlad <mvlad!~mvlad@2a02:2f08:4b12:b100:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)23:16
khemkirkstone would mean new ports mostly, its how it is turning out for RDK,23:16
khemscripts are helping but people have done some really innovative stuff internally23:17
*** lettucepunch[m] <lettucepunch[m]!~lettucepu@2001:470:69fc:105::1:c900> has joined #yocto23:17
RPkhem: I dread to think :)23:17
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto23:23
JaMaRP: ah :/23:25
*** ar__ <ar__!~akiCA@user/akica> has quit IRC (Ping timeout: 272 seconds)23:29
*** florian_kc <florian_kc!> has joined #yocto23:36
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Remote host closed the connection)23:36
*** ldericher <ldericher!> has quit IRC (Quit: ZNC 1.8.2 -
*** ldericher <ldericher!> has joined #yocto23:43
RPThere is a downside to the renames where once renamed, new bitbake is happy but the older layers can silently break if you still claim compatibility with them23:47
RPi.e. we don't detect the new names in the old bitbake23:48
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)23:55

Generated by 2.17.2 by Marius Gedminas - find it at!