| *** steev_ <steev_!~steev@de1.hashbang.sh> has quit IRC (Quit: leaving) | 00:17 | |
| *** camus <camus!~Instantbi@183.192.142.149> has joined #yocto | 00:57 | |
| *** geoffhp <geoffhp!~geoff@cpe-107-185-48-203.socal.res.rr.com> has joined #yocto | 01:00 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Ping timeout: 260 seconds) | 01:01 | |
| geoffhp | Since 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 the | 01: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 invoking | 01:07 |
| geoffhp | -c configure? | 01:07 |
| *** shoragan <shoragan!~shoragan@user/shoragan> has joined #yocto | 01:12 | |
| *** jclsn <jclsn!~jclsn@149.224.24.240.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 245 seconds) | 01:14 | |
| *** jclsn <jclsn!~jclsn@149.224.24.240.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 01:20 | |
| *** jclsn <jclsn!~jclsn@149.224.24.240.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 256 seconds) | 01:26 | |
| *** jclsn <jclsn!~jclsn@149.224.24.240.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 01:32 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 01:40 | |
| *** jclsn <jclsn!~jclsn@149.224.24.240.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 260 seconds) | 01:41 | |
| *** otavio <otavio!~otavio@201-3-135-79.paemt705.dsl.brasiltelecom.net.br> has quit IRC (Ping timeout: 250 seconds) | 01:45 | |
| *** jclsn <jclsn!~jclsn@149.224.24.240.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 01:46 | |
| *** otavio <otavio!~otavio@201-3-135-79.user3p.brasiltelecom.net.br> has joined #yocto | 01:47 | |
| *** jclsn <jclsn!~jclsn@149.224.24.240.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 260 seconds) | 01:51 | |
| *** jclsn <jclsn!~jclsn@149.224.24.240.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 01:56 | |
| *** jclsn <jclsn!~jclsn@149.224.24.240.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 256 seconds) | 02:03 | |
| *** otavio <otavio!~otavio@201-3-135-79.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 240 seconds) | 02:07 | |
| *** jclsn <jclsn!~jclsn@149.224.24.240.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 02:09 | |
| *** otavio <otavio!~otavio@201-3-135-79.user3p.brasiltelecom.net.br> has joined #yocto | 02:09 | |
| *** starblue <starblue!~juergen@dslb-094-221-191-054.094.221.pools.vodafone-ip.de> has quit IRC (Ping timeout: 256 seconds) | 02:13 | |
| *** otavio <otavio!~otavio@201-3-135-79.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 240 seconds) | 02:13 | |
| *** starblue <starblue!~juergen@dslb-188-100-128-085.188.100.pools.vodafone-ip.de> has joined #yocto | 02:15 | |
| *** jclsn <jclsn!~jclsn@149.224.24.240.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 240 seconds) | 02:18 | |
| *** camus <camus!~Instantbi@183.192.142.149> has quit IRC (Read error: Connection reset by peer) | 02:18 | |
| *** camus <camus!~Instantbi@183.192.142.149> has joined #yocto | 02:18 | |
| *** jclsn <jclsn!~jclsn@149.224.24.240.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 02:19 | |
| *** otavio <otavio!~otavio@201-3-135-79.user3p.brasiltelecom.net.br> has joined #yocto | 02:21 | |
| *** rber|res <rber|res!~rber|res@athedsl-115141.home.otenet.gr> has joined #yocto | 02:32 | |
| *** jclsn <jclsn!~jclsn@149.224.24.240.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 272 seconds) | 02:32 | |
| *** RobertBerger <RobertBerger!~rber|res@athedsl-115141.home.otenet.gr> has quit IRC (Ping timeout: 256 seconds) | 02:34 | |
| *** jclsn <jclsn!~jclsn@149.224.24.240.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 02:38 | |
| *** jclsn <jclsn!~jclsn@149.224.24.240.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 256 seconds) | 02:44 | |
| *** jclsn <jclsn!~jclsn@149.224.24.240.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 02:51 | |
| *** jclsn <jclsn!~jclsn@149.224.24.240.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 272 seconds) | 02:59 | |
| *** jclsn <jclsn!~jclsn@149.224.24.240.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:04 | |
| *** jclsn <jclsn!~jclsn@149.224.24.240.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 260 seconds) | 03:09 | |
| *** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:14 | |
| *** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 260 seconds) | 03:27 | |
| *** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:33 | |
| *** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 240 seconds) | 03:37 | |
| *** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:44 | |
| *** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 272 seconds) | 03:56 | |
| *** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 04:01 | |
| *** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 272 seconds) | 04:06 | |
| *** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 04:12 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 04:33 | |
| *** amitk <amitk!~amit@103.59.74.159> has joined #yocto | 04:41 | |
| geoffhp | s/libtool 2.4.8/libtool 2.4.7/ | 04:41 |
| *** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 05:43 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 05:52 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Client Quit) | 05:52 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Read error: Connection reset by peer) | 06:22 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 06: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 #yocto | 07: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 #yocto | 07:01 | |
| *** frieder <frieder!~frieder@i59F4BC46.versanet.de> has joined #yocto | 07:09 | |
| *** lucaceresoli_ <lucaceresoli_!~lucaceres@77.244.183.192> has joined #yocto | 07:17 | |
| RP | geoffhp: 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 #yocto | 07:44 | |
| *** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has joined #yocto | 07:47 | |
| *** camus <camus!~Instantbi@183.192.142.149> has quit IRC (Ping timeout: 252 seconds) | 07:48 | |
| *** mckoan|away is now known as mckoan | 07:49 | |
| mckoan | good morning | 07:49 |
| hmw[m] | good mornig | 07:49 |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has joined #yocto | 07:50 | |
| *** camus <camus!~Instantbi@183.192.142.149> has joined #yocto | 07:52 | |
| *** wyre <wyre!~wyre@user/wyre> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 07:53 | |
| *** florian <florian!~florian@dynamic-078-048-004-245.78.48.pool.telefonica.de> has joined #yocto | 07:53 | |
| *** wyre <wyre!~wyre@user/wyre> has joined #yocto | 07:55 | |
| *** florian <florian!~florian@dynamic-078-048-004-245.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 260 seconds) | 08:01 | |
| *** florian <florian!~florian@dynamic-078-048-004-245.78.48.pool.telefonica.de> has joined #yocto | 08:02 | |
| *** florian <florian!~florian@dynamic-078-048-004-245.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 260 seconds) | 08:07 | |
| *** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto | 08:10 | |
| qschulz | jsbronder: nope, tags aren't reproducible because they can be moved. Been there, done that. Only reproducible way is to point to a commit hash | 08:12 |
| qschulz | which is via SRCREV: https://docs.yoctoproject.org/ref-manual/variables.html#term-SRCREV | 08:18 |
| *** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has quit IRC (Quit: Konversation terminated!) | 08:27 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 08:38 | |
| LetoThe2nd | yo dudX | 08:45 |
| *** camus <camus!~Instantbi@183.192.142.149> has quit IRC (Remote host closed the connection) | 08:52 | |
| mckoan | hey LetoThe2nd | 08:52 |
| *** camus <camus!~Instantbi@183.192.142.149> has joined #yocto | 08:53 | |
| *** camus <camus!~Instantbi@183.192.142.149> has quit IRC (Ping timeout: 240 seconds) | 08:57 | |
| *** camus <camus!~Instantbi@183.192.142.149> has joined #yocto | 09:01 | |
| hmw[m] | hi, | 09:02 |
| qschulz | o/ | 09:04 |
| hmw[m] | when i try to run this code https://pastebin.com/Qen4K97r... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/385a72cf13934c85cf984fd6edd60399cfef0802) | 09:08 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 09: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 #yocto | 09:19 | |
| *** Schiller <Schiller!~Schiller@p200300efa71d2b01c982f37b710a2340.dip0.t-ipconnect.de> has joined #yocto | 09:21 | |
| qschulz | hmw[m]: you need a leading space in your PACKAGECONFIG:append | 09:24 |
| qschulz | (before sql-mysql) | 09:24 |
| qschulz | but 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@46.55.231.62> has joined #yocto | 09: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!mcfrisk@kapsi.fi> has joined #yocto | 09:30 | |
| mcfrisk | I 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@77.244.183.192> has quit IRC (Quit: Leaving) | 09:48 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has joined #yocto | 09:48 | |
| wyre | hi guys, I've included `apt` in IMAGE_INSTALL but ... I've not available apt command by just doing this 🤔 | 10:07 |
| wyre | is it maybe another different recipe? 🤔 | 10:07 |
| wyre | I just have apt-get, maybe this is enough | 10:07 |
| qschulz | wyre: what are you plannign to do with apt? | 10:09 |
| Schiller | Is 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 typhoon.yocto.io:8686:Â and it just hangs. | 10:09 |
| RP | Schiller: just don't configure one | 10:11 |
| wyre | qschulz, 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 reposotory | 10:11 |
| wyre | is this possible/good idea? or should I reflash the whole image everytime I make updates? | 10:11 |
| LetoThe2nd | wyre: it "depends" | 10:12 |
| wyre | well, I guess there must be described a proper workflow to do this in the doco, right? 🤔 | 10:13 |
| LetoThe2nd | wyre: 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 |
| qschulz | wyre: https://docs.yoctoproject.org/dev-manual/common-tasks.html#working-with-packages | 10:15 |
| LetoThe2nd | wyre: 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 |
| Schiller | RP: 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 |
| qschulz | wyre: I've always ever reflashed the whole thing and package updates seem to be a complex beast to me | 10:17 |
| RP | Schiller: just set it to empty, turn it off | 10:17 |
| LetoThe2nd | qschulz: ++ | 10:17 |
| RP | Schiller: was that with the latest buildbot or an older version? Glad you have it working though! | 10:17 |
| qschulz | wyre: if you need package updates for basically "rolling releases", think also if debian or the likes aren't more suitable to you? | 10:18 |
| qschulz | as LetoThe2nd said "it depends" | 10:18 |
| RP | wyre: 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 annoying | 10:18 |
| pasherring | wyre, and maybe, during this first "discovery stage" (if this is where you are), it might be useful just running qemu | 10:18 |
| LetoThe2nd | full disclosure: there are companies who offer solutions for tackling this kind of problem and I work for one - mender.io | 10:19 |
| Schiller | RP 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 then | 10:21 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 10:22 | |
| wyre | I see, thank you very much guys 😊 I'm going to check the links you pasted, hehe | 10:23 |
| *** wyre <wyre!~wyre@user/wyre> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 10:24 | |
| *** wyre <wyre!~wyre@user/wyre> has joined #yocto | 10:25 | |
| RP | Schiller: ok, just a useful data point for me when we upgrade | 10:25 |
| Schiller | RP: 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@185.178.95.254> 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 https://libera.ems.host/_matrix/media/r0/download/libera.chat/fe5993f98a3fb6ae217b3316da73d80748755292) | 10:36 |
| RP | Schiller: sorry, you need to set BB_SIGNATURE_HANDLER = "OEBasicHash" too | 10:37 |
| qschulz | kayterina[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 #yocto | 10:52 | |
| rburton | kayterina[m]: pastebin.com | 10:54 |
| kayterina[m] | qschulz: https://pastebin.com/FxL7GjPQ | 10:54 |
| *** starblue <starblue!~juergen@dslb-188-100-128-085.188.100.pools.vodafone-ip.de> has quit IRC (Ping timeout: 252 seconds) | 10:54 | |
| rburton | chown the files to root.root | 10:54 |
| *** starblue <starblue!~juergen@dslb-188-100-128-085.188.100.pools.vodafone-ip.de> has joined #yocto | 10:56 | |
| kayterina[m] | The tar.gz is downloaded from git. chown root the tar.gz and then push it to remote? | 10:58 |
| rburton | no, chown the contents. why can't you unpack it in the usual way, with an entry in SRC_URI? | 11:00 |
| rburton | but basically the tarball contains files with uid 1000 | 11:01 |
| rburton | which doesn't exist in the target system | 11:01 |
| rburton | so you need to chown it | 11:02 |
| rburton | after you've unpacked, chown to root or whatever user is appropriate | 11:02 |
| Alban[m] | It seems some variable dependency is missing here: https://github.com/openembedded/openembedded-core/blob/master/meta/classes/packagegroup.bbclass#L25 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 |
| rburton | kayterina[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 | |
| rburton | if root, tar preserves ownership. | 11:04 |
| rburton | i'd do the unpack in a do_unpack[postfuncs] | 11:05 |
| rburton | so all the unpacking happens in the unpack task | 11:05 |
| qschulz | Alban[m]: I'm sorry, I didn't get the question/suggestion, can you rephrase please? | 11:05 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> 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 |
| rburton | yes, but not uglty | 11:08 |
| Schiller | RP: 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 |
| RP | Schiller: what error do you see? Perhaps just remove the BB_HASHSERV line entirely? | 11:15 |
| Schiller | RP 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 |
| RP | Schiller: replace the line on 63 with the BB_SIGNATURE_HANDLER = 'OEBasicHash' setting | 11:29 |
| Schiller | RP 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 #yocto | 11:36 | |
| *** selff <selff!~selff@176.33.66.199> has joined #yocto | 11:37 | |
| RP | Schiller: I doubt you're running the qemuarm-oecore target so it probably doesn't matter | 11:38 |
| Schiller | RP: Seems to be building fine. Thanks for all the advice. | 11:45 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 11:45 | |
| selff | hello everyone, im running an image with openvpn in rpi4. i enabled "AUTO_SYSTEM_ENABLE" in "openvpn_2.4.9.bb". 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 control | 11:46 |
| selff | process exited with error code. | 11:46 |
| selff | See "systemctl status openvpn@client.service" and "journalctl -xe" for details. | 11:46 |
| selff | but when I run it manually the vpn works. | 11:46 |
| selff | "openvpn --config /etc/openvpn/client_vpn_test_conf" works manually | 11:46 |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 11: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 etc | 11:49 |
| *** ardo <ardo!~ardo@host-188-10-58-99.business.telecomitalia.it> has quit IRC (Ping timeout: 272 seconds) | 11:55 | |
| *** ardo <ardo!~ardo@host-188-10-58-99.business.telecomitalia.it> has joined #yocto | 11:57 | |
| selff |  openvpn@client.service status : "openvpn@client.service: Control process exited, code=exited, status=1/FAILURE" | 11:58 |
| selff | Failed to start OpenVPN Robust And Highly Flexible Tunneling Application On client | 11:58 |
| selff | when i check the openvpn --version . i saw "enable_systemd=no " Is it possible that the problem is caused by this? | 12:00 |
| mihai | selff, try placing the config at /etc/openvpn/client.conf | 12:01 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: xmn) | 12:03 | |
| selff | mihai ty, i changed my config name "self_test.conf" to "client.conf" and restart the service, problem gone. | 12:04 |
| mihai | good :) | 12:04 |
| selff | Thanks for help | 12:04 |
| selff | I couldn't find any information about it anywhere. I was probably searching wrong. | 12:05 |
| mihai | http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-support/openvpn/openvpn/openvpn@.service#n9 | 12:06 |
| mihai | selff, here's why | 12:06 |
| selff | thank you again, have a nice day everyone | 12:07 |
| mihai | you're welcome, you too | 12:08 |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 12:09 | |
| *** selff <selff!~selff@176.33.66.199> has quit IRC (Quit: Client closed) | 12:11 | |
| *** Tamis <Tamis!~Tamis@165.225.203.153> has joined #yocto | 12:18 | |
| Tamis | hello, curl recipe on dunfel branch seems not to respect the PACKAGECONFIG option ldap, ldaps | 12:21 |
| Tamis | and this because | 12:21 |
| Tamis | PACKAGECONFIG[ldap] = "--enable-ldap,--disable-ldap," | 12:21 |
| Tamis | PACKAGECONFIG[ldaps] = "--enable-ldaps,--disable-ldaps," | 12:21 |
| Tamis | seems to missing the openldap dependency. Has anyone see that? | 12:21 |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC (Quit: WeeChat 2.8) | 12:21 | |
| Tamis | Only after I corrected the PACKAGECONFIG with the openldap dependency I was able to see: | 12:24 |
| Tamis | LDAP support: enabled (OpenLDAP) | 12:24 |
| Tamis | LDAPS support: enabled | 12:24 |
| Tamis | on curl configuration | 12:24 |
| Tamis | Shouldn't this be corrected on recipes? | 12:24 |
| *** sstiller <sstiller!~sstiller@p200300f07f18ae00ff95079c3b6524a9.dip0.t-ipconnect.de> has joined #yocto | 12:24 | |
| *** wmat[m] <wmat[m]!~wmatmatri@2001:470:69fc:105::1:38e6> has left #yocto | 12:25 | |
| qrsBRWNanyall[m] | @selff:libera.chat: next time. Make sure you check journalctl too. It will show in plain text that it can't open the config file or something similar | 12:26 |
| *** mak <mak!~mak@147.161.171.88> has joined #yocto | 12:29 | |
| *** mak <mak!~mak@147.161.171.88> has quit IRC (Client Quit) | 12:29 | |
| rburton | Tamis: guess so, yes. send a patch? | 12:34 |
| qschulz | Tamis: master branch also does not have it so send a patch to be applied against master first | 12:34 |
| MrSaturn | Is there a way to determine where kernel configuration fragements exist either within the regular bitbake environment, or when using devtool? | 12:51 |
| mihai | MrSaturn, you can find available config fragments in the kernel-meta directory, in the linux-yocto work dir | 12:58 |
| mihai | remote is here https://git.yoctoproject.org/yocto-kernel-cache/tree/ | 12:59 |
| MrSaturn | so something like this should work for applying patches? I am only asking, because to test it is a rather lengthy process: | 13:00 |
| MrSaturn | do_configure_append() { cat ${B}/kernel-meta/*.cfg >> ${B}/.config | 13:01 |
| MrSaturn | } | 13:01 |
| qschulz | MrSaturn: just add your cfg file to SRC_URI of your kernel recipe | 13:07 |
| Tamis | rburton: yeah I will do so. | 13:08 |
| MrSaturn | The 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 patches | 13:09 |
| rburton | just write your own fragment that does the assignments you want | 13:13 |
| mihai | MrSaturn, yes, write a .cfg file and add it to SRC_URI and the class will know what to do, same with .patch | 13:18 |
| MrSaturn | mihai: 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 |
| qschulz | MrSaturn: devtool modify only patches the source files, but config fragments are applied before do_compile is run | 13:25 |
| qschulz | at least that's my quick reading of kernel-yocto.bbclass | 13:25 |
| qschulz | so it's normal, just too early in the process | 13:25 |
| qschulz | do_kernel_configme seems to be the task that needs to run to configure the config | 13:26 |
| *** mak_gr <mak_gr!~mak_gr@147.161.171.88> has joined #yocto | 13:29 | |
| *** pgowda_ <pgowda_!uid516182@id-516182.ilkley.irccloud.com> has joined #yocto | 13:33 | |
| RP | JPEW: do you happen to be around? or still away? Had a question about asyncio | 13:37 |
| MrSaturn | qschulz: 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 | |
| JPEW | RP: Ya, I'm here | 13:46 |
| JPEW | RP: Where is it not calling close() ? | 13:47 |
| RP | JPEW: the client() inside siggen.py ? | 13:48 |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 13:49 | |
| RP | JPEW: I'm wondering why https://bugzilla.yoctoproject.org/show_bug.cgi?id=14767 shows an asyncio thread hanging around | 13:49 |
| JPEW | RP: Ya, possibly. Is there a defined way to know when bitbake is "done" ? | 13:51 |
| RP | JPEW: we'd have to add something, the way siggen is hooked in right now is horrible | 13:51 |
| RP | JPEW: I'm just not clear if the lack of a close() call could intermittently lock up the server exit? | 13:52 |
| JPEW | RP: That seems the most likely culprit for the warning, given it's one of the few places we use asyncio | 13:52 |
| JPEW | Not sure about if that can cause the lockup, but it should probably be fixed either way | 13:52 |
| RP | JPEW: the warning may or may not be a problem, it was just a possible lead | 13:53 |
| RP | but yes, perhaps better to fix anyway | 13:53 |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has quit IRC (Quit: Leaving) | 13:57 | |
| *** lucaceresoli_ <lucaceresoli_!~lucaceres@77.244.183.192> has joined #yocto | 14:02 | |
| *** lucaceresoli_ <lucaceresoli_!~lucaceres@77.244.183.192> has quit IRC (Client Quit) | 14:03 | |
| *** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Quit: Ping timeout (120 seconds)) | 14:06 | |
| *** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 14:06 | |
| *** Schiller <Schiller!~Schiller@p200300efa71d2b01c982f37b710a2340.dip0.t-ipconnect.de> has quit IRC (Quit: Client closed) | 14:08 | |
| kayterina[m] | when PV is set inside a recipe_0.1.bb to this value | 14: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 |
| qschulz | kayterina[m]: this is usually used with AUTOREV | 14:10 |
| qschulz | and 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 |
| qschulz | kayterina[m]: yes but not recommended | 14:15 |
| qschulz | as this means you never have reproducible builds | 14:15 |
| qschulz | ok for development | 14:15 |
| qschulz | definitely not okay for releases | 14:15 |
| *** amitk <amitk!~amit@103.59.74.159> has quit IRC (Ping timeout: 260 seconds) | 14:28 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has joined #yocto | 14:29 | |
| *** amitk <amitk!~amit@103.59.74.159> has joined #yocto | 14:29 | |
| *** akiCA <akiCA!~akiCA@user/akica> has joined #yocto | 14:32 | |
| *** sstiller <sstiller!~sstiller@p200300f07f18ae00ff95079c3b6524a9.dip0.t-ipconnect.de> has quit IRC (Quit: Leaving) | 14:35 | |
| LetoThe2nd | whats the best practise to patch something in a git submodule that is being pulled in by a recipe? | 14:37 |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Read error: Connection reset by peer) | 14:37 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 14:37 | |
| qschulz | LetoThe2nd: are you using gitsm fetcher inm SRC_URI? | 14:38 |
| LetoThe2nd | qschulz: nope, go magic is involved :( | 14:39 |
| LetoThe2nd | it 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@147.161.171.88> has quit IRC (Quit: Client closed) | 14:42 | |
| jsbronder | qschulz: 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@94.71.69.57> has joined #yocto | 14:45 | |
| qschulz | jsbronder: that's fine, tags moving, less. Because then you'll be building something you weren't expecting and you will not know about it | 14:45 |
| *** rber|res <rber|res!~rber|res@athedsl-115141.home.otenet.gr> has quit IRC (Ping timeout: 252 seconds) | 14:46 | |
| qschulz | jsbronder: sha disappearing should be handled by your org with a mirror | 14:46 |
| jsbronder | I took steev_'s question to only be regarding internal apps. | 14:50 |
| jsbronder | git will eventually delete any unreachable objects, even on a mirror. | 14:52 |
| jsbronder | anyways, I think we agree vigorously, point at the sha of a tag. | 14:53 |
| qschulz | jsbronder: 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 package | 14:54 |
| *** Guest8 <Guest8!~Guest8@76.115.15.249> has joined #yocto | 14:54 | |
| qschulz | but yes, we agree :) | 14:54 |
| *** amitk <amitk!~amit@103.59.74.159> has quit IRC (Ping timeout: 240 seconds) | 14:59 | |
| Guest8 | bitbake 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 installed | 14: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 the | 14:59 |
| Guest8 | FILESEXTRAPATHS_prepend and overrides) in the output doesn't contain either my directory or the inherited directory which seems odd. | 14:59 |
| *** amitk <amitk!~amit@103.59.74.159> has joined #yocto | 15:00 | |
| qschulz | Guest8: ${WORKDIR}/temp/log.do_fetch will tell you which paths and in which order are traversed to find your file | 15:03 |
| qschulz | typically, if the path relative to FILESEXTRAPATH entry is not the same, whatever the priority is won't matter | 15:04 |
| qschulz | specifically, one can use OVERRIDES in file paths without specifying the OVERRIDE in SRC_URI | 15:04 |
| qschulz | Guest8: which version of Yocto are you using? | 15:05 |
| qschulz | might also be that it should be FILESEXTRAPATHS:prepend actually | 15:06 |
| qschulz | Guest8: https://pretalx.com/media/yocto-project-summit-2021/submissions/WTT3UV/resources/Demystifying_the_OVERRIDES_mechan_no6J6fb.pdf starting slide 72 | 15:06 |
| qschulz | actually.. slide 70 | 15:06 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 15:08 | |
| *** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has quit IRC (Quit: Leaving) | 15:08 | |
| landgraf | Has triage meeting been moved? o_O | 15:09 |
| Guest8 | qschulz 1.46.0Â bitbake | 15:09 |
| qschulz | Guest8: ok, so _append should work just fine | 15:10 |
| Guest8 | so I just invoke ${WORKDIR}/temp/log.do_fetch in my append() rule? | 15:10 |
| qschulz | Guest8: no no no, it's a log file, it'll just tell you which files are fetched and from where | 15:10 |
| Guest8 | oic | 15:10 |
| landgraf | oh. summer time :-/ | 15:13 |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 15:15 | |
| rfs613 | qschulz: 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@107.116.82.161> has quit IRC (Ping timeout: 240 seconds) | 15:17 | |
| sgw | Morning all | 15:18 |
| qschulz | rfs613: I wrote the slides in such a way that it isn't necessary to listen to me for 30min :) | 15:18 |
| sgw | Well 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 |
| sgw | b'' | 15:18 |
| qschulz | so it's a bit more verbose than usual | 15:18 |
| rfs613 | qschulz: I do appreciate the slide deck, have referred to it several times (and probably more to come). | 15:19 |
| sgw | digging deeper into rootfs construction | 15:19 |
| rfs613 | I 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@107.116.82.161> has joined #yocto | 15:21 | |
| *** mihai <mihai!~mihai@user/mihai> has left #yocto (Leaving) | 15:23 | |
| qschulz | rfs613: 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 suggestion | 15:24 |
| qschulz | there are complex and confusing areas in YP/Bitbake for sure | 15:24 |
| qschulz | the _ override syntax was one | 15:24 |
| *** mihai <mihai!~mihai@user/mihai> has joined #yocto | 15:24 | |
| *** mnme <mnme!~mnme@22.71.14.46.static.wline.lns.sme.cust.swisscom.ch> has joined #yocto | 15:24 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 15:25 | |
| mnme | Hi all! Is anyone else experiencing very slow download speeds from downloads.yoctoproject.org? | 15:30 |
| rfs613 | mnme: it's been reported a few times in the past days... | 15:30 |
| *** Guest8 <Guest8!~Guest8@76.115.15.249> has quit IRC (Quit: Connection closed) | 15:30 | |
| sgw | RP: so it looks like depmodwrapper has been failing silently in master, not sure for how long | 15:31 |
| * sgw hates finding hidden issues | 15:31 | |
| mnme | rfs613: Okay, so it's not a problem on my end, that's good to know | 15:34 |
| mnme | I 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 |
| qschulz | it's actually recommended to share them | 15:38 |
| qschulz | same for SSTATE_DIR | 15:38 |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 15:40 | |
| mnme | Perfect, 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 downloads | 15:45 |
| RP | sgw: ah. We need better tests too :/ | 15:47 |
| sgw | Yeah, I will try to address that also, first I need to figure out what's broken | 15:47 |
| sgw | In Master: ResourceWarning: Enable tracemalloc to get the object allocation traceback | 15:48 |
| *** frieder <frieder!~frieder@i59F4BC46.versanet.de> has quit IRC (Remote host closed the connection) | 15:50 | |
| khem | geoffhp: I think key is to regenerate aclocal.m4 | 15:51 |
| khem | before running further tasks | 15:51 |
| smurray | khem: 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 |
| rfs613 | mnme: 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 |
| mnme | rfs613: Thanks for confirming. I'll use a shared directory and see if anything breaks. | 16:15 |
| khem | smurray: yoe distro does not use pollkit | 16:15 |
| *** mnme <mnme!~mnme@22.71.14.46.static.wline.lns.sme.cust.swisscom.ch> has quit IRC (Quit: Client closed) | 16:15 | |
| *** mnme <mnme!~mnme@22.71.14.46.static.wline.lns.sme.cust.swisscom.ch> has joined #yocto | 16:16 | |
| smurray | khem: it gets pulled into the AGL demo image these days. I'll send a patch in a bit | 16:16 |
| smurray | khem: 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_!uid516182@id-516182.ilkley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 16:21 | |
| *** mnme <mnme!~mnme@22.71.14.46.static.wline.lns.sme.cust.swisscom.ch> has quit IRC (Quit: Client closed) | 16:24 | |
| *** Tokamak <Tokamak!~Tokamak@107.116.82.161> has quit IRC (Ping timeout: 240 seconds) | 16:32 | |
| *** Tokamak <Tokamak!~Tokamak@107.116.82.161> has joined #yocto | 16:33 | |
| *** Tamis <Tamis!~Tamis@165.225.203.153> has quit IRC (Quit: Client closed) | 16:40 | |
| *** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto | 16:42 | |
| khem | yes it could be | 16:46 |
| khem | thanks for a patch | 16:46 |
| *** bantu <bantu!~bantu@edna.bantux.com> has quit IRC (Quit: bantu) | 16:48 | |
| *** Tokamak_ <Tokamak_!~Tokamak@172.58.191.11> has joined #yocto | 16:48 | |
| *** bantu <bantu!~bantu@edna.bantux.com> has joined #yocto | 16:49 | |
| *** Tokamak <Tokamak!~Tokamak@107.116.82.161> has quit IRC (Ping timeout: 240 seconds) | 16:49 | |
| smurray | khem: 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 |
| smurray | khem: 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 back | 16:55 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> 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!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 256 seconds) | 16:59 | |
| *** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 17:06 | |
| *** kevinrowland <kevinrowland!~kevinrowl@104.129.199.51> has joined #yocto | 17:22 | |
| *** mckoan is now known as mckoan|away | 17:30 | |
| *** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has joined #yocto | 17:30 | |
| *** akiCA <akiCA!~akiCA@user/akica> has joined #yocto | 17:49 | |
| *** amitk <amitk!~amit@103.59.74.159> has quit IRC (Ping timeout: 252 seconds) | 17:49 | |
| dirtyflag | hi, getting this error: ERROR: Nothing RPROVIDES 'nativesdk-qtcreator-mel' but qtcreator-mel_1.0.bb is in the layer | 17:55 |
| LetoThe2nd | dirtyflag: does the recipe actually provide native? | 17:58 |
| dirtyflag | LetoThe2nd: seems not | 17:59 |
| LetoThe2nd | dirtyflag: https://www.oreilly.com/library/view/embedded-linux-development/9781788399210/34fa077a-7c49-47c4-bd63-945f4d8089f9.xhtml | 17:59 |
| dirtyflag | LetoThe2nd: thanks a lot | 18:00 |
| LetoThe2nd | dirtyflag: have fun! | 18:00 |
| geoffhp | RP:, khem:, smurray: Thanks for the reponse re polkit libtool upgrade. Looking forwared to the patch | 18:02 |
| vvn | the /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__!~creich@p200300f6af2a72107b065ee738a7213c.dip0.t-ipconnect.de> has joined #yocto | 18:33 | |
| *** creich_ <creich_!~creich@p200300f6af2fa2103004eb7d76543b37.dip0.t-ipconnect.de> 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 [https://lists.openembedded.org/g/openembedded-core/message/163606] 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 https://libera.ems.host/_matrix/media/r0/download/libera.chat/5941f38a31adb54e10c7fc90b20c37a4fb8c9314) | 18:48 |
| 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!uid110099@id-110099.uxbridge.irccloud.com> has joined #yocto | 18:55 | |
| *** kevinrowland <kevinrowland!~kevinrowl@104.129.199.51> has quit IRC (Quit: Client closed) | 19:10 | |
| khem | RP: where do we document minimum python version ? | 19:12 |
| *** Tokamak_ <Tokamak_!~Tokamak@172.58.191.11> has quit IRC (Ping timeout: 240 seconds) | 19:39 | |
| *** Tokamak <Tokamak!~Tokamak@166.205.152.51> has joined #yocto | 19:44 | |
| *** kevinrowland <kevinrowland!~kevinrowl@104.129.199.51> has joined #yocto | 20:09 | |
| *** florian_kc <florian_kc!~florian@78.48.4.245> has joined #yocto | 20:10 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 20:11 | |
| *** behanw_ <behanw_!uid110099@id-110099.uxbridge.irccloud.com> has joined #yocto | 20:15 | |
| *** codavi <codavi!~akiCA@user/akica> has joined #yocto | 20:16 | |
| *** behanw <behanw!uid110099@id-110099.uxbridge.irccloud.com> has quit IRC (Ping timeout: 260 seconds) | 20:16 | |
| *** behanw_ is now known as behanw | 20:16 | |
| jonmason | RP: any idea what to do with https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/4870/steps/6/logs/stdio ? 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 #yocto | 20: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!~bantu@edna.bantux.com> has quit IRC (Quit: No Ping reply in 180 seconds.) | 20:25 | |
| *** bantu <bantu!~bantu@edna.bantux.com> has joined #yocto | 20:25 | |
| *** kevinrowland <kevinrowland!~kevinrowl@104.129.199.51> has quit IRC (Quit: Client closed) | 20:31 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 20:32 | |
| RP | khem: bitbake codes it and the manuals do mention it I think? | 20:34 |
| RP | jonmason: 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 file | 20:35 |
| RP | jonmason: it isn't supposed to be possible to do that | 20:35 |
| RP | jonmason: probably in the ignore until happens again pile | 20:35 |
| jonmason | thanks | 20:39 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> 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!~gilles@115.188.198.77.rev.sfr.net> has joined #yocto | 21: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@77.244.183.192> has quit IRC (Ping timeout: 240 seconds) | 21:26 | |
| abelloni | I was really wondering what happened to this one | 21:27 |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Ping timeout: 256 seconds) | 21:28 | |
| RP | abelloni: I don't know how it happened, just that the logs say it did :/ | 21:29 |
| *** mak_gr <mak_gr!~mak_gr@165.225.203.34> has joined #yocto | 21:34 | |
| RP | abelloni: you got the efi bug and the tinfoil one in the same build :/ | 21:37 |
| *** GillesM <GillesM!~gilles@115.188.198.77.rev.sfr.net> has quit IRC (Quit: Leaving) | 21:47 | |
| *** a849572 <a849572!~a849572@ppp079167186232.access.hol.gr> has joined #yocto | 21:50 | |
| *** a849572 <a849572!~a849572@ppp079167186232.access.hol.gr> has quit IRC (Read error: Connection reset by peer) | 21:50 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 21:51 | |
| *** a849572 <a849572!~a849572@ppp079167186232.access.hol.gr> has joined #yocto | 21:52 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> 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!~a849572@ppp079167186232.access.hol.gr> has left #yocto (Leaving) | 21:58 | |
| *** mak_gr <mak_gr!~mak_gr@165.225.203.34> has quit IRC (Quit: Client closed) | 22:00 | |
| *** Guest79 <Guest79!~Guest79@2601:644:8102:f530:65e1:75ad:10c5:5957> has joined #yocto | 22:03 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 22:04 | |
| Guest79 | Is there a recipe for telegraf or influxdb ? | 22:05 |
| *** GillesM <GillesM!~gilles@115.188.198.77.rev.sfr.net> has joined #yocto | 22:11 | |
| khem | Guest79: I had then in meta-influx but have not kept them uptodate | 22:14 |
| khem | https://github.com/alihanyalcin/meta-influx seems to be another option | 22:16 |
| *** florian_kc <florian_kc!~florian@78.48.4.245> 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@137.220.68.120> has joined #yocto | 22: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 #yocto | 22:44 | |
| Guest11 | Hey gang! | 22:45 |
| Guest11 | I'm experiencing some slowness with this artifact | 22:45 |
| Guest11 | http://downloads.yoctoproject.org/mirror/sources/git2_github.com.opencv.opencv_3rdparty.git.tar.gz | 22:45 |
| Guest11 | Uploaded file: https://uploads.kiwiirc.com/files/ced4cb27da360bf2b59032f93d90c0a4/Screenshot%202022-03-24%20at%2023.01.28.png | 23:06 |
| Guest11 | Actually I don't know what to make of this | 23:06 |
| Guest11 | There the bitbake-worker has been hung for 6 hours | 23:07 |
| Guest11 | googling for decafbadbeef doesn't yield sensible results | 23:07 |
| *** alimon <alimon!~alimon@2806:10b7:3:8b00:2c32:cfff:fe8e:de1f> has quit IRC (Ping timeout: 252 seconds) | 23:22 | |
| *** alimon <alimon!~alimon@189.172.100.150> has joined #yocto | 23:23 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 23:41 | |
| *** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has quit IRC (Quit: Konversation terminated!) | 23:47 | |
| *** Guest11 <Guest11!~Guest11@137.220.68.120> has quit IRC (Quit: Connection closed) | 23:56 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
