Thursday, 2022-03-24

*** steev_ <steev_!> has quit IRC (Quit: leaving)00:17
*** camus <camus!~Instantbi@> has joined #yocto00:57
*** geoffhp <geoffhp!> has joined #yocto01:00
*** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Ping timeout: 260 seconds)01:01
geoffhpSince the libtool upgrade on master to 2.4.8 my builds fail building polkit with the "libtool: Version mismatch error.  This is libtool 2.4.7, but the01:07
geoffhp..." error. I see Khem's patches to fix this error on various other package on the oe-devel mailing list. The strange thing is if I explicitly run do_configiure in devshell or with bitbake -c configure, the do_compile will work.  However, if I do a standard 'bitbake polkit' from a clean state, I hit the libtool mismatch error although I see the do_compile step scroll by in bitbake. Any idea on why I can work-around by manually invoking01:07
geoffhp -c configure?01:07
*** shoragan <shoragan!~shoragan@user/shoragan> has joined #yocto01:12
*** jclsn <jclsn!> has quit IRC (Ping timeout: 245 seconds)01:14
*** jclsn <jclsn!> has joined #yocto01:20
*** jclsn <jclsn!> has quit IRC (Ping timeout: 256 seconds)01:26
*** jclsn <jclsn!> has joined #yocto01:32
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)01:40
*** jclsn <jclsn!> has quit IRC (Ping timeout: 260 seconds)01:41
*** otavio <otavio!> has quit IRC (Ping timeout: 250 seconds)01:45
*** jclsn <jclsn!> has joined #yocto01:46
*** otavio <otavio!> has joined #yocto01:47
*** jclsn <jclsn!> has quit IRC (Ping timeout: 260 seconds)01:51
*** jclsn <jclsn!> has joined #yocto01:56
*** jclsn <jclsn!> has quit IRC (Ping timeout: 256 seconds)02:03
*** otavio <otavio!> has quit IRC (Ping timeout: 240 seconds)02:07
*** jclsn <jclsn!> has joined #yocto02:09
*** otavio <otavio!> has joined #yocto02:09
*** starblue <starblue!> has quit IRC (Ping timeout: 256 seconds)02:13
*** otavio <otavio!> has quit IRC (Ping timeout: 240 seconds)02:13
*** starblue <starblue!> has joined #yocto02:15
*** jclsn <jclsn!> has quit IRC (Ping timeout: 240 seconds)02:18
*** camus <camus!~Instantbi@> has quit IRC (Read error: Connection reset by peer)02:18
*** camus <camus!~Instantbi@> has joined #yocto02:18
*** jclsn <jclsn!> has joined #yocto02:19
*** otavio <otavio!> has joined #yocto02:21
*** rber|res <rber|res!~rber|> has joined #yocto02:32
*** jclsn <jclsn!> has quit IRC (Ping timeout: 272 seconds)02:32
*** RobertBerger <RobertBerger!~rber|> has quit IRC (Ping timeout: 256 seconds)02:34
*** jclsn <jclsn!> has joined #yocto02:38
*** jclsn <jclsn!> has quit IRC (Ping timeout: 256 seconds)02:44
*** jclsn <jclsn!> has joined #yocto02:51
*** jclsn <jclsn!> has quit IRC (Ping timeout: 272 seconds)02:59
*** jclsn <jclsn!> has joined #yocto03:04
*** jclsn <jclsn!> has quit IRC (Ping timeout: 260 seconds)03:09
*** jclsn <jclsn!> has joined #yocto03:14
*** jclsn <jclsn!> has quit IRC (Ping timeout: 260 seconds)03:27
*** jclsn <jclsn!> has joined #yocto03:33
*** jclsn <jclsn!> has quit IRC (Ping timeout: 240 seconds)03:37
*** jclsn <jclsn!> has joined #yocto03:44
*** jclsn <jclsn!> has quit IRC (Ping timeout: 272 seconds)03:56
*** jclsn <jclsn!> has joined #yocto04:01
*** jclsn <jclsn!> has quit IRC (Ping timeout: 272 seconds)04:06
*** jclsn <jclsn!> has joined #yocto04:12
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)04:33
*** amitk <amitk!~amit@> has joined #yocto04:41
geoffhps/libtool 2.4.8/libtool 2.4.7/04:41
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Quit: ZNC 1.8.2 -
*** alessioigor <alessioigor!~alessioig@> has joined #yocto05:52
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Client Quit)05:52
*** Wouter0100 <Wouter0100!> has quit IRC (Read error: Connection reset by peer)06:22
*** Wouter0100 <Wouter0100!> has joined #yocto06:22
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 240 seconds)06:45
*** rob_w <rob_w!~bob@2001:a61:60c9:601:b069:2ef:f9f0:60f9> has joined #yocto07:00
*** rob_w <rob_w!~bob@2001:a61:60c9:601:b069:2ef:f9f0:60f9> has quit IRC (Client Quit)07:01
*** rob_w <rob_w!~rob@2001:a61:60c9:601:3cd9:66a2:5d99:5dc1> has joined #yocto07:01
*** frieder <frieder!> has joined #yocto07:09
*** lucaceresoli_ <lucaceresoli_!~lucaceres@> has joined #yocto07:17
RPgeoffhp: seems odd but I guess something in the first run does eventually clean up the files, just too late to avoid the mismatch? The second run then works. It has to be a second run as the script wouldn't exist otherwise?07:40
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto07:44
*** kroon <kroon!> has joined #yocto07:47
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 252 seconds)07:48
*** mckoan|away is now known as mckoan07:49
mckoangood morning07:49
hmw[m]good mornig07:49
*** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has joined #yocto07:50
*** camus <camus!~Instantbi@> has joined #yocto07:52
*** wyre <wyre!~wyre@user/wyre> has quit IRC (Quit: ZNC 1.8.2 -
*** florian <florian!> has joined #yocto07:53
*** wyre <wyre!~wyre@user/wyre> has joined #yocto07:55
*** florian <florian!> has quit IRC (Ping timeout: 260 seconds)08:01
*** florian <florian!> has joined #yocto08:02
*** florian <florian!> has quit IRC (Ping timeout: 260 seconds)08:07
*** rfuentess <rfuentess!> has joined #yocto08:10
qschulzjsbronder: nope, tags aren't reproducible because they can be moved. Been there, done that. Only reproducible way is to point to a commit hash08:12
qschulzwhich is via SRCREV:
*** dev1990 <dev1990!> has quit IRC (Quit: Konversation terminated!)08:27
*** prabhakarlad <prabhakarlad!> has joined #yocto08:38
LetoThe2ndyo dudX08:45
*** camus <camus!~Instantbi@> has quit IRC (Remote host closed the connection)08:52
mckoanhey LetoThe2nd08:52
*** camus <camus!~Instantbi@> has joined #yocto08:53
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 240 seconds)08:57
*** camus <camus!~Instantbi@> has joined #yocto09:01
hmw[m]when i try to run this code (full message at
*** florian <florian!> has joined #yocto09:08
hmw[m]what can i do next to determine the problem ?09:18
hmw[m]*the required PACKAGECONFIG:append = "sql-mysql"09:19
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:ed18:1e9b:ba56:6e33> has joined #yocto09:19
*** Schiller <Schiller!> has joined #yocto09:21
qschulzhmw[m]: you need a leading space in your PACKAGECONFIG:append09:24
qschulz(before sql-mysql)09:24
qschulzbut since the file makes it, it's likely not the issue (but it can be one, so better fix it :) )09:25
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto09:26
hmw[m]qschulz: it is from a larger string ( PACKAGECONFIG:append = " accessibility libinput sql-sqlite mtdev sql-mysql dbus xkbcommon" )09:26
*** mcfrisk <mcfrisk!> has joined #yocto09:30
mcfriskI hope others can also test the polkit switch from mozjs to duktape. my tests on one product CI look good.09:32
*** lucaceresoli_ <lucaceresoli_!~lucaceres@> has quit IRC (Quit: Leaving)09:48
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto09:48
wyrehi guys, I've included `apt` in IMAGE_INSTALL but ... I've not available apt command by just doing this 🤔10:07
wyreis it maybe another different recipe? 🤔10:07
wyreI just have apt-get, maybe this is enough10:07
qschulzwyre: what are you plannign to do with apt?10:09
SchillerIs it possible to run a full build in the YPAutobuilder without setting up a Hash Equivalency Server or do i have to provide a local one? My workers fail currently to connect to  and it just hangs.10:09
RPSchiller: just don't configure one10:11
wyreqschulz, well, I'd like to make modular updates, I mean ... I'd like to retrieve the debs after the bitbake building process and include them into an apt reposotory10:11
wyreis this possible/good idea? or should I reflash the whole image everytime I make updates?10:11
LetoThe2ndwyre: it "depends"10:12
wyrewell, I guess there must be described a proper workflow to do this in the doco, right? 🤔10:13
LetoThe2ndwyre: first things first: "apt" is just the fancy new form of apt-get. if you want to use deb-style package repositories, then apt-get will be perfectly enough. secondly, this is actually only somewhat useful during the development stage. you probably don't want the users of your device to type apt commands into a terminal if you want them to get updates.10:15
LetoThe2ndwyre: so in a nutshell - it can be helpful, but only in very limited situations. usually you're much better off understanding your usecase properly first, and then picking an update solution.10:16
SchillerRP: Do you mean i can just throw the BB_HASHSERVE variable in the config.json out? Btw tasks in the created json file get now worked on. I die setup a new OS and started everything from scratch.10:16
qschulzwyre: I've always ever reflashed the whole thing and package updates seem to be a complex beast to me10:17
RPSchiller: just set it to empty, turn it off10:17
LetoThe2ndqschulz: ++10:17
RPSchiller: was that with the latest buildbot or an older version? Glad you have it working though!10:17
qschulzwyre: if you need package updates for basically "rolling releases", think also if debian or the likes aren't more suitable to you?10:18
qschulzas LetoThe2nd said "it depends"10:18
RPwyre: It is documented somewhere I think and there are basic QA tests for it however getting the packages onto an http service and having your image able to find it can be annoying10:18
pasherringwyre, and maybe, during this first "discovery stage" (if this is where you are), it might be useful just running qemu10:18
LetoThe2ndfull disclosure: there are companies who offer solutions for tackling this kind of problem and I work for one - mender.io10:19
SchillerRP currently i am on the Buildbotversion you suggested. But it's hard to tell what the problem was before as i was running Linux Mint and now changed it to Ubuntu 18.04 which i will end up running in the Docker then10:21
*** alessioigor <alessioigor!~alessioig@> has joined #yocto10:22
wyreI see, thank you very much guys 😊 I'm going to check the links you pasted, hehe10:23
*** wyre <wyre!~wyre@user/wyre> has quit IRC (Quit: ZNC 1.8.2 -
*** wyre <wyre!~wyre@user/wyre> has joined #yocto10:25
RPSchiller: ok, just a useful data point for me when we upgrade10:25
SchillerRP: There are some dependencies involved when turning off the BB_HASHSERVE. Currently OEEquivHash says it requires it to be set. Is it safe to throw everything regarding to the HASHSERV to empty?10:29
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)10:30
kayterina[m]Hello. Why can't I extract a tar from $B inside the do_install() task? It fails at do_package in exec_python_func(). I know it works if I untar in $B during a do_unpack_append.... (full message at
RPSchiller: sorry, you need to set BB_SIGNATURE_HANDLER = "OEBasicHash" too10:37
qschulzkayterina[m]: the error message would be helpful :)10:43
hmw[m]what is the best way to debug qsql ?10:49
kayterina[m]qschulz: hm,where to upload it? there was a page I would paste the message cannot remember it now.10:51
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto10:52
rburtonkayterina[m]: pastebin.com10:54
*** starblue <starblue!> has quit IRC (Ping timeout: 252 seconds)10:54
rburtonchown the files to root.root10:54
*** starblue <starblue!> has joined #yocto10:56
kayterina[m]The tar.gz is downloaded from git. chown root the tar.gz and then push it to remote?10:58
rburtonno, chown the contents.  why can't you unpack it in the usual way, with an entry in SRC_URI?11:00
rburtonbut basically the tarball contains files with uid 100011:01
rburtonwhich doesn't exist in the target system11:01
rburtonso you need to chown it11:02
rburtonafter you've unpacked, chown to root or whatever user is appropriate11:02
Alban[m]It seems some variable dependency is missing here: It modify ${PACKAGES} when ${PACKAGEGROUP_DISABLE_COMPLEMENTARY} is 1 using ${DISTRO_FEATURES}. In a case like this should it just add both variables to the dependency list, or add DISTRO_FEATURES only when it is actually used?11:02
kayterina[m]SRC_URI has the remote git and inside it there are some files and a tar archive. Can it be extracted with SRC_URI?11:04
rburtonkayterina[m]: ah no the big problem is you're doing this in do_install which is fakeroot, so tar behaves differently.11:04
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)11:04
rburtonif root, tar preserves ownership.11:04
rburtoni'd do the unpack in a do_unpack[postfuncs]11:05
rburtonso all the unpacking happens in the unpack task11:05
qschulzAlban[m]: I'm sorry, I didn't get the question/suggestion, can you rephrase please?11:05
*** xmn <xmn!> has quit IRC (Ping timeout: 240 seconds)11:07
Alban[m]This anonymous function changes the content of ${PACKAGE} when ptest is in the DISTRO_FEATURES, but this is not properly tracked by the dependency system. PACKAGEGROUP_DISABLE_COMPLEMENTARY and DISTRO_FEATURES should be PACKAGEVARS to be correctly tracked.11:08
kayterina[m]rburton: a,fakeroot...ok thanks. That was the question really, why it did not work during do_install.11:08
kayterina[m]is do_unpack[postfuncs] equivalent to a do_extract task that is appended in do_unpack_append() ?11:08
rburtonyes, but not uglty11:08
SchillerRP: I still get some Errors. Can you confirm i edited the necessary lines correctly. In yocto-auto-helper/config.json Line: 63 "BB_HASHSERVE = ' '", Line: 243 "BB_SIGNATURE_HANDLER = 'OEBasicHash'"11:09
Alban[m]But DISTRO_FEATURE only matter when PACKAGEGROUP_DISABLE_COMPLEMENTARY has a specific value. What I'm wondering is how this should be represented correctly.11:09
RPSchiller: what error do you see? Perhaps just remove the BB_HASHSERV line entirely?11:15
SchillerRP in local.json there are multiple BB_HASHSERVE variables. Should i empty them all? Some are set to 'auto'. I just edited the Lines 63 and 243.11:27
RPSchiller: replace the line on 63 with the BB_SIGNATURE_HANDLER = 'OEBasicHash' setting11:29
SchillerRP and line 243 should remain as "BB_SIGNATURE_HANDLER = 'OEEquivHash'" or also beeing edited to BB_SIGNATURE_HANDLER = 'OEBasicHash'11:31
*** mihai <mihai!~mihai@user/mihai> has joined #yocto11:36
*** selff <selff!~selff@> has joined #yocto11:37
RPSchiller: I doubt you're running the qemuarm-oecore target so it probably doesn't matter11:38
SchillerRP: Seems to be building fine. Thanks for all the advice.11:45
*** xmn <xmn!> has joined #yocto11:45
selffhello everyone, im running an image with openvpn in rpi4. i enabled "AUTO_SYSTEM_ENABLE" in "". i also put the existing client_vpn_test.conf file in /etc/openvpn. however, the service cannot run the config. when "openvpn@client.service" is run, it prints the following error: job for openvpn@client.service failed because the control11:46
selffprocess exited with error code.11:46
selffSee "systemctl status openvpn@client.service" and "journalctl -xe" for details.11:46
selffbut when I run it manually the vpn works.11:46
selff"openvpn --config /etc/openvpn/client_vpn_test_conf" works manually11:46
*** goliath <goliath!~goliath@user/goliath> has joined #yocto11:46
qrsBRWNanyall[m]Do you have any logs about it?11:48
qrsBRWNanyall[m]Could be a timing issue. That the OpenVPN client tries to connect to early before network is ready etc etc11:49
*** ardo <ardo!> has quit IRC (Ping timeout: 272 seconds)11:55
*** ardo <ardo!> has joined #yocto11:57
selff openvpn@client.service status  : "openvpn@client.service: Control process exited, code=exited, status=1/FAILURE"11:58
selffFailed to start OpenVPN Robust And Highly Flexible Tunneling Application On client11:58
selffwhen i check the openvpn --version . i saw "enable_systemd=no " Is it possible that the problem is caused by this?12:00
mihaiselff, try placing the config at /etc/openvpn/client.conf12:01
*** xmn <xmn!> has quit IRC (Quit: xmn)12:03
selffmihai ty, i changed my config name "self_test.conf" to "client.conf" and restart the service, problem gone.12:04
mihaigood :)12:04
selffThanks for help12:04
selffI couldn't find any information about it anywhere. I was probably searching wrong.12:05
mihaiselff, here's why12:06
selffthank you again, have a nice day everyone12:07
mihaiyou're welcome, you too12:08
*** florian_kc <florian_kc!> has joined #yocto12:09
*** selff <selff!~selff@> has quit IRC (Quit: Client closed)12:11
*** Tamis <Tamis!~Tamis@> has joined #yocto12:18
Tamishello, curl recipe on dunfel branch seems not to respect the PACKAGECONFIG option ldap, ldaps12:21
Tamisand this because12:21
TamisPACKAGECONFIG[ldap] = "--enable-ldap,--disable-ldap,"12:21
TamisPACKAGECONFIG[ldaps] = "--enable-ldaps,--disable-ldaps,"12:21
Tamisseems to missing the openldap dependency. Has anyone see that?12:21
*** dv_ <dv_!> has quit IRC (Quit: WeeChat 2.8)12:21
TamisOnly after I corrected the PACKAGECONFIG with the openldap dependency I was able to see:12:24
TamisLDAP support:     enabled (OpenLDAP)12:24
TamisLDAPS support:    enabled12:24
Tamison curl configuration12:24
TamisShouldn't this be corrected on recipes?12:24
*** sstiller <sstiller!> has joined #yocto12:24
*** wmat[m] <wmat[m]!~wmatmatri@2001:470:69fc:105::1:38e6> has left #yocto12:25
qrsBRWNanyall[m] next time. Make sure you check journalctl too. It will show in plain text that it can't open the config file or something similar12:26
*** mak <mak!~mak@> has joined #yocto12:29
*** mak <mak!~mak@> has quit IRC (Client Quit)12:29
rburtonTamis: guess so, yes.  send a patch?12:34
qschulzTamis: master branch also does not have it so send a patch to be applied against master first12:34
MrSaturnIs there a way to determine where kernel configuration fragements exist either within the regular bitbake environment, or when using devtool?12:51
mihaiMrSaturn, you can find available config fragments in the kernel-meta directory, in the linux-yocto work dir12:58
mihairemote is here
MrSaturnso something like this should work for applying patches? I am only asking, because to test it is a rather lengthy process:13:00
MrSaturndo_configure_append() { cat ${B}/kernel-meta/*.cfg >> ${B}/.config13:01
qschulzMrSaturn: just add your cfg file to SRC_URI of your kernel recipe13:07
Tamisrburton: yeah I will do so.13:08
MrSaturnThe base class will know the files ending in .cfg are to be applied to the .config file? and .patch files patch source? Alright, I will give that a shot. Fragments are _way_ more confusing to me than patches13:09
rburtonjust write your own fragment that does the assignments you want13:13
mihaiMrSaturn, yes, write a .cfg file and add it to SRC_URI and the class will know what to do, same with .patch13:18
MrSaturnmihai: I did that, and when I ran "devtool modify virtual/kernel" the source in the workspace does not have the .cfg fragments applied. The fragment files are visible in a directory called "oe-local-files"13:21
qschulzMrSaturn: devtool modify only patches the source files, but config fragments are applied before do_compile is run13:25
qschulzat least that's my quick reading of kernel-yocto.bbclass13:25
qschulzso it's normal, just too early in the process13:25
qschulzdo_kernel_configme seems to be the task that needs to run to configure the config13:26
*** mak_gr <mak_gr!~mak_gr@> has joined #yocto13:29
*** pgowda_ <pgowda_!> has joined #yocto13:33
RPJPEW: do you happen to be around? or still away? Had a question about asyncio13:37
MrSaturnqschulz: thanks, I will try that out. I was trying to parse through the class file and getting lost.13:37
* RP is just wondering whether the hash equivalence siggen client code needs to call .close() and since it doesn't do that (as far as I can tell), would that cause bitbake to hang at exit?13:38
JPEWRP: Ya, I'm here13:46
JPEWRP: Where is it not calling close() ?13:47
RPJPEW: the client() inside ?13:48
*** sakoman <sakoman!> has joined #yocto13:49
RPJPEW: I'm wondering why shows an asyncio thread hanging around13:49
JPEWRP: Ya, possibly. Is there a defined way to know when bitbake is "done" ?13:51
RPJPEW: we'd have to add something, the way siggen is hooked in right now is horrible13:51
RPJPEW: I'm just not clear if the lack of a close() call could intermittently lock up the server exit?13:52
JPEWRP: That seems the most likely culprit for the warning, given it's one of the few places we use asyncio13:52
JPEWNot sure about if that can cause the lockup, but it should probably be fixed either way13:52
RPJPEW: the warning may or may not be a problem, it was just a possible lead13:53
RPbut yes, perhaps better to fix anyway13:53
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC (Quit: Leaving)13:57
*** lucaceresoli_ <lucaceresoli_!~lucaceres@> has joined #yocto14:02
*** lucaceresoli_ <lucaceresoli_!~lucaceres@> has quit IRC (Client Quit)14:03
*** jclsn <jclsn!> has quit IRC (Quit: Ping timeout (120 seconds))14:06
*** jclsn <jclsn!> has joined #yocto14:06
*** Schiller <Schiller!> has quit IRC (Quit: Client closed)14:08
kayterina[m]when PV is set inside a to this value14:10
kayterina[m]PV = "1.0+git${SRCPV}14:10
kayterina[m]where does it help? To not rename the .bb file version on every new commit to the source?14:10
qschulzkayterina[m]: this is usually used with AUTOREV14:10
qschulzand yes, it's to have a workdir specific to this version (and probably also make this work with package managers when trying to install packages from different commit hashes)14:11
kayterina[m]I have a project where many(perhaps all) files have set SRCREV to a revision and also set PV.14:12
kayterina[m]so this is a valid set of the variables in a .bb? SRCREV = "${AUTOREV}" PV = "1.0+git${SRCPV}"14:13
qschulzkayterina[m]: yes but not recommended14:15
qschulzas this means you never have reproducible builds14:15
qschulzok for development14:15
qschulzdefinitely not okay for releases14:15
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 260 seconds)14:28
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto14:29
*** amitk <amitk!~amit@> has joined #yocto14:29
*** akiCA <akiCA!~akiCA@user/akica> has joined #yocto14:32
*** sstiller <sstiller!> has quit IRC (Quit: Leaving)14:35
LetoThe2ndwhats the best practise to patch something in a git submodule that is being pulled in by a recipe?14:37
*** Wouter0100 <Wouter0100!> has quit IRC (Read error: Connection reset by peer)14:37
*** Wouter0100 <Wouter0100!> has joined #yocto14:37
qschulzLetoThe2nd: are you using gitsm fetcher inm SRC_URI?14:38
LetoThe2ndqschulz: nope, go magic is involved :(14:39
LetoThe2ndit would be enough to patch the resulting state, but git add doesn't pick it up because of the submodules.14:40
*** mak_gr <mak_gr!~mak_gr@> has quit IRC (Quit: Client closed)14:42
jsbronderqschulz: Regarding tags, sure, they can be moved.  And we do point to the annotated commit sha in our recipes.  Luckily my org isn't so nuts as to move or delete tags.  Shas can disappear too if you want to be truly paranoid ;)14:43
*** RobertBerger <RobertBerger!~rber|res@> has joined #yocto14:45
qschulzjsbronder: that's fine, tags moving, less. Because then you'll be building something you weren't expecting and you will not know about it14:45
*** rber|res <rber|res!~rber|> has quit IRC (Ping timeout: 252 seconds)14:46
qschulzjsbronder: sha disappearing should be handled by your org with a mirror14:46
jsbronderI took steev_'s question to only be regarding internal apps.14:50
jsbrondergit will eventually delete any unreachable objects, even on a mirror.14:52
jsbronderanyways, I think we agree vigorously, point at the sha of a tag.14:53
qschulzjsbronder: you can deactivate git gc :) but in any case, you can host a PREMIRROS on your premises which will save whatever's needed by bitbake to build your package14:54
*** Guest8 <Guest8!~Guest8@> has joined #yocto14:54
qschulzbut yes, we agree :)14:54
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 240 seconds)14:59
Guest8bitbake question.  I'm trying to override a config file.  My local .bbappend contains "FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:".     However I have another layer I'm inheriting that also tries to override this file using it's on bbappend and FILESEXTRAPATHS_prepend.       I added a do_install_append() to my .bbappend and installed14:59
Guest8"my file" to a different path and sure enough it actually installs the file from the other inherited layer.   I've altered the priority of my layer in my .conf to be lower than this inherited layer and it makes no diff.   What is the solution?     Also, I ran bitbake -e but FILESPATH (which I thought was generated from all the14:59
Guest8FILESEXTRAPATHS_prepend and overrides) in the output doesn't contain either my directory or the inherited directory which seems odd.14:59
*** amitk <amitk!~amit@> has joined #yocto15:00
qschulzGuest8: ${WORKDIR}/temp/log.do_fetch will tell you which paths and in which order are traversed to find your file15:03
qschulztypically, if the path relative to FILESEXTRAPATH entry is not the same, whatever the priority is won't matter15:04
qschulzspecifically, one can use OVERRIDES in file paths without specifying the OVERRIDE in SRC_URI15:04
qschulzGuest8: which version of Yocto are you using?15:05
qschulzmight also be that it should be FILESEXTRAPATHS:prepend actually15:06
qschulzGuest8: starting slide 7215:06
qschulzactually.. slide 7015:06
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)15:08
*** kroon <kroon!> has quit IRC (Quit: Leaving)15:08
landgrafHas triage meeting been moved? o_O15:09
Guest8qschulz 1.46.0  bitbake15:09
qschulzGuest8: ok, so _append should work just fine15:10
Guest8so I just invoke ${WORKDIR}/temp/log.do_fetch  in my append() rule?15:10
qschulzGuest8: no no no, it's a log file, it'll just tell you which files are fetched and from where15:10
landgrafoh. summer time :-/15:13
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto15:15
rfs613qschulz: you know, when it takes a 75+ page slide deck to "demystify" a concept, that says something about the concept ;-)15:17
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)15:17
sgwMorning all15:18
qschulzrfs613: I wrote the slides in such a way that it isn't necessary to listen to me for 30min :)15:18
sgwWell I think I found a silent failure: NOTE: Command '['depmodwrapper', '-a', '-b', '/srv/nvme/yocto/poky/builds/dbg/tmp/work/genericx86_64-poky-linux/core-image-full-cmdline/1.0-r0/rootfs', '5.15.22-yocto-standard']' returned -11:15:18
qschulzso it's a bit more verbose than usual15:18
rfs613qschulz: I do appreciate the slide deck, have referred to it several times (and probably more to come).15:19
sgwdigging deeper into rootfs construction15:19
rfs613I do wonder if all these special cases are really needed, could we not simplify and get rid of most of them? I'm sure it's been discussed... and it would be a mega project, more complex than the recent override syntax change.15:20
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto15:21
*** mihai <mihai!~mihai@user/mihai> has left #yocto (Leaving)15:23
qschulzrfs613: each special case actually has its usecase so it's difficult to just say to remove them. I don't think anything is not up for debate, just need to formulate something and offer some implementation or suggestion15:24
qschulzthere are complex and confusing areas in YP/Bitbake for sure15:24
qschulzthe _ override syntax was one15:24
*** mihai <mihai!~mihai@user/mihai> has joined #yocto15:24
*** mnme <mnme!> has joined #yocto15:24
*** prabhakarlad <prabhakarlad!> has joined #yocto15:25
mnmeHi all! Is anyone else experiencing very slow download speeds from
rfs613mnme: it's been reported a few times in the past days...15:30
*** Guest8 <Guest8!~Guest8@> has quit IRC (Quit: Connection closed)15:30
sgwRP: so it looks like depmodwrapper has been failing silently in master, not sure for how long15:31
* sgw hates finding hidden issues15:31
mnmerfs613: Okay, so it's not a problem on my end, that's good to know15:34
mnmeI currently have a per-branch download directory on my build server. Could using a single download directory with concurrent builds lead to problems? (I'm still on dunfell)15:36
qschulzit's actually recommended to share them15:38
qschulzsame for SSTATE_DIR15:38
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)15:40
mnmePerfect, thanks. I knew about sstate being fine to share (I think there was even some conversation about it in the mailing list recently), but wasn't sure for the downloads15:45
RPsgw: ah. We need better tests too :/15:47
sgwYeah, I will try to address that also, first I need to figure out what's broken15:47
sgwIn Master: ResourceWarning: Enable tracemalloc to get the object allocation traceback15:48
*** frieder <frieder!> has quit IRC (Remote host closed the connection)15:50
khemgeoffhp: I think key is to regenerate aclocal.m415:51
khembefore running further tasks15:51
smurraykhem: I'm also seeing polkit failing here with libtool version errors, nuking the libtool m4 files from its buildutil dir seemed to work.  I guess your test builds aren't seeing it fail, though?16:00
rfs613mnme: I build on dunfell with a single download directory shared by multiple concurrent builds. Mostly works fine. Had some hiccups with cve-check (seems to be resolved for me now) and also with some local packages that make use of MIRRORs feature. No issues for any of the regular poky/meta-oe/etc recipes.16:01
mnmerfs613: Thanks for confirming. I'll use a shared directory and see if anything breaks.16:15
khemsmurray: yoe distro does not use pollkit16:15
*** mnme <mnme!> has quit IRC (Quit: Client closed)16:15
*** mnme <mnme!> has joined #yocto16:16
smurraykhem: it gets pulled into the AGL demo image these days.  I'll send a patch in a bit16:16
smurraykhem: speaking of kits, I noticed recently when I went to try an experiment with it that rtkit isn't in meta-oe, do you see any value to carrying it there?16:18
*** pgowda_ <pgowda_!> has quit IRC (Quit: Connection closed for inactivity)16:21
*** mnme <mnme!> has quit IRC (Quit: Client closed)16:24
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)16:32
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto16:33
*** Tamis <Tamis!~Tamis@> has quit IRC (Quit: Client closed)16:40
*** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto16:42
khemyes it could be16:46
khemthanks for a patch16:46
*** bantu <bantu!> has quit IRC (Quit: bantu)16:48
*** Tokamak_ <Tokamak_!~Tokamak@> has joined #yocto16:48
*** bantu <bantu!> has joined #yocto16:49
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)16:49
smurraykhem: my interest was for using it with pipewire, but the newest versions of that have some code to poke the rt prio directly if it is run as a system service (which we currently do in AGL)16:54
smurraykhem: I'll think about shifting rtkit, the recipe I found in the layer index did seem to work fine.  I have to afk for a bit, will send a patch for polkit when I get back16:55
*** florian <florian!> has quit IRC (Quit: Ex-Chat)16:56
*** akiCA <akiCA!~akiCA@user/akica> has quit IRC (Ping timeout: 240 seconds)16:57
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 256 seconds)16:59
*** rfuentess <rfuentess!> has quit IRC (Remote host closed the connection)17:06
*** kevinrowland <kevinrowland!~kevinrowl@> has joined #yocto17:22
*** mckoan is now known as mckoan|away17:30
*** dev1990 <dev1990!> has joined #yocto17:30
*** akiCA <akiCA!~akiCA@user/akica> has joined #yocto17:49
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 252 seconds)17:49
dirtyflaghi, getting this error:  ERROR: Nothing RPROVIDES 'nativesdk-qtcreator-mel'  but is in the layer17:55
LetoThe2nddirtyflag: does the recipe actually provide native?17:58
dirtyflagLetoThe2nd: seems not17:59
dirtyflagLetoThe2nd: thanks a lot18:00
LetoThe2nddirtyflag: have fun!18:00
geoffhpRP:, khem:, smurray: Thanks for the reponse re polkit libtool upgrade. Looking forwared to the patch18:02
vvnthe /dev/root device in the default wic fstab is only there as info, right? you might symlink your root device to /dev/root if you want this line to be applied but that's not the default behavior, correct?18:19
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:ed18:1e9b:ba56:6e33> has quit IRC (Quit: Leaving)18:23
*** unknown__ <unknown__!> has joined #yocto18:33
*** creich_ <creich_!> has quit IRC (Ping timeout: 256 seconds)18:35
Alban[m]I have been investigating a bug with package groups which seems quiet subtle. I submitted  a related patch today [] which is not really correct and it turned out later that it doesn't solve the problem. If someone has any idea here is the flow:... (full message at
Alban[m]I give up for today, but if someone has idea where I could look at that would be appreciated.18:49
*** behanw <behanw!> has joined #yocto18:55
*** kevinrowland <kevinrowland!~kevinrowl@> has quit IRC (Quit: Client closed)19:10
khemRP: where do we document minimum python version ?19:12
*** Tokamak_ <Tokamak_!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)19:39
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto19:44
*** kevinrowland <kevinrowland!~kevinrowl@> has joined #yocto20:09
*** florian_kc <florian_kc!~florian@> has joined #yocto20:10
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)20:11
*** behanw_ <behanw_!> has joined #yocto20:15
*** codavi <codavi!~akiCA@user/akica> has joined #yocto20:16
*** behanw <behanw!> has quit IRC (Ping timeout: 260 seconds)20:16
*** behanw_ is now known as behanw20:16
jonmasonRP: any idea what to do with ?  Is that another network issue, similar to Bug 14706?  Or should I open a unique bug to track it?20:18
*** ar__ <ar__!~akiCA@user/akica> has joined #yocto20:19
*** akiCA <akiCA!~akiCA@user/akica> has quit IRC (Ping timeout: 240 seconds)20:19
*** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 256 seconds)20:21
*** bantu <bantu!> has quit IRC (Quit: No Ping reply in 180 seconds.)20:25
*** bantu <bantu!> has joined #yocto20:25
*** kevinrowland <kevinrowland!~kevinrowl@> has quit IRC (Quit: Client closed)20:31
*** prabhakarlad <prabhakarlad!> has joined #yocto20:32
RPkhem: bitbake codes it and the manuals do mention it I think?20:34
RPjonmason: that was a really bizarre one - the same worker ran two of the same build at the same time and it broke by corrupting the layerinfo.json file20:35
RPjonmason: it isn't supposed to be possible to do that20:35
RPjonmason: probably in the ignore until happens again pile20:35
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)20:45
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection)21:09
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 240 seconds)21:09
*** GillesM <GillesM!> has joined #yocto21:18
*** rob_w <rob_w!~rob@2001:a61:60c9:601:3cd9:66a2:5d99:5dc1> has quit IRC (Read error: Connection reset by peer)21:25
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC (Ping timeout: 240 seconds)21:26
abelloniI was really wondering what happened to this one21:27
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Ping timeout: 256 seconds)21:28
RPabelloni: I don't know how it happened, just that the logs say it did :/21:29
*** mak_gr <mak_gr!~mak_gr@> has joined #yocto21:34
RPabelloni: you got the efi bug and the tinfoil one in the same build :/21:37
*** GillesM <GillesM!> has quit IRC (Quit: Leaving)21:47
*** a849572 <a849572!> has joined #yocto21:50
*** a849572 <a849572!> has quit IRC (Read error: Connection reset by peer)21:50
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto21:51
*** a849572 <a849572!> has joined #yocto21:52
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Client Quit)21:54
*** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)21:57
*** a849572 <a849572!> has left #yocto (Leaving)21:58
*** mak_gr <mak_gr!~mak_gr@> has quit IRC (Quit: Client closed)22:00
*** Guest79 <Guest79!~Guest79@2601:644:8102:f530:65e1:75ad:10c5:5957> has joined #yocto22:03
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto22:04
Guest79Is there a recipe for telegraf or influxdb ?22:05
*** GillesM <GillesM!> has joined #yocto22:11
khemGuest79: I had then in meta-influx but have not kept them uptodate22:14
khem seems to be another option22:16
*** florian_kc <florian_kc!~florian@> has quit IRC (Ping timeout: 256 seconds)22:22
*** Guest79 <Guest79!~Guest79@2601:644:8102:f530:65e1:75ad:10c5:5957> has quit IRC (Ping timeout: 256 seconds)22:35
*** ar__ <ar__!~akiCA@user/akica> has quit IRC (Ping timeout: 272 seconds)22:36
*** Guest11 <Guest11!~Guest11@> has joined #yocto22:44
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 240 seconds)22:44
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto22:44
Guest11Hey gang!22:45
Guest11I'm experiencing some slowness with this artifact22:45
Guest11Uploaded file:
Guest11Actually I don't know what to make of this23:06
Guest11There the bitbake-worker has been hung for 6 hours23:07
Guest11googling for decafbadbeef doesn't yield sensible results23:07
*** alimon <alimon!~alimon@2806:10b7:3:8b00:2c32:cfff:fe8e:de1f> has quit IRC (Ping timeout: 252 seconds)23:22
*** alimon <alimon!~alimon@> has joined #yocto23:23
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)23:41
*** dev1990 <dev1990!> has quit IRC (Quit: Konversation terminated!)23:47
*** Guest11 <Guest11!~Guest11@> has quit IRC (Quit: Connection closed)23:56

Generated by 2.17.2 by Marius Gedminas - find it at!