*** chandana73 <chandana73!~ckalluri@149.199.62.130> has quit IRC | 00:04 | |
*** agust <agust!~agust@p5483354E.dip0.t-ipconnect.de> has quit IRC | 00:22 | |
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 00:31 | |
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 00:45 | |
*** nighty- <nighty-!~nighty@b157153.ppp.asahi-net.or.jp> has joined #yocto | 00:50 | |
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 01:00 | |
*** anujm <anujm!~anujm@192.55.54.44> has joined #yocto | 01:30 | |
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto | 01:34 | |
*** blueness_ <blueness_!~blueness@gentoo/developer/blueness> has quit IRC | 01:34 | |
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC | 01:35 | |
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC | 01:51 | |
*** blueness_ <blueness_!~blueness@gentoo/developer/blueness> has joined #yocto | 01:51 | |
*** blueness_ <blueness_!~blueness@gentoo/developer/blueness> has quit IRC | 01:57 | |
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto | 01:57 | |
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 02:46 | |
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 03:49 | |
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 03:49 | |
*** Crofton <Crofton!~Crofton@69.7.123.146> has quit IRC | 03:58 | |
*** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 04:15 | |
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 04:48 | |
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 04:57 | |
*** tensa <tensa!~spline@vm-irc.spline.inf.fu-berlin.de> has quit IRC | 05:36 | |
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 05:49 | |
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 05:50 | |
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 06:07 | |
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 06:08 | |
*** saraf <saraf!~a_saraf@123.252.238.18> has joined #yocto | 06:24 | |
*** chandana73 <chandana73!~ckalluri@149.199.62.129> has joined #yocto | 06:28 | |
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-htispecybreiiiaq> has quit IRC | 06:31 | |
*** chandana73 <chandana73!~ckalluri@149.199.62.129> has quit IRC | 06:47 | |
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 06:49 | |
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 06:49 | |
*** thaytan <thaytan!~thaytan@121-200-23-18.79c817.syd.nbn.aussiebb.net> has quit IRC | 06:51 | |
*** thaytan <thaytan!~thaytan@121-200-23-18.79c817.syd.nbn.aussiebb.net> has joined #yocto | 06:53 | |
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-arkwdjyttrizhklx> has joined #yocto | 07:02 | |
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 07:03 | |
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 07:04 | |
*** lfa <lfa!~lfa@213-47-163-50.cable.dynamic.surfer.at> has quit IRC | 07:06 | |
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 07:13 | |
*** jeanba <jeanba!~jbl@77.243.63.34> has joined #yocto | 07:20 | |
*** jeanba <jeanba!~jbl@77.243.63.34> has left #yocto | 07:20 | |
*** tprrt <tprrt!~tprrt@217.114.201.133> has joined #yocto | 07:32 | |
*** anujm <anujm!~anujm@192.55.54.44> has quit IRC | 07:38 | |
*** agust <agust!~agust@p5483354E.dip0.t-ipconnect.de> has joined #yocto | 07:42 | |
*** lfa <lfa!~lfa@217.19.35.51> has joined #yocto | 07:43 | |
*** mckoan|away is now known as mckoan | 07:46 | |
mckoan | good morning | 07:46 |
---|---|---|
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 07:49 | |
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 07:49 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 07:49 | |
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 07:50 | |
*** fl0v0 <fl0v0!~fvo@89.244.124.144> has joined #yocto | 07:53 | |
*** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has quit IRC | 08:00 | |
*** varjag <varjag!~user@122.62-97-226.bkkb.no> has joined #yocto | 08:03 | |
*** yacar_ <yacar_!~yacar@87-231-0-37.rev.numericable.fr> has joined #yocto | 08:07 | |
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 08:13 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 08:19 | |
*** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto | 08:20 | |
*** prabhakarlad <prabhakarlad!~prabhakar@194.75.40.178> has joined #yocto | 08:33 | |
*** SimoneNascivera <SimoneNascivera!~simone@37.180.44.111> has joined #yocto | 08:36 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 08:39 | |
SimoneNascivera | Hi everyone | 08:41 |
SimoneNascivera | Is here anyone that could help my with a simple question? | 08:42 |
SimoneNascivera | I 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 image | 08:44 |
SimoneNascivera | Is there a way to add packages after having compiled an image or should I recompile everything every time? | 08:44 |
LetoThe2nd | SimoneNascivera: you have to rebuild the image, yes | 08:46 |
mckoan | SimoneNascivera: first of all ensure you added the packege using IMAGE_INSTALL_append = " packagename" | 08:46 |
LetoThe2nd | SimoneNascivera: 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 |
mckoan | SimoneNascivera: then you can call: bitbake yourimagename -C rootfs that Populate rootfs again | 08:47 |
LetoThe2nd | or just bitbake your_image | 08:48 |
LetoThe2nd | SimoneNascivera: 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 image | 08:49 |
SimoneNascivera | mckoan: bitbake yourimagename -C rootfs seems to work | 08:53 |
SimoneNascivera | mckoan: thank you so much | 08:53 |
SimoneNascivera | mckoan: 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 bitbake | 08:59 |
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC | 09:01 | |
yocti | New 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 #yocto | 09:11 | |
*** lfa <lfa!~lfa@217.19.35.51> has quit IRC | 09:14 | |
RP | armpit: 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 #yocto | 09:32 | |
*** cvasilak <cvasilak!~cvasilak@ppp-94-64-10-185.home.otenet.gr> has joined #yocto | 09:40 | |
*** lfa <lfa!~lfa@217.19.35.51> has joined #yocto | 09:41 | |
*** lfa_ <lfa_!~lfa@217.19.35.51> has quit IRC | 09:44 | |
*** lfa_ <lfa_!~lfa@217.19.35.51> has joined #yocto | 09: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 devtool | 09:52 |
*** lfa <lfa!~lfa@217.19.35.51> has quit IRC | 09:52 | |
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 10:05 | |
*** SimoneNascivera <SimoneNascivera!~simone@37.180.44.111> has quit IRC | 10:11 | |
*** lukma <lukma!~lukma@85-222-111-42.dynamic.chello.pl> has quit IRC | 10:11 | |
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 10:11 | |
*** SimoneNascivera <SimoneNascivera!~simone@37.180.44.111> has joined #yocto | 10:12 | |
*** lukma <lukma!~lukma@85-222-111-42.dynamic.chello.pl> has joined #yocto | 10:18 | |
*** ctlnwr_ <ctlnwr_!~catalin@89.121.200.102> has quit IRC | 10:21 | |
mckoan | yacar_: 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 |
mckoan | yacar_: 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 #yocto | 10: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 #yocto | 10:47 | |
lukma | Dear All, | 10:47 |
lukma | I would like to ask for a confirmation if my understanding is correct | 10:47 |
lukma | The libstd++ is provided in OE/Yocto as part of gcc-runtime recipe (provided with gcc recipe to be used on target) | 10:48 |
lukma | Hence 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 |
lukma | is to update the recipe, which provide gcc -> e.g. from 6.x to 7.x | 10:49 |
mckoan | yacar_: if you are building a kernel module, you can do that out of the kernel tree at the beginning | 10:49 |
mckoan | yacar_: see my presentation "Kernel Modules with eSDK" https://youtu.be/K3Jqvv5q5eI | 10:49 |
yacar_ | mckoan: Thanks :) | 10:50 |
*** SimoneNascivera <SimoneNascivera!~simone@37.180.44.111> has quit IRC | 10:50 | |
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has joined #yocto | 10:50 | |
alicef | how i modify recipe added with bakekake-layers add-layer | 11:19 |
alicef | using devtool modify ? | 11:20 |
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has quit IRC | 11:23 | |
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has joined #yocto | 11:24 | |
*** berton <berton!~berton@177.194.204.148> has joined #yocto | 11:24 | |
*** berton <berton!~berton@177.194.204.148> has quit IRC | 11:32 | |
*** berton <berton!~berton@177.194.204.148> has joined #yocto | 11:33 | |
*** SimoneNascivera <SimoneNascivera!~SimoneNas@5.90.94.212> has joined #yocto | 11:41 | |
*** saraf <saraf!~a_saraf@123.252.238.18> has quit IRC | 11:41 | |
alicef | eSDK dosen't automatically update with poky 7e7ee662f5dea4d090293045f7498093322802cc | 11:45 |
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 11:49 | |
RP | lukma: yes, libstdc++ comes from gcc and you want it to match your compiler | 11:51 |
*** SimoneNascivera <SimoneNascivera!~SimoneNas@5.90.94.212> has quit IRC | 12:05 | |
*** cvasilak <cvasilak!~cvasilak@ppp-94-64-10-185.home.otenet.gr> has quit IRC | 12:09 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 12:15 | |
*** yacar_ <yacar_!~yacar@87-231-0-37.rev.numericable.fr> has quit IRC | 12:26 | |
yocti | New 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 #yocto | 12:42 | |
*** AndersD_ <AndersD_!~AndersD@194-237-220-218.customer.telia.com> has joined #yocto | 12:44 | |
*** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has quit IRC | 12:46 | |
*** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has quit IRC | 12:47 | |
*** jeanba <jeanba!~jbl@80-62-117-50-mobile.dk.customer.tdc.net> has joined #yocto | 12:47 | |
*** Crofton <Crofton!~Crofton@69.7.123.146> has joined #yocto | 12:55 | |
*** jeanba <jeanba!~jbl@80-62-117-50-mobile.dk.customer.tdc.net> has left #yocto | 12:57 | |
*** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has joined #yocto | 13:04 | |
*** AndersD__ <AndersD__!~AndersD@194-237-220-218.customer.telia.com> has joined #yocto | 13:05 | |
*** AndersD_ <AndersD_!~AndersD@194-237-220-218.customer.telia.com> has quit IRC | 13:06 | |
*** yacar_ <yacar_!~yacar@87-231-0-37.rev.numericable.fr> has joined #yocto | 13:14 | |
*** aduskett <aduskett!~aduskett@178.128.184.60> has joined #yocto | 13:19 | |
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has quit IRC | 13:19 | |
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has joined #yocto | 13:20 | |
*** aduskett <aduskett!~aduskett@178.128.184.60> has quit IRC | 13:25 | |
*** gaulishcoin <gaulishcoin!~gaulishco@anice-652-1-371-223.w83-201.abo.wanadoo.fr> has joined #yocto | 13:30 | |
*** AndersD__ <AndersD__!~AndersD@194-237-220-218.customer.telia.com> has quit IRC | 13:32 | |
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 13:50 | |
*** benesim <benesim!~bisbarn@p5DF58D12.dip0.t-ipconnect.de> has joined #yocto | 14:01 | |
vladzouth | Hi 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 |
vladzouth | But 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_VERSION | 14:03 |
vladzouth | to select the correct version or don't depend on multiple versions | 14:03 |
vladzouth | Any idea on how to fix this, thanks in advance ! | 14:04 |
*** henriknj <henriknj!~hnje@193.106.123.182> has quit IRC | 14:05 | |
mckoan | vladzouth: you can't put PREFERRED_VERSION_linux-karo in local.conf, set it into the MACHINE config file | 14:08 |
rburton | you can generally, unless this bsp is being dumb | 14:09 |
mckoan | https://github.com/Freescale/meta-freescale-3rdparty/blob/master/conf/machine/include/tx6-karo-common.inc | 14:10 |
vladzouth | mckoan: Ok i will try to do it in machine.conf file | 14:11 |
vladzouth | rburton: 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 #yocto | 14:12 | |
rburton | you *should* be able to. | 14:13 |
vladzouth | OK Thanks ! | 14:13 |
vladzouth | I try to put that in local.conf or machine.conf files but it doesn't change anything, i still have the same error | 14:14 |
LetoThe2nd | quetion 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 |
rburton | LetoThe2nd: does your test output in the format ptest-runner is expecting? | 14:15 |
benesim | Hi 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 |
LetoThe2nd | rburton: how to check? is it documented? | 14:15 |
LetoThe2nd | rburton: 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 |
rburton | LetoThe2nd: well, ptest-runner really doesn't care much | 14:17 |
rburton | ross@flashheart ~/Programming/ptest-runner2 (master) | 14:17 |
rburton | $ git grep UNKNOWN |wc -l | 14:17 |
rburton | 0 | 14:17 |
rburton | so i think you need to find out what is printing unknown | 14:18 |
LetoThe2nd | rburton: can you try for lower case or case invariant too please? | 14:18 |
LetoThe2nd | then i'll forward it. | 14:18 |
rburton | $ git grep -i UNKNOWN |wc -l | 14:18 |
rburton | 0 | 14:18 |
rburton | i'd love to see ptest overhauled, maybe mandate TAP-style output for the tests, so we can patch less and reuse more tooling | 14:19 |
LetoThe2nd | rburton: so in a nutshell, the ptest-runner is not expected to output the literal "unknown" by itself. right? | 14:19 |
rburton | ptest-runner does not contain the string unknown | 14:19 |
rburton | maybe he means the gnome test runner? | 14:19 |
LetoThe2nd | rburton: actually $coworker was explicitly pleased with the test-image, that was the only thing he wondered about :) | 14:19 |
rburton | LetoThe2nd: 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 |
LetoThe2nd | rburton: yeah, i was aware that there has been recent work, thats why i also asked. | 14:21 |
RP | LetoThe2nd, rburton: UNKNOWN sounds like something coming from python unittest | 14:24 |
RP | LetoThe2nd: 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 fail | 14:24 |
RP | LetoThe2nd: instead we report the ptest results separately. If all the ptests pass it should show success though | 14:25 |
LetoThe2nd | RP: 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 |
LetoThe2nd | RP: any pointer i can give him to dig deeper? | 14:26 |
RP | LetoThe2nd: what behaviour do they want? | 14:27 |
LetoThe2nd | RP: "show PASS or FAIL" :) | 14:28 |
RP | LetoThe2nd: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oeqa/runtime/cases/ptest.py | 14:28 |
* RP notes the @unittest.expectedFailure | 14:28 | |
RP | LetoThe2nd: also, https://bugzilla.yoctoproject.org/show_bug.cgi?id=13150 | 14:29 |
yocti | Bug 13150: normal, Medium+, 2.7 M3, richard.purdie, NEW , Test report contains UNKNOWN status when tests were skipped | 14:29 |
*** yates <yates!~user@rrcs-96-10-234-158.midsouth.biz.rr.com> has joined #yocto | 14:29 | |
RP | LetoThe2nd: so I suspect "expected failures" aren't being handled correctly | 14:29 |
yates | what package provides gdbserver ? | 14:29 |
RP | yates: gdbserver? | 14:30 |
LetoThe2nd | RP: ah ok, so its basically "a bug" | 14:30 |
yates | nm | 14:30 |
yates | no, it's gdb | 14:30 |
RP | yates: nm is in binutils | 14:30 |
RP | yates: gdb is the recipe in the gdbserver package | 14:30 |
RP | LetoThe2nd: approximately speaking | 14:31 |
LetoThe2nd | RP: 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 |
RP | LetoThe2nd: 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 unitest | 14:34 |
RP | LetoThe2nd: glad they liked it and any help in improving gratefully received | 14:35 |
LetoThe2nd | RP: could you elaborate on "expect to fail?" | 14:35 |
LetoThe2nd | RP: 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 |
RP | LetoThe2nd: https://docs.python.org/3/library/unittest.html#skipping-tests-and-expected-failures | 14:36 |
RP | LetoThe2nd: its a unittest outcome (pass, fail, skip, expectedFail, unexpectedSuccess, unknown) | 14:37 |
LetoThe2nd | RP: i see, thanks. I'll forward this, and if we can help I'll let you know. | 14:38 |
RP | LetoThe2nd: we will likely improve things, just other priorities right now | 14:39 |
*** chandana73 <chandana73!~ckalluri@149.199.62.130> has joined #yocto | 14:39 | |
yates | RP: whatever. i bitbake gdb, not bitbake gdbserver | 14:47 |
yates | it generates a package gdb, which i then smart install as gdb. sounds like gdb is the package to me | 14:47 |
*** benesim <benesim!~bisbarn@p5DF58D12.dip0.t-ipconnect.de> has quit IRC | 15:14 | |
yates | rburton: 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 transparency | 15:15 |
yates | where are the latest oe recipes maintained? | 15:18 |
*** jcelerier <jcelerier!~kdab@static-176-159-162-190.ftth.abo.bbox.fr> has joined #yocto | 15:28 | |
jcelerier | hello :-) | 15:28 |
jcelerier | I have a problem while trying to build an image with its sdk : | 15:28 |
jcelerier | Problem: package perl-module-overload-5.24.4-r0.armv7at2hf_neon requires perl-module-warnings-register, but none of the providers can be installed | 15:28 |
jcelerier | (fsl-image-machine-test from fsl-community-bsp) | 15:28 |
jcelerier | building the image in itself works correctly | 15:28 |
jcelerier | where 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 #yocto | 15:36 | |
sveinse | I 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 |
sveinse | I 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 prompt | 15:39 |
RP | yates: my point is to ask about recipes, not packages then. Two different things, say what you mean! :) | 15:39 |
armpit | RP, 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 |
armpit | if not, than any quick build is in accurate | 15:43 |
armpit | can we move that build to full ? | 15:44 |
sveinse | runqemu 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 IRC | 15:46 | |
RP | armpit: I guess I've just been aware its a known weakness. My -next builds are run in three different branches | 15:47 |
armpit | does Ross's ? | 15:48 |
armpit | master-next is not part of this as its updated by you at the same time | 15:49 |
RP | armpit: no, mut doesn't | 15:50 |
RP | armpit: 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 represents | 15:51 |
armpit | k, now that I now I will adjust my process | 15:51 |
armpit | the good thing it stagged sumo changes are good for a pull request so we can get the next point release started | 15:53 |
RP | armpit: apart from testresult and the -helper changes? :/ | 15:55 |
armpit | err, fine... I still want the batch of my plate to then get thud sorted for those needed changes | 15:56 |
RP | armpit: that is fine, one step at a time | 15:58 |
RP | armpit: I'm happy to help with this, I just need M3 built using the new process/tools | 15:58 |
sveinse | It 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 |
sveinse | Isn't this somewhat unexpected behaviour? | 16:00 |
yates | has 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 |
yates | rburton: have you? | 16:13 |
*** sk_tandt_ <sk_tandt_!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto | 16:15 | |
*** chandana73 <chandana73!~ckalluri@149.199.62.130> has quit IRC | 16:17 | |
*** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC | 16:19 | |
*** sk_tandt_ <sk_tandt_!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC | 16:20 | |
yates | rburton: i see you've done some work on the latest versions of matchbox-wm - could ypu please respond to my previous question? | 16:28 |
yates | namely, 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 |
yates | as 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 IRC | 16:30 | |
rburton | yates: as i said last time, wm compositing has nothing to do with alpha blending inside the windows | 16:30 |
yates | then what does? | 16:30 |
yates | do 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 #yocto | 16:32 | |
rburton | yates: wxwidgets | 16:34 |
rburton | because you can't get a 32-bit visual maybe? because wxwidgets doesn't have compositing enabled? | 16:34 |
yates | what do you mean by a "32-bit visual"? | 16:35 |
rburton | *how* does wx do transparency | 16:35 |
rburton | gtk+ does it by just drawing everything onto a single X surface | 16:35 |
rburton | so it has complete control | 16:35 |
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 16:35 | |
rburton | kergoth: the one thing that article is missing is a list of five blessed licenses we can all move to slowly | 16:35 |
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 16:36 | |
yates | i don't know | 16:36 |
rburton | yates: i'd be asking the wx channel what would explain your behaviour, instead of asking people who have never used wx | 16:37 |
yates | well i have been. no one seems to know there, and i thought there may be some people here who have used wx | 16:38 |
yates | perhaps i should just dive into the wx source | 16:38 |
yates | and i thought you said a week or two ago yourself that the problem was because compositing was not enabled on mbwm.. | 16:39 |
rburton | you said window transparency :) | 16:39 |
yates | oh | 16:40 |
rburton | don't even know what a wxframe *is* | 16:40 |
yates | probably don't care, either? | 16:40 |
yates | :) | 16:40 |
rburton | if a wxframe is a top-level then you care for window-level transparency | 16:41 |
yates | https://docs.wxwidgets.org/3.0/classwx_frame.html | 16:41 |
rburton | if 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 do | 16:41 |
yates | yes, it is | 16:41 |
rburton | ie i doubt gtk2 can do that | 16:41 |
yates | i.e., a wxFrame is the top level client area of the window | 16:42 |
yates | perhaps it is the case that my desktop linux wx is based on gtk3 but the embedded yocto wx is based on gtk2 | 16:43 |
rburton | i see to recall this is your wx recipe | 16:44 |
rburton | gtk2 is so unmaintained and dead its not even funny, so if you're doing that then switch to gtk3 before gtk4 is released | 16:44 |
yates | ok, right. looking into it now | 16:44 |
yates | yes, it is my recipe | 16:45 |
rburton | did you submit it to meta-oe yet? | 16:45 |
yates | no. i guess i should? | 16:46 |
rburton | yes | 16:46 |
armpit | RP, 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 ok | 16:46 |
RP | armpit: "to make sure it does break something" ? :) | 16:46 |
RP | armpit: is this a new policy? | 16:46 |
armpit | hehe | 16:49 |
JaMa | :) | 16:49 |
armpit | I am finding doing things wrong unites the community | 16:50 |
rburton | i thought that was policy? | 16:50 |
JaMa | unites the community against common enemy? :) | 16:50 |
yates | ok | 16:50 |
armpit | rburton, I changed wiki so it must be true ; ) | 16:50 |
armpit | the Internet does not lie | 16:51 |
armpit | JaMa, thats right.. I am the unifier | 16:51 |
yates | rburton: 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/1H3iOrxeIKCJMXi25EFo5w | 16:51 |
* JaMa just noticed "Having difficulty on the list, or with someone on the list?" in the topic :) | 16:51 | |
rburton | yates: thats 2 | 16:52 |
rburton | yates: the gtk3 recipe is called gtk3 | 16:52 |
*** chandana73 <chandana73!~ckalluri@149.199.62.129> has joined #yocto | 16:52 | |
yates | not gtk+3? | 16:52 |
rburton | no, because the depends is gtk+ | 16:52 |
rburton | so you're after the recipe called gtk+_<version> | 16:52 |
rburton | not gtk+3_<version> | 16:52 |
rburton | filename is name_version | 16:52 |
RP | armpit: 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 |
sveinse | Any 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 |
RP | sveinse: wrong processor being emulated by qemu? | 16:55 |
JaMa | sveinse: yes, probably wrong -cpu parameter, but it should show an warning before dying like that | 16:55 |
rburton | sveinse: 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 |
JaMa | sveinse: unless you see the SIGILL somewhere in mesa/llvm stack which is what I'm seeing now even with correct -cpu | 16:56 |
sveinse | RP: yeah, I suspected. Yet, runqemu prints MACHINE: [qemux86], which I believe should be correct | 16:56 |
JaMa | sveinse: something like this? https://paste.ubuntu.com/p/PDnnJGvFw8/ | 16:56 |
yates | so i should DEPENDS gtk+_3.20.9? | 16:57 |
sveinse | JaMa: alledgedly the app is a non-GUI, but I'll have to confirm that, so for now, all possible causes are open I suppose | 16:57 |
RP | yates: no. DEPENDS += "gtk+3" | 16:57 |
RP | yates: gtk+ and gtk+3 are two different recipe PN | 16:58 |
JaMa | sveinse: FWIW by backtrace is from VirtualBox, not QEmu | 16:58 |
yates | oh. | 16:58 |
*** fl0v0 <fl0v0!~fvo@89.244.124.144> has quit IRC | 17:00 | |
rburton | sveinse: you can attach a gdb to the app inside qemu and watch what instruction it crashes on | 17:00 |
sveinse | JaMa: 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 it | 17:01 |
JaMa | sveinse: ok, might still be the -cpu parameter, a bit more details here: http://lists.openembedded.org/pipermail/openembedded-core/2018-April/150173.html | 17:03 |
sveinse | I 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 :D | 17:03 |
JaMa | sveinse: 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 IRC | 17:04 | |
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has joined #yocto | 17:06 | |
sveinse | JaMa, yes I do, https://bpaste.net/show/91efc35c360c . | 17:07 |
JaMa | -cpu pentium2 shown on last line | 17:08 |
*** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has joined #yocto | 17:09 | |
*** mckoan is now known as mckoan|away | 17:10 | |
sveinse | The 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 |
JaMa | which is the default for 32bit qemux86 | 17:10 |
JaMa | meta/conf/machine/include/qemuboot-x86.inc:QB_CPU_x86 = "-cpu pentium2" | 17:10 |
JaMa | meta/conf/machine/include/qemuboot-x86.inc:QB_CPU_KVM_x86 = "-cpu pentium2" | 17:10 |
sveinse | Allright, I need to test more tomorrow. Thanks JaMa | 17:15 |
sveinse | Oh, 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 |
rburton | sveinse: if you're using qemu for random emulation then yes, use qemux86-64 and turn on QEMU_USE_KVM | 17:19 |
rburton | maximal performance that way | 17:19 |
JaMa | sveinse: as first test you can run the qemu manually and edit the cpu parameter | 17:19 |
sveinse | rburton: thanks. Then I'll recompile for x64. It takes a while, so great to start in the evening | 17:21 |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 17:32 | |
yates | rburton: are you saying i need both gtk+ and gtk+3 in my DEPENDS? | 17:33 |
rburton | no | 17:33 |
rburton | gtk+ is a recipe | 17:33 |
rburton | so is gtk+3 | 17:33 |
yates | ok | 17:33 |
rburton | you depend on gtk+, which is gtk+ 2.something | 17:33 |
rburton | (which has been unmaintained for not a long way off a decade now) | 17:34 |
rburton | just change it to gtk+3 | 17:34 |
yates | but 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-dep | 17:34 |
yates | DEPENDS = "webkitgtk gstreamer gtk+3 jpeg tiff libpng zlib expat libxinerama libglu" | 17:34 |
rburton | so it still links to gtk2 | 17:34 |
rburton | you'll need to figure out how to change that | 17:34 |
yates | is it perhaps this? BINCONFIG_GLOB = "arm-fslc-linux-gnueabi-gtk2-unicode-3.0" | 17:35 |
rburton | no | 17:35 |
yates | i've forgotten what BINCONFIG_GLOB does | 17:35 |
rburton | thats the glob that tells the binconfig class where the scripts to rewrite are | 17:36 |
rburton | you'll want a lot more * in there | 17:36 |
yates | here is the entire recipe now: https://paste.fedoraproject.org/paste/01VykQ~dpLwTgejHpEAoVA | 17:36 |
rburton | ie any build that isn't gtk2 for arm using freescale won't have that filename | 17:36 |
rburton | i'm guessing you need to look how to build wx and tell it what backend to use | 17:36 |
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 17:43 | |
rburton | yates: 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 IRC | 17:48 | |
*** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-091-089-212-176.hsi2.kabel-badenwuerttemberg.de> has quit IRC | 17:52 | |
yates | rburton: i had not. are you saying this would be a separate line in the recipe file? | 17:54 |
rburton | yates: if you run ./configure --help for wxwidgets you'll see "--with-gtk=VERSION etc etc" | 17:54 |
rburton | so that tells you how to tell it to use gtk3 | 17:54 |
yates | aha. | 17:55 |
yates | i 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 #yocto | 17:56 | |
yates | my conjecture was that webkitgtk itself DEPENDSed on gtk+ (2) | 17:56 |
yates | i'll try it - what the heck | 17:57 |
psrcode | RP: do you have a link with console output for the https://autobuilder.yocto.io/pub/non-release/20190318-7/testresults/ failure? | 18:04 |
jae1 | Hi Does anyone know if there is a reason why the devtool build command doesnt run 'deploy' task? | 18:12 |
jae1 | Right now its only running build task, populate sysroot, packagedata | 18:12 |
*** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has joined #yocto | 18:12 | |
jae1 | would 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 IRC | 18:14 | |
*** jcelerier <jcelerier!~kdab@static-176-159-162-190.ftth.abo.bbox.fr> has quit IRC | 18:17 | |
*** black_13 <black_13!927305a2@gateway/web/freenode/ip.146.115.5.162> has joined #yocto | 18:20 | |
black_13 | how do you force the rebuild of an indivisual recipe | 18:20 |
black_13 | individual | 18:20 |
black_13 | or just build an individual recipe | 18:25 |
yates | black_13: bitbake <recipe-name> | 18:29 |
black_13 | can you provide the full path name | 18:30 |
yates | no | 18:30 |
yates | just the recipe name. if you're rebuilding svn, then "bitbake svn" | 18:32 |
yates | the specified layers determine which specific recipe and bbappends (if any) are used | 18:32 |
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 18:36 | |
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 18:36 | |
black_13 | yah | 18:40 |
kergoth | black_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 -C | 18:42 |
kergoth | will force the tasks to run | 18:42 |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 19:02 | |
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 19:07 | |
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 19:08 | |
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 19:13 | |
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 19:14 | |
jonmason | RP: can I close https://bugzilla.yoctoproject.org/show_bug.cgi?id=12499 as "won't fix"? | 19:22 |
yocti | Bug 12499: normal, Low, Future, jon.mason, NEW , [2.5 M1 RC3] qemuarm: failed to shutdown | 19:22 |
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-arkwdjyttrizhklx> has quit IRC | 19:52 | |
*** tprrt <tprrt!~tprrt@217.114.201.133> has quit IRC | 19:58 | |
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 19:59 | |
yates | rburton: modifying wx ./configure options... :) | 20:30 |
rburton | yates: no.... passing the right one via EXTRA_OECONF | 20:30 |
rburton | --help tells you the available options, pass the right one to configure | 20:30 |
yates | rburton: does that work in morty? | 20:31 |
rburton | passing options to configure scripts has literally always worked | 20:31 |
yates | ok, great | 20:31 |
yates | thanks | 20:31 |
rburton | probably worth reading how autotools.bbclass works too | 20:32 |
yates | For information on how this variable works within that class, see the meta/classes/autotools.bbclass file. | 20:34 |
yates | wow, self-documenting code... | 20:35 |
sveinse | Does yocto have any mechanisms for compiling an installable package using the SDK? | 20:36 |
sveinse | Because 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 |
yates | sveinse: i like your idea | 20:39 |
yocti | New 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_13 | is there predifined file for the root directory for the bitbake recipe | 20:53 |
yates | black_13: i don't understand your question. recipes are under <yoctoproject>/sources in various places | 20:56 |
yates | sources/poky, sources/meta-mycompany, etc... | 20:57 |
black_13 | there is a ${D} and ${system} is there something that represents /root | 20:58 |
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 21:01 | |
*** likewise <likewise!~leon@145.132.74.106> has joined #yocto | 21:04 | |
*** jeanba <jeanba!~jbl@80-62-117-50-mobile.dk.customer.tdc.net> has joined #yocto | 21:05 | |
*** jeanba <jeanba!~jbl@80-62-117-50-mobile.dk.customer.tdc.net> has left #yocto | 21:05 | |
yates | black_13: you can find those types of definitions in <>/sources/poky/meta/conf/bitbake.conf | 21:14 |
yates | not sure, to answer your question | 21:14 |
black_13 | ${IMAGE_ROOTFS} is the answer | 21:17 |
*** berton <berton!~berton@177.194.204.148> has quit IRC | 21:20 | |
sveinse | JaMa: 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 |
JaMa | AVX .................................. AVX AVX2 | 21:23 |
JaMa | you don't have AVX2 in emulated pentium2 I believe | 21:23 |
JaMa | change the cpu parameter to see if it helps | 21:23 |
sveinse | Thanks, I'll try. | 21:25 |
sveinse | The 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 |
JaMa | it 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 case | 21:26 |
JaMa | it 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 on | 21:27 |
sveinse | I'm attempting to make an image with qtbase-dbg | 21:28 |
JaMa | changing -cpu is much faster than rebuilding anything, but your call | 21:29 |
RP | psrcode: the console output is embedded in there, extracting it is a pain, I have a "todo" item for that :( | 21:31 |
RP | psrcode: specifically its embeddedin https://autobuilder.yocto.io/pub/non-release/20190318-7/testresults/qemux86-64-ptest/testresults.json | 21:31 |
RP | psrcode: I'll get it out soon, just several things to do right now (including sleep) :/ | 21:32 |
RP | jonmason: yes, we can close that now | 21:32 |
sveinse | JaMa: Yeah, that did work. I picked -cpu Haswell by random, and now the Qt app is running. Thanks | 21:35 |
sveinse | Not sure how high up I need to go for this thou. My insight into the intel gens are limited | 21:35 |
sveinse | But 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 what | 21:38 |
*** aehs29 <aehs29!~aehs29@149.199.62.131> has joined #yocto | 21:41 | |
JaMa | sveinse: 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 |
yates | why am i getting this package qa error? i don't remember getting it previously. | 21:47 |
sveinse | JaMa: yep. got it. | 21:49 |
*** black_13 <black_13!927305a2@gateway/web/freenode/ip.146.115.5.162> has quit IRC | 21:58 | |
yates | THIS error: https://paste.fedoraproject.org/paste/X3zRAOZ-34AzWwmOAVOVTQ | 22:01 |
JaMa | because /usr/lib/wx/3.0/web-extensions/webkit2_extu-3.0.so doesn't belong to -dev package | 22:13 |
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has quit IRC | 22:54 | |
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has joined #yocto | 22:54 | |
*** agust <agust!~agust@p5483354E.dip0.t-ipconnect.de> has quit IRC | 23:23 | |
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 23:26 | |
*** gaulishcoin <gaulishcoin!~gaulishco@anice-652-1-371-223.w83-201.abo.wanadoo.fr> has quit IRC | 23:43 | |
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC | 23:57 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!