Tuesday, 2019-08-20

*** armpit <armpit!~armpit@wsip-184-183-165-38.sd.sd.cox.net> has quit IRC00:11
*** sgw <sgw!~sgw@> has quit IRC00:37
*** diego_r <diego_r!~diego@> has joined #yocto00:39
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto00:48
*** armpit <armpit!~armpit@> has joined #yocto00:55
*** Crofton|mini <Crofton|mini!~Crofton@c-73-152-143-112.hsd1.va.comcast.net> has quit IRC01:20
*** chinhuat091 <chinhuat091!~chinhuat@> has joined #yocto01:35
*** chinhuat09 <chinhuat09!~chinhuat@> has quit IRC01:36
*** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has joined #yocto02:22
*** armpit <armpit!~armpit@> has quit IRC02:37
*** diego_r <diego_r!~diego@> has quit IRC03:29
*** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has quit IRC04:22
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto05:19
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-tivdpxpjeppvgsga> has quit IRC05:19
*** sgw <sgw!sgw@nat/intel/x-rtdfypzokvrnnkdl> has joined #yocto05:52
*** diego_r <diego_r!~diego@> has joined #yocto05:58
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto06:03
*** jeanba <jeanba!~jbl@> has joined #yocto06:10
*** jeanba <jeanba!~jbl@> has left #yocto06:19
*** kroon <kroon!~kroon@> has joined #yocto06:29
*** Crofton|mini <Crofton|mini!~Crofton@> has joined #yocto06:35
*** balister__ <balister__!~Crofton@> has joined #yocto06:39
*** Crofton|mini <Crofton|mini!~Crofton@> has quit IRC06:39
*** cengiz_io <cengiz_io!~cengiz_io@> has quit IRC06:44
*** cengiz_io <cengiz_io!~cengiz_io@> has joined #yocto06:45
*** chinhuat0915 <chinhuat0915!~chinhuat@> has joined #yocto06:47
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto06:48
*** chinhuat091 <chinhuat091!~chinhuat@> has quit IRC06:48
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto06:49
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC06:51
*** mihai- <mihai-!~mihai@unaffiliated/mihai> has joined #yocto06:52
*** diego_r <diego_r!~diego@> has quit IRC07:02
*** balister__ <balister__!~Crofton@> has quit IRC07:02
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC07:14
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto07:16
*** yizhao <yizhao!~zhaoyi@> has quit IRC07:18
*** yacar_ <yacar_!~yacar@> has joined #yocto07:22
*** yizhao <yizhao!~zhaoyi@> has joined #yocto07:22
*** fabo <fabo!~fabo@linaro/fabo> has joined #yocto07:28
PinkSnakeHello guys, I would to build and use a tools during the image generation, i think the class is the better way to do but I don't know how to build the binary for the host and note for the target ... any advice ? cheers07:29
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto07:31
*** marka <marka!~marka@> has quit IRC07:40
*** marka <marka!~marka@> has joined #yocto07:40
mihai-PinkSnake, you can add a native only recipe for the host binary you need07:41
mihai-and use it through DEPENDS in other recipes where needed07:42
*** mihai- is now known as mihai07:42
*** Crofton <Crofton!~Crofton@> has joined #yocto07:49
PinkSnakemihai sounds good ! Thx. But do you know i can 'install custom tool in order to call it from the recipe ? Maybe i'm wrong and it's the better way :S07:49
jofrPinkSnake: Yes you can07:52
PinkSnake@jofr I'm trying BBCLASSEXTEND += "native", keep in touch ;)07:53
*** chinhuat0915 <chinhuat0915!~chinhuat@> has quit IRC07:54
*** chinhuat0915 <chinhuat0915!~chinhuat@> has joined #yocto07:54
jofrPinkSnake: Yes. And then in your other recipe you "DEPENDS" on yourrecipe-native"07:56
PinkSnake@jofr it's the same if I use a bbclass instead of a recipe ?07:57
jofri.e. Your devtoolrecipe "BBCLASSEXTEND"s, has a proper do_install section, and then you have yourotherrecipe "DEPENDS" on devtoolrecipe-native07:58
jofrNo, you are only creating (.bb) recipes.08:00
*** goliath <goliath!~goliath@> has joined #yocto08:00
jofrThe "native.bbclass" already exists. Your devtoolrecipe is just "using" it.08:01
jofrPinkSnake: Something like this?  https://gist.github.com/johannfr/4c08bc904665be60e93477b6e4bee666 Hopefully I'm not just confusing you even more  :p08:22
PinkSnake@jofr exactly what I would like to do, i have to fix my install methode and should be okay, thx !08:23
*** tprrt <tprrt!~tprrt@> has joined #yocto08:31
*** sgw <sgw!sgw@nat/intel/x-rtdfypzokvrnnkdl> has quit IRC08:36
Tamisif oe-pkgdata-util find-path *libfreetype.so.6 reports that 2 recipes provide that library, and one of them is in PRIVATE_LIBS, is there a command that I can see that runtime dependency resolver will include in image the right one?09:07
PinkSnakejofr All right ! tha again ;)09:08
*** tprrt <tprrt!~tprrt@> has quit IRC09:13
*** tprrt <tprrt!~tprrt@> has joined #yocto09:13
nrossiRP: have you had a chance to look at the second version of toolchain testing RFC? looking to clean it up as a patch series this week09:18
jofrPinkSnake: No problem  :)09:18
*** kroon <kroon!~kroon@> has quit IRC09:24
rburtonRP: so meta-darwin, do you remember how much of the osx sdk is needed?  just libc and a few friends, right?09:26
rburtonRP: wondering how much effort it would be to bootstrap it using https://github.com/darlinghq instead09:27
rburtonooh, or even better https://github.com/phracker/MacOSX-SDKs09:27
RPrburton: right, it doesn;t need much09:32
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto09:33
RPnrossi: I did quickly read through it and worried you were starting to overlap with the test result handling elsewhere in oeqa but in general its good09:33
rburtonRP: hm meta-darwin also builds 32-bit binaries, which are pretty much deprecated on modern macos09:38
*** behanw <behanw!uid110099@gateway/web/irccloud.com/x-dwxryqgvbhxfbmrc> has quit IRC09:46
RPrburton: its been a while since it was touched!09:52
*** yacar_ <yacar_!~yacar@> has quit IRC09:52
RPrburton: switching it to 64 bit should be fine09:52
RPrburton: thats more recently than I thought!09:55
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto09:56
nrossiRP: you mentioned there was some filtering stuff in oeqa, but I was not sure what you were referring to, got an example testcase that makes use of it?09:58
mihaiis zeus 2.8 or 3.0?09:59
*** kroon <kroon!~kroon@> has joined #yocto10:00
RPnrossi: sorry, I should be clearer. We don't filter the results, we write all of them into the testresults.json files and then the plan is to handle the filtering at a later stage10:01
RPnrossi: Ultimately the idea is that resulttool regression/report would handle this10:02
RPmihai: 2.8 became and is 3.010:02
mihaiRP, ok, thanks10:04
nrossiRP: I see, so should each testsuite output each test case that failed/etc as part of the testresults.json?10:04
RPnrossi: yes, that would be the best way to handle things I think10:04
nrossiRP: so it should be similar to how ptest works?10:04
RPnrossi: Given the number of cases, I think its going to end up working like ltp/ltp posix/ptest10:04
RPnrossi: yes10:05
RPnrossi: we might need to generalise that code a bit...10:05
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC10:12
nrossiRP: ok so just looking at the resulttool part, there does not appear to be any filtering instead its based on regression vs previous executions. Is that right or am I missing something?10:13
RPnrossi: you're right, the plan was to add more filtering but we're not there yet10:15
RPnrossi: what I'm worried about is having this kind of thing in multiple places. It really belongs in resulttool and the test data should always be saved10:15
nrossiRP: it makes sense, I am just not very familar with it all. At the moment though there is not a large amount of tests that need filtering, so maybe I should stick to having the results fully populated for resulttool and skip filtering in this series?10:17
RPnrossi: sorry, I'm explaining this badly. This is why I hadn't gotten to reply to the email :(10:18
RPnrossi: Probably, yes. Unless there are any tests that hang in which case its find to skip those10:18
nrossiRP: thats ok, I know you have been very busy10:18
RPnrossi: I do like the info you've got in the series about the expected results10:18
RPhash equiv's last build seems to have gotten a lot worse :(10:19
nrossiRP: ok, so I think that has sorted out the plan for the patch series. will have to look into the filtering as a separate part. Did you have any opinion on the qemu-user use for gcc tests? given the improved results10:22
RPnrossi: I don't really trust qemu user :/10:30
RPnrossi: thats purely because I have an idea of what its doing and all the ways it can break having looked at the code...10:30
RPnrossi: so basically I'm torn10:31
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC10:34
nrossiRP: for gcc it is probably worthwhile using qemu-user due to the runtime speed. And the gcc tests are created with running in a simulator in mind. But it is also probably worth running the tests against qemu system and physical hardware for a release10:34
*** kaspter <kaspter!~Instantbi@> has quit IRC10:34
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto10:34
RPnrossi: having configuration that allows us to do both is certainly great and yes, I agree10:35
*** kaspter <kaspter!~Instantbi@> has joined #yocto10:36
rburtonRP: did a next build last night and it died in all sorts of exciting ways10:38
rburtongstreamer and systemd failed to compile10:38
RPrburton: hash equiv enabled or disabled?10:39
rburtondisabled i think10:39
RPrburton: I thought there might be bad patches in there :/10:39
rburtonhm swear i did a build last night and this morning its rebuilding10:42
rburtoni wonder what i poked since10:42
rburtonis it intentional that changing BB_HASHSERVE or BB_SIGNATURE_HANDLER causes a full rebuild?10:43
yoctiNew news from stackoverflow: Bitbake do_rootfs failure for syslog-ng <https://stackoverflow.com/questions/57571560/bitbake-do-rootfs-failure-for-syslog-ng>10:44
RPrburton: that depends. It if no longer has the equiv data it would rebuild stuff10:45
rburtoni had it set yesterday, disabled this morning and caused a rebuild10:45
RPrburton: it can no longer see things are equivalent so yes, I'd say that is expected10:46
rburtonyeah fair enough10:46
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto10:46
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC10:54
*** yacar_ <yacar_!~yacar@> has joined #yocto11:04
*** lemagoup <lemagoup!~lemagoup@softbank-robotics-gw1.ter4.eqx2.par.cust.as8218.eu> has joined #yocto11:05
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC11:11
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto11:12
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC11:18
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC11:27
*** berton <berton!~berton@> has joined #yocto11:39
*** learningc <learningc!~learningc@> has joined #yocto11:47
*** berton <berton!~berton@> has quit IRC11:50
*** berton <berton!~berton@> has joined #yocto11:52
*** nabokov <nabokov!~armand@> has joined #yocto12:08
kroonRP, Did an incremental build of my distro, going from bitbake/oe-core master to master-next, with hashequiv enabled, no issues12:12
*** kroon <kroon!~kroon@> has quit IRC12:13
*** Tamis <Tamis!504e0570@> has quit IRC12:19
*** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has joined #yocto12:20
*** AndersD_ <AndersD_!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto12:22
*** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has quit IRC12:25
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC12:37
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto12:47
*** AndersD_ <AndersD_!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC12:56
*** AndersD__ <AndersD__!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto12:56
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto12:59
*** paulbarker <paulbarker!sid269702@gateway/web/irccloud.com/x-dfbljzuywjryrywt> has joined #yocto13:06
*** kanavin <kanavin!~kanavin@> has quit IRC13:21
* zeddii searches for the core-image-sato test results13:24
*** kanavin <kanavin!~kanavin@> has joined #yocto13:26
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC13:28
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto13:33
kayterinacan anyone here share experiance with NAND-flash boards? We are thinking of switching from rpi, so that someone won't just copy the SD card and easily reproduce our distribution.13:38
kayterinaI'm guessing it's only a matter of switching the machine layer?13:38
PinkSnakekayterina NAND-flash are not really "easy to use", you have to use MTD partition with or without file system support ;) , if you have choice, you should choose emmc13:40
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto13:40
kayterinabut...it is not easy even with yocto?13:41
kayterinathere are some myirtech boards that says "256Mb NAND-flash"13:43
kayterinaand there is MTD support in the linux kernel13:43
kayterinaand JJFS filesystem13:44
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC13:45
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto13:52
*** yacar_ <yacar_!~yacar@> has quit IRC13:53
zeddiiRP: do you happen to have a link where I can look at the test history ? I can’t find it this morning. I’m not able to get sato graphics on any x86-64 build. So it isn’t my new kernel or headers, since I’ve gone all the way back to 4.19 and can’t get anything to work. qemuarm64 did work, so I know the qemu build, etc, is at least somewhat sane.13:54
RPzeddii: http://git.yoctoproject.org/cgit.cgi/yocto-testresults/14:02
* zeddii clicks and looks.14:04
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC14:07
zeddiihmm. X is running, I just can’t connect vncview to it.14:11
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto14:15
RPzeddii: I think it does work but I haven't personally checked recently14:17
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC14:24
*** yacar_ <yacar_!~yacar@> has joined #yocto14:37
*** goliath <goliath!~goliath@> has quit IRC14:37
*** AndersD__ <AndersD__!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC14:39
*** rcw <rcw!~rcw@> has joined #yocto14:41
*** vineela <vineela!~vtummala@> has joined #yocto14:46
*** tprrt <tprrt!~tprrt@> has quit IRC14:49
*** fitzsim <fitzsim!~user@69-165-165-189.dsl.teksavvy.com> has quit IRC14:54
*** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has quit IRC14:54
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC14:55
*** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has joined #yocto14:57
*** marka <marka!~marka@> has quit IRC14:57
vmesonhttps://autobuilder.yocto.io/pub/non-release/ is down. Who handles that server?14:58
vmesonapparently it's just my connection, so nevermind.15:02
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto15:03
*** marka <marka!~marka@> has joined #yocto15:04
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC15:04
halsteadvmeson, I'm the person to ping about that server.15:14
yoctiNew news from stackoverflow: RTOS on kw41z. Yocto project <https://stackoverflow.com/questions/57576280/rtos-on-kw41z-yocto-project>15:15
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC15:16
*** nameclash <nameclash!3e60c2d5@h-> has joined #yocto15:21
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has joined #yocto15:24
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC15:24
*** sgw <sgw!sgw@nat/intel/x-oyffemcacjbvojby> has joined #yocto15:25
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC15:25
nameclashguys, I have a problem understanding the sysroot thing. In yocto 2.4.4, the webkitgtk recipe fails to compile because of some conflicting typedefs in [...]/recipe-sysroot/usr/include/GL/glext.h15:26
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto15:26
nameclashFrom what I've understood from the yocto manual, the sysroot in the workdir of a recipe is for pulling in dependent headers15:27
nameclashSo, when I need to patch one of these headers, I guess I should patch that in the originating recipe rather than in the webkitgtk recipe, right?15:27
*** litb <litb!~js@pd907fca9.dip0.t-ipconnect.de> has joined #yocto15:28
litbhello folks15:28
litbis it possible to access the image/ folder of a recipe from another recipe?15:28
litbour installer recipe needs to package the data of our firmware recipe and encrypt it. so it needs access to the image/   (like devtool does it)15:28
nameclashe.g. package A depends on header B.h from recipe B, I should patch B.h with a B.bbappend recipe...15:29
mihainameclash, that's correct15:30
nameclashHowever, I have a hard time finding the source of GL/glext.h -- when I grep through the yocto layers for do_populate_sysroot() I get very few matches15:30
nameclashI'm stuck on finding the source recipe for GL/glext.h15:31
kergothnameclash: just use oe-pkgdata-util15:31
kergothyou can use that to search for the package/recipe that provides it15:32
nameclashah ok -- will look into it, thx!15:32
litbbut you can only use it if you already have the package built, as far as I know?15:34
litbsometimes, I wanted to know what recipe/package provides  a certain file without having built it. I wasn't able to make that work15:34
*** fray <fray!~fray@kernel.crashing.org> has quit IRC15:40
*** vineela <vineela!~vtummala@> has quit IRC15:41
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto15:42
yoctiNew news from stackoverflow: How to install files in the native sysroot with yocto when doing populate_sdk? <https://stackoverflow.com/questions/57576746/how-to-install-files-in-the-native-sysroot-with-yocto-when-doing-populate-sdk>15:45
PinkSnakeStupid question : I would like to override SSCACHE_DIR variable from the setup-env but the following cmd (export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE SSTATE_DIR") doesn't seem to work... any tips ? :)15:46
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC15:47
*** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has joined #yocto15:48
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC15:49
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto15:57
*** yacar_ <yacar_!~yacar@> has quit IRC15:59
nameclashok, not yet there..15:59
nameclashI ran: oe-pkgdata-util find-path /usr/include/GL/glext.h16:00
nameclashwhich gave me:16:00
nameclashlibgl-mesa-dev: /usr/include/GL/glext.h16:00
*** stephano <stephano!~stephano@> has joined #yocto16:00
nameclashthen I ran: oe-pkgdata-util lookup-recipe libgl-mesa-dev16:01
nameclashwhich gave me 'mesa' as the recipe in question16:01
nameclashhowever, to be able to create a patch for glext.h, I need to cd into the sources dir of the mesa recipe (afaik)16:02
nameclashmy problem is, I can't find any sources fetched for mesa16:03
kanavinnameclash, try 'devtool modify mesa'16:04
nameclashuser@devbuntu:~/os/yocto/build$ find . -name glext.h./tmp/work/cortexa9t2hf-neon-montavista-linux-gnueabi/webkitgtk/2.18.6-r0.5/recipe-sysroot/usr/include/GL/glext.h./tmp/work/cortexa9t2hf-neon-montavista-linux-gnueabi/webkitgtk/2.18.6-r0.5/recipe-sysroot/usr/include/GLES/glext.h./tmp/sysroots-components/cortexa9hf-neon/mesa/usr/include/GL/glext.h.16:05
nameclashok kanavin16:05
*** learningc <learningc!~learningc@> has quit IRC16:10
*** kaspter <kaspter!~Instantbi@> has quit IRC16:11
nameclashkergoth, kanavin, thank you guys, saved my evening!16:11
*** kaspter <kaspter!~Instantbi@> has joined #yocto16:12
nameclashif devtool works as charming as advertised in https://wiki.yoctoproject.org/wiki/TipsAndTricks/Patching_the_source_for_a_recipe then it's a pretty decent tool to know!16:14
kanavinnameclash, devtool is by far the most underrated and not widely known tool in yocto.16:22
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC16:22
kanavinI would probably add a notice about it to the default env init banner16:23
zeddiiRP: back now. yah, it *appears* to be running, so I asssume it works. but vncviewer attachs and detaches immediately with “Unknown message type 190 from VNC server” .. google isn’t useful for what that is yet. Trying to see If I can figure out how to build SDL instead.16:23
kergothkanavin: agreed. recipetool too. the two both provide a lot of value. actually every tool we have other than bitbake itself is probably not as well known as it should be. even bitbake-layers16:26
kergothHmm, i bet a lot of folks don't know you can replace arbitrary config files on the target with recipetool appendfile, or in the source with appendsrcfile16:27
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto16:29
derRichardis yocto warrior broken for rpm package types? i get:16:34
derRichardERROR: core-image-minimal-1.0-r0 do_rootfs: Could not invoke dnf.16:34
derRichardModuleNotFoundError: No module named '_curses'16:34
derRichardin do_rootfs16:34
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto16:41
kanavinderRichard, probably not, as it is tested on the autobuilder16:42
RPkanavin, kergoth: I'd take a patch to the oe-build-init-env script...16:43
derRichardkanavin: maybe a host-system related issue, i'll dig into it16:44
derRichardi'm on opensuse 15.116:44
kanavinRP: I am just trying to figure out why do we have two copies of conf/conf-notes.txt, in meta and meta-poky16:44
yoctiNew news from stackoverflow: Controlling SAMA5D27-SOM1-EK1 Board LEDS using DEVICE-TREE file in linux kernel <https://stackoverflow.com/questions/57578148/controlling-sama5d27-som1-ek1-board-leds-using-device-tree-file-in-linux-kernel>16:45
*** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto16:46
kanavinRP: as that is where the banner is. maybe best left for tomorrow16:46
kergothhm that reminds me, i dont think i ever got the change merged to split cooker construction from bitbake.conf parsing to allow bitbake-layers to avoid parsing errors due to layer addition/removal order16:50
* kergoth wonders where he put that old branch16:50
*** rewitt <rewitt!rewitt@nat/intel/x-lrrrfyhbatzmlhyu> has quit IRC16:53
*** kaspter <kaspter!~Instantbi@> has quit IRC16:56
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC16:58
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC17:03
*** kaspter <kaspter!~Instantbi@> has joined #yocto17:04
*** vineela <vineela!~vtummala@> has joined #yocto17:08
yoctiNew news from stackoverflow: List packages which will be included in host Yocto SDK <https://stackoverflow.com/questions/57578271/list-packages-which-will-be-included-in-host-yocto-sdk>17:16
*** litb <litb!~js@pd907fca9.dip0.t-ipconnect.de> has quit IRC17:21
*** mischief <mischief!~mischief@wopr.sciops.net> has joined #yocto17:23
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto17:29
mischiefwhat is the right way to make sanity.bbclass use my custom local.conf.sample instead of pokys?17:32
mischiefhm, i suppose i need to make a distro layer.17:38
*** rewitt <rewitt!~rewitt@> has joined #yocto17:40
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC17:42
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto17:51
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto18:13
*** jae1 <jae1!95c73e81@> has joined #yocto18:18
*** JPEW <JPEW!cc4da371@> has joined #yocto18:23
JPEWRP: I think I've figured out how to improve the hash equiv server performance by a factor of 518:27
JPEWThe thing I'm not sure about is how to structure the protocol18:36
rburtonJPEW: have you tried enabling keep-alive?18:45
rburton(or do you already)18:45
rburtonassuming lots of connections come from relatively few clients, that could help a lot18:45
JPEWYa, reusing connections is part of the improvement. Unfortunately, python's urllib doesn't let you do that, so we'll have to manually18:47
rburtoni saw the server can be made to do keep-alive but didn't look at the client18:47
rburtonembed a copy of requests?18:47
JPEWrequests has quite a few dependencies18:48
kergothsome days i wish bitbake was handled the way most python projects are. install with pip, etc. harder due to the tight interdependence with oe-core, though18:48
rburtonkergoth: i absolutely wish that bitbake had a requirements.txt18:49
JPEWkergoth: I really like pipenv... I use it all the time for my projects18:49
kergothpipenv is handy indeed. poetry is pretty nice too18:49
JPEWBut, it might be academic because the other big improvement is to optimize the protocol to not send full HTTP headers for each hash lookup during signature generation18:49
*** stephano <stephano!~stephano@> has quit IRC18:51
JPEWYou can to this over HTTP, using the "Upgrade" header a la websockets. We can negotiate a HTTP connection to a simple byte orientated TCP connection (which is exactly what websockets do)18:51
*** tgraydon <tgraydon!~tgraydon@> has joined #yocto18:51
JPEWSo, we could 1) just use websockets, 2) make our own Upgrade procotcol over HTTP 3) ditch HTTP completely and use a JSON over TCP protocol18:52
denixcan a package that depends on a virtual provider be generic (arch) or should it be marked as machine-specific? as it records the actual provider and not virtual18:52
JPEWEach has advantages and disadvanges.18:52
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto18:57
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC18:57
*** opennandra <opennandra!~marek@90-64-83-226.dynamic.orange.sk> has joined #yocto18:58
denixrburton: maybe you know? see above18:58
rburtonif the provider is machine specific you should make the recipe machine specific18:58
opennandrahello is anybody here with experience with external toolchains used in yocto?19:00
opennandraI have this issue and not sure how to resolve it: https://lists.yoctoproject.org/pipermail/yocto/2019-August/046391.html19:00
denixrburton: so, let's say there are machine-specific providers for GLES in Aarch64 world. does it mean all the recipes that RDEPEND on virtual/libgles1 have to be machine-specific? e.g. gstreamer-plugins-base, etc.19:00
rburtonwould be nice if the apps would link to the generic soname, as the generated deps should be using the generic names too19:05
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC19:06
denixrburton: even when the app links to a generic libGLES.so, the package (at least opkg) ends up recording dependency to a specific machine package (e.g. TI SGX or RPi VC4), even though those are marked as providers for libgles1/2, etc.19:17
kergothafaik it *should* go purely based on the SONAME, so if that doesn't change, it should work..19:18
denixkergoth: what if there are bunch of SONAMEs in a package, but it sets R/PROVIDES for all of them?19:21
kergothdoubt it matters unless you override or disable shlibs, as that goes by soname19:21
* kergoth shrugs19:22
denixkeith: should each lib gets packaged into own package instead of one bundle?19:22
denixkergoth: sorry^^^19:22
*** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC19:25
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto19:40
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto19:55
denixkergoth, rburton: and a related question - even when a package depends on SONAME, different providers will have different versions. the package will have Depends: SONAME (>= X.Y.Z) and X.Y.Z will be widely different per machine19:57
kergothgood point. it sounds like this may be a case where manual is superior to shlibs for rdepends/rprovides handling19:58
denixkergoth, rburton: e.g. gstreamer-plugins-base records it depends on libgles1 (>= 19.0.0) and I have libgles1 for my platform that is lower...19:59
denixkergoth: are there examples of manually driving shlibs rdepends?20:00
kergothnot a clue. ideally we'd only disable it for these libs, otherwise we'd have to also manually add libc, etc20:00
kergothi.e. EXCLUDE_FROM_SHLIBS is likely too large an implement for this case20:01
kergothcheck package.bbclass, thats' where it's handled20:01
denixok, thanks20:02
*** naknick <naknick!b9b8f483@> has quit IRC20:14
*** rcw <rcw!~rcw@> has quit IRC20:18
*** rcw <rcw!~rcw@> has joined #yocto20:19
*** diego_r <diego_r!~diego@wsip-184-188-36-2.sd.sd.cox.net> has joined #yocto20:33
*** diego_r <diego_r!~diego@wsip-184-188-36-2.sd.sd.cox.net> has quit IRC20:56
*** rcw <rcw!~rcw@> has quit IRC21:00
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC21:02
*** diego_r <diego_r!~diego@wsip-184-188-36-2.sd.sd.cox.net> has joined #yocto21:12
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto21:12
*** micka <micka!~micka@reverse-75.fdn.fr> has quit IRC21:14
*** berton <berton!~berton@> has quit IRC21:15
*** micka <micka!~micka@reverse-75.fdn.fr> has joined #yocto21:16
*** diego_r <diego_r!~diego@wsip-184-188-36-2.sd.sd.cox.net> has quit IRC21:19
*** opennandra <opennandra!~marek@90-64-83-226.dynamic.orange.sk> has quit IRC21:21
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC21:23
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto21:37
*** fitzsim <fitzsim!~user@69-165-165-189.dsl.teksavvy.com> has joined #yocto21:59
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC22:00
*** Crofton <Crofton!~Crofton@> has quit IRC22:05
*** diego_r <diego_r!~diego@wsip-184-188-36-2.sd.sd.cox.net> has joined #yocto22:10
*** chinhuat0915 is now known as chinhuat22:15
*** rburton <rburton!~rburton@> has quit IRC22:17
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-emzrtsvlizeykogr> has joined #yocto22:26
*** diego_r <diego_r!~diego@wsip-184-188-36-2.sd.sd.cox.net> has quit IRC22:45
*** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has quit IRC22:46
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC22:47
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC22:59
*** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has joined #yocto23:12
*** diego_r <diego_r!~diego@wsip-184-188-36-2.sd.sd.cox.net> has joined #yocto23:25
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has quit IRC23:40
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has joined #yocto23:41
*** georgem <georgem!~georgem@> has quit IRC23:41
*** georgem <georgem!~georgem@> has joined #yocto23:41
*** diego_r <diego_r!~diego@wsip-184-188-36-2.sd.sd.cox.net> has quit IRC23:50
*** tgraydon <tgraydon!~tgraydon@> has quit IRC23:53

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!