Monday, 2019-03-18

*** chandana73 <chandana73!~ckalluri@149.199.62.130> has quit IRC00:04
*** agust <agust!~agust@p5483354E.dip0.t-ipconnect.de> has quit IRC00:22
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC00:31
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto00:45
*** nighty- <nighty-!~nighty@b157153.ppp.asahi-net.or.jp> has joined #yocto00:50
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC01:00
*** anujm <anujm!~anujm@192.55.54.44> has joined #yocto01:30
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto01:34
*** blueness_ <blueness_!~blueness@gentoo/developer/blueness> has quit IRC01:34
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC01:35
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC01:51
*** blueness_ <blueness_!~blueness@gentoo/developer/blueness> has joined #yocto01:51
*** blueness_ <blueness_!~blueness@gentoo/developer/blueness> has quit IRC01:57
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto01:57
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto02:46
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC03:49
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto03:49
*** Crofton <Crofton!~Crofton@69.7.123.146> has quit IRC03:58
*** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC04:15
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC04:48
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto04:57
*** tensa <tensa!~spline@vm-irc.spline.inf.fu-berlin.de> has quit IRC05:36
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC05:49
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto05:50
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC06:07
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto06:08
*** saraf <saraf!~a_saraf@123.252.238.18> has joined #yocto06:24
*** chandana73 <chandana73!~ckalluri@149.199.62.129> has joined #yocto06:28
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-htispecybreiiiaq> has quit IRC06:31
*** chandana73 <chandana73!~ckalluri@149.199.62.129> has quit IRC06:47
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC06:49
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto06:49
*** thaytan <thaytan!~thaytan@121-200-23-18.79c817.syd.nbn.aussiebb.net> has quit IRC06:51
*** thaytan <thaytan!~thaytan@121-200-23-18.79c817.syd.nbn.aussiebb.net> has joined #yocto06:53
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-arkwdjyttrizhklx> has joined #yocto07:02
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC07:03
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto07:04
*** lfa <lfa!~lfa@213-47-163-50.cable.dynamic.surfer.at> has quit IRC07:06
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC07:13
*** jeanba <jeanba!~jbl@77.243.63.34> has joined #yocto07:20
*** jeanba <jeanba!~jbl@77.243.63.34> has left #yocto07:20
*** tprrt <tprrt!~tprrt@217.114.201.133> has joined #yocto07:32
*** anujm <anujm!~anujm@192.55.54.44> has quit IRC07:38
*** agust <agust!~agust@p5483354E.dip0.t-ipconnect.de> has joined #yocto07:42
*** lfa <lfa!~lfa@217.19.35.51> has joined #yocto07:43
*** mckoan|away is now known as mckoan07:46
mckoangood morning07:46
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC07:49
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto07:49
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC07:49
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC07:50
*** fl0v0 <fl0v0!~fvo@89.244.124.144> has joined #yocto07:53
*** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has quit IRC08:00
*** varjag <varjag!~user@122.62-97-226.bkkb.no> has joined #yocto08:03
*** yacar_ <yacar_!~yacar@87-231-0-37.rev.numericable.fr> has joined #yocto08:07
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto08:13
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:19
*** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto08:20
*** prabhakarlad <prabhakarlad!~prabhakar@194.75.40.178> has joined #yocto08:33
*** SimoneNascivera <SimoneNascivera!~simone@37.180.44.111> has joined #yocto08:36
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:39
SimoneNasciveraHi everyone08:41
SimoneNasciveraIs here anyone that could help my with a simple question?08:42
SimoneNasciveraI have build an image with yocto, then  after building it I tried to add other packages both using bitbake <package> command and also editing locl.conf file but after building the image another time nothings seems to have changed, in other words the packages are not added to the new image08:44
SimoneNasciveraIs there a way to add packages after having compiled an image or should I recompile everything every time?08:44
LetoThe2ndSimoneNascivera: you have to rebuild the image, yes08:46
mckoanSimoneNascivera: first of all ensure you added the packege using IMAGE_INSTALL_append = " packagename"08:46
LetoThe2ndSimoneNascivera:  you have to add whatever you need to the image, be it through IMAGE_INSTALL, CORE_IMAGE_EXTRA_INSTALL (or howsit called), and then rebuild the image.08:47
mckoanSimoneNascivera: then you can call: bitbake yourimagename -C rootfs that Populate rootfs again08:47
LetoThe2ndor just bitbake your_image08:48
LetoThe2ndSimoneNascivera: you have to be aware that this won't recompile everything, it reuses as much as possible. if all packages are already built, this actually just "repackages" everything into the image08:49
SimoneNasciveramckoan: bitbake yourimagename -C rootfs seems to work08:53
SimoneNasciveramckoan: thank you so much08:53
SimoneNasciveramckoan: the command did actually rebuild the rootfs and image file, but it did not add the package to it, even if I added it both in local.conf and using bitbake08:59
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC09:01
yoctiNew news from stackoverflow: create the symlink failed in yocto project <https://stackoverflow.com/questions/55217433/create-the-symlink-failed-in-yocto-project>09:11
*** lfa_ <lfa_!~lfa@217.19.35.51> has joined #yocto09:11
*** lfa <lfa!~lfa@217.19.35.51> has quit IRC09:14
RParmpit: there is a build that consists of bitbake and oe-core, yes. Sorry its causing so much pain :/09:27
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has joined #yocto09:32
*** cvasilak <cvasilak!~cvasilak@ppp-94-64-10-185.home.otenet.gr> has joined #yocto09:40
*** lfa <lfa!~lfa@217.19.35.51> has joined #yocto09:41
*** lfa_ <lfa_!~lfa@217.19.35.51> has quit IRC09:44
*** lfa_ <lfa_!~lfa@217.19.35.51> has joined #yocto09:49
yacar_Hi guys, what is the equivalent of "bitbake virtual/kernel -c menuconfig" for devtool  ?09:51
yacar_is there one ?09:51
yacar_In the end I just want to access linux menuconfig from within devtool09:52
*** lfa <lfa!~lfa@217.19.35.51> has quit IRC09:52
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto10:05
*** SimoneNascivera <SimoneNascivera!~simone@37.180.44.111> has quit IRC10:11
*** lukma <lukma!~lukma@85-222-111-42.dynamic.chello.pl> has quit IRC10:11
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto10:11
*** SimoneNascivera <SimoneNascivera!~simone@37.180.44.111> has joined #yocto10:12
*** lukma <lukma!~lukma@85-222-111-42.dynamic.chello.pl> has joined #yocto10:18
*** ctlnwr_ <ctlnwr_!~catalin@89.121.200.102> has quit IRC10:21
mckoanyacar_: it is a not available option, there is a patch in waiting list: https://patchwork.openembedded.org/patch/141208/10:41
yacar_Ok thanks for the info, but I guess modifying directly my kernel's .config should also do the trick ?10:42
mckoanyacar_: what's the problem using bitbake ?10:42
yacar_It's not really a problem here, it's just for convenience. My use case is this: up to now I was only modifying stuff in the kernel using the SDK, but now that everything is set up I want to add a new driver directly in the kernel and start the development.10:44
*** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto10:44
yacar_Plus I'm not exactly familiar with the gymnastic of going back and forth from yocto to the SDK.10:46
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto10:47
lukmaDear All,10:47
lukmaI would like to ask for a confirmation if my understanding is correct10:47
lukmaThe libstd++ is provided in OE/Yocto as part of gcc-runtime recipe (provided with gcc recipe to be used on target)10:48
lukmaHence the only way to update it (similar to one here: https://forum.linuxgameconsortium.com/t/libstdc-so-6-version-glibcxx-3-4-22-not-found-fix/316)10:48
lukmais to update the recipe, which provide gcc -> e.g. from 6.x to 7.x10:49
mckoanyacar_: if you are building a kernel module, you can do that out of the kernel tree at the beginning10:49
mckoanyacar_: see my presentation "Kernel Modules with eSDK" https://youtu.be/K3Jqvv5q5eI10:49
yacar_mckoan: Thanks :)10:50
*** SimoneNascivera <SimoneNascivera!~simone@37.180.44.111> has quit IRC10:50
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has joined #yocto10:50
alicefhow i modify recipe added with bakekake-layers add-layer11:19
alicefusing devtool modify ?11:20
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has quit IRC11:23
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has joined #yocto11:24
*** berton <berton!~berton@177.194.204.148> has joined #yocto11:24
*** berton <berton!~berton@177.194.204.148> has quit IRC11:32
*** berton <berton!~berton@177.194.204.148> has joined #yocto11:33
*** SimoneNascivera <SimoneNascivera!~SimoneNas@5.90.94.212> has joined #yocto11:41
*** saraf <saraf!~a_saraf@123.252.238.18> has quit IRC11:41
alicefeSDK dosen't automatically update with poky 7e7ee662f5dea4d090293045f7498093322802cc11:45
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto11:49
RPlukma: yes, libstdc++ comes from gcc and you want it to match your compiler11:51
*** SimoneNascivera <SimoneNascivera!~SimoneNas@5.90.94.212> has quit IRC12:05
*** cvasilak <cvasilak!~cvasilak@ppp-94-64-10-185.home.otenet.gr> has quit IRC12:09
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:15
*** yacar_ <yacar_!~yacar@87-231-0-37.rev.numericable.fr> has quit IRC12:26
yoctiNew news from stackoverflow: how to make bitbake print options of do_configure <https://stackoverflow.com/questions/44541876/how-to-make-bitbake-print-options-of-do-configure>12:41
*** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has joined #yocto12:42
*** AndersD_ <AndersD_!~AndersD@194-237-220-218.customer.telia.com> has joined #yocto12:44
*** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has quit IRC12:46
*** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has quit IRC12:47
*** jeanba <jeanba!~jbl@80-62-117-50-mobile.dk.customer.tdc.net> has joined #yocto12:47
*** Crofton <Crofton!~Crofton@69.7.123.146> has joined #yocto12:55
*** jeanba <jeanba!~jbl@80-62-117-50-mobile.dk.customer.tdc.net> has left #yocto12:57
*** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has joined #yocto13:04
*** AndersD__ <AndersD__!~AndersD@194-237-220-218.customer.telia.com> has joined #yocto13:05
*** AndersD_ <AndersD_!~AndersD@194-237-220-218.customer.telia.com> has quit IRC13:06
*** yacar_ <yacar_!~yacar@87-231-0-37.rev.numericable.fr> has joined #yocto13:14
*** aduskett <aduskett!~aduskett@178.128.184.60> has joined #yocto13:19
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has quit IRC13:19
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has joined #yocto13:20
*** aduskett <aduskett!~aduskett@178.128.184.60> has quit IRC13:25
*** gaulishcoin <gaulishcoin!~gaulishco@anice-652-1-371-223.w83-201.abo.wanadoo.fr> has joined #yocto13:30
*** AndersD__ <AndersD__!~AndersD@194-237-220-218.customer.telia.com> has quit IRC13:32
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC13:50
*** benesim <benesim!~bisbarn@p5DF58D12.dip0.t-ipconnect.de> has joined #yocto14:01
vladzouthHi community, i would like to change my kernel version on my build, i make the following change on my local.conf: PREFERRED_VERSION_linux-karo = "4.13%"14:03
vladzouthBut i got the following error:  Multiple versions of linux-karo are due to be built (/home/theoris/projects/EdDUV2_yocto/fsl-community-bsp/sources/meta-fsl-arm-extra/recipes-kernel/linux/linux-karo_4.13.bb /home/theoris/projects/EdDUV2_yocto/fsl-community-bsp/sources/meta-fsl-arm-extra/recipes-kernel/linux/linux-karo_4.1.15.bb). Only one version of a given PN should be built in any given build. You likely need to set PREFERRED_VERSION14:03
vladzouthto select the correct version or don't depend on multiple versions14:03
vladzouthAny idea on how to fix this, thanks in advance !14:04
*** henriknj <henriknj!~hnje@193.106.123.182> has quit IRC14:05
mckoanvladzouth: you can't put PREFERRED_VERSION_linux-karo in local.conf, set it into the MACHINE config file14:08
rburtonyou can generally, unless this bsp is being dumb14:09
mckoanhttps://github.com/Freescale/meta-freescale-3rdparty/blob/master/conf/machine/include/tx6-karo-common.inc14:10
vladzouthmckoan: Ok i will try to do it in machine.conf file14:11
vladzouthrburton: what you are saying is that we can do the modification in local.conf ?14:12
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto14:12
rburtonyou *should* be able to.14:13
vladzouthOK Thanks !14:13
vladzouthI try to put that in local.conf or machine.conf files but it doesn't change anything, i still have the same error14:14
LetoThe2ndquetion for the ptest-gurus around: we have a test-image that does everything nice and clean, but the result of the system ptest runner always seems to be "UNKNOWN", regardless if it runs one of our tests or an included one, and regardless if if passes or not. any pointers?14:14
rburtonLetoThe2nd: does your test output in the format ptest-runner is expecting?14:15
benesimHi there, I was wondering if it would be possible to enable a complete bbappend recipe for a given override (in my particular case that would be libc-musl)14:15
LetoThe2ndrburton: how to check? is it documented?14:15
LetoThe2ndrburton: its not my project, i'm just the community facing part ATM. and $coworker said that he gets "UNKOWN" also for the included test that he tried.14:16
rburtonLetoThe2nd: well, ptest-runner really doesn't care much14:17
rburtonross@flashheart ~/Programming/ptest-runner2 (master)14:17
rburton$ git grep UNKNOWN |wc -l14:17
rburton014:17
rburtonso i think you need to find out what is printing unknown14:18
LetoThe2ndrburton: can you try for lower case or case invariant too please?14:18
LetoThe2ndthen i'll forward it.14:18
rburton$ git grep -i UNKNOWN |wc -l14:18
rburton014:18
rburtoni'd love to see ptest overhauled, maybe mandate TAP-style output for the tests, so we can patch less and reuse more tooling14:19
LetoThe2ndrburton: so in a nutshell, the ptest-runner is not expected to output the literal "unknown" by itself. right?14:19
rburtonptest-runner does not contain the string unknown14:19
rburtonmaybe he means the gnome test runner?14:19
LetoThe2ndrburton: actually $coworker was explicitly pleased with the test-image, that was the only thing he wondered about :)14:19
rburtonLetoThe2nd: we've got more tooling now, RP did some great work if you're going to be running ptest images often you might want to find out what we have (because I can never remember)14:20
LetoThe2ndrburton: yeah, i was aware that there has been recent work, thats why i also asked.14:21
RPLetoThe2nd, rburton: UNKNOWN sounds like something coming from python unittest14:24
RPLetoThe2nd: ptest in testimage is handled a little differently since there is no one exit status that can tell us what we need to know. Its likely some ptest will always fail14:24
RPLetoThe2nd: instead we report the ptest results separately. If all the ptests pass it should show success though14:25
LetoThe2ndRP: yes exactly. $coworker says that he gets the seperate results in seperate logs, all is well. he just wondered about the "net" result.14:25
LetoThe2ndRP: any pointer i can give him to dig deeper?14:26
RPLetoThe2nd: what behaviour do they want?14:27
LetoThe2ndRP: "show PASS or FAIL" :)14:28
RPLetoThe2nd: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oeqa/runtime/cases/ptest.py14:28
* RP notes the @unittest.expectedFailure14:28
RPLetoThe2nd: also, https://bugzilla.yoctoproject.org/show_bug.cgi?id=1315014:29
yoctiBug 13150: normal, Medium+, 2.7 M3, richard.purdie, NEW , Test report contains UNKNOWN status when tests were skipped14:29
*** yates <yates!~user@rrcs-96-10-234-158.midsouth.biz.rr.com> has joined #yocto14:29
RPLetoThe2nd: so I suspect "expected failures" aren't being handled correctly14:29
yateswhat package provides gdbserver ?14:29
RPyates: gdbserver?14:30
LetoThe2ndRP: ah ok, so its basically "a bug"14:30
yatesnm14:30
yatesno, it's gdb14:30
RPyates: nm is in binutils14:30
RPyates: gdb is the recipe in the gdbserver package14:30
RPLetoThe2nd: approximately speaking14:31
LetoThe2ndRP: thanks! don't get me wrong, he explicitly pointed out that he liked the whole construction very much. its just in discussion that i told him there has been recent work, and so he asked me to check with folks here if it might be due to exactly that rework before her really goes digging deeper.14:32
RPLetoThe2nd: I think its somewhere between that bug I linked to and the fact we "expect" ptest to fail which has a special status in py unitest14:34
RPLetoThe2nd: glad they liked it and any help in improving gratefully received14:35
LetoThe2ndRP: could you elaborate on "expect to fail?"14:35
LetoThe2ndRP: now that we've got the context sorted out i'll see if we can help improve or will just live with the current state. no promises there, sorry.14:36
RPLetoThe2nd: https://docs.python.org/3/library/unittest.html#skipping-tests-and-expected-failures14:36
RPLetoThe2nd: its a unittest outcome (pass, fail, skip, expectedFail, unexpectedSuccess, unknown)14:37
LetoThe2ndRP: i see, thanks. I'll forward this, and if we can help I'll let you know.14:38
RPLetoThe2nd: we will likely improve things, just other priorities right now14:39
*** chandana73 <chandana73!~ckalluri@149.199.62.130> has joined #yocto14:39
yatesRP: whatever. i bitbake gdb, not bitbake gdbserver14:47
yatesit generates a package gdb, which i then smart install as gdb. sounds like gdb is the package to me14:47
*** benesim <benesim!~bisbarn@p5DF58D12.dip0.t-ipconnect.de> has quit IRC15:14
yatesrburton: were you able to discern any other changes to the matchbox window manager recipe? just patching so that the --enable-composite option builds still did not provide transparency15:15
yateswhere are the latest oe recipes maintained?15:18
*** jcelerier <jcelerier!~kdab@static-176-159-162-190.ftth.abo.bbox.fr> has joined #yocto15:28
jcelerierhello :-)15:28
jcelerierI have a problem while trying to build an image with its sdk :15:28
jcelerierProblem: package perl-module-overload-5.24.4-r0.armv7at2hf_neon requires perl-module-warnings-register, but none of the providers can be installed15:28
jcelerier(fsl-image-machine-test from fsl-community-bsp)15:28
jcelerierbuilding the image in itself works correctly15:28
jcelerierwhere should I look in order to be able to fix this ?15:29
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto15:36
sveinseI tried compiling a qemux86 image of a Qt application (non-gui). When I fire up qemu and try to run it, I get SIGILL, illegal instruction from libQt5Core.so. Any ideas in how to apprach this? Am I running my qemu correctly?15:38
sveinseI noticed that I cannot run runqemu myimage straight out of the box, its complaining about "*.qemuboot.conf: No such file or directory". When I give it the .ext4 image specifically, I get the VM prompt15:39
RPyates: my point is to ask about recipes, not packages then. Two different things, say what you mean! :)15:39
armpitRP, regarding the oecore only build, it means changes have to be done in three repos Poky, core and bitbake for each and every mut and next style builds.15:42
armpitif not, than any quick build is in accurate15:43
armpitcan we move that build to full ?15:44
sveinserunqemu fails with "runqemu - ERROR - Command 'ls -t /home/sveinse/build-qemu/build/tmp/deploy/images//*.qemuboot.conf' returned non-zero exit status 2.", which seems to me to come from "bitbake -e", so perhaps the "//" is an indication that I'm missing setting a variable in my image?15:44
*** varjag <varjag!~user@122.62-97-226.bkkb.no> has quit IRC15:46
RParmpit: I guess I've just been aware its a known weakness. My -next builds are run in three different branches15:47
armpitdoes Ross's ?15:48
armpitmaster-next is not part of this as its updated by you at the same time15:49
RParmpit: no, mut doesn't15:50
RParmpit: You can easily replicate my scripts/setup if it bothers you but I really would try just not to worry about that build. Just be aware of what it represents15:51
armpitk, now that I now I will adjust my process15:51
armpitthe good thing it stagged sumo changes are good for a pull request so we can get the next point release started15:53
RParmpit: apart from testresult and the -helper changes? :/15:55
armpiterr, fine... I still want the batch of my plate to then get thud sorted for those needed changes15:56
RParmpit: that is fine, one step at a time15:58
RParmpit: I'm happy to help with this, I just need M3 built using the new process/tools15:58
sveinseIt is related to DEPLOY_DIR_IMAGE, which in turn is dependent on MACHINE. Now, unless MACHINE is explicitly defined (MACHINE=) in either local.conf or as enviroment, this variable is wrong. It is not correct if MACHINE is weakly defined using MACHINE?= or MACHINE??=16:00
sveinseIsn't this somewhat unexpected behaviour?16:00
yateshas anyone ever seen the matchbox window manager compositing work so that transparency works? e.g., putting a wxPanel on a wxFrame that is transparent? (speaking in terms of wxWidgets)?16:12
yatesrburton: have you?16:13
*** sk_tandt_ <sk_tandt_!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto16:15
*** chandana73 <chandana73!~ckalluri@149.199.62.130> has quit IRC16:17
*** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC16:19
*** sk_tandt_ <sk_tandt_!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC16:20
yatesrburton: i see you've done some work on the latest versions of matchbox-wm - could ypu please respond to my previous question?16:28
yatesnamely, have you ever seen the matchbox window manager compositing work so that transparency works? e.g., putting a wxPanel on a wxFrame that is transparent? (speaking in terms of wxWidgets)?16:28
yatesas i stated a couple of weeks back, this works under desktop linux (presumably because it has a decent compositor) but does NOT work with mbwm, even though i've recompiled to enable the repositor (and patched the -lm problem)16:29
*** tsjsieb <tsjsieb!~quassel@2a06:5b80:1::2be3:ec4> has quit IRC16:30
rburtonyates: as i said last time, wm compositing has nothing to do with alpha blending inside the windows16:30
yatesthen what does?16:30
yatesdo you have any clue why my transparency works under desktop linux but not under yocto linux (using wxwidgets)?16:32
*** tsjsieb <tsjsieb!~quassel@2a06:5b80:1::2be3:ec4> has joined #yocto16:32
rburtonyates: wxwidgets16:34
rburtonbecause you can't get a 32-bit visual maybe?  because wxwidgets doesn't have compositing enabled?16:34
yateswhat do you mean by a "32-bit visual"?16:35
rburton*how* does wx do transparency16:35
rburtongtk+ does it by just drawing everything onto a single X surface16:35
rburtonso it has complete control16:35
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:35
rburtonkergoth: the one thing that article is missing is a list of five blessed licenses we can all move to slowly16:35
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC16:36
yatesi don't know16:36
rburtonyates: i'd be asking the wx channel what would explain your behaviour, instead of asking people who have never used wx16:37
yateswell i have been. no one seems to know there, and i thought there may be some people here who have used wx16:38
yatesperhaps i should just dive into the wx source16:38
yatesand i thought you said a week or two ago yourself that the problem was because compositing was not enabled on mbwm..16:39
rburtonyou said window transparency :)16:39
yatesoh16:40
rburtondon't even know what a wxframe *is*16:40
yatesprobably don't care, either?16:40
yates:)16:40
rburtonif a wxframe is a top-level then you care for window-level transparency16:41
yateshttps://docs.wxwidgets.org/3.0/classwx_frame.html16:41
rburtonif its not then you care about wx-level, but as all i know about wx is that it basically wraps other toolkits then it depends on what the toolkit can do16:41
yatesyes, it is16:41
rburtonie i doubt gtk2 can do that16:41
yatesi.e., a wxFrame is the top level client area of the window16:42
yatesperhaps it is the case that my desktop linux wx is based on gtk3 but the embedded yocto wx is based on gtk216:43
rburtoni see to recall this is your wx recipe16:44
rburtongtk2 is so unmaintained and dead its not even funny, so if you're doing that then switch to gtk3 before gtk4 is released16:44
yatesok, right. looking into it now16:44
yatesyes, it is my recipe16:45
rburtondid you submit it to meta-oe yet?16:45
yatesno. i guess i should?16:46
rburtonyes16:46
armpitRP, i just sent a revert for boost. I am starting a build just to make sure it does break something. I'll let you know if its ok16:46
RParmpit: "to make sure it does break something" ? :)16:46
RParmpit: is this a new policy?16:46
armpithehe16:49
JaMa:)16:49
armpitI am finding doing things wrong unites the community16:50
rburtoni thought that was policy?16:50
JaMaunites the community against common enemy? :)16:50
yatesok16:50
armpitrburton, I changed wiki so it must be true ; )16:50
armpitthe Internet does not lie16:51
armpitJaMa, thats right.. I am the unifier16:51
yatesrburton: my wx recipe DEPENDS on gtk+. it's kinda confusing to me which version (2 or 3) this grabs. if these are my gtk+ recipes, which would be grabbed? https://paste.fedoraproject.org/paste/1H3iOrxeIKCJMXi25EFo5w16:51
* JaMa just noticed "Having difficulty on the list, or with someone on the list?" in the topic :)16:51
rburtonyates: thats 216:52
rburtonyates: the gtk3 recipe is called gtk316:52
*** chandana73 <chandana73!~ckalluri@149.199.62.129> has joined #yocto16:52
yatesnot gtk+3?16:52
rburtonno, because the depends is gtk+16:52
rburtonso you're after the recipe called gtk+_<version>16:52
rburtonnot gtk+3_<version>16:52
rburtonfilename is name_version16:52
RParmpit: I'm now wondering if each change can only break one thing or if multiple breakages are allowed if specified in the commit message :)16:54
sveinseAny quick proposals off the bat why libQt5Core SIGILLs when building it for qemux86 and running in qemu? Does it ring any bells to anyone?16:54
RPsveinse: wrong processor being emulated by qemu?16:55
JaMasveinse: yes, probably wrong -cpu parameter, but it should show an warning before dying like that16:55
rburtonsveinse: because qt is ignoring the tune, trying to use cool instructions, and qemu is being told to emulate a machine that doesn't have those instructions.    *might* be because qemux86 machine and qemu invocation don't match, but i thought we'd aligned those.16:56
JaMasveinse: unless you see the SIGILL somewhere in mesa/llvm stack which is what I'm seeing now even with correct -cpu16:56
sveinseRP: yeah, I suspected. Yet, runqemu prints MACHINE: [qemux86], which I believe should be correct16:56
JaMasveinse: something like this? https://paste.ubuntu.com/p/PDnnJGvFw8/16:56
yatesso i should DEPENDS gtk+_3.20.9?16:57
sveinseJaMa: alledgedly the app is a non-GUI, but I'll have to confirm that, so for now, all possible causes are open I suppose16:57
RPyates: no. DEPENDS += "gtk+3"16:57
RPyates: gtk+ and gtk+3 are two different recipe PN16:58
JaMasveinse: FWIW by backtrace is from VirtualBox, not QEmu16:58
yatesoh.16:58
*** fl0v0 <fl0v0!~fvo@89.244.124.144> has quit IRC17:00
rburtonsveinse: you can attach a gdb to the app inside qemu and watch what instruction it crashes on17:00
sveinseJaMa: no, it seems, its only dl_open and libQt5Core in the bt before dying. I need to install the -dbg packages in this image so that I can get more sensible data from it17:01
JaMasveinse: ok, might still be the -cpu parameter, a bit more details here: http://lists.openembedded.org/pipermail/openembedded-core/2018-April/150173.html17:03
sveinseI need to debug more on this on my own. How can I know that -cpu parameter I should have for qemux86? Is there somewhere I can look at for .... right, thanks :D17:03
JaMasveinse: are you using runqemu script? IIRC it shows the whole cmd line used to execute qemu (which includes the -cpu parameter)17:04
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has quit IRC17:04
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has joined #yocto17:06
sveinseJaMa, yes I do, https://bpaste.net/show/91efc35c360c .17:07
JaMa-cpu pentium2 shown on last line17:08
*** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has joined #yocto17:09
*** mckoan is now known as mckoan|away17:10
sveinseThe qt configure log is lost in the sstate cache, but AFAICR I think it does compile with sse options. I think I've seen that.17:10
JaMawhich is the default for 32bit qemux8617:10
JaMameta/conf/machine/include/qemuboot-x86.inc:QB_CPU_x86 = "-cpu pentium2"17:10
JaMameta/conf/machine/include/qemuboot-x86.inc:QB_CPU_KVM_x86 = "-cpu pentium2"17:10
sveinseAllright, I need to test more tomorrow. Thanks JaMa17:15
sveinseOh, btw, I picked qemux86 just by random (and because my HW system is 32-bit arm). Is it likely that this would be fixed if I compiled the whole thing for qemux64?17:17
sveinse(at this point we dont really know if its -cpu related thou)17:18
rburtonsveinse: if you're using qemu for random emulation then yes, use qemux86-64 and turn on QEMU_USE_KVM17:19
rburtonmaximal performance that way17:19
JaMasveinse: as first test you can run the qemu manually and edit the cpu parameter17:19
sveinserburton: thanks. Then I'll recompile for x64. It takes a while, so great to start in the evening17:21
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC17:32
yatesrburton: are you saying i need both gtk+ and gtk+3 in my DEPENDS?17:33
rburtonno17:33
rburtongtk+ is a recipe17:33
rburtonso is gtk+317:33
yatesok17:33
rburtonyou depend on gtk+, which is gtk+ 2.something17:33
rburton(which has been unmaintained for not a long way off a decade now)17:34
rburtonjust change it to gtk+317:34
yatesbut when i changed the gtk+ to gtk+3 i am now getting "WARNING: wxwidgets-3.0.4-r0 do_package_qa: QA Issue: wxwidgets rdepends on gtk+, but it isn't a build dependency, missing gtk+ in DEPENDS or PACKAGECONFIG? [build-dep17:34
yatesDEPENDS = "webkitgtk gstreamer gtk+3 jpeg tiff libpng zlib expat libxinerama libglu"17:34
rburtonso it still links to gtk217:34
rburtonyou'll need to figure out how to change that17:34
yatesis it perhaps this? BINCONFIG_GLOB = "arm-fslc-linux-gnueabi-gtk2-unicode-3.0"17:35
rburtonno17:35
yatesi've forgotten what BINCONFIG_GLOB does17:35
rburtonthats the glob that tells the binconfig class where the scripts to rewrite are17:36
rburtonyou'll want a lot more * in there17:36
yateshere is the entire recipe now: https://paste.fedoraproject.org/paste/01VykQ~dpLwTgejHpEAoVA17:36
rburtonie any build that isn't gtk2 for arm using freescale won't have that filename17:36
rburtoni'm guessing you need to look how to build wx and tell it what backend to use17:36
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC17:43
rburtonyates: if you haven't found it, AC_ARG_WITH(gtk,  [[  --with-gtk[=VERSION]    use GTK+, VERSION can be 4 (EXPERIMENTAL), 3, 2 (default), 1 or "any"]],17:47
*** yacar_ <yacar_!~yacar@87-231-0-37.rev.numericable.fr> has quit IRC17:48
*** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-091-089-212-176.hsi2.kabel-badenwuerttemberg.de> has quit IRC17:52
yatesrburton: i had not. are you saying this would be a separate line in the recipe file?17:54
rburtonyates: if you run ./configure --help for wxwidgets you'll see "--with-gtk=VERSION etc etc"17:54
rburtonso that tells you how to tell it to use gtk317:54
yatesaha.17:55
yatesi found that removing the webkitgtk DEPENDS caused the build to complete without that do_package_qa warning. do you think i still need to look into this?17:56
*** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-091-089-212-176.hsi2.kabel-badenwuerttemberg.de> has joined #yocto17:56
yatesmy conjecture was that webkitgtk itself DEPENDSed on gtk+ (2)17:56
yatesi'll try it  - what the heck17:57
psrcodeRP: do you have a link with console output for the https://autobuilder.yocto.io/pub/non-release/20190318-7/testresults/ failure?18:04
jae1Hi Does anyone know if there is a reason why the devtool build command doesnt run 'deploy' task?18:12
jae1Right now its only running build task, populate sysroot, packagedata18:12
*** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has joined #yocto18:12
jae1would there be any reasons to not stick deploy into the tasklist for devtool build?18:13
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC18:14
*** jcelerier <jcelerier!~kdab@static-176-159-162-190.ftth.abo.bbox.fr> has quit IRC18:17
*** black_13 <black_13!927305a2@gateway/web/freenode/ip.146.115.5.162> has joined #yocto18:20
black_13how do you force the rebuild of an indivisual recipe18:20
black_13individual18:20
black_13or just build an individual recipe18:25
yatesblack_13: bitbake <recipe-name>18:29
black_13can you provide the full path name18:30
yatesno18:30
yatesjust the recipe name. if you're rebuilding svn, then "bitbake svn"18:32
yatesthe specified layers determine which specific recipe and bbappends (if any) are used18:32
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC18:36
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto18:36
black_13yah18:40
kergothblack_13: to force a rebuild, just bitbake -c clean somerecipe; bitbake somerecipe. that won't necessarily rebuild from scratch, however, it'll pull from the sstate cache to use the prebuilt binaries. to rebuild from scratch, bitbake -c clean somerecipe; bitbake -C fetch somerecipe; is the most reliable method. there is -c cleansstate, but if sstate mirrors are involved, it may still download and use those rather thanj building from scratch, whereas -C18:42
kergoth will force the tasks to run18:42
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:02
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC19:07
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto19:08
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC19:13
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto19:14
jonmasonRP: can I close https://bugzilla.yoctoproject.org/show_bug.cgi?id=12499 as "won't fix"?19:22
yoctiBug 12499: normal, Low, Future, jon.mason, NEW , [2.5 M1 RC3] qemuarm: failed to shutdown19:22
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-arkwdjyttrizhklx> has quit IRC19:52
*** tprrt <tprrt!~tprrt@217.114.201.133> has quit IRC19:58
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC19:59
yatesrburton: modifying wx ./configure options... :)20:30
rburtonyates: no.... passing the right one via EXTRA_OECONF20:30
rburton--help tells you the available options, pass the right one to configure20:30
yatesrburton: does that work in morty?20:31
rburtonpassing options to configure scripts has literally always worked20:31
yatesok, great20:31
yatesthanks20:31
rburtonprobably worth reading how autotools.bbclass works too20:32
yatesFor information on how this variable works within that class, see the meta/classes/autotools.bbclass file.20:34
yateswow, self-documenting code...20:35
sveinseDoes yocto have any mechanisms for compiling an installable package using the SDK?20:36
sveinseBecause it is nice and well to make recipes with packages in Yocto, yet Yocto and bitbake is not for everyone. Especially for those who are working with component development and are more or less ignorant to the workings of bitbake. The SDK provides a toolchain, and it does provide target deployment, but does it allow producing something that could be used as a package feed?20:38
yatessveinse: i like your idea20:39
yoctiNew news from stackoverflow: How to add users at build time via Yocto? <https://stackoverflow.com/questions/55229706/how-to-add-users-at-build-time-via-yocto>20:43
black_13is there predifined file for the root directory for the bitbake recipe20:53
yatesblack_13: i don't understand your question. recipes are under <yoctoproject>/sources in various places20:56
yatessources/poky, sources/meta-mycompany, etc...20:57
black_13there is a ${D} and ${system} is there something that represents /root20:58
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto21:01
*** likewise <likewise!~leon@145.132.74.106> has joined #yocto21:04
*** jeanba <jeanba!~jbl@80-62-117-50-mobile.dk.customer.tdc.net> has joined #yocto21:05
*** jeanba <jeanba!~jbl@80-62-117-50-mobile.dk.customer.tdc.net> has left #yocto21:05
yatesblack_13: you can find those types of definitions in <>/sources/poky/meta/conf/bitbake.conf21:14
yatesnot sure, to answer your question21:14
black_13${IMAGE_ROOTFS} is the answer21:17
*** berton <berton!~berton@177.194.204.148> has quit IRC21:20
sveinseJaMa: If you're still around: This is the config for Qt on MACHINE="emux86" https://bpaste.net/show/be5acd9f2fdb - Most noticable: "Building for: linux-oe-g++ (i386, CPU features: <none>)"21:20
JaMaAVX .................................. AVX AVX221:23
JaMayou don't have AVX2 in emulated pentium2 I believe21:23
JaMachange the cpu parameter to see if it helps21:23
sveinseThanks, I'll try.21:25
sveinseThe Qt configure output is a little vague on what "Target compilers supports" really mean. Does it literally mean what the compiler supports, or does it imply what the output is build with...21:26
JaMait says that target compiler supports these (not that it's actually going to use them, but lets assume it does which would explain the SIGILL, but doesn't explain why it doesn't show readable error about missing instructions like with ssse3 in my case21:26
JaMait could be that in your case it crashes before it even reaches the point where it verifies the features of the cpu it's running on21:27
sveinseI'm attempting to make an image with qtbase-dbg21:28
JaMachanging -cpu is much faster than rebuilding anything, but your call21:29
RPpsrcode: the console output is embedded in there, extracting it is a pain, I have a "todo" item for that :(21:31
RPpsrcode: specifically its embeddedin https://autobuilder.yocto.io/pub/non-release/20190318-7/testresults/qemux86-64-ptest/testresults.json21:31
RPpsrcode: I'll get it out soon, just several things to do right now (including sleep) :/21:32
RPjonmason: yes, we can close that now21:32
sveinseJaMa: Yeah, that did work. I picked -cpu Haswell by random, and now the Qt app is running. Thanks21:35
sveinseNot sure how high up I need to go for this thou. My insight into the intel gens are limited21:35
sveinseBut as rburton suggested if I understood him correctly, running a qemux86_64 when my host is running a 64-os is perhaps more efficient, so I'll attempt that.21:38
black_13${WORKDIR} represents what21:38
*** aehs29 <aehs29!~aehs29@149.199.62.131> has joined #yocto21:41
JaMasveinse: yes, qemux86-64 can be more efficient but the default -cpu might be too high for your host (like it was for me in the e-mail thread I've shared before)21:41
yateswhy am i getting  this package qa error? i don't remember getting it previously.21:47
sveinseJaMa: yep. got it.21:49
*** black_13 <black_13!927305a2@gateway/web/freenode/ip.146.115.5.162> has quit IRC21:58
yatesTHIS error: https://paste.fedoraproject.org/paste/X3zRAOZ-34AzWwmOAVOVTQ22:01
JaMabecause /usr/lib/wx/3.0/web-extensions/webkit2_extu-3.0.so doesn't belong to -dev package22:13
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has quit IRC22:54
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has joined #yocto22:54
*** agust <agust!~agust@p5483354E.dip0.t-ipconnect.de> has quit IRC23:23
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC23:26
*** gaulishcoin <gaulishcoin!~gaulishco@anice-652-1-371-223.w83-201.abo.wanadoo.fr> has quit IRC23:43
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC23:57

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