*** AccelShark <AccelShark!~ace@104.156.30.150> has joined #yocto | 00:14 | |
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 00:17 | |
black_13 | what is the settings for the local.conf to allow me to use the qemu arm test | 00:19 |
---|---|---|
khem | black_13: https://github.com/YoeDistro/yoe-distro/blob/master/conf/local.conf.sample | 00:24 |
khem | copy it into local.conf | 00:24 |
khem | and make changes as needed | 00:24 |
*** gtristan <gtristan!~tristanva@110.11.179.2> has joined #yocto | 00:26 | |
khem | did you follow the readme ? | 00:27 |
khem | . ./qemuarm-envsetup.sh && bitbake yoe-simple-image then execute runqemu nographic | 00:28 |
nerdboy | khem: thud doesn't fail on either bison or cross-localedef | 00:33 |
nerdboy | * for me on unsupported gentoo build host | 00:33 |
nerdboy | i probably don't update frequently enough but i'm pretty much always on ~hardened or ~musl-hardened profile | 00:35 |
khem | nerdboy: yeah thud is recent enough | 00:36 |
khem | usually glibc (uninative) is an issue for rolling distros | 00:36 |
nerdboy | yeah i don't remember the shim being installed until (relatively) recently | 00:37 |
nerdboy | branch-wise recently... | 00:37 |
*** vmesons <vmesons!~rmacleod@24-52-238-240.cable.teksavvy.com> has joined #yocto | 00:55 | |
*** vmeson <vmeson!~rmacleod@192-0-133-18.cpe.teksavvy.com> has quit IRC | 00:56 | |
*** nighty- <nighty-!~nighty@b157153.ppp.asahi-net.or.jp> has joined #yocto | 00:58 | |
*** vmesons is now known as vmeson | 01:04 | |
*** gtristan <gtristan!~tristanva@110.11.179.2> has quit IRC | 01:06 | |
*** chandana73 <chandana73!~ckalluri@149.199.62.130> has joined #yocto | 01:15 | |
*** ferlzc <ferlzc!~ferlzc@177.76.63.8> has quit IRC | 01:36 | |
black_13 | khem: i had to step away and make dinner | 02:08 |
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 02:52 | |
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 03:07 | |
black_13 | how do you use ipk or get bitbake to generate ipk packages | 03:11 |
*** AccelShark <AccelShark!~ace@104.156.30.150> has quit IRC | 03:47 | |
*** BuddyButterfly <BuddyButterfly!~BuddyButt@p5080D248.dip0.t-ipconnect.de> has joined #yocto | 03:47 | |
*** BuddyButterfly1 <BuddyButterfly1!~BuddyButt@p5080DC0B.dip0.t-ipconnect.de> has quit IRC | 03:49 | |
khem | black_13: if you use yoe then ipk is default backend | 04:52 |
khem | so you can do bitbake foo | 04:52 |
khem | yoe_setup_feed_server <ip of target device> | 04:53 |
khem | yoe_feed_server | 04:53 |
khem | this will start a feed server on your build machine | 04:53 |
khem | now you can go to your target machine and do opkg update && opkg install foo | 04:54 |
khem | provided you have n/w setup on your target | 04:54 |
*** sno <sno!~sno@b2b-78-94-80-58.unitymedia.biz> has quit IRC | 05:12 | |
*** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 05:18 | |
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto | 05:49 | |
*** jobroe <jobroe!~manjaro-u@193.158.0.154> has joined #yocto | 05:59 | |
*** AndersD <AndersD!~AndersD@194.237.220.218> has joined #yocto | 06:11 | |
*** AndersD <AndersD!~AndersD@194.237.220.218> has quit IRC | 06:15 | |
*** pbb <pbb!~quassel@pbb4.pbb.lc> has joined #yocto | 06:16 | |
*** AndersD <AndersD!~AndersD@194.237.220.218> has joined #yocto | 06:16 | |
*** ctlnwr <ctlnwr!~catalin@89.121.200.102> has quit IRC | 06:20 | |
*** ctlnwr_ <ctlnwr_!~catalin@89.121.200.102> has quit IRC | 06:20 | |
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has quit IRC | 06:44 | |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 06:44 | |
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has joined #yocto | 06:49 | |
*** agust <agust!~agust@p54833194.dip0.t-ipconnect.de> has joined #yocto | 06:55 | |
*** ctlnwr <ctlnwr!~catalin@89.121.200.102> has joined #yocto | 06:58 | |
*** ctlnwr_ <ctlnwr_!~catalin@89.121.200.102> has joined #yocto | 06:58 | |
*** paulg <paulg!~paulg@24-246-4-37.cable.teksavvy.com> has quit IRC | 07:06 | |
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto | 07:07 | |
*** tprrt <tprrt!~tprrt@217.114.201.133> has joined #yocto | 07:13 | |
*** paulg <paulg!~paulg@24-246-7-167.cable.teksavvy.com> has joined #yocto | 07:23 | |
*** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has joined #yocto | 07:43 | |
*** rubdos_ <rubdos_!~rubdos@ptr-1uzevqefjgxdm5wv65h.18120a2.ip6.access.telenet.be> has quit IRC | 07:44 | |
*** mckoan|away is now known as mckoan | 07:46 | |
*** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto | 08:00 | |
*** jobroe <jobroe!~manjaro-u@193.158.0.154> has quit IRC | 08:01 | |
*** chandana73 <chandana73!~ckalluri@149.199.62.130> has quit IRC | 08:02 | |
*** jobroe <jobroe!~manjaro-u@193.158.0.154> has joined #yocto | 08:03 | |
*** yacar_ <yacar_!~yacar@static-css-ccs-204145.business.bouyguestelecom.com> has joined #yocto | 08:04 | |
*** fl0v0 <fl0v0!~fvo@mue-88-130-107-064.dsl.tropolys.de> has joined #yocto | 08:09 | |
*** jij <jij!jonashg@nat/axis/x-qkkiixzjrocdpbrh> has joined #yocto | 08:16 | |
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 08:27 | |
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 08:29 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 08:32 | |
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto | 08:35 | |
*** gtristan <gtristan!~tristanva@114.207.54.12> has joined #yocto | 08:42 | |
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 08:45 | |
*** retoatwork <retoatwork!~reto@85.195.220.82> has quit IRC | 08:49 | |
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 08:49 | |
RP | JaMa: From what I remember do_install had to have the get_auto_pr else the PR values would be incorrect | 09:01 |
JaMa | PKGR, right? but do_install doesn't seem to use them anywhere (other than WORKDIR where it's not expanded anyway) | 09:02 |
RP | JaMa: yes, its the use of PKGR | 09:02 |
RP | JaMa: I suspect back then it may have done but changed over time? | 09:03 |
JaMa | I'll try to remove it to see if something breaks now | 09:03 |
RP | JaMa: definitely worth looking at, it does seem an odd thing to do now... | 09:04 |
*** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 09:04 | |
JaMa | I've also replaced PKGR with PR to work around this (PKGR can be used in the symlink later) | 09:05 |
RP | JaMa: you're effectively just reverting that commit then | 09:06 |
RP | (?) | 09:06 |
JaMa | only partially and with do_deploy_links task after do_deploy it can result in the same artifact names | 09:08 |
RP | JaMa: but the artefact name itself would have the unexpanded PR? | 09:08 |
JaMa | the goal is to have reusable do_deploy sstate, which is then hard linked with any filenames you want (which might mean expanded PKGR) | 09:09 |
RP | JaMa: you are right, the use of TASKHASH in get_auto_pr means it has to be called consistently | 09:09 |
JaMa | e.g. with DATETIME currently included in artifact names, you either have to re-execute do_deploy every single build (which means rebuild for builds with rm_work) or you have "old" datetime in deploy directory artifacts | 09:10 |
JaMa | it's more annoying if you do "releases" by setting the version suffix e.g. from jenkins job -> again either you need to rebuild kernel or you might get different release number for kernel artifact in some builds (those where kernel checksums didn't change since previous release) | 09:11 |
RP | JaMa: my main worry with this is that we then break "stacking" artefacts | 09:12 |
RP | JaMa: the old OE behaviour was to generate a new image each run, the symlinks were then added to you could easily find "latest" | 09:12 |
JaMa | in webOS we work around this by extra task (do_deploy_fixup) but it's quite error prone to do from "outside" in our layer, because every do_deploy needs to be wrapped with do_deploy_fixup and then the task dependencies which might depend on other recipe do_deploy need to be adjusted as well | 09:12 |
RP | JaMa: with sstate we started letting it clean up previous output but left it so you could easily disable that | 09:13 |
JaMa | this use case is still supported | 09:13 |
*** sk_tandt_ <sk_tandt_!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto | 09:13 | |
JaMa | that's why the links are hardlinks (so whatever the version says you'll get) and the latest is the one without version | 09:14 |
RP | JaMa: hmm, right | 09:14 |
JaMa | maybe it could be simiplified even more and use just KERNEL_VERSION variable in do_deploy (as the latest one) like do_install does, but that will prevent people from renaming the "latest" one in deploy | 09:15 |
RP | JaMa: I agree we need to do something to improve things | 09:15 |
JaMa | I have something which works in most cases, once I test it on more combinations, I'll share it in the bugzilla to better show how it looks now and how it will look like in deploy dir | 09:16 |
*** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC | 09:17 | |
RP | JaMa: sounds good. I think explaining the change and the reasons behind it will be impoartant | 09:17 |
JaMa | having the extra variables introduced in thud already helps with "external" sollution, but hopefully with good explanation people will agree to get it all in oe-core | 09:18 |
RP | JaMa: yes | 09:19 |
* RP notes its technically 2.7 feature freeze today. We're nowhere near ready :( | 09:21 | |
*** florian_kc is now known as florian | 09:22 | |
*** YokoOkto <YokoOkto!91fdde45@gateway/web/freenode/ip.145.253.222.69> has joined #yocto | 09:22 | |
*** Saur <Saur!pkj@nat/axis/x-zmajdjsemlvbjkmq> has joined #yocto | 09:24 | |
YokoOkto | hello, I applied the preempt_rt patch and still see peaks of 15ms although normally it runs with 300µs. Do you also have such experience, and what is the best tool to analyze where that is reasoned? | 09:25 |
LetoThe2nd | YokoOkto: probably better to ask the linux rt channel over at OFTC | 09:27 |
YokoOkto | hmm ok thank you | 09:28 |
*** Saur <Saur!pkj@nat/axis/x-zmajdjsemlvbjkmq> has quit IRC | 09:28 | |
*** Saur <Saur!pkj@nat/axis/x-dbkaxfgucdnjycdm> has joined #yocto | 09:30 | |
*** Saur <Saur!pkj@nat/axis/x-dbkaxfgucdnjycdm> has quit IRC | 09:32 | |
*** Saur <Saur!pkj@nat/axis/x-gdtnljjpmbhvewit> has joined #yocto | 09:34 | |
*** dv_ <dv_!~dv@62.178.50.190> has quit IRC | 09:38 | |
RP | kanavin: around? | 09:43 |
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 09:45 | |
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has quit IRC | 09:46 | |
* RP sends email | 09:47 | |
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto | 09:52 | |
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-mqgndvccekexrryt> has joined #yocto | 09:55 | |
*** alinucs <alinucs!~abo@215.ip-51-38-235.eu> has quit IRC | 10:02 | |
*** YokoOkto <YokoOkto!91fdde45@gateway/web/freenode/ip.145.253.222.69> has quit IRC | 10:03 | |
*** alinucs <alinucs!~abo@static-176-158-51-218.ftth.abo.bbox.fr> has joined #yocto | 10:04 | |
*** alinucs <alinucs!~abo@static-176-158-51-218.ftth.abo.bbox.fr> has quit IRC | 10:09 | |
*** alinucs <alinucs!~abo@215.ip-51-38-235.eu> has joined #yocto | 10:09 | |
*** gsalazar <gsalazar!~gsalazar@66.252.115.89.rev.vodafone.pt> has quit IRC | 10:14 | |
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 10:15 | |
*** alinucs <alinucs!~abo@215.ip-51-38-235.eu> has quit IRC | 10:20 | |
*** alinucs <alinucs!~abo@215.ip-51-38-235.eu> has joined #yocto | 10:21 | |
*** sk_tandt_ <sk_tandt_!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC | 10:30 | |
*** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto | 10:42 | |
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has joined #yocto | 10:42 | |
*** nslu2-log <nslu2-log!~nslu2-log@23.141.224.193> has quit IRC | 10:48 | |
*** alinucs <alinucs!~abo@215.ip-51-38-235.eu> has quit IRC | 10:50 | |
*** hugo___ <hugo___!sid6079@gateway/web/irccloud.com/x-ltboftqgxbyqvilu> has joined #yocto | 10:52 | |
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 10:53 | |
hugo___ | Hi everyone! I added `SDK_EXTRA_TOOLS = " nativesdk-cmake " ` as described here: https://wiki.yoctoproject.org/wiki/TipsAndTricks/Cmake,Eclipse,_and_SDKS to get a CMake toolchain for my SDK. However, the CMake Toolchain would only work if I source the SDK environment before hand. Is there a "configuration/buildstep/install" step that would allow the SDK to export a Cmake toolchain with the paths needed to cross compile | 10:54 |
hugo___ | without sourcing? thanks in advnace | 10:54 |
*** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC | 10:55 | |
kanavin | RP: yep | 10:59 |
*** nslu2-log <nslu2-log!~nslu2-log@23.141.224.193> has joined #yocto | 10:59 | |
*** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto | 10:59 | |
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 11:00 | |
*** daniel-k <daniel-k!~daniel@195.14.245.218> has joined #yocto | 11:01 | |
RP | kanavin: I've taken some bits of virtgl in so the patchset should reduce a bit more :) | 11:02 |
kanavin | RP: thanks :) I did notice that debian 8 also fails the selftest with an unhelpful error message | 11:03 |
RP | kanavin: right, two issues. the unhelpful message and the fact it fails :( | 11:04 |
RP | probably should have a bug for the former | 11:04 |
kanavin | RP: I suspect the actual testimage log might tell a bit more | 11:04 |
kanavin | log file | 11:04 |
kanavin | oh, massive update to master, finally! | 11:04 |
RP | kanavin: this batch took quite a bit of sorting out | 11:05 |
*** sk_tandt_ <sk_tandt_!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto | 11:06 | |
*** alinucs <alinucs!~abo@static-176-158-51-218.ftth.abo.bbox.fr> has joined #yocto | 11:06 | |
RP | we now have a working resulttool, buildhistory and auto updating repositories of all the data, hopefully | 11:08 |
*** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC | 11:09 | |
rburton | hugo___: you need to source to use the sdk | 11:10 |
*** alinucs <alinucs!~abo@static-176-158-51-218.ftth.abo.bbox.fr> has quit IRC | 11:13 | |
*** alinucs <alinucs!~abo@static-176-158-51-218.ftth.abo.bbox.fr> has joined #yocto | 11:13 | |
*** sk_tandt_ <sk_tandt_!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC | 11:21 | |
jofr | hugo___: And that's a feature, not a bug. ;-) | 11:27 |
*** sno <sno!~sno@2a01:598:9904:28c3:c31:9ed0:a77f:f2ad> has joined #yocto | 11:28 | |
*** gsalazar <gsalazar!~gsalazar@66.252.115.89.rev.vodafone.pt> has joined #yocto | 11:30 | |
hugo___ | rburton: jofr : Ok, need is a strong word ;P | 11:31 |
*** berton <berton!~berton@177.194.204.148> has joined #yocto | 11:33 | |
rburton | hugo___: bits of the sdk use environment variables exported by the setup script, so need is the correct word | 11:42 |
*** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has joined #yocto | 11:42 | |
RP | hugo___: it does not work without it. I'm sure you could wrap every binary in the SDK to set the right envvars to avoid sourcing but you'd still have to modify PATH to find said binaries and to do that you'd probably still have to source something | 11:47 |
*** sgw <sgw!~sgw@134.134.139.73> has quit IRC | 11:53 | |
*** AndersD_ <AndersD_!~AndersD@194.237.220.218> has joined #yocto | 11:58 | |
*** AndersD <AndersD!~AndersD@194.237.220.218> has quit IRC | 12:00 | |
*** sno <sno!~sno@2a01:598:9904:28c3:c31:9ed0:a77f:f2ad> has quit IRC | 12:04 | |
*** ferlzc <ferlzc!~ferlzc@177.76.63.8> has joined #yocto | 12:14 | |
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 12:16 | |
kanavin | RP: I'll send a patch that removes the _remove in qemu recipe in a moment | 12:17 |
yacar_ | Hey guys, I have still no review on my patch sent on the mailing list, shall I change something ? See mailing list thread : "Fixing devtool issue with kernel bbhappen do_patch recipe" | 12:27 |
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 12:29 | |
*** alinucs <alinucs!~abo@static-176-158-51-218.ftth.abo.bbox.fr> has quit IRC | 12:33 | |
RP | kanavin: thanks | 12:36 |
kanavin | RP: removing _remove is actually tricky, can you give me a suggestion? I'd like to ensure that gtk+ is not in the final value, but it seems impossible to override what is set in local.conf, other than through use of _remove | 12:36 |
kanavin | yacar_, that should be looked at by Paul Eggleton | 12:37 |
LetoThe2nd | kanavin: already poked him couple of days back, probably he forgot again :/ | 12:37 |
*** agnem <agnem!~agnem@instant.ed.ntnu.no> has quit IRC | 12:41 | |
yacar_ | kanavin : do you have Paul's email address ? | 12:42 |
LetoThe2nd | yacar_: its easy to find on the ML, and he's here as bluelightning. but just offline, due to timezone | 12:43 |
kanavin | paul.eggleton@linux.intel.com | 12:43 |
yacar_ | Thanks! | 12:43 |
RP | kanavin: hmm, that is harder than I was initially thinking | 12:53 |
kanavin | RP: we can drop the qemu related bits from local.conf altogether, and enable gtk+ directly from the recipe | 12:53 |
RP | kanavin: this is something users may want to configure | 12:54 |
RP | kanavin: perhaps remove is the right thing :/ | 12:54 |
RP | kanavin: it would only become a problem if someone works on enabling gtk on mingw/darwin | 12:54 |
kanavin | but then they would adjust the recipe as a part of that | 12:55 |
kanavin | to not do the remove | 12:55 |
* RP just reran a-full and its nearly completed in less than 1 hour 50 minutes with hot sstate | 12:55 | |
RP | remaining bits are ptest, mips, mips64 and qemuarm | 12:56 |
RP | that is a pretty amazing build time | 12:56 |
kanavin | RP: yeah, I was going to ask if we really need to run those very long mips target tests, or make them shorter somehow | 12:58 |
RP | kanavin: we already did cut a few out | 12:58 |
RP | kanavin: actually, I'm not sure you do need to change PACKAGECONFIG for mingw from local.conf | 12:59 |
RP | kanavin: if the user configures gtk+ into a mingw build that is their own fault | 12:59 |
kanavin | RP: but it's set for all nativesdk variants from local.conf | 12:59 |
kanavin | and uncommented by default, which will break things on mingw | 13:00 |
black_13 | ERROR: ParseError in configuration INHERITs: Could not inherit file classes/package_rpmpackage_ipk.bbclass | 13:00 |
black_13 | what is this error from | 13:00 |
RP | kanavin: hmm, I was thinking mingw has its own namespace but you're right | 13:00 |
RP | black_13: misset PACKAGE_CLASSES variable (missing space) | 13:01 |
kanavin | RP: you can give it special treatment via PACKAGECONFIG_mingw32_class-nativesdk though, but it would further bloat local.conf, and really shouldn't belong there | 13:01 |
RP | kanavin: right, that is a level of ugliness the user doesn't need | 13:02 |
black_13 | this is my local.conf : http://codepad.org/J4JeieU4 | 13:06 |
black_13 | PACKAGE_CLASSES ?= " package_rpm" | 13:08 |
*** gtristan <gtristan!~tristanva@114.207.54.12> has quit IRC | 13:09 | |
RP | black_13: I strongly suspend something is appending to that without a space | 13:09 |
*** gtristan <gtristan!~tristanva@114.207.54.12> has joined #yocto | 13:12 | |
black_13 | how do you instruct bitbake to use on the ipk package format and install the package manager | 13:15 |
black_13 | what bothers me is i had this working | 13:15 |
RP | black_13: the problem is those last two lines. Why not just set PACKAGE_CLASSES = "package_ipk" ? | 13:21 |
RP | black_13: PACKAGE_CLASSES_append = " package_ipk" (with a space) would have worked | 13:22 |
black_13 | i will check | 13:23 |
black_13 | ok its bitbaking lets see what happens | 13:24 |
black_13 | still buiding PACKAGE_CLASSES_append = "package_ipk" PACKAGE_CLASSES_remove = "package_rpm" | 13:29 |
black_13 | sorry it is still build the rpm package manager | 13:29 |
LetoThe2nd | black_13: whats wrong with setting PACKAGE_CLASSES ?= "package_ipk" | 13:32 |
LetoThe2nd | or even more directly PACKAGE_CLASSES = "package_ipk" | 13:32 |
black_13 | i did that i believe | 13:32 |
LetoThe2nd | probably not, then | 13:33 |
LetoThe2nd | bitbake -e $WHATEVER | less, and then search for PACKAGE_CLASSES | 13:34 |
*** dev1990 <dev1990!~dev@dynamic-78-8-185-181.ssp.dialog.net.pl> has quit IRC | 13:35 | |
*** lexa_` <lexa_`!~user@217.66.60.5> has joined #yocto | 13:37 | |
black_13 | http://codepad.org/JKQiuR1J | 13:37 |
LetoThe2nd | black_13: then chances are that something that you do need rpm for other reasons | 13:39 |
black_13 | it use rpm for other reason but will also have ipk packages available | 13:40 |
LetoThe2nd | is that a statement or a question? | 13:41 |
*** gtristan <gtristan!~tristanva@114.207.54.12> has quit IRC | 13:43 | |
black_13 | a statement | 13:52 |
Piraty | yocto being really late to the p3 party yes? | 13:52 |
black_13 | you are saying that though it may build the rpm package management system it will have ipkg files available for use | 13:52 |
LetoThe2nd | black_13: no, thats not what i am saying. | 13:53 |
Piraty | LOL it needs both py2 and py3 | 13:53 |
LetoThe2nd | black_13: i am saying that when you have package_ipk as the package_class, then this is what it will use to build the image and to provide packages. | 13:54 |
LetoThe2nd | black_13: there can be packages that require the rpm tooling for other reasons, but that doesn't affect the image building and packaging process then. | 13:55 |
lexa_` | Hi, I have a problem with Yocto, I'm not sure how to approach. I want to build a | 13:55 |
lexa_` | few Yocto images, which are 99% identical, except for the couple of packages. | 13:55 |
lexa_` | Usually, I want to install one or two extra packages. | 13:55 |
lexa_` | 13:55 | |
lexa_` | I want to save some space on multiple rootfs images. Is there some way to produce one 'base' image and them install rpm package in the image on the host? | 13:55 |
lexa_` | 13:55 | |
black_13 | LetoThe2nd: your correct i see multiple ipk files present in ./build/tmp/deploy/ipk/all | 13:56 |
LetoThe2nd | lexa_`: you can have a base image recipe, and 99 other recipes that jsut include it and extend it by one or two packages. | 13:57 |
lexa_` | LetoThe2nd: But I don't want to build multiple images in Yocto. Maybe it is possible to install packages into pre-build rootfs? | 13:59 |
LetoThe2nd | lexa_`: i don't get the point | 13:59 |
lexa_` | LetoThe2nd: save some diskspace by having one big image + packages which could be installed when needed. | 14:00 |
LetoThe2nd | lexa_`: you want yocto to create a base image, and then run a whatever-something that takes this image, and makes it into 99 other images that only differ by a handful of packages. | 14:00 |
lexa_` | exactly! | 14:01 |
LetoThe2nd | lexa_`: i mean, you explicitly wrote "install rpm package in the image on the host" | 14:01 |
LetoThe2nd | so there's no diskspace saving in any case. | 14:01 |
LetoThe2nd | or did you actually mean to create a base image + a package feed, and then install the add-ons in the TARGET? | 14:01 |
lexa_` | Usually, I don't want to have all images at the same moment, so I could have one base image and one base image with an extra package installed. | 14:02 |
lexa_` | LetoThe2nd: I wouldn't like to install packages on the host, because it implies RW rootfs. | 14:03 |
*** gtristan <gtristan!~tristanva@110.11.179.2> has joined #yocto | 14:03 | |
LetoThe2nd | lexa_`: so what would be the difference to bitbake'ing the base-image and the special image? | 14:04 |
LetoThe2nd | lexa_`: so then this was a freudian error now, you meant "I wouldn't like to install packages on the target, because it implies RW rootfs." | 14:04 |
LetoThe2nd | ok, that makes perfect sense | 14:04 |
*** Pharaoh_Atem <Pharaoh_Atem!~neal@fedora/ngompa> has quit IRC | 14:06 | |
lexa_` | LetoThe2nd: The difference between base-image and a special image is that special image has a few packages extra. | 14:07 |
LetoThe2nd | lexa_`: i understood that. | 14:07 |
lexa_` | LetoThe2nd: So, what was the question 'so what would be the difference to bitbake'ing the base-image and the special image?' | 14:08 |
LetoThe2nd | lexa_`: but i don't see what "diskspace savings" you expect. if you bitbake special-image which depends on base-image, then bitbake will literally build only what those two images need, and assemble them | 14:08 |
LetoThe2nd | the more they share, the better. | 14:08 |
*** black_13 <black_13!d106cd8b@gateway/web/freenode/ip.209.6.205.139> has quit IRC | 14:08 | |
*** Pharaoh_Atem <Pharaoh_Atem!~neal@fedora/ngompa> has joined #yocto | 14:09 | |
JaMa | anyone seeing illegal instructions from llvm when used with mesa on qemux86? | 14:10 |
JaMa | kanavin: for me qemu-native doesn't work with gtk+, but works with sdl2, so it might be useful for people to configure | 14:11 |
lexa_` | LetoThe2nd: Oh, forgot to explain that. I didn't meant to save space in Yocto. I want to save space on the resulting images, because I have to share them over the Internt. | 14:11 |
LetoThe2nd | lexa_`: sorry, but you're not making sense. | 14:12 |
LetoThe2nd | lexa_`: if you have an image that you want to contain a defined set of things, where is the space saving opportunity? | 14:13 |
*** Bunio_FH <Bunio_FH!~bunio@2a01:4b00:874a:fd00:6809:184d:862f:1e01> has joined #yocto | 14:15 | |
JaMa | kanavin: any link to upstream where it shows that sdl is deprecated in favor of gtk+? | 14:16 |
lexa_` | LetoThe2nd: Compare: 5 images each 1Gb vs 1 image 1Gb + 5 packages of negligible size. | 14:18 |
lexa_` | and I have to share these images over the network. | 14:18 |
lexa_` | So, I'm not saving a diskspace, but a network throughput. | 14:19 |
LetoThe2nd | lexa_`: ok. now i think i see the missing part. you mean, that you are kind of "development host 1". you produce the base image and feed and share it. "development host 2" receives things, and then creates the images. right? | 14:19 |
lexa_` | exactly! | 14:20 |
LetoThe2nd | it would have been very helpful to mention that there are multiple "hosts". you did always only name "host" | 14:21 |
kanavin | JaMa, I tried everything I could to make qemu work with sdl2, it would either refuse to start, crash on driver initialization or show a blank window when starting smth graphical | 14:21 |
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 14:21 | |
lexa_` | LetoThe2nd: sorry, I forgot to mention that fact. | 14:21 |
kanavin | if you have a branch somewhere which works for you, with precise instructions, I could give it a try | 14:21 |
kanavin | JaMa, sdl is deprecated in favor of gtk+ in poky distro | 14:22 |
LetoThe2nd | lexa_`: in that case, i don't know of any fitting solution. you can of course provide a base image plus a package feed, but the re-packaging of the image is something you'd probably have to script yourself. | 14:22 |
JaMa | kanavin: "qemu: build target variant with gtk+, and nativesdk variant without sdl" this commit isn't poky specific and still it says sdl is deprecated | 14:27 |
lexa_` | LetoThe2nd: I guest I'll to script image re-packaging. | 14:27 |
JaMa | kanavin: https://github.com/webosose-emulator/prebuilt-emulator | 14:29 |
kanavin | JaMa, which version of qemu is that? | 14:30 |
JaMa | the prebuilt one is 2.7.0 | 14:30 |
JaMa | I was using http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/qemu to build it with OE | 14:30 |
JaMa | but my version of mesa-native was also depending on drm-native, so I wasn't using that much from host as your version | 14:31 |
kanavin | yes, that was a trade-off in time needed to build all the drivers | 14:32 |
JaMa | and my version still had some issues, like mesa loading the drm driver from the path in libdrm WORKDIR which of course didn't work after rm_work removed libdrm WORKDIR | 14:32 |
JaMa | now I've built your version with both sdl and gtk+ support so I should be able to test both just by changing -display parameter | 14:33 |
kanavin | yep, if you can make sdl work, that'd be great | 14:33 |
JaMa | virgl enabled qemu in gentoo has the same issue (sdl works and gtk+ doesn't) | 14:33 |
kanavin | fedora and opensuse have the opposite problem | 14:34 |
kanavin | ubuntu doesn't have virgl enabled at all | 14:34 |
JaMa | but there might be some new issue in either xubuntu (as guest) or newer qemu, because now with default display xubuntu fails to start graphics, it works only with passthrough gpu or qxl display (slowly) | 14:34 |
JaMa | I have ubuntu packages rebuilt with sdl and virgl, but I haven't tried them with gtk display | 14:35 |
JaMa | as in http://forum.webosose.org/t/pre-built-images-available/392/2 | 14:36 |
JaMa | ah I didn't use GTK because "With GTK UI there are few more issues, the | 14:37 |
JaMa | resolution isn't set correctly and the cursor isn't rendered inside QEmu | 14:37 |
JaMa | window." | 14:37 |
*** Bunio_FH <Bunio_FH!~bunio@2a01:4b00:874a:fd00:6809:184d:862f:1e01> has quit IRC | 14:48 | |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 14:55 | |
*** jobroe <jobroe!~manjaro-u@193.158.0.154> has quit IRC | 14:59 | |
*** AndersD_ <AndersD_!~AndersD@194.237.220.218> has quit IRC | 15:01 | |
varjag | i'm setting up my own distro, but when i bake virtual/kernel, it seems to ignore my preferred_provider | 15:03 |
varjag | how does one go about diagnosing that? | 15:04 |
LetoThe2nd | varjag: bitbake -e | 15:04 |
varjag | i tried getting the dependencies graph for recipes, but it doesn't help | 15:04 |
LetoThe2nd | varjag: chances are that COMPATIBLE_MACHINE or such is off | 15:04 |
varjag | aha.. | 15:04 |
varjag | thanks, it looks like my definition is getting overriden | 15:14 |
*** TobSnyder1 <TobSnyder1!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 15:14 | |
LetoThe2nd | :-) | 15:14 |
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 15:16 | |
yocti | New news from stackoverflow: Qt - Module "QtQuick.Controls" is not installed <https://stackoverflow.com/questions/54869192/qt-module-qtquick-controls-is-not-installed> | 15:17 |
ernstp | when is ${B} cleaned? | 15:19 |
ernstp | if I do some file processing in there, should my recipe task start with a bunch of rm first, to not have stale files from the previous run? | 15:19 |
jofr | They stay there between runs, yes. In some cases you may need to remove stuff. | 15:25 |
*** mckoan is now known as mckoan|away | 15:26 | |
jofr | ernstp: FWIW: I have a recipe that, among other things, creates a zip archive. When I originally created that recipe, I do recall that zip added my files into the old archive if they had a new name. So now I start by removing it so I don't have to do a -c cleanall before building that recipe. | 15:28 |
kergoth | depends on the task being rerun | 15:28 |
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 15:34 | |
ernstp | kergoth: if I trigger compile to rerun | 15:45 |
ernstp | should I always start with rm -rf ${B}* ? | 15:45 |
kergoth | no | 15:45 |
ernstp | rm -rf ${B}/* | 15:45 |
jofr | no | 15:45 |
ernstp | so what's the idea? :-) | 15:45 |
jofr | Only the build artifact that would be added to incrementally. | 15:46 |
*** varjag <varjag!~user@122.62-97-226.bkkb.no> has quit IRC | 15:46 | |
ernstp | I discovered it because I had an intermediate file where I did >> instead of > | 15:47 |
jofr | Let's say you have something that does an "echo sumfink >> somefile" in your recipe. If you run that build over and over again, your "sumefile" will contain lots of "sumfink"s. | 15:47 |
ernstp | indeed | 15:47 |
daniel-k | Hi! I'm trying to build an eSDK with SDK_INCLUDE_PKGDATA="1" and it keeps failing during populate_sdk_ext with "No such file or directory: '[...]/build/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-base/1.0-r0/recipe-sysroot/world-pkgdata/locked-sigs-pkgdata.inc'" Any ideas? | 15:48 |
jofr | So in this simple example you have two options. Either have the first echo do an overwrite ">" or have a build-step that first does a: rm -f somefile and then does you append-stuff. You don't want to erase everything to get rid of a single file. | 15:49 |
jofr | your* | 15:49 |
ernstp | jofr: when do you want to keep old stuff around in ${B}?! | 15:50 |
jofr | When you build something more often than once in your lifetime. ;-) | 15:50 |
ernstp | a assume a cmake recipe that triggers do_compile nukes the build directory? | 15:50 |
jofr | Nope | 15:51 |
jofr | Only if the upstream has changed and it needs to fetch again | 15:51 |
ernstp | well there's the ccache, and when I work on something I compile it myself. I didn't expect yocto to do dirty buidls | 15:51 |
ernstp | I mean sstate | 15:52 |
ernstp | ok, fetch deletes B? | 15:53 |
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 15:56 | |
jofr | I believe it does. If I'm wrong, I hope someone will correct me on that? :p | 15:56 |
jofr | I've only used ${B} once and that was for a temporary workaround that I'm not even using anymore. | 15:58 |
*** lquirion <lquirion!~luq@modemcable114.129-37-24.static.videotron.ca> has joined #yocto | 16:01 | |
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 16:01 | |
ernstp | I guess this ties in with "B: By default, this directory is the same as the S directory" | 16:02 |
ernstp | cmake has rm -rf ${B} mkdir -p ${B} in do_configure | 16:03 |
*** TobSnyder1 <TobSnyder1!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 16:04 | |
jofr | Yes. But doesn't it only do a configure when it needs to fetch new sources? | 16:05 |
ernstp | yeah I guess it's quite rare to only trigger do compile, perhaps mostly happens when developing a recipe itself | 16:06 |
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 16:07 | |
lpapp | hi, is this the syntax of fetching from a local repo on the machine? SRC_URI = "file:///home/lpapp/foo;protocol=file;nocheckout=1;branch=topic \ | 16:07 |
*** stephano <stephano!~stephano@134.134.139.72> has joined #yocto | 16:08 | |
RP | lpapp: for git, no | 16:09 |
RP | lpapp: SRC_URI = "git:///home/xxxx;protocol=file" | 16:09 |
lpapp | oh ok, tried that, too, thanks | 16:09 |
kergoth | file:// won't call out to git, it'll copy the file over | 16:10 |
lpapp | hmm, that may be good enough as well | 16:10 |
ernstp | you might think that git over ssh is ssh://path but it's git://path;protocol=ssh etc | 16:10 |
lpapp | with git:/// -> unable to find revision | 16:10 |
lpapp | WARNING: Failed to fetch URL git:///home/lpapp/foo;protocol=file, attempting MIRRORS if available | 16:11 |
lpapp | ERROR: Fetcher failure: Unable to find revision b9e8d459764b211392089f4ea04ce003229ae0b9 in branch master even from upstream | 16:11 |
ernstp | lpapp/foo/.git ? | 16:12 |
jofr | lpapp: Try adding: SRCREV = "${AUTOREV}" and PV = "1.0+git${SRCPV}" (you may want a different PV though) | 16:13 |
jofr | If you want to use the latest head, that is. | 16:14 |
lpapp | no, it is not auto, sorry | 16:19 |
lpapp | it is not the latest, etc | 16:19 |
lpapp | so why is it failing to fetch given that git show b9e8d459764b211392089f4ea04ce003229ae0b9 is just fine in that local repo when I cd in? | 16:20 |
lpapp | if I specify the branch, it is "better" | 16:21 |
lpapp | thanks | 16:24 |
*** tprrt <tprrt!~tprrt@217.114.201.133> has quit IRC | 16:30 | |
*** tprrt <tprrt!~tprrt@217.114.201.133> has joined #yocto | 16:32 | |
*** dmoseley <dmoseley!~dmoseley@143.59.215.118> has joined #yocto | 16:38 | |
*** nighty- <nighty-!~nighty@b157153.ppp.asahi-net.or.jp> has quit IRC | 16:41 | |
*** mort <mort!~mort96@snow/mort96> has joined #yocto | 16:42 | |
*** JaMa <JaMa!~martin@217.30.68.212> has quit IRC | 16:43 | |
ernstp | so COPY_LIC_DIRS puts all the licenses that are part of the image on the target rootfs, but is there a method to get a bundle outside the target? | 16:46 |
ernstp | tmp/deploy/license/ just has licenses for everything compiled for some reason | 16:47 |
rburton | for a good reason: everything that gets built puts the license in deploy | 16:48 |
rburton | just like everythingt hat gets built put packages into deploy | 16:48 |
rburton | you can use the image manifest to get the package names, so you know what bits of the license folder to pick | 16:49 |
*** yacar_ <yacar_!~yacar@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC | 16:49 | |
ernstp | rburton: I mean everything compiled regardless of what triggered it :-) | 16:51 |
ernstp | so it includes hosttools etc | 16:51 |
ernstp | I'm thinking about stealing /usr/share/common-licenses from the target rootfs but that feels a bit backwards :-) | 16:52 |
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC | 16:54 | |
rburton | ernstp: just copy what you need from deploy/licenses | 16:57 |
rburton | RP: alsa patch from tanu on the list if you didn't spot it | 16:57 |
*** dev1990 <dev1990!~dev@dynamic-78-8-185-181.ssp.dialog.net.pl> has joined #yocto | 17:02 | |
ernstp | rburton: i have to implement package to recipe mapping then, don't I have? feels like a lot of work duplication | 17:05 |
*** tprrt <tprrt!~tprrt@217.114.201.133> has quit IRC | 17:05 | |
rburton | ernstp: oe-pkgdata-util can do that | 17:06 |
rburton | i even extended it recently to take a list for pretty much this purpose | 17:06 |
rburton | i'm assuming that license.bbclass can't generate a license manifest for you per-image | 17:07 |
rburton | maybe it can | 17:07 |
*** sno <sno!~sno@b2b-78-94-80-58.unitymedia.biz> has joined #yocto | 17:07 | |
rburton | also ripping it out of the rootfs isn't that nasty tbh :) | 17:08 |
rburton | ensure you have the rootfs as a tar.gz and then you can just tar them out | 17:08 |
ernstp | :-) | 17:09 |
rburton | do you actually what the license text, or just the names? | 17:09 |
ernstp | my idea was to do it in a postprocess hook and nuke them from the image | 17:09 |
ernstp | I want the text | 17:09 |
rburton | if you don't want them in the image, don't put them in the image... | 17:09 |
ernstp | yeah but that was the available method to get them collected per image :-) | 17:10 |
*** fl0v0 <fl0v0!~fvo@mue-88-130-107-064.dsl.tropolys.de> has quit IRC | 17:10 | |
rburton | so i'd turn off license_image, then take the image manifest, turn each package into a recipe, and grab the files from deploy/licenses/[recipe] | 17:11 |
rburton | $ oe-pkgdata-util lookup-pkg -r pkg [pkg ...] | 17:11 |
ernstp | license.bbclass has quite a lot of code... | 17:11 |
rburton | or was it lookup-recipe | 17:12 |
rburton | yeah license.bbclass is arguably over-engineered | 17:12 |
rburton | visitor classes and what not | 17:12 |
rburton | no glory in rewriting something that works though ... | 17:12 |
ernstp | cat tmp/deploy/images/machine/my-image-machine.manifest | awk '{ print $1 }' | xargs oe-pkgdata-util lookup-recipe | sort | uniq | xargs -i ls 'tmp/deploy/licenses/{}' -d | 17:14 |
ernstp | ls returns without any errors so that looks good | 17:14 |
rburton | the long term fix would be to enhance imagelicence.bbclass so its behaviour is configurable: you want per-image license texts outside the image which is can almost but not quite do. | 17:15 |
ernstp | the usecase is: no UI on device, licenses go on homepage/companion app, which I think is quite common | 17:17 |
rburton | yeah | 17:17 |
rburton | add some toggles to the class | 17:17 |
ernstp | LICENSE_CREATE_IMAGE_ARCHIVE or something | 17:18 |
rburton | i could see it writing a directory of the licenses under deploy/images/[image name]/ | 17:19 |
RP | rburton: I had, thanks | 17:19 |
RP | kanavin: playing with virtgl locally, its not easy to use compared to sdl :( | 17:19 |
kanavin | RP: how come? | 17:19 |
ernstp | rburton: right, then you can archive it however you like | 17:20 |
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 17:20 | |
rburton | exactly | 17:20 |
RP | kanavin: I use X over ssh for example which no longer works :/ | 17:20 |
RP | kanavin: I also just tried egl-headless here and it seems broken :( | 17:20 |
kanavin | RP: does the oe-selftest pass for it? | 17:21 |
ernstp | I wonder if I have waited long enough to ping you about https://bugzilla.yoctoproject.org/show_bug.cgi?id=12107 again... ;-) | 17:22 |
yocti | Bug 12107: normal, Medium, 2.7, JPEWhacker, NEW , useradd-staticids: groupadd: GID already exists | 17:22 |
RP | kanavin: its skipped, I'll retry with better permissions | 17:22 |
kanavin | RP: you need /dev/dri/render* with appropriate permissions | 17:23 |
kanavin | lexander@alexander-box:~/development/mbient-virgl/build-qemu-spark$ ls -l /dev/dri/ | 17:23 |
kanavin | total 0 | 17:23 |
kanavin | drwxr-xr-x 2 root root 80 Feb 21 19:18 by-path | 17:23 |
kanavin | crw-rw----+ 1 root video 226, 0 Feb 21 19:18 card0 | 17:23 |
kanavin | crw-rw----+ 1 root video 226, 128 Feb 21 19:18 renderD128 | 17:23 |
RP | kanavin: actually, X fails to start in my image with a GLSL compile failure :( | 17:23 |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 17:24 | |
RP | kanavin: (with runqemu gl) | 17:24 |
kanavin | RP: for me core-image-sato starts without problems, it adjusts to use Glamor X server automatically when it sees 'hardware' gl | 17:25 |
kanavin | for weston, you need to 'fix' the config file to use dri instead of fbdev | 17:25 |
RP | kanavin: this was core-image-sato ;( | 17:25 |
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 17:27 | |
*** sk_tandt <sk_tandt!~sk_tandt@net-5-88-141-17.cust.vodafonedsl.it> has quit IRC | 17:27 | |
*** sgw <sgw!~sgw@192.55.54.42> has joined #yocto | 17:31 | |
*** berton <berton!~berton@177.194.204.148> has quit IRC | 17:33 | |
RP | kanavin: the headless selftest passes but running it with runqemu just "hangs" | 17:41 |
RP | kanavin: running the qemu command on the console I see errors to do with bad dri driver paths by the looks of it | 17:42 |
kanavin | RP: you don't get anything when you connect to qemu with vnc? | 17:42 |
*** nerdboy <nerdboy!~sarnold@107.77.244.102> has joined #yocto | 17:44 | |
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 17:44 | |
RP | kanavin: there is no vnc to connect to, qemu dies afaict | 17:45 |
RP | kanavin: I'm probably doing something wrong | 17:45 |
kanavin | but egl-headless only makes sense if you also enable vnc, if you actually want to see the output | 17:46 |
RP | kanavin: right, it doesn't pass in that option though so I need to do that | 17:46 |
RP | ? | 17:46 |
kanavin | yes :) | 17:47 |
kanavin | runqemu kvm egl-headless publicvnc | 17:47 |
RP | kanavin: its confusing as runqemu just appears to hang, bad error handling? | 17:47 |
kanavin | it starts, but renders its output into nothing. if it has an ssh server, you can log into it. | 17:48 |
*** gtristan <gtristan!~tristanva@110.11.179.2> has quit IRC | 17:48 | |
kanavin | publicvnc option lets you see the output | 17:48 |
RP | kanavin: here, if I run the qemu command from the console that runqemu claims to be running, I just get errors | 17:49 |
RP | gbm: failed to open any driver (search paths /media/build1/poky/build/tmp/work/x86_64-linux/mesa-native/2_18.3.4-r0/recipe-sysroot-native/usr/lib/dri) | 17:49 |
RP | kanavin: what is worrying me more is that a) the headless test passes and b) I'm not seeing errors from runqemu | 17:50 |
kanavin | RP: runqemu does special magic to use the host dri drivers: | 17:50 |
kanavin | dripath = subprocess.check_output("PATH=/bin:/usr/bin:$PATH pkg-config --variable=dridriverdir dri", shell=True) | 17:50 |
kanavin | os.environ['LIBGL_DRIVERS_PATH'] = dripath.decode('utf-8').strip() | 17:51 |
kanavin | so I think it works as it should | 17:51 |
rburton | assuming host has libdrm-dev? | 17:52 |
kanavin | rburton, yes | 17:52 |
RP | kanavin: earlier it warned me about missing dri.pc, the reality was pkg-config wasn't installed :/ | 17:52 |
RP | kanavin: right, so my expectation of being able to copy and paste the command is now invalid | 17:53 |
*** lexa_` <lexa_`!~user@217.66.60.5> has quit IRC | 18:16 | |
*** andycooper <andycooper!uid246432@gateway/web/irccloud.com/x-haffyvcztrawrddm> has quit IRC | 18:21 | |
*** gtristan <gtristan!~tristanva@110.11.179.2> has joined #yocto | 18:30 | |
*** armpit <armpit!~armpit@2601:202:4180:c33:70ef:357b:adf:5cc4> has quit IRC | 18:33 | |
kanavin | RP: fwiw, just tried core-image-sato here, plain gl works fine, egl-headless also works fine via vncviewer. | 18:44 |
*** armpit <armpit!~armpit@2601:202:4180:c33:5d2e:f64b:3649:ebdb> has joined #yocto | 18:45 | |
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-mqgndvccekexrryt> has quit IRC | 19:10 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 19:11 | |
*** lexano <lexano!~lexano@CPEa021b7ac59c9-CMf0f249028110.cpe.net.cable.rogers.com> has quit IRC | 19:34 | |
*** lexano <lexano!~lexano@CPEa021b7ac59c9-CMf0f249028110.cpe.net.cable.rogers.com> has joined #yocto | 19:34 | |
*** daniel-k <daniel-k!~daniel@195.14.245.218> has quit IRC | 19:40 | |
hugo___ | rburton: RP Sorry for late reply. I currently support multiple toolchains for multiple platforms in the embedded space. I currently update them when theres a bump in the Poky SDK, which sometimes means a change in specific compiler flags. Most of the time, its not really an issue, as the sdk stays consistent. The reason I do this is to let the developers use the same editor but switch toolchain and reconfigure Cmake. We do not | 19:52 |
hugo___ | NEED to source for this to work. It would be great if yocto could export the toolchain in the setup step, as it now know the path of the sdk on the host. | 19:52 |
hugo___ | This is something I could do as a custom build step when we generate the sdk, just wondering before hand so I don't do unnecessary work :) Anyone have a pointer to the code where the current Cmake toolchain is compiled? | 19:54 |
*** ljp <ljp!~quassel@2001:8003:e043:6900:ba27:ebff:febb:59b> has joined #yocto | 20:01 | |
*** lpotter <lpotter!~quassel@2001:8003:e043:6900:ba27:ebff:febb:59b> has quit IRC | 20:01 | |
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 20:05 | |
*** andycooper <andycooper!uid246432@gateway/web/irccloud.com/x-dlqlzqflbekbbzbn> has joined #yocto | 20:07 | |
*** dfaught <dfaught!~dfaught@12.179.39.33> has joined #yocto | 20:57 | |
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 21:01 | |
*** lazyape <lazyape!~lazyape@athedsl-212890.home.otenet.gr> has quit IRC | 21:04 | |
*** lazyape <lazyape!~lazyape@athedsl-212890.home.otenet.gr> has joined #yocto | 21:04 | |
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 21:51 | |
RP | kanavin: I'm just not getting a good vibe about this being usable as it stands. I can't quite put a finger on why, just lots of odd things happening and things which don't quite work. Thinking we might mark this as experimental for 1.7 | 21:52 |
RP | 2.7 | 21:52 |
*** lazyape <lazyape!~lazyape@athedsl-212890.home.otenet.gr> has quit IRC | 21:56 | |
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 21:56 | |
*** lazyape <lazyape!~lazyape@athedsl-212890.home.otenet.gr> has joined #yocto | 21:57 | |
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 22:05 | |
*** Crofton <Crofton!~balister@c-73-152-143-112.hsd1.va.comcast.net> has quit IRC | 22:08 | |
*** Crofton <Crofton!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has joined #yocto | 22:09 | |
*** Klox <Klox!~Klox@c-73-22-66-195.hsd1.il.comcast.net> has quit IRC | 22:09 | |
*** mario-goulart <mario-goulart!~user@static.107.70.9.5.clients.your-server.de> has quit IRC | 22:10 | |
*** Klox <Klox!~Klox@c-73-22-66-195.hsd1.il.comcast.net> has joined #yocto | 22:10 | |
*** derRichard <derRichard!~derRichar@static.16.105.130.94.clients.your-server.de> has quit IRC | 22:10 | |
*** mario-go` <mario-go`!~user@static.107.70.9.5.clients.your-server.de> has joined #yocto | 22:10 | |
*** derRichard <derRichard!~derRichar@static.16.105.130.94.clients.your-server.de> has joined #yocto | 22:10 | |
*** lukma <lukma!~lukma@85-222-111-42.dynamic.chello.pl> has quit IRC | 22:11 | |
JPEW | ernstp: Sorry I missed your question on YOCTO #12107. I haven't had a chance to look at it yet :( | 22:11 |
*** lukma <lukma!~lukma@85-222-111-42.dynamic.chello.pl> has joined #yocto | 22:12 | |
*** mario-go` <mario-go`!~user@static.107.70.9.5.clients.your-server.de> has quit IRC | 22:12 | |
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 22:12 | |
*** mario-goulart <mario-goulart!~user@static.107.70.9.5.clients.your-server.de> has joined #yocto | 22:13 | |
*** ferlzc <ferlzc!~ferlzc@177.76.63.8> has quit IRC | 22:16 | |
*** ferlzc <ferlzc!~ferlzc@177.76.63.8> has joined #yocto | 22:17 | |
*** [Sno] <[Sno]!~sno@b2b-78-94-80-58.unitymedia.biz> has joined #yocto | 22:17 | |
*** sno <sno!~sno@b2b-78-94-80-58.unitymedia.biz> has quit IRC | 22:20 | |
*** [Sno] <[Sno]!~sno@b2b-78-94-80-58.unitymedia.biz> has joined #yocto | 22:21 | |
*** gtristan <gtristan!~tristanva@110.11.179.2> has quit IRC | 23:08 | |
*** black_13 <black_13!927305a2@gateway/web/freenode/ip.146.115.5.162> has joined #yocto | 23:16 | |
*** nerdboy <nerdboy!~sarnold@107.77.244.94> has joined #yocto | 23:16 | |
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 23:16 | |
black_13 | is tere something that is even smaller than core-image-minimal | 23:19 |
*** emg <emg!~emg@47.180.176.91> has joined #yocto | 23:21 | |
emg | can I enable two systemd services from one bb file? I added a second one to SYSTEMD_SERVICE_${PN} but that didn't seem to enable it | 23:22 |
*** ljp is now known as llornkcor | 23:30 | |
*** llornkcor <llornkcor!~quassel@2001:8003:e043:6900:ba27:ebff:febb:59b> has left #yocto | 23:30 | |
*** agust <agust!~agust@p54833194.dip0.t-ipconnect.de> has quit IRC | 23:35 | |
khem | you can | 23:38 |
khem | what does service look like ? is it there in image | 23:38 |
*** ferlzc <ferlzc!~ferlzc@177.76.63.8> has quit IRC | 23:44 | |
*** black_13 <black_13!927305a2@gateway/web/freenode/ip.146.115.5.162> has quit IRC | 23:50 | |
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has joined #yocto | 23:56 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!