Tuesday, 2021-01-12

*** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC00:02
*** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto00:03
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has joined #yocto00:08
*** leon-anavi <leon-anavi!~Leon@> has quit IRC00:08
*** linums <linums!~linums@> has quit IRC00:12
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has quit IRC00:12
*** madatun_1 <madatun_1!~madatun_3@240e:3b3:30b0:a6c0:55d0:9a6:8238:b6dc> has joined #yocto00:33
*** madatun_1 <madatun_1!~madatun_3@240e:3b3:30b0:a6c0:55d0:9a6:8238:b6dc> has quit IRC00:35
*** Wouter0100 <Wouter0100!~Wouter010@84-80-174-188.fixed.kpn.net> has quit IRC00:37
*** minimaxwell <minimaxwell!~minimaxwe@apoitiers-259-1-26-122.w90-55.abo.wanadoo.fr> has quit IRC00:37
*** Wouter0100 <Wouter0100!~Wouter010@84-80-174-188.fixed.kpn.net> has joined #yocto00:42
*** Kyubi <Kyubi!~Kyubi@2601:640:10d:6041:dda0:577e:5469:b423> has joined #yocto00:43
*** Kyubi <Kyubi!~Kyubi@2601:640:10d:6041:dda0:577e:5469:b423> has quit IRC00:48
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto00:58
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto01:01
*** manuel_ <manuel_!~manuel@213-147-160-84.nat.highway.bob.at> has joined #yocto01:43
*** manuel1985 <manuel1985!~manuel@089144219161.atnat0028.highway.a1.net> has quit IRC01:45
*** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC01:53
*** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto01:53
*** gourve_l <gourve_l!~laurent@> has quit IRC01:55
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:57
*** Kyubi_ <Kyubi_!~Kyubi@c-67-188-92-153.hsd1.ca.comcast.net> has joined #yocto02:05
*** Kyubi <Kyubi!~Kyubi@> has quit IRC02:05
*** gourve_l <gourve_l!~laurent@static-176-175-104-214.ftth.abo.bbox.fr> has joined #yocto02:07
*** ahadi <ahadi!~ahadi@> has quit IRC03:30
*** ahadi <ahadi!~ahadi@> has joined #yocto03:31
*** DanmerZ <DanmerZ!~op@> has quit IRC03:43
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has joined #yocto03:44
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has quit IRC03:48
*** Kyubi_ <Kyubi_!~Kyubi@c-67-188-92-153.hsd1.ca.comcast.net> has quit IRC04:04
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto04:05
*** dreyna_ <dreyna_!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has quit IRC04:05
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto04:17
*** camus1 <camus1!~Instantbi@> has joined #yocto04:18
*** kaspter <kaspter!~Instantbi@> has quit IRC04:19
*** camus1 is now known as kaspter04:19
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has joined #yocto04:47
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC04:49
*** armpit <armpit!~armpit@2601:202:4180:a5c0:785d:a2f4:77f9:c779> has quit IRC05:12
*** ahadi <ahadi!~ahadi@> has quit IRC05:21
*** ahadi <ahadi!~ahadi@> has joined #yocto05:22
*** armpit <armpit!~armpit@2601:202:4180:a5c0:2960:99d5:cba5:7114> has joined #yocto05:24
*** la_croix <la_croix!~la_croix@cpc139740-walt24-2-0-cust196.13-2.cable.virginm.net> has quit IRC05:29
*** manuel__ <manuel__!~manuel@213-147-160-84.nat.highway.bob.at> has joined #yocto05:32
*** manuel_ <manuel_!~manuel@213-147-160-84.nat.highway.bob.at> has quit IRC05:35
*** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto05:46
*** Kyubi_ <Kyubi_!~Kyubi@c-67-188-92-153.hsd1.ca.comcast.net> has joined #yocto05:50
*** Kyubi <Kyubi!~Kyubi@> has quit IRC05:50
idadelHello, I have been trying to run a build on the [paule/rpurdie-license-experiments-osls] branch. I haven’t been successful due to some errors. The errors are very similar to one already reported on a mailing list. Sadly no solution was provided. My system is Ubuntu 20.04. When I run the build I get the error message: ERROR: qemu-native-3.1.0-r0 do_compile: oe_runmake failed05:53
idadelAttached is a link to the same issue reported previously in a mailing list:05:53
idadelP.s the shared log in the attached report has the exact same issues as my current log. I will upload logs if required. Thank you for helping05:53
*** kaspter <kaspter!~Instantbi@> has quit IRC05:54
*** kaspter <kaspter!~Instantbi@> has joined #yocto05:54
idadelI'm using the poky-contrib repo05:56
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has quit IRC06:12
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has joined #yocto06:12
*** Siva38 <Siva38!ad277954@> has joined #yocto06:14
Siva38Yocto Zeus has both Python 3.x and Python 2.7.x. How can i exclude python 2.7.x from the image?06:15
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has quit IRC06:17
*** vineela <vineela!~vtummala@> has quit IRC06:21
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-tvdzswmnegeoxufu> has quit IRC06:27
*** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto06:35
*** minimaxwell <minimaxwell!~minimaxwe@apoitiers-259-1-26-122.w90-55.abo.wanadoo.fr> has joined #yocto06:45
*** AndersD_ <AndersD_!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto06:51
*** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC06:54
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has joined #yocto06:56
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has quit IRC07:02
*** luneff <luneff!~yury@> has joined #yocto07:15
*** thekappe <thekappe!c65a42b1@> has quit IRC07:15
*** alessioigor <alessioigor!~alessioig@93-47-228-8.ip115.fastwebnet.it> has joined #yocto07:17
*** alessioigor <alessioigor!~alessioig@93-47-228-8.ip115.fastwebnet.it> has quit IRC07:22
*** luneff <luneff!~yury@> has quit IRC07:24
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:29
*** manuel__ <manuel__!~manuel@213-147-160-84.nat.highway.bob.at> has quit IRC07:29
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto07:32
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has joined #yocto07:33
*** frsc <frsc!~frsc@p50937620.dip0.t-ipconnect.de> has joined #yocto07:37
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has quit IRC07:39
*** mckoan|away is now known as mckoan07:39
*** Chrys <Chrys!a5e14d1c@> has joined #yocto07:43
ChrysHello:)  How can I see the logs of yesterday discussion please ? Thanks ^^07:46
*** kaspter <kaspter!~Instantbi@> has quit IRC07:47
*** camus1 <camus1!~Instantbi@> has joined #yocto07:47
*** camus1 is now known as kaspter07:49
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has joined #yocto07:49
*** NiksDev <NiksDev!~NiksDev@> has quit IRC07:50
*** kaspter <kaspter!~Instantbi@> has quit IRC07:51
*** kaspter <kaspter!~Instantbi@240e:46c:8c01:3f29:882b:57b4:83c5:5913> has joined #yocto07:51
mckoanChrys: https://www.yoctoproject.org/irc/07:52
mckoanhalstead: looks like IRC logs aren't working for 2021 ^^^07:52
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has quit IRC07:54
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC07:56
ChrysYep ! So i don't know if i get answered yesterday x)07:56
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/kiwiirc.com/ip.> has joined #yocto07:57
mckoanChrys: let me check my own logs07:58
*** kaspter <kaspter!~Instantbi@240e:46c:8c01:3f29:882b:57b4:83c5:5913> has quit IRC07:58
mckoanChrys: no answers07:59
mckoanChrys: IMHO you should explain better your issue07:59
ChrysThanks mckoan08:00
*** fl0v0 <fl0v0!~fvo@i59F44EA3.versanet.de> has joined #yocto08:00
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto08:00
*** yizhao <yizhao!~zhaoyi@> has quit IRC08:00
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto08:00
*** yizhao <yizhao!~zhaoyi@> has joined #yocto08:01
*** kaspter <kaspter!~Instantbi@> has joined #yocto08:05
*** DanmerZ <DanmerZ!~op@> has joined #yocto08:08
*** RobertBerger <RobertBerger!~rber@ppp-2-86-143-170.home.otenet.gr> has left #yocto08:14
*** camus1 <camus1!~Instantbi@> has joined #yocto08:17
*** kaspter <kaspter!~Instantbi@> has quit IRC08:18
*** camus1 is now known as kaspter08:18
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has joined #yocto08:27
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has quit IRC08:32
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-mvyxzducavgailhd> has joined #yocto08:32
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has joined #yocto08:34
*** creich <creich!~creich@p200300f6af24e910000000000000039b.dip0.t-ipconnect.de> has quit IRC08:35
*** creich <creich!~creich@p200300f6af24e910000000000000039b.dip0.t-ipconnect.de> has joined #yocto08:37
*** eduardas <eduardas!~eduardas@78-61-200-153.static.zebra.lt> has joined #yocto08:48
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has quit IRC09:05
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC09:05
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto09:06
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has joined #yocto09:09
qschulzSiva38: just don't put it in the image?09:09
*** m1ster_r- <m1ster_r-!~m1ster_r0@prometheus.umask.eu> has quit IRC09:18
*** m1ster_r0b0t <m1ster_r0b0t!~m1ster_r0@prometheus.umask.eu> has joined #yocto09:18
qschulzidadel: on which branch are you developing? qemu is 5.2.0 on master09:22
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC09:34
*** Chrys <Chrys!a5e14d1c@> has quit IRC09:35
*** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC09:35
*** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto09:35
*** sno <sno!~sno@p4fe9374b.dip0.t-ipconnect.de> has quit IRC09:36
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto09:38
idadelqschulz: paule/rpurdie-license-experiments-osls09:40
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC09:40
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto09:41
*** justas <justas!~justas@78-61-38-172.static.zebra.lt> has joined #yocto09:43
justashello, I'm trying to build some userspace applications and I get the following message: "...arm-zaku-linux-musleabi/10.2.0/ld: cannot find -lgcc_s", in total these are missing: "crti.o, crtbeginS.o, -lgcc, -lgcc_s, -lc, -lgcc, -lgcc_s, crtendS.o, crtn.o". The linker seems to be broken. Is there something wrong with my makefile or .bb recipe?09:46
LetoThe2ndjustas: the latter, usually. espcially if you're using a handcarved makefile, then chances are roughly 100% (give or take some)09:49
qschulzidadel: ah right, forgot you already mentioned it sorry. It's apparently based on thud according to meta-poky/conf/distro/poky.conf.09:54
qschulzI'm not sure it's worth debugging right now since thud does not support Ubuntu 20.04 officially09:54
qschulzso, either rebase on a branch that supports Ubuntu 20.04 officially, or maybe use containers09:55
qschulzmaybe RP did build the branch on a decently recent distribution, and might be able to help09:56
qschulzfor containers, kas, or pyrex are usually the go-to, I've personally used neither of them09:56
qschulzalso, those bugs might be fixed in qemu itself or glibc or something so wandering through the respective git repo/mailing lists and try to find patches you can backport is also an option09:57
justaswhat could be the debugging steps to find out what part of the recipe is breaking the linker?10:00
LetoThe2ndjustas: are you using a handcarved makefile?10:11
justasyes, it's not from autotools.10:13
LetoThe2ndjustas: any particular, real technical reason for that? (other than "i don't like build systems"?= because chances are that migrationg to meson, cmake, autotools will fix stuff properly.10:16
Siva38Zeus has both Python 3.x and Python 2.7.x. is there anyway to remove python 2.7.x from the rootfs image?10:18
LetoThe2ndjustas: else, the debugging steps are basically: make sure that your makefile has basically nothing hardcoded, especially _no_ _absolute_ pathes and no binary names, anywhere.10:18
LetoThe2ndSiva38: just do not put it into the rootfs?10:18
justasit's a kernel module from a big vendor, they apparently do things different. :/ ok thank you, I'll check it out :)10:19
LetoThe2ndjustas: even the so called "big vendors" ship crap.10:19
paulbarkerRP: Looking at this failed build: https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/293810:20
paulbarkerRP: I see it has PACKAGE_CLASSES = "package_rpm package_deb package_ipk" in the write config stage10:20
paulbarkerRP: Am I right thinking the rootfs is built with the first entry on that list, i.e. RPM?10:20
LetoThe2ndpaulbarker: yep, first one is actually used in the process, others are just to create package streams.10:21
paulbarkerActually, yes, that's what the comment in my local.conf says10:21
paulbarkerSo the rootfs will be built with RPM. And the "rootfs_ipk: allow do_populate_sdk in parallel to do_rootfs" patch won't have any affect here10:22
paulbarkers/affect/effect/, I need more coffee10:23
paulbarkerThe build failure is almost certainly due to my patches then and not that rootfs_ipk patch if the rootfs isn't being built with ipk10:24
paulbarkerLetoThe2nd: I'll save the beers for later10:24
qschulzSiva38: something is pulling python2, so you need to either configure this thing to not use python2 or remove the thing(s) that need python2 from your image. Easiest way is to just remove the python2 recipe and see what fails to build10:24
qschulzand iterate over and over again until it does not fail anymore and then you're good to go10:25
LetoThe2ndpaulbarker: i've been chasing sig mismatches on esdk generation for a krogoth based thing for days now. such fun for all of us.10:25
*** manuel1985 <manuel1985!~manuel@> has joined #yocto10:26
paulbarkerI'll kick off a local build with a roughly similar config to the failing autobuilder one and see what happens10:27
RPpaulbarker: correct, I should have realised that earlier. It is your series then :(10:27
paulbarkerRP: Is there a command to check if a path is in the pseudo db?10:28
RPpaulbarker: not directly, no10:28
paulbarkerThe build failure is probably non-deterministic but hopefully the pseudo db state after do_image_wic finishes is deterministic10:28
RPpaulbarker: right. I did have patches to hack status checks onto the DB10:29
paulbarkerRP: The way wic invokes pseudo when wic is already running under pseudo does always worry me10:29
RPpaulbarker: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=73b183bd81bb47181ea622389de5675f63848ac7  http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=34853d4bcca9dd4fb457706c7cc7d0b7c8384a1210:30
Siva38ok, let me remove ./poky/meta/recipes-devtools/python/python_2.7.17.bb, ./poky/meta/recipes-devtools/python/python-native_2.7.17.bb and check10:30
RPpaulbarker: may give you inspiration10:30
paulbarkerRP: Ok, I'll let this build run locally and then see what I can do with the results10:30
RPpaulbarker: it worries me too :/10:30
paulbarkerRP: Feel free to back my patches out of master-next for now10:31
paulbarkerRP: Patches 1 & 3 of the series should be relatively un-controversial10:35
paulbarkerThe rest may need some re-work once I've found out what's corrupting the pseudo db10:35
*** oberstet <oberstet!~oberstet@> has joined #yocto10:40
RPpaulbarker: will do, these things can be a bit tricky10:45
*** camus1 <camus1!~Instantbi@> has joined #yocto10:47
*** kaspter <kaspter!~Instantbi@> has quit IRC10:47
*** camus1 is now known as kaspter10:47
ant__RP: hi10:49
ant__again about PRIVATE_LIBS, say a recipe foo.bb gives the unversioned, no soname,  bar.so10:50
ant__is it pointless to add the lib to RPROVIDES_{PN} isn't?10:51
ant__the shlibs resolver would not pick it up10:51
*** DanmerZ <DanmerZ!~op@> has quit IRC10:52
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC10:54
ant__afais the oly way to force it and fix the [file-rdeps] QA would be ASSUME_SHLIBS bazooka which doesn't sound right with private libs10:55
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto10:55
ant__atm we added the build/runtime dependency in the recipe needing it10:56
ant__(it's a v3driver providing gles2)10:56
*** NiksDev <NiksDev!~NiksDev@> has quit IRC10:57
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto10:57
*** Siva38 <Siva38!ad277954@> has quit IRC11:00
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto11:03
*** ldts <ldts!sid269548@gateway/web/irccloud.com/x-bzeryewohkqrtapi> has quit IRC11:06
*** john-mark <john-mark!uid481123@gateway/web/irccloud.com/x-yzheqkmwwbnejiit> has quit IRC11:06
*** john-mark <john-mark!uid481123@gateway/web/irccloud.com/x-gxdytzemqeadoupz> has joined #yocto11:06
*** andycooper <andycooper!uid246432@gateway/web/irccloud.com/x-gnvbkbfkmdyalgsz> has quit IRC11:06
*** andycooper <andycooper!uid246432@gateway/web/irccloud.com/x-iihujydmhgggydny> has joined #yocto11:06
*** ldts <ldts!sid269548@gateway/web/irccloud.com/x-xfzjoicksgycbcqh> has joined #yocto11:07
*** sno <sno!~sno@2001-4dd6-cbe9-0-3904-fab9-bafb-82b6.ipv6dyn.netcologne.de> has joined #yocto11:18
*** jobroe <jobroe!~manjaro-u@p579eb304.dip0.t-ipconnect.de> has joined #yocto11:24
*** kaspter <kaspter!~Instantbi@> has quit IRC11:31
*** jobroe <jobroe!~manjaro-u@p579eb304.dip0.t-ipconnect.de> has quit IRC11:38
*** manuel1985 <manuel1985!~manuel@> has quit IRC11:39
*** manuel1985 <manuel1985!~manuel@> has joined #yocto11:39
*** jobroe <jobroe!~manjaro-u@p579eb304.dip0.t-ipconnect.de> has joined #yocto11:41
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto11:50
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has quit IRC11:52
RPant__: Adding an INSANE_SKIP is probably fair in this case11:53
*** tgoodwin <tgoodwin!~tgoodwin@pool-100-16-74-100.bltmmd.fios.verizon.net> has joined #yocto12:02
*** w00die <w00die!~w00die@> has quit IRC12:04
*** w00die <w00die!~w00die@> has joined #yocto12:06
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC12:17
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto12:18
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC12:19
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto12:19
*** kaspter <kaspter!~Instantbi@> has joined #yocto12:26
*** jonasbits <jonasbits!~quassel@78-72-26-143-no162.tbcn.telia.com> has quit IRC12:28
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto12:38
*** thekappe <thekappe!c65a42b1@> has joined #yocto12:38
*** ThomasD13 <ThomasD13!~thomas@DSL01.> has joined #yocto12:38
*** creich <creich!~creich@p200300f6af24e910000000000000039b.dip0.t-ipconnect.de> has quit IRC12:39
*** creich <creich!~creich@p200300f6af24e910000000000000039b.dip0.t-ipconnect.de> has joined #yocto12:41
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC12:42
thekappeHello guys. I need an high level suggestion.. I will have two boards with the same SoC chip but with different external devices and FPGA IP cores. What it was asked me is, if it possible, to have one main project that can build the proper Linux distro for each board without the need to menage two separate projects. How can I do that in yocto ? I've12:43
thekappeseen someone using different MACHINE and others using multiconfig. Which is in your opinion the best way to do that ?12:43
*** elGamal <elGamal!~elg@> has quit IRC12:44
qschulzare the different external devices accessed via the SoC?12:46
qschulzor via the FPGA?12:47
ant__RP: eh, yes12:47
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has joined #yocto12:47
thekappeqschulz, both of them, so the DT will be different and probably also the kernel configuration file.12:48
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-zzrpulgdynzirorj> has joined #yocto12:49
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has quit IRC12:49
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has joined #yocto12:49
LetoThe2ndthekappe: different kernel configurations definitively mean two distinct MACHINE configurations.12:53
qschulzthekappe: "It depends"12:57
qschulzif you can have the same kernel but different device trees and you can detect from u-boot which board you're booting, then embed all dts in the fitimage and select the correct configuration at runtime12:58
qschulzyou could also put all FPGA FW in the same fitimage and select which one to flash from there12:58
LetoThe2nd"same kernel" != "different kernel configuration files"12:59
qschulzLetoThe2nd: well... it depends :) if one board needs a more featureful configuration than the other, maybe you can just use the featureful configuration for the other board too12:59
LetoThe2ndbut then they aren't different anymore. QED.13:00
qschulzLetoThe2nd: which was the point I was trying to raise. It's not because you want more features for one board than you want to exclude those features from the other board13:01
qschulzespecially since most of the config nowadays for most people/vendors are just enabling drivers13:01
LetoThe2ndyeah, i know what you mean.13:01
qschulzthekappe: and you'll need multiconfig anyway :)13:02
thekappeLetoThe2nd, qschulz, thanks for the hints13:02
qschulzto build your FPGA FW13:02
thekappe@qschulz also because I need the overlay feature13:03
qschulzso all in all, you just have to figure out if you want to share the same MACHINE for your two boards (which is doable in some cases, but most often not)13:03
qschulzthekappe: fitimage supports dt overlays13:03
qschulzwell, u-boot supports dt overlays sorry13:03
qschulznot sure if you can put them in the configuration node though, might need to handle the logic from u-boot side13:04
thekappethe overlay and fpga fw will be on a dedicated partition13:04
qschulzbut I've done it before by using bootm ${loadaddr}#additionnal-dtb#additional-dtb13:04
thekappeand will be used after the kernel has booted13:04
qschulzthekappe: then you can use fdt support in u-boot13:04
thekappesince they are related to a specific application package13:05
qschulzto patch the dtb you loaded13:05
qschulzwhy applying them after the kernel has booted?13:05
thekappeI really don't know. The guys told me they do so13:07
thekappeI didn't know that u-boot manages dtbo files13:08
thekappethis channel is fu**** amazing13:11
*** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC13:36
*** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto13:36
dagmcrhi guys, i'm running a PR service (bitbake-prserv) but I'm getting a lot of this issues from time to time in my ci/cd:13:50
dagmcr`ERROR: mc:qt5122:gstd1.0-0.6.2+gitAUTOINC+3526d0ffdb-r0 do_package: Can NOT get PRAUTO, exception [Errno 111] Connection refused`13:50
dagmcrIs there anything specific you can recommend to get rid of this errors? I don't know if they happen because of multiple access at once... or the machine running the PR Server is busy/not responding... any idea?13:50
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto13:50
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/kiwiirc.com/ip.> has quit IRC13:54
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/kiwiirc.com/ip.> has joined #yocto13:54
RPdagmcr: its likely some kind of performance/scaling issue :/13:55
RPdagmcr: what kind of scale is this running at? how many workers pointed at the prserv?13:56
eduardashello, while compiling a 3rd party out-of-tree kernel module, I get error: the frame size of 1192 bytes is larger than 1190 bytes [-Werror=frame-larger-than=]14:15
eduardasis there a standard way to tweak the GCC compiler flags under Yocto to work around this?14:15
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC14:17
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto14:18
*** yizhao <yizhao!~zhaoyi@> has quit IRC14:21
*** Chrys46 <Chrys46!a5e14d1c@> has joined #yocto14:21
*** yizhao <yizhao!~zhaoyi@> has joined #yocto14:22
Chrys46Hello all:)    The situation : I want to remove a RDEPENDS within a packagroups which is in the 2nd highest layer. In my first highest layer, i put un RDEPENDS_remove of this package that is in the packagegroup... Problem. It's say that "nothing provide" that package. Which is normal as I removed it. I Check with bitbake -g .... No dependencies14:23
Chrys46with it... If i don't use the packagegroup and I manually add one by one the package except the one i want to remove, everything is fine.... Any workaround?14:23
Chrys46I want to remove a package which RDEPENDS*14:25
qschulzChrys46:  RDEPENDS_${PN}_remove14:25
qschulzbitbake -e <your-package-group> is here to help14:26
Chrys46I already have 3 packages on my REDEPENDS_${PN}_remove, when i had the fourth one, it doesn't work.14:26
Chrys46but something strange is...14:26
qschulzgive us what you're doing14:27
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC14:27
qschulzfor now it seems your issue is not with RDEPENDS_${PN}_remove but with one partiular element of your packagegroup14:27
Chrys46if i delete the first line of this RDEPENDS_remove....14:27
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto14:27
Chrys46it works14:27
qschulzgive us the line14:27
Chrys46it's another package14:27
qschulzgive us your too RDEPENDS_${PN}_remove14:28
*** Sponge5 <Sponge5!~adam@ip-89-177-129-187.net.upcbroadband.cz> has joined #yocto14:28
*** ThomasD13 <ThomasD13!~thomas@DSL01.> has quit IRC14:35
*** kaspter <kaspter!~Instantbi@> has quit IRC14:36
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC14:42
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto14:43
*** NiksDev <NiksDev!~NiksDev@> has quit IRC14:48
Chrys46qschulz sorry, i have been busy14:49
Chrys46for example : RDEPENDS_${PN}_remove = "proftpd dhcp-client ifupdown"14:50
qschulzwhat would be the second _remove then that would fail this one?14:51
Chrys46and that is the RDEPENDS14:51
Chrys46From the RDEPENDS, i want to remove fuse14:51
Chrys46So i put it to RDEPENDS_${PN}_remove14:52
Chrys46( because it's a bbappend of this file )14:52
Chrys46and that fail14:52
Chrys46if i remove the first package of the REMOVE, it works...14:52
Chrys46or the second, or the third14:53
qschulzChrys46: can you put a package per RDEPENDS_${PN}_remove? (basically have one _remove per package?)14:57
Chrys46mhh what's your guessing?14:57
Chrys46some special character that mess up?14:58
qschulzChrys46: i don't know, just trying out my luck :p14:59
Chrys46I've already done that14:59
LetoThe2ndmultiple _remove on a single variable are supposed to not work anyways...14:59
Chrys46And it removes all the time the first 3 removes15:00
Chrys46I mean, i have 4 x times RDEPENDS_${PN}_remove15:00
qschulzChrys46: can you give us the lines above the line starting with RDEPENDS_${PN}= in the output of bitbake -e <your-package-group>?15:00
qschulzLetoThe2nd: What? sources?15:00
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC15:00
qschulzLetoThe2nd: https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#removal-override-style-syntax15:01
LetoThe2ndhttps://theyoctojester.info/session_14/main.html comment by Chris15:01
qschulzLetoThe2nd: nah, that's a different thing15:01
qschulzit's a way to make it possible for other bbappends to cancel your _remove15:02
*** uso <uso!~uso@unaffiliated/uso> has left #yocto15:02
LetoThe2ndyes. maybe it works when everything is in the same recipe?15:02
LetoThe2ndbut if the removes are spread out i don't think they work15:02
qschulzthere's no reason for them not to work15:02
qschulzbut eh, happy to be proven otherwise :)15:02
qschulzin any case, one of us will have learn something today :)15:02
qschulzChrys46: the output of bitbake -e will give you the history of how the variable was set, so this is usually a very good place to start looking when things are going not the way you expected15:04
LetoThe2ndbut i'm so old already that i will instantly forget again!15:04
qschulzLetoThe2nd: I'll remind you until the day I'm too old too don't worry15:07
LetoThe2ndthanks mate15:08
Sponge5Where can I list all available packages to install with IMAGE_INSTALL?15:10
LetoThe2ndSponge5: maybe oe-pkgdata-util15:11
Chrys46qschulz trying to check :)15:12
Sponge5LetoThe2nd: huh, networkmanager is not there15:12
LetoThe2ndSponge5: hum, so what?15:14
Chrys46If i see the remove done before the "add"15:14
Chrys46it will add?15:14
Sponge5LetoThe2nd: idk, thought it was a pretty basic package. So if it's not there I have to find/make a recipe to include it in my image, right?15:16
LetoThe2ndSponge5: its a package provided by meta-openembedded/meta-oe. so it is supposed to be there if you have added that layer, and to not be there if you haven't added it.15:17
*** emrius <emrius!~emrius@dslb-088-064-250-061.088.064.pools.vodafone-ip.de> has joined #yocto15:17
v0nhi there15:18
v0nI've enabled debug-tweaks for passwordless root login on my dev board, but I'm still getting: login: can't set groups: Operation not permitted15:18
v0nany idea?15:18
Sponge5LetoThe2nd: got it, thanks. Interesting that noone has asked this on SO yet15:19
qschulzChrys46: _remove is final, it's the last thing to be done so no it shouldn't matter, but obviously bugs are possible15:20
qschulzSponge5: http://layers.openembedded.org/layerindex/branch/master/recipes/ for recipes15:20
emrius@v0n I think that happened to me when I also enabled readonly root filesystem without symlinking /etc/shadow etc to persistent storage. So, did you enable read only rootfs?15:20
*** justas <justas!~justas@78-61-38-172.static.zebra.lt> has quit IRC15:20
qschulzbut obviously this does not allow you to look for packages, only recipes15:21
Chrys46i've done a show-layers15:22
Chrys46And my bbappend is there15:23
Chrys46Btw, it seems that... i don't see the RDEPENDS_${PN}_remove15:23
Chrys46on the bitbake -e <packagegroup>15:23
v0nemrius: my distro is quite simple at the moment, no packages, nothing. I've only added debug-tweaks to my machine definition15:23
Chrys46the bbappend is in a different layer in a highest layer15:23
qschulzChrys46: you won't see an entry for RDPEENDS_${PN}_remove, same for _append15:24
qschulzYocto builds variables directly but give you the history15:24
qschulzif the bbappend is parsed (thus, found by yocto), the priority does not matter15:25
Chrys46Ok so he know thats there is a "remove" and it shows me the final result then?15:25
qschulzChrys46: more or less15:25
qschulzbecause sometimes you have machine specific variables15:25
Chrys46so if i see my package still in RDEPENDS_${PN} ..15:25
qschulzmmmmm... actually no, you're right, it is final result you see in the variable15:26
qschulzChrys46: you're screwed :)15:26
Chrys46And i see that some of the package have been removed by RDEPENDS_${PN}_remove, but not others..;15:26
qschulzwell, there might be other stuff going on, in which case, you'd need to send us the commented lines above RDEPENDS_${PN} or try to make sense of the history yourself if you don't want to share it15:27
*** yizhao <yizhao!~zhaoyi@> has quit IRC15:29
*** yizhao <yizhao!~zhaoyi@> has joined #yocto15:32
qschulz(from the output of bitbake -e)15:32
Chrys46it have been removed15:33
Chrys46i checked the comment and not the variable xD15:33
Chrys46My guessing is that another package depend it15:34
Chrys46where is the log of the bitbake i've done to see which task failed?15:34
*** emrius <emrius!~emrius@dslb-088-064-250-061.088.064.pools.vodafone-ip.de> has quit IRC15:37
Chrys46Maybe caching problems?15:37
LetoThe2ndwhere are the signatures respectively basehashes egnerated?15:40
LetoThe2nd(which files/functions to look at?)15:40
roussinmI would like to know if anyone develops using the native SDK? How am I suppose to use the libraries in there? Do I need to source the environment and _not_ load the OEToolchainConfig.cmake?15:41
Chrys46Ok, it was a caching problem15:44
Chrys46why is sstate putting fuse if i don't ask for?15:45
qschulzChrys46: you need to give us more context, we don't have access to your building machine, error logs or config :/15:46
Chrys46so the problem was the Sstate cache15:46
Chrys46i cleansstate of the packagegroup15:46
qschulzChrys46: you have bigger problems if you need to cleansstate a packagegroup15:47
RPah, there is a bug open for packagegroups :/15:47
qschulzah! thanks RP for chiming in :P)15:47
qschulzChrys46: well there you have it, a bug :)15:47
RPI'm guessing its related to that15:48
* paulg wonders if there is a good example of package "b" that somehow makes use of knowledge that package "a" has some or all of what it needs already...15:50
qschulzLetoThe2nd: have you looked into the TMPDIR/stamps directory?15:50
paulg...or to go one step further, a meta-package that primarily exists just to "prime" the downloads dir with content.15:50
qschulzRP: not entirely clear but can't rule it out15:50
Chrys46Ok we use jenkins15:50
Chrys46and we take the sstate on a server15:51
Chrys46when i clean, i do it locally15:51
Chrys46but still i take it from the server15:51
qschulzmmmm... but the sstate-cache signature should not match for the one you take from the server15:52
manuel1985I shall update our build machine. It's DELL Optiplex 7010 from 2014. CPU is a octocore i7-3770 CPU @ 3.40GHz. We're maxing RAM out to 32GB. Shall I go for a SATA (about 500MB/s read&write speed) or a PCI-express one (3000 to 6000MB/s readwrite speed)?15:52
manuel1985For the SSD15:52
qschulzpaulg: what is your prime recipe providing for other recipes? in other words, can't you have a recipe which compiles everything you need in one recipe only?15:53
qschulzif not, can't you just create your prime recipe and add it to the DEPENDS of other recipes?15:53
paulbarkermanuel1985: NVMe drives are worthwhile if you have a CPU with enough cores15:54
Chrys46when a task is done, can we know from where the "work" have been taken?15:54
manuel1985paulbarker: Enough being considerably more than 8 cores I suppose?15:54
Chrys46like if it was taken from those sstate or whatever15:54
paulbarkermanuel1985: I'm running a 6c/12t machine and an 8c/16t machine, both with NVMe drives15:54
qschulzChrys46: if taken from sstate-cache, you won't have a new file in ${WORKDIR}/temp/log.do_<task>15:55
paulbarkerI think if you have at least 12 threads it's worthwhile. If there's a tradeoff to be made below that, spend the extra money on CPU not disk15:55
armpitYPTM - armin is on15:55
Chrys46qschulz i needed to check de timestamp of the file right?15:56
Chrys46to make sure he have really made the task15:56
qschulzor just remove the ones you have currently15:57
qschulzthe ${WORKDIR}/temp dir can be safely removed15:57
Chrys46if i remove, and no news one, it means sstate cache?15:57
Chrys46ok i see15:57
manuel1985I'm just not sure if that old cpu is a bottleneck. But my thinking is that a full build will run only at night when build time doesn't matter, and builds during the day will be incremental, that is we might benefit from fast disk access more than cpu power15:57
Chrys46thanks you15:57
Chrys46have a good day qschulz15:58
qschulzChrys46: you too, please don't forget to keep us updated or open a bugreport if you find something odd15:59
paulgqschulz, yeah - the prime will be a depends of the children for sure.. I was more concerned if it was allowed for pkg B to make direct references to content in the downloads dir from pkg A, or if that violated some kind of fetcher rules.15:59
*** lelle <lelle!~lelle@static-213-115-118-178.sme.telenor.se> has joined #yocto15:59
Chrys46qschulz no prob15:59
paulgbasically I think I just have to try my idea and see what breaks.   :-P16:00
qschulzpaulg: either you want something like work-shared that is used by the kernel recipe, or abuse DEPENDS with a custom SYSROOT_DIRSA16:00
qschulzpaulg: otherwise if the concern is just "not download from the network twice the same tarball", that should alreayd be handled by the fetcher IIRC if you have the exact same URLs16:01
qschulzif it's "do not untar the tarball twice", then it's a different thing16:01
*** adelcast <adelcast!~adelcast@2603-8080-1e08-7cd8-69bd-ceed-aadd-e606.res6.spectrum.com> has quit IRC16:03
*** Kyubi_ <Kyubi_!~Kyubi@c-67-188-92-153.hsd1.ca.comcast.net> has quit IRC16:03
paulgqschulz, ah but there is the rub.  It is 2021 and I'm not using tarballs.  I'm using git, and want to capitalize on the fact that objects from A are used in B (like git clone --reference...)16:08
paulgSeparate projects, but a fair chunk of shared history.16:09
qschulzpaulg: what about subpath in the git fetcher? https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-fetching.html#git-fetcher-git16:09
*** frsc <frsc!~frsc@p50937620.dip0.t-ipconnect.de> has quit IRC16:09
*** Konsgn <Konsgn!~Konsgnx3@unafiliated/joyseph> has joined #yocto16:10
qschulzyou would clone only what you need *if you have separate directory for your projects)16:10
paulgthanks for the pointer.  I'll have a read of that once I get some boilerplate test framework in place.  Trying to steer clear of the fetcher as much as possible, of course.16:11
paulgI've heard small children have strayed in there and never been seen again.16:11
*** eduardas <eduardas!~eduardas@78-61-200-153.static.zebra.lt> has quit IRC16:12
paulgzeddii was fighting with it once.  Didn't see him for a year and he came back with grey hair.16:12
qschulzpaulg: I'll let you do it by yourself then, too young still to have grey hair16:14
*** adelcast <adelcast!~adelcast@2603-8080-1e08-7cd8-fd30-b045-70ef-c7f1.res6.spectrum.com> has joined #yocto16:15
*** Chrys46 <Chrys46!a5e14d1c@> has quit IRC16:16
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto16:16
*** lelle <lelle!~lelle@static-213-115-118-178.sme.telenor.se> has quit IRC16:19
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC16:25
*** yann <yann!~yann@> has quit IRC16:30
*** AndersD_ <AndersD_!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC16:31
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has quit IRC16:34
manuel1985If I would like to have a shared sstate-cache for all users on a unix system, where would I put it? What's the canonical location? /var/opt?16:44
*** yann <yann!~yann@> has joined #yocto16:44
*** gpanders <gpanders!~gpanders@c-73-228-7-205.hsd1.nm.comcast.net> has quit IRC16:48
*** gpanders <gpanders!~gpanders@c-73-228-7-205.hsd1.nm.comcast.net> has joined #yocto16:53
JPEWmanuel1985: You can put it whereever, just set SSTATE_DIR correctly16:53
*** dreyna_ <dreyna_!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has joined #yocto16:57
manuel1985Yeah I know, I just don't want to violate some agreed standards.17:02
*** Sponge5 <Sponge5!~adam@ip-89-177-129-187.net.upcbroadband.cz> has quit IRC17:02
rburtonput it in /srv if you want to follow a standard17:03
rburtoni live wild and free, and have /yocto17:03
manuel1985Some people just want to see the world burn.17:03
rburtonthat's how I roll17:03
* zeddii doesnt' have a shared sstate cache. so there!!!17:04
manuel1985What do I do if I want to access the same sstate-cache from several unix user accounts? Standard file permission is 644, so even if I put all the accounts into the same group only the creating one will have write access. (If I understand right.)17:06
frayMy sstate-cache is on a read-only parition, that way it never updates and I always have to build from source.. <sarcasm>17:09
rburtonmanuel1985: change your umask17:10
rburtongroup yocto, sticky bits on the parent, etc17:10
*** adam1 <adam1!~adam@ip-89-177-129-187.net.upcbroadband.cz> has joined #yocto17:11
manuel1985rburton: Thanks17:13
ant__rburton, my sstate-cache is bigger than yours :)17:14
dagmcrpurple: sorry for the delay.  6 workers at max pointing to the same PR service.17:15
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC17:15
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto17:16
*** fl0v0 <fl0v0!~fvo@i59F44EA3.versanet.de> has quit IRC17:17
rburtonant__: 111G/yocto/ross/sstate/ i did purge it fairly recently17:17
*** mckoan is now known as mckoan|away17:19
*** vineela <vineela!vtummala@nat/intel/x-eqjxlmfwndkqjbhd> has joined #yocto17:26
RPrburton:  601G here :)17:41
RPzeddii: https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/2941 - the warning - is that a quick fix for you or do I report to Kevin?17:42
rburtonthe CI builder has 383G and thats only been up a few months17:47
RPrburton: we could ask michael what the autobuilder is at? :)17:47
rburtonBets on how long it takes to actually calculate?17:48
ant__wasn't JaMa always purging it?17:49
ant__iirc he had some clever scripts17:49
rburtonthat was for his meta-oe builder, yeah17:49
zeddiiRP: I have a configuration tweak patch from him, I'll send it by EOD with some other changes.17:49
RPzeddii: ok, so I could merge and this will be resolved soon? :)17:50
rburtonzeddii: might have another defconfig warning with 5.10 that a bsp is triggering17:50
halsteadRP, calculating now with a timer.17:52
zeddii RP: poky-contrib zedd/kernel has the -stable updates and the likely warning fix.17:52
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has joined #yocto17:53
RPzeddii: I'll wait for you to send but its good to know I can keep the change in queue :)17:54
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto18:00
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has quit IRC18:00
v0nIs f2fs still better than ext4 for (e)MMC or is it not true anymore?18:00
*** manuel1985 <manuel1985!~manuel@> has quit IRC18:02
khemI use f2fs its certainly faster writes than default ext4 but you can tune ext4 to get better18:07
*** john-mark <john-mark!uid481123@gateway/web/irccloud.com/x-gxdytzemqeadoupz> has quit IRC18:12
RPpaulbarker: just as a datapoint, I reran that failed build and it did repeat: https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/294018:17
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/kiwiirc.com/ip.> has quit IRC18:20
*** aleblanc <aleblanc!~textual@192-222-183-114.qc.cable.ebox.net> has quit IRC18:22
*** aleblanc <aleblanc!~textual@192-222-183-114.qc.cable.ebox.net> has joined #yocto18:24
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has joined #yocto18:28
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has joined #yocto18:34
*** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC18:36
*** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto18:36
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has quit IRC18:44
*** rcw <rcw!~rcwoolley@> has joined #yocto18:46
*** wherearethelogs <wherearethelogs!59cd856f@> has joined #yocto18:51
wherearethelogswhere are the irc logs for 2021?18:52
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-mvyxzducavgailhd> has quit IRC18:53
*** Anarky <Anarky!~Anarky@2a01:cb14:585:6700:baac:6fff:fea4:58b5> has joined #yocto18:58
paulglaying on the forest floor?19:00
wherearethelogsStephano, give me a sign! Tell me what to do, cause I'm gonna get through whatever you want me too, Stephano, give me a sign!19:00
PaowZpaulg: xD19:00
paulgeither that, or check the fireplace.19:00
wherearethelogspaulg i've checked already, wasn't there19:00
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has quit IRC19:06
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC19:13
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto19:13
*** wherearethelogs <wherearethelogs!59cd856f@> has quit IRC19:14
ant__ah, I was about pointing to the 'backup' courtesy of ka6sox19:25
ant__halstead, ou can grab the old logs from there19:26
ant__these days more and more people are asking about the logs :) strange19:26
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC19:27
*** kanavin_home <kanavin_home!~Srain@> has joined #yocto19:27
*** w00die <w00die!~w00die@> has quit IRC19:33
halsteadThe irc logs were being collected but not published. I've fixed the publish job so they are back up at https://www.yoctoproject.org/irc/19:34
halsteadGlad you are keeping backups available ant__19:34
*** w00die <w00die!~w00die@> has joined #yocto19:34
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has quit IRC19:44
*** aleblanc <aleblanc!~textual@192-222-183-114.qc.cable.ebox.net> has quit IRC19:45
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has joined #yocto19:46
*** aleblanc <aleblanc!~textual@192-222-183-114.qc.cable.ebox.net> has joined #yocto19:46
ant__halstead, do not thank me, ka6sox instead19:57
* halstead nods. Will do.19:57
ant__(he's keeping #oe, #kexecboot and many others)19:58
halsteadI have the yocti backups, personal backups, and now I know about ka6sox's backups. IRC data shall survive. :)19:58
abellonione yocto, two yocti ?20:03
*** adam1 <adam1!~adam@ip-89-177-129-187.net.upcbroadband.cz> has quit IRC20:05
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has quit IRC20:10
halsteadYocti is the name of the little Yocto Project fluffball mascots.20:10
yoctihalstead: Error: "is" is not a valid command.20:10
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has joined #yocto20:13
halsteadabelloni, https://imgur.com/a/yruuUn120:16
abelloniah ok, I have multiple of those20:22
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has joined #yocto20:22
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has quit IRC20:27
* RP is pleased halstead linked to the "proper" ones with the ball feet :)20:29
halsteadRP, The others are impostors.20:29
RPhalstead: Yes! There are only four 'real' models. red, yellow, blue and there is one green one20:30
RPgreen was a mock up prototype so in some ways is the original...20:31
*** Ad0 <Ad0!~Ad0@> has quit IRC20:31
*** vineela <vineela!vtummala@nat/intel/x-eqjxlmfwndkqjbhd> has quit IRC20:34
*** Ad0 <Ad0!~Ad0@> has joined #yocto20:37
*** adam1 <adam1!~adam@ip-89-177-129-187.net.upcbroadband.cz> has joined #yocto20:44
halsteadDo you still have the green one? It would be fitting.20:50
*** adam1 <adam1!~adam@ip-89-177-129-187.net.upcbroadband.cz> has quit IRC20:58
*** asteriusio <asteriusio!~derek@104-179-196-18.lightspeed.brhmal.sbcglobal.net> has joined #yocto20:59
*** adam1 <adam1!~adam@ip-89-177-129-187.net.upcbroadband.cz> has joined #yocto20:59
RPhalstead: I do, its sitting near me :)21:06
halsteadMine are boxed up at the moment. Most of them are the feet-cutout style. I have one of the original 8 ball style if I remember correctly.21:08
*** vineela <vineela!~vtummala@> has joined #yocto21:08
RPIts been a long time since the ball style ones were made. We should do another run...21:09
sgwI found mine I have a red, yellow and blue, but no green21:18
RPthe green one is definitely the only one like that, it was a mock up for the others21:20
*** adam1 <adam1!~adam@ip-89-177-129-187.net.upcbroadband.cz> has quit IRC21:29
*** adam1 <adam1!~adam@ip-89-177-129-187.net.upcbroadband.cz> has joined #yocto21:32
*** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC21:35
*** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto21:36
*** aleblanc <aleblanc!~textual@192-222-183-114.qc.cable.ebox.net> has quit IRC21:36
*** jobroe <jobroe!~manjaro-u@p579eb304.dip0.t-ipconnect.de> has quit IRC21:43
*** adam1 <adam1!~adam@ip-89-177-129-187.net.upcbroadband.cz> has quit IRC21:46
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has quit IRC21:50
*** adam1 <adam1!~adam@ip-89-177-129-187.net.upcbroadband.cz> has joined #yocto21:51
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto21:53
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC21:54
*** adam1 <adam1!~adam@ip-89-177-129-187.net.upcbroadband.cz> has quit IRC21:57
RPJPEW: is there something we can do to limit the time diffoscope spends? Its taking hours :(21:58
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has joined #yocto22:01
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has joined #yocto22:10
*** vineela <vineela!~vtummala@> has quit IRC22:11
*** sesom <sesom!~sesom@lns-bzn-40-82-251-130-58.adsl.proxad.net> has quit IRC22:15
JPEWRP: You can limit the depth (I think....)22:18
JPEWBut it would make the output a lot less useful22:18
RPJPEW: right, I wish it was more sensible about the kinds of diffs it produced :/22:19
*** adam1 <adam1!~adam@ip-89-177-129-187.net.upcbroadband.cz> has joined #yocto22:20
JPEWAh... I don't think so22:21
RPJPEW: its slowing the builds down so much its making it effectively mandatory I fix the repro issues asap :/22:22
RPe.g. diffs of this vulkan staticdevs package22:22
RP(its a 25MB archive)22:22
RPalthough my local system did it in 60s :/22:22
RPhmm, it just shows lots of "file format not recognised" which is why its fast22:24
RPbroken objdump on that host distro, cross one works22:33
*** vineela <vineela!vtummala@nat/intel/x-dzdgzhxlykjtqufv> has joined #yocto22:35
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC22:36
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto22:36
*** adam1 <adam1!~adam@ip-89-177-129-187.net.upcbroadband.cz> has quit IRC22:39
*** adam1 <adam1!~adam@ip-89-177-129-187.net.upcbroadband.cz> has joined #yocto22:45
*** adam1 <adam1!~adam@ip-89-177-129-187.net.upcbroadband.cz> has quit IRC22:50
*** adam1 <adam1!~adam@ip-89-177-129-187.net.upcbroadband.cz> has joined #yocto22:53
*** linums <linums!~linums@apn-94-44-115-237.vodafone.hu> has joined #yocto22:54
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC23:00
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto23:03
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC23:07
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto23:08
*** leon-anavi <leon-anavi!~Leon@> has quit IRC23:10
*** adam1 <adam1!~adam@ip-89-177-129-187.net.upcbroadband.cz> has quit IRC23:32
*** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC23:33
*** adam1 <adam1!~adam@ip-89-177-129-187.net.upcbroadband.cz> has joined #yocto23:34
*** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC23:36
*** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto23:36
*** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto23:36
*** Kyubi <Kyubi!~Kyubi@> has quit IRC23:47
*** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto23:49
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC23:53
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has quit IRC23:56

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