Tuesday, 2018-01-16

*** kaspter <kaspter!~Instantbi@> has quit IRC00:02
*** kaspter <kaspter!~Instantbi@> has joined #yocto00:03
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto00:13
*** bodangly <bodangly!~bodangly@2601:18a:c780:27a0:a4b8:dfad:f2dd:40f1> has joined #yocto00:16
*** rcwoolley <rcwoolley!~rcwoolley@> has quit IRC00:25
*** learningc <learningc!~User@> has quit IRC00:26
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC00:36
*** mr_science_ <mr_science_!~sarnold@cpe-45-37-179-170.nc.res.rr.com> has quit IRC00:36
*** lamego <lamego!~lamego@> has quit IRC00:41
*** learningc <learningc!~User@mti-37-145.tm.net.my> has joined #yocto00:51
*** kaspter <kaspter!~Instantbi@> has quit IRC01:29
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:31
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC01:39
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto01:49
*** batman_ <batman_!95c73efe@gateway/web/freenode/ip.> has quit IRC01:50
*** scottrif <scottrif!~scottrif@> has quit IRC01:54
-YoctoAutoBuilder- build #721 of nightly-musl is complete: Failure [failed BuildImages] Build details are at https://autobuilder.yocto.io/builders/nightly-musl/builds/72101:58
*** Snert <Snert!~LoginName@106-24-237-24.gci.net> has quit IRC02:01
*** Snert <Snert!~LoginName@106-24-237-24.gci.net> has joined #yocto02:03
*** nighty- <nighty-!~nighty@s229123.ppp.asahi-net.or.jp> has quit IRC02:04
*** nighty- <nighty-!~nighty@s229123.ppp.asahi-net.or.jp> has joined #yocto02:05
-YoctoAutoBuilder- build #715 of nightly-x86-lsb is complete: Failure [failed Running Sanity Tests] Build details are at https://autobuilder.yocto.io/builders/nightly-x86-lsb/builds/71502:06
*** nighty-- <nighty--!~nighty@kyotolabs.asahinet.com> has joined #yocto02:12
-YoctoAutoBuilder- build #696 of nightly-mips-lsb is complete: Failure [failed Running Sanity Tests] Build details are at https://autobuilder.yocto.io/builders/nightly-mips-lsb/builds/69602:13
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC02:40
*** sgw <sgw!~swold@> has quit IRC02:47
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto03:18
*** learningc <learningc!~User@mti-37-145.tm.net.my> has quit IRC03:30
*** learningc <learningc!~User@mti-37-145.tm.net.my> has joined #yocto03:31
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC03:49
*** hamis <hamis!~irfan@> has joined #yocto03:59
*** dv_ <dv_!~dv@62-178-118-86.cable.dynamic.surfer.at> has quit IRC04:11
-YoctoAutoBuilder- build #177 of nightly-musl-x86-64 is complete: Failure [failed BuildImages] Build details are at https://autobuilder.yocto.io/builders/nightly-musl-x86-64/builds/17704:15
-YoctoAutoBuilder- build #692 of nightly-world-lsb is complete: Failure [failed BuildImages] Build details are at https://autobuilder.yocto.io/builders/nightly-world-lsb/builds/69204:16
-YoctoAutoBuilder- build #707 of nightly-arm-lsb is complete: Failure [failed Running Sanity Tests] Build details are at https://autobuilder.yocto.io/builders/nightly-arm-lsb/builds/70704:16
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto04:19
*** dv_ <dv_!~dv@62-178-118-86.cable.dynamic.surfer.at> has joined #yocto04:25
*** bananadev <bananadev!~onlyester@> has joined #yocto04:41
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC04:45
*** kaspter <kaspter!~Instantbi@> has quit IRC05:03
*** kaspter <kaspter!~Instantbi@> has joined #yocto05:04
*** TheSeven <TheSeven!~quassel@rockbox/developer/TheSeven> has quit IRC05:07
*** fjay <fjay!~jay@icryed.org> has quit IRC05:10
*** bananadev <bananadev!~onlyester@> has quit IRC05:24
*** bananadev <bananadev!~onlyester@> has joined #yocto05:27
*** agust <agust!~agust@p4FCB4189.dip0.t-ipconnect.de> has joined #yocto05:30
*** sgw <sgw!~swold@c-73-180-42-186.hsd1.or.comcast.net> has joined #yocto05:36
*** TheSeven <TheSeven!~quassel@rockbox/developer/TheSeven> has joined #yocto05:41
*** gtristan <gtristan!~tristanva@> has quit IRC05:42
-YoctoAutoBuilder- build #708 of nightly-qa-extras is complete: Failure [failed BuildImages_2] Build details are at https://autobuilder.yocto.io/builders/nightly-qa-extras/builds/70805:45
*** mbourhis <mbourhis!~mbourhis@glo44-1-82-67-130-147.fbx.proxad.net> has quit IRC05:46
*** clement <clement!~clement@lns-bzn-39-82-255-32-23.adsl.proxad.net> has quit IRC05:46
*** TheSeven <TheSeven!~quassel@rockbox/developer/TheSeven> has quit IRC05:46
*** clement <clement!~clement@static-css-ccs-204145.business.bouyguestelecom.com> has joined #yocto05:47
*** mbourhis <mbourhis!~mbourhis@glo44-1-82-67-130-147.fbx.proxad.net> has joined #yocto05:47
*** sgw <sgw!~swold@c-73-180-42-186.hsd1.or.comcast.net> has quit IRC05:48
*** sgw <sgw!~swold@> has joined #yocto05:50
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-eronghvsqthsjhdr> has quit IRC05:55
*** gtristan <gtristan!~tristanva@> has joined #yocto06:09
*** t0mmy <t0mmy!~tprrt@ram31-1-82-234-79-177.fbx.proxad.net> has quit IRC06:19
*** TheSeven <TheSeven!~quassel@rockbox/developer/TheSeven> has joined #yocto06:38
*** TheSeven <TheSeven!~quassel@rockbox/developer/TheSeven> has quit IRC06:43
-YoctoAutoBuilder- build #755 of nightly-oe-selftest is complete: Success [build successful] Build details are at https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/75506:44
*** chinhuat <chinhuat!c0c693a5@gateway/web/freenode/ip.> has joined #yocto06:56
*** hamis <hamis!~irfan@> has quit IRC06:59
*** hamis <hamis!~irfan@> has joined #yocto07:03
*** pohly <pohly!~pohly@p54BD5DCA.dip0.t-ipconnect.de> has joined #yocto07:03
*** open-nandra <open-nandra!~marek@> has joined #yocto07:07
*** TheSeven <TheSeven!~quassel@rockbox/developer/TheSeven> has joined #yocto07:08
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto07:10
-YoctoAutoBuilder- build #693 of nightly-world is complete: Failure [failed BuildImages] Build details are at https://autobuilder.yocto.io/builders/nightly-world/builds/69307:17
-YoctoAutoBuilder- build #716 of nightly-x86-64-lsb is complete: Failure [failed Running Sanity Tests] Build details are at https://autobuilder.yocto.io/builders/nightly-x86-64-lsb/builds/71607:34
*** hamis <hamis!~irfan@> has quit IRC07:36
-YoctoAutoBuilder- build #782 of nightly is complete: Failure [failed] Build details are at https://autobuilder.yocto.io/builders/nightly/builds/78207:36
*** hamis <hamis!~irfan@> has joined #yocto07:37
*** t0mmy <t0mmy!~tprrt@> has joined #yocto07:40
*** Kakounet <Kakounet!~Thunderbi@LFbn-1-11962-248.w90-93.abo.wanadoo.fr> has joined #yocto07:42
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:42
*** sagner <sagner!~ags@2001:1620:c6e::127> has quit IRC07:44
*** hamis <hamis!~irfan@> has quit IRC07:47
*** hamis <hamis!~irfan@> has joined #yocto07:48
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto07:55
*** hamis <hamis!~irfan@> has quit IRC08:00
*** maxin <maxin!maxin@nat/intel/x-qcrkrlcdvzvcolje> has joined #yocto08:00
*** hamis <hamis!~irfan@> has joined #yocto08:04
*** ctwr <ctwr!~catalin@> has quit IRC08:07
*** hamis <hamis!~irfan@> has quit IRC08:12
*** grma <grma!~gruberm@> has joined #yocto08:13
*** hamis <hamis!~irfan@> has joined #yocto08:13
*** fl0v0 <fl0v0!~fvo@i5E86303A.versanet.de> has joined #yocto08:13
*** ctwr <ctwr!~catalin@> has joined #yocto08:18
*** JaMa <JaMa!~martin@> has joined #yocto08:18
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC08:19
*** mdnneo <mdnneo!~umaucher@> has joined #yocto08:20
*** hnje <hnje!~hnje@> has joined #yocto08:22
*** sagner <sagner!~ags@> has joined #yocto08:23
*** Snert <Snert!~LoginName@106-24-237-24.gci.net> has quit IRC08:27
*** Snert <Snert!~LoginName@106-24-237-24.gci.net> has joined #yocto08:30
*** hamis <hamis!~irfan@> has quit IRC08:32
*** hamis <hamis!~irfan@> has joined #yocto08:32
*** vdehors <vdehors!~vdehors@91-162-62-2.subs.proxad.net> has joined #yocto08:37
*** hnje <hnje!~hnje@> has quit IRC08:40
*** hnje <hnje!~hnje@> has joined #yocto08:42
*** ed21 <ed21!~Adium@> has joined #yocto08:46
*** hamis <hamis!~irfan@> has quit IRC08:49
*** joshuagl <joshuagl!joshuagl@nat/intel/x-clyevpotllpbqooj> has joined #yocto08:56
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC08:57
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto08:57
*** hamis <hamis!~irfan@> has joined #yocto08:57
aurelehi everyone08:58
xthunderheartxgood morning08:58
aureleI'm facing an issue with asterisk, they are using a bootstrap.sh to run aclocal autoconf ... and the configure fails because my recipe don't run the "bootstrap.sh"09:00
aureleshould I call the bootstrap.sh in a do_configure_append? or just override aclocal (how can I do that?)09:01
xthunderheartxaurele: It may be a little early for the folks who could answer with authority09:03
aurelexthunderheartx, I will try some things, and maybe come back later ;)09:04
xthunderheartxAt least US folks anyway. It will liven up in a few hours09:05
xthunderheartxAs an asterisk fan from *way back* I wish you luck ... you'll need it.09:06
xthunderheartxOr awesome skillz ... those will do as well :)09:07
*** chinhuat <chinhuat!c0c693a5@gateway/web/freenode/ip.> has quit IRC09:09
LetoThe2ndaurele: probably overriding the do_configure command does the trick. but better be absolutely sure that this magic script does not introduce any host dependencies.09:13
LetoThe2ndaurele: or prepending it.09:13
*** cisasystems <cisasystems!547c4608@gateway/web/freenode/ip.> has joined #yocto09:13
cisasystemsHello everybody!!09:13
*** ranran <ranran!59ed719b@gateway/web/freenode/ip.> has joined #yocto09:16
ranranwhat is the purpose of sysroot ?09:16
ranranIs it for kernel headers ?09:16
*** mckoan|away is now known as mckoan09:17
LetoThe2ndranran: it has a couple of uses, the primary probably serving as sysroots for the compilers. this means the compilers use this as their root, instead of looking at the host.09:17
ranranIs it that a package which depends on another one for the build, find the other package (header/library) in sysroot ?09:22
ranranI mean, does the sysroot also used during build of packages to resolve dependency ?09:22
LetoThe2ndranran: basically, yes. but what is it that you are *ACTUALLY* trying to do?09:23
cisasystemsHow can I set the owner of the config files ?09:24
ranranLetoThe2nd, I just try to have better understanding of sysroot. Is sysroot used for the build process or only for the sdk package ?09:24
LetoThe2ndranran: it is especially used in the build process.09:24
LetoThe2ndcisasystems: meaning... what?09:25
LetoThe2ndranran: https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html09:25
ranranThank you.09:26
*** toanju <toanju!~toanju@> has joined #yocto09:28
*** ranran <ranran!59ed719b@gateway/web/freenode/ip.> has quit IRC09:32
*** skz81 <skz81!~SKZ@> has joined #yocto09:33
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-gihdzyyidjlteikx> has joined #yocto09:59
*** lazyape <lazyape!~lazyape@athedsl-244581.home.otenet.gr> has joined #yocto10:03
*** alinucs <alinucs!~abo@bgn92-1-82-67-207-244.fbx.proxad.net> has quit IRC10:16
lukmaGood morning,10:25
lukmaI do have a question regarding devtool10:25
lukmais it possible to have verbose output of devtool build <recipe> ?10:25
lukmasomething like bitbake -v <recipe>10:26
lukmaI do find devtool as a good developer's tool, but I would like to see the detailed output of compilation - including errors and warnings10:26
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC10:36
*** ipuustin <ipuustin!~ipuustin@dyn9kkyrcj-m---xk12qy-3.rev.dnainternet.fi> has joined #yocto10:46
*** learningc <learningc!~User@mti-37-145.tm.net.my> has quit IRC10:56
*** rburton <rburton!~textual@home.burtonini.com> has joined #yocto10:57
*** rburton <rburton!~textual@home.burtonini.com> has quit IRC10:59
*** rburton <rburton!~textual@home.burtonini.com> has joined #yocto11:00
*** alinucs <alinucs!~abo@bgn92-1-82-67-207-244.fbx.proxad.net> has joined #yocto11:01
ttllkklukma: maybe bitbake package -DDD ?11:03
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto11:12
*** acrap <acrap!~andrey@host-85-237-33-147.dsl.sura.ru> has joined #yocto11:17
acraphi, guys!11:17
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC11:32
*** nighty-- <nighty--!~nighty@kyotolabs.asahinet.com> has quit IRC11:32
*** sjolley <sjolley!~sjolley@> has quit IRC11:32
*** sjolley <sjolley!~sjolley@> has joined #yocto11:33
aurelehi again I have updated my layers and I have the folowing issue : https://pastebin.com/rBnFCYh811:42
aurele"pseudo-native" doesn't compile for a strange reason...11:43
*** falk0n <falk0n!~falk0n@a79-168-122-55.cpe.netcabo.pt> has joined #yocto11:44
aurelesorry for bothering everyone but a simple cleanall did the trick11:58
rburtoncleanall isn't simple, just clean would have worked12:05
*** RP <RP!~richard@5751f4a1.skybroadband.com> has quit IRC12:09
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto12:13
aurelerburton, I will try to remember for next time but sometimes clean is not enough and I try cleanall (and usually this doesn't fix the issue). So now I use cleanall directly12:14
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto12:15
*** ed21 <ed21!~Adium@> has quit IRC12:24
*** ed21 <ed21!~Adium@> has joined #yocto12:24
rburtonaurele: cleanall will delete the working tree (same as clean), and all sstate objects (same as cleansstate), and all tarballs downloaded12:25
rburtonunless you want to remove objects from sstate, clean is sufficient12:25
*** cisasystems <cisasystems!547c4608@gateway/web/freenode/ip.> has quit IRC12:28
*** bananadev <bananadev!~onlyester@> has quit IRC12:33
*** learningc <learningc!~User@> has joined #yocto12:42
*** learningc <learningc!~User@> has quit IRC12:44
*** learningc <learningc!~User@> has joined #yocto12:44
*** kaspter <kaspter!~Instantbi@> has quit IRC12:44
*** learningc <learningc!~User@> has quit IRC12:45
*** learningc <learningc!~User@> has joined #yocto12:45
*** learningc <learningc!~User@> has quit IRC12:47
*** learningc <learningc!~User@> has joined #yocto12:47
*** hamis <hamis!~irfan@> has quit IRC13:02
*** marka <marka!~masselst@> has joined #yocto13:20
rburtonanyone who uses cmake, i've just sent a RFC to the oe-core list13:26
*** kanavin <kanavin!ak@nat/intel/x-pgniaimzpcokeuwo> has quit IRC13:27
*** kanavin <kanavin!~ak@> has joined #yocto13:27
*** xthundermobilex <xthundermobilex!~androirc@> has joined #yocto13:45
*** stephano <stephano!~stephano@> has joined #yocto13:48
*** gtristan <gtristan!~tristanva@> has quit IRC13:53
sveinseANyone know anything about any noteable changes in gobject / glib / dbus in rocko (vs pyro)? I just can't get my pygobject dbus listener script to work on rocko. I've spent many hours trying to debug it, and it boils down to something in so-land refusing to start13:53
sveinse(and gobject / glib is apparently not the easiest beast)13:54
rburtonsveinse: sounds like something we need to add to sanity testing...13:55
rburtonpastebin the error?13:55
xthunderworkxGeez ... connect fingers to brain13:56
xthunderworkxrburton: So I have a working recipe for dbus-cxx and I be happy to submit it.13:56
xthunderworkxOne issue though, which you commented on yesterday is it looks like the upstream maintainer doesn't do much in the was of "maintaining" these days.13:57
xthunderworkxThe library version information seems to never change though the package version *has* been diligently updated.13:59
rburtoni'd just report a bug upstream to tell them to library version13:59
rburtonyou can't do anything13:59
xthunderworkxYeah, I can do that. However the bug reporting mechanism is just a post to the list server and there have bee a total of 3 posting since 2014.14:00
xthunderworkxNot sure it is getting much attention14:00
rburtonfork it! :)14:00
xthunderworkxI thought about that ...14:01
joshuaglI suspect that's because GLib users have dbusglib bindings for cxx and QT users have Qt bindings for cxx, I'd wager that not many people use/need dbus-cxx :-/14:02
sveinserburton, I will paste the error and what I've investigated. Hold on14:03
zarzar1rburton: i added sanity.conf14:03
xthunderworkxWell, I just need an IPC mechanism that supports signals and rpc for what we are doing and dbus-cxx seemed to fit the bill. Plus the examples worked and were easy to follow.14:04
rburtonindeed, dbus is good.  its a shame dbus-cxx is unmaintained14:05
xthunderworkxWell I've been taking from the Linux community for decades (literally). Maybe this would be an opportunity to give back. Lend a hand.14:06
*** paulg <paulg!~paulg@198-84-239-75.cpe.teksavvy.com> has quit IRC14:06
rburtona polite mail to the last known maintainer is nice, but i'd be throwing up a github clone and putting the out of tree build fix in there for a start14:09
rburtonthen learn library versioning and do that14:09
sveinsedbus might be good, but alas I've been having my troubles with the event loops glib or gobject14:10
xthunderworkxYep, I figured I'd send an email to rvinyard. Go from there.  Is there a defined process for submitting a recipe to OE?14:10
rburtonpick a layer (meta-oe sounds right), then submit a patch to the relevant list (openembedded-devel@lists.openembedded.org)14:11
xthunderworkxI did smoke over library versioning lastnight and I think I have a grasp of the idea.14:11
xthunderworkxRoss you are the Yocto dbus guy (maintainer) right?14:13
xthunderworkxSo you would likely review it?14:13
rburtoni certainly hope not14:13
rburtoni might glance at the odd patch for meta-oe but i don't review them all14:14
xthunderworkxLOL!  "Sato/GTK/Dbus - Ross Burton" ... not you?14:14
rburtondamnit where does it say that14:14
xthunderworkxCome on now!14:14
rburtonRECIPE_MAINTAINER_pn-dbus = "Chen Qi <Qi.Chen@windriver.com>"14:14
rburtonnot me! :)14:14
xthunderworkxCoffee just spewed out of my nose ...14:15
*** gtristan <gtristan!~tristanva@> has joined #yocto14:15
rburtonif thats from the web site then we know its out of date and there's a replacement on the way14:15
xthunderworkxThat's the top response to google "rburton yocto"14:16
xthunderworkxJust assumed it was you.14:17
*** aratiu1 <aratiu1!~adi@> has joined #yocto14:20
*** aratiu <aratiu!~adi@> has quit IRC14:20
sveinserburton: https://bpaste.net/show/be2b530702cc. Works on pyro, fails on rocko.14:21
sveinseI do have other differences in the manifests between these two versions, but nothing which stands out as being related to this. So it it is fully possible that the root cause is a missing dependency14:23
rburtonsveinse: presumably you're adding your own python-gobject?14:23
sveinserburton: no. why?14:25
rburtonah, there's a recipe in meta-oe still14:26
rburtonpresumably you're using that then14:26
sveinseIt's supposed to listen on dbus events from udisks14:26
rburtonsveinse: easy test: have you tried with py3?14:26
rburtonwhat with us doing everything we can to delete py2 from oe-core knowing if it works in py3 would be useful14:27
*** toanju <toanju!~toanju@> has quit IRC14:27
sveinserburton: yes. it doesn't. It follows the same path as py2. But this time it doesnt mask the proper gi error, it reads: "ImportError: cannot import name GObject, introspection typelib not found"14:28
rburtonso... is the introspection typelib present? :)14:28
sveinserburton: I honestly don't know what I'm looking for14:29
rburtoni guess gobject is a special one14:29
*** sgw <sgw!~swold@> has quit IRC14:29
sveinseAs the paste said, it fails because _gi.so lib returns [] on enumerate_versions() on rocko, while ['2.0'] on pyro. This is the same for py2 and py314:30
rburtonbuilding stuff here now14:34
rburtonneed to add a test case for this to ensure it doesn't regress14:34
sveinseI'm fine-reading the manifest-diff now14:35
rburtonmost likely a proper bug and not a manifest issue14:36
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC14:37
*** stephano <stephano!~stephano@> has quit IRC14:38
*** aratiu1 <aratiu1!~adi@> has quit IRC14:40
sveinsemeanwhile, I should perhaps see after other approaches for dbus access from python14:40
*** aratiu <aratiu!~adi@> has joined #yocto14:41
rburtonsveinse: >>> GObject.glib_version14:48
rburton(2, 54, 2)14:48
rburtonworks for me14:48
sveinserburton: right. tested on what machine?14:49
sveinseI need to get a qemu environment up so I can test too. I must read the docs how one does that14:51
rburtonset MACHINE=qemuwhatever when doing a build, then use runqemu14:52
yoctiNew news from stackoverflow: How to package CMake Module in NativeSDK? <https://stackoverflow.com/questions/48283891/how-to-package-cmake-module-in-nativesdk>14:53
*** hnje <hnje!~hnje@> has quit IRC14:57
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto15:03
*** ntl <ntl!~nathanl@65-36-80-8.dyn.grandenetworks.net> has joined #yocto15:05
*** lamego <lamego!lamego@nat/intel/x-yitlzizzfpzuicoz> has joined #yocto15:06
zarzar1i ran bitbake core-image-base -c fetchall but there are very few c and h files pulled in, also does not look like uboot was pulled in15:06
zarzar1is there an image that would pull in uboot file?15:07
rburtonzarzar1: that image will, assuming you picked a machine which uses uboot15:13
*** dave0x6d <dave0x6d!uid190567@gateway/web/irccloud.com/x-vefedeutfrqowsxv> has quit IRC15:13
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC15:14
zarzar1rburton: hmmm, seems like very few source files were pulled in, not sure what the deal is15:14
rburtonwhere are you looking?15:14
zarzar1rburton: https://pastebin.com/ZmP0z69B15:15
rburtonthats not where downloads go15:15
rburtonalso downloads are tarballs, not unpacked15:15
zarzar1oh ok15:15
rburtonlook in whatever you've set DL_DIR to15:15
zarzar1dang, i didn't set DL_DIR15:16
rburtontheres a default value15:17
*** falk0n <falk0n!~falk0n@a79-168-122-55.cpe.netcabo.pt> has quit IRC15:17
*** falk0n <falk0n!~falk0n@a79-168-122-55.cpe.netcabo.pt> has joined #yocto15:19
zarzar1rburton: so that's not good, tarballs of code, I mainly pulled code in order to use find and grep on the source files for uboot15:22
*** open-nandra <open-nandra!~marek@> has quit IRC15:22
*** stephano <stephano!~stephano@> has joined #yocto15:22
sveinsebitbake -c unpack u-boot ?15:23
sveinseProbably need some building to get there15:23
zarzar1can i run unack on an image? like i did with fetchall15:24
zarzar1building takes up too much disk space, trying to avoid a full build but just want to look at sources15:25
zarzar1could i run a build then delete tmp folder without losing sources?15:25
sveinsenot sure when bitbake populates the recipe's DEPENDS when building, so I'm not sure if do_unpack is run prior to this15:26
sveinseBut are you using a shared sstate cache?15:27
zarzar1no sahred sstate cache that i know of15:28
sveinsezarzar1: That will surely save you a ton and a half, both with respect to compile time and disk space15:29
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC15:30
sveinseSet SSTATE_DIR in local.conf to a location that can hold much data. This can be shared across MACHINES, DISTROs and Yocto versions. This way bitbake -c unpack u-boot will only take a few minutes to progress (given that all objects exists in the cache)15:31
*** sgw <sgw!swold@nat/intel/x-pnsnsjfdsjngtffw> has joined #yocto15:32
zarzar1devtool modify <recipename> ?15:40
rburtonyeah that15:40
zarzar1found that here: https://wiki.yoctoproject.org/wiki/TipsAndTricks/Patching_the_source_for_a_recipe15:40
rburtonyou said you wanted all sources, so were told how to do that (fetchall)15:40
zarzar1rburton: true, i did not know they would be tar ablled15:41
rburtonupstream sources are almost all either git repos or tarballs15:41
zarzar1error: recipe is an image, and therefore is not supported by this tool15:41
rburtonyeah you can't modify images as they don't have sources15:42
rburtonyou said uboot, so modify uboot15:42
zarzar1oh ok15:42
*** skz81 <skz81!~SKZ@> has quit IRC15:42
*** skz81_ <skz81_!~SKZ@> has joined #yocto15:42
zarzar1that worked15:42
zarzar1is it possible to find all recipes in an image?15:44
sveinsezarzar1: an image generates a manifest, that is the list of all packages installed in it15:45
zarzar1what's the diff between package and recipe?15:45
zarzar1is it possible to find all recipes in an image?15:46
rburtona recipe generates packages15:46
zarzar1for devtool modify i need recipes15:46
rburtona recipe (say, glib) will generate many packages (libglib, libglib-dev, libglib-doc, libglib-locale-*, etc)15:46
zarzar1i don't think i need packages for devtool modify15:46
rburtoncorrect, you tell it what recipe15:46
rburtonrecipes make packages, images are collections of packages15:47
zarzar1so can i get the recipes use by an image or no?15:47
rburtonbitbake imagename -g will write pn-buildlist, which lists all recipes it will be building to satisfy the requirements15:49
*** jku <jku!~jku@dyj-skyylh9rf8bj5n84y-3.rev.dnainternet.fi> has joined #yocto15:50
zarzar1holy moly15:53
zarzar1i'll just run a build and delete tmp after15:53
zarzar1is there an email list for feature requests?15:57
*** jku <jku!~jku@dyj-skyylh9rf8bj5n84y-3.rev.dnainternet.fi> has quit IRC15:58
*** xthundermobilex <xthundermobilex!~androirc@> has quit IRC16:06
ttllkkWhere can I check the list of packages upgraded on a new yocto version16:07
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC16:10
*** ed21 <ed21!~Adium@> has quit IRC16:14
*** ulf` <ulf`!ulf@nat/intel/x-talrourfsiiajtks> has joined #yocto16:15
*** stephano <stephano!~stephano@> has quit IRC16:24
*** stephano <stephano!~stephano@> has joined #yocto16:24
sveinserburton: I found the issue. And it was mine. gobject-introspection-data was added to DISTRO_FEATURES_BACKFILL_CONSIDERED for some reason. Thank you very much for persuing the issue.16:28
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto16:31
*** Nilesh_ <Nilesh_!uid116340@gateway/web/irccloud.com/x-hrkxlciwyxeaibgo> has joined #yocto16:36
*** t0mmy <t0mmy!~tprrt@> has quit IRC16:36
*** mbourhis <mbourhis!~mbourhis@glo44-1-82-67-130-147.fbx.proxad.net> has quit IRC16:37
*** tripzero <tripzero!tripzero@nat/intel/x-xrkmoqwtatbtzejk> has joined #yocto16:37
kergothHmm, wonder why we don't pass —unity to meson by default, the docs say they recommend it for distro builds, since it's always from scratch rather than incremental16:39
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC16:41
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto16:46
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC16:48
*** skz81_ <skz81_!~SKZ@> has quit IRC16:49
*** vmeson <vmeson!~rmacleod@192-0-133-4.cpe.teksavvy.com> has quit IRC16:52
rburtonsveinse: haha16:54
rburtonsveinse: yeah that would be it.  want to send a patch to make python-pygobject abort in that case?16:54
*** vmeson <vmeson!~rmacleod@192-0-133-4.cpe.teksavvy.com> has joined #yocto16:55
rburtonkergoth: patches welcome!  personally, never heard of that flag before16:55
*** paulg <paulg!~paulg@198-84-239-75.cpe.teksavvy.com> has joined #yocto16:58
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC16:59
*** armpit <armpit!~armpit@2601:202:4000:1184:94e2:24fc:6a2d:d1a9> has quit IRC17:01
*** mdnneo <mdnneo!~umaucher@> has quit IRC17:03
*** bavery_fn1 <bavery_fn1!bavery@nat/intel/x-lcbomczbtzsilbty> has joined #yocto17:04
*** bavery_fn <bavery_fn!bavery@nat/intel/x-iwoitaxkaskqlcxq> has quit IRC17:05
*** bavery_fn1 <bavery_fn1!bavery@nat/intel/x-lcbomczbtzsilbty> has quit IRC17:08
*** mattsm <mattsm!~mattsm@> has quit IRC17:12
*** mckoan is now known as mckoan|away17:15
*** fl0v0 <fl0v0!~fvo@i5E86303A.versanet.de> has quit IRC17:19
*** vdehors <vdehors!~vdehors@91-162-62-2.subs.proxad.net> has quit IRC17:23
*** stephano <stephano!~stephano@> has quit IRC17:26
*** sjolley <sjolley!~sjolley@> has quit IRC17:28
*** stephano <stephano!~stephano@> has joined #yocto17:31
*** Kakounet <Kakounet!~Thunderbi@LFbn-1-11962-248.w90-93.abo.wanadoo.fr> has quit IRC17:31
*** RP1 <RP1!~richard@5751f4a1.skybroadband.com> has joined #yocto17:39
*** batman_ <batman_!95c73efe@gateway/web/freenode/ip.> has joined #yocto17:42
*** RP1 is now known as RP17:44
*** sagner <sagner!~ags@> has quit IRC17:46
kergothhttp://mesonbuild.com/Unity-builds.html the potential crash issue probably makes it not worth enabling globally, though17:46
*** scottrif <scottrif!~scottrif@> has joined #yocto17:47
batman_Hello, Where can see the logs of functions which are run with a eventmask. example: do_app_setup[eventmask] = "bb.event.BuildStarted"17:48
batman_where can I check what happened with do_app_setup ?17:48
batman_do_app_setup[eventmask] is part of a bbclass and I have already looked at the logs of the recipe which inherits the bbclass.17:49
*** bavery_fn <bavery_fn!bavery@nat/intel/x-rnrtzatyuehqnkqb> has joined #yocto17:59
*** xthundermobilex <xthundermobilex!~androirc@> has joined #yocto17:59
*** t0mmy <t0mmy!~tprrt@fs-93-93-41-87.fullsave.info> has joined #yocto17:59
batman_Let me rephrase the question: "Where can I check logs of even handlers?"18:03
batman_*event handlers?18:03
kergothevent handlers most likely log to the bitbake console log only18:04
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-ygdzxzyeuriifkcw> has joined #yocto18:05
*** stephano <stephano!~stephano@> has quit IRC18:10
*** stephano <stephano!stephano@nat/intel/x-vyjdtgsmbofcrfca> has joined #yocto18:11
*** bavery_fn <bavery_fn!bavery@nat/intel/x-rnrtzatyuehqnkqb> has quit IRC18:13
sveinsekergoth, rburton: Found this more informative: https://lists.yoctoproject.org/pipermail/yocto/2016-April/029579.html18:13
kergothnice, that should probably go in the yocto docs somewhere if it isn't already18:13
sveinseHonestly I don't have a clue what introspection data is about. I see its mentioned in the dev manual (4.11), but the manual kind of gave the impression that its linked to qemu18:14
batman_kergoth: Thanks for clarifying that.18:15
*** bodangly <bodangly!~bodangly@c-24-218-194-93.hsd1.ct.comcast.net> has joined #yocto18:15
sveinsebut that's clearly not the case. A little wiser today!18:15
kergothafaik introspection is when it actually has to run the target binary to get info about the target binary, or something?18:15
kergothpossibly similar to help2man?18:15
kergothno clue18:15
kergothbatman_: np18:15
kergothbatman_: so you should be able to find it in tmp/log/18:15
kergothmight be worth improving event handler logging int he future, feel free to open an issue in bugzilla18:16
*** mattsm <mattsm!~mattsm@> has joined #yocto18:18
*** sjolley <sjolley!~sjolley@> has joined #yocto18:18
sveinseI use gobject as an event loop in a dbus listener python app. Frankly I don't really care how it works and why it needs introspection-data. The API interface I'm interfacing is dbus. But that was evidently a too simple assumption. :)18:19
* kergoth nods18:19
*** stephano <stephano!stephano@nat/intel/x-vyjdtgsmbofcrfca> has quit IRC18:20
sveinseBut yes, python-pygobject should fail on backfilled gobject-instrospection-data. Or should it? Are there usecases where python-pygobject would work even without the introspection data? I have no clue18:21
sveinserburton: Perhaps this should be discussed on the mail lists?18:21
*** hmwel <hmwel!~hmw@zimbra.welvaarts.com> has quit IRC18:22
*** stephano <stephano!~stephano@> has joined #yocto18:23
sveinseAhh, gobject-introspection-data requires qemu to be able to generate the data, so there are a number of archs where this package is problematic.18:24
sveinseAlas, the old assumption about that I can always run what I build. I think all sw devs should intern at least one half year with cross building for other targets. :P :D18:26
*** hmwel <hmwel!~hmw@zimbra.welvaarts.com> has joined #yocto18:33
xthunderworkxI need a way to make certain that the toolchain bitbake uses is a specific version.18:36
*** clsulliv <clsulliv!~clsulliv@> has quit IRC18:37
xthunderworkxBasically because we need to build a FIPs 140-2 compliant image.18:37
frayThe toolchain itself is not usually a requirement of FIPS 140-2..18:37
*** toanju <toanju!~toanju@x55b420f5.dyn.telefonica.de> has joined #yocto18:37
frayit's the crypto itself that is the issue..18:38
xthunderworkxAnd how the crypto is built18:38
frayAre you focusing on a particular cryptographic engine (or engines)?18:38
frayOpenSSL crypto module is the easiest to build.  But what we determined, for FIPS-140-2 support, is the only way to build it and conform the stated requirements was construct an SDK.. and then build it from the SDK following all of the rules in the guide..18:38
frayThe the build system itself could package the prebuilt binaries into the image.. but building it withint he YP/OE environment would not allow us to ensure that the user guide requirements were followed.18:39
xthunderworkxRight. So then bitbake could use the toolchain in there right?18:39
frayUse bitbake to construct an SDK..18:40
frayuse the SDK to build the openssl-fips module, following the guide..18:40
fraytar up the resulting binaries, as well as the logs for external verification..18:40
fraycreate a recipe that replaces the OpenSSL package with one that includes the BINARY openssl w/ fips module..18:41
fraythe recipe just extracts the tarball, puts the thins in the right location and the package is created, which is used to popualte the FS image..18:41
xthunderworkxHmmmm ... that makes sense.18:41
frayThe binaries become immutable to OE/YP..18:41
fraysince you built them in a specific way, you know they meet the requirements and can pass the certifiations required.18:41
*** clsulliv <clsulliv!clsulliv@nat/intel/x-ekioyamknbuvsntb> has joined #yocto18:42
xthunderworkxSo our hardware vendor (Digi) is responsible getting their OE attached to one of the existing OpenSSL certs18:42
xthunderworkxiMX6ul OE18:43
frayfor the OpenSSL fips module certificate, you need a corresponding architecture, and compiler version (at a minimum)..18:43
fraythere are ones that are in the list hat would be compatible with the i.mx6, but perhaps not as optimized..18:43
xthunderworkxYep but old kernels18:43
frayif you want/need optimized there is a good chance you will have to run through your own certification (or better yet, work with the OpenSSL Foundation to request an update)18:43
frayThe kernel does not matter for OpenSSL-fips.. (at least last time I checked)18:44
xthunderworkxYep, Digi is submitting to OpenSSL and paying the ransom18:44
frayyes, that is the right way to do this18:44
*** Nilesh_ <Nilesh_!uid116340@gateway/web/irccloud.com/x-hrkxlciwyxeaibgo> has quit IRC18:45
xthunderworkxThere is an OE on the cert now ... but it is Dizzy/Daisy kernel rev. (3.14) which fell off LTS in Octobe.18:45
xthunderworkxThe G don't like that.18:45
xthunderworkxSo Digi will submit the Morty kernel etc.18:46
frayCerting against teh YP is going to continue that to happen.. as the YP only supports for roughly 1 year at a time..18:46
kergothit's so weird to me hearing that digi is using OE, considering OE was started while I was working there in tech support, often did the early work on bitbake while waiting between calls :)18:46
frayyou (and your supplier) should look at a commercial YP provider -- as you can get much longer support time frames (2-5 years typically)..18:46
frayThere is another thing to be aware of teh OpenSSL-FIPS module certifiate will be expiring in I believe 2020, and it does not appear that it can be renewed as currently implemented.. (I may be a year or two early.. may be 2022)...18:47
fray(you can find the current cert on the FIPS website, and look at the expiration date...)18:48
fraythat has been a problem for some of our customers, and they have choosen to certify there platform themselves to get a slightly later expiration date.. (and yes, that costs MUCH more)18:49
xthunderworkxYep though I doubt we care past this year. G funded prototype for evaluation.  If the thing gets out of trial ... money will not be of prime consideration.18:50
xthunderworkxThe G never runs out of money.18:50
xthunderworkxBut those are good points and I will definitely push up to the Suits18:50
* fray works for a commercial YP vendor.. so I'm familiar with all of these problems..18:51
fraybut I'm not trying to advertise my company here.....  just making clear commercial support may be a better long term option, assuming you need longer term then a year..18:51
*** armpit <armpit!~armpit@> has joined #yocto18:52
xthunderworkxDood, I love to store your 411.  If the thing works, we may definitely need your help.18:52
*** dreyna <dreyna!~dreyna@> has joined #yocto18:53
*** rburton <rburton!~textual@home.burtonini.com> has quit IRC18:53
*** rburton <rburton!~textual@home.burtonini.com> has joined #yocto18:53
xthunderworkxSo build the binaries using the rulez, stash them in a repo and pull them into the image with bitbake.18:55
frayyes, that is what i recommend.. it seems to be the easiest way to follow the user guide requirements, provide something to be certified (and verified logs), and show conformance with the requirements if requested18:55
*** xthundermobilex <xthundermobilex!~androirc@> has quit IRC18:59
*** xthundermobilex <xthundermobilex!~androirc@> has joined #yocto18:59
*** stephano <stephano!~stephano@> has quit IRC19:02
*** stephano <stephano!~stephano@> has joined #yocto19:02
*** rewitt <rewitt!rewitt@nat/intel/x-acccdgrsxyrniqsh> has joined #yocto19:19
xthunderworkxkergoth: Yeah, Digi is doing a custom baseboard for us with their iMX6ul SOM. We've done non-YP Linux stuff for them in the past though I didn't work on that.19:21
xthunderworkxIn the context of that conversation I meant "Operational Environment" not OpenEmbedded, but yeah they provide YP based releases for their SOMs.19:22
xthunderworkxI actually like Digi ... they have been pretty good so far even though we squeezed them on the budget.19:24
sveinsefray, out of curiosity, what does a commercial YP provider deliver exactly?19:35
fraylong term support beyond the regular Yocto Project life cycle19:35
frayso if you want 2 years of support on a release, maybe 5.. or even say 15.. many of the commercial providers can do this19:35
frayif you are able to upgrade your product on a 6month or yearly basis.. then that may not be a big deal -- but, then there are other things like faster bug fixes.. (things not merged upstream would be availabel, QA'd and supported for you..19:36
sveinseThe company I work for make end-user products which makes the SW image on it using Yocto. The end-user is never directly involved in Yocto. We have a sub contractor which provides us with both the custom HW and the BSP plus a distro.19:36
sveinseWe track poky releases more or less19:36
frayadditional CVE fixes etc..  (We and any YP supplier who follows the general community rules will supply there patches to the tree during the YP support period...)19:36
frayit's all about having someone to fix a problem, if you have a problem...  someone to track security issues on your behalf... and maintenance ability beyond the community..19:37
frayone or all of those often justifies a commercial provider19:38
sveinseSo a use case for our case would be to get a commercial YP from one source, while the HW vendor maintain the BSP. In a kind of threesome relationship?19:39
*** lazyape <lazyape!~lazyape@athedsl-244581.home.otenet.gr> has quit IRC19:40
frayit can be...  In my employers case, they have special ways to setup those agreements...19:40
*** lazyape <lazyape!~lazyape@athedsl-244581.home.otenet.gr> has joined #yocto19:40
fraya lot of our customers use COTS boards and skip the HW vendor part..19:40
fraywe offer a lot of COTs BSPs... but that doesn't always mean everything you want is supported on a particular BSP.. so thats part of the business discussion (or well should be)19:41
frayoften things like camera modules, or specific GPIOs may not be supported without a specific use-case or customer need.. (in my employers case)19:41
sveinsefray: you don't happen to work for a Brazillian company? ;)19:42
frayI know we have customers in Brazil though..19:42
sveinseanyhow, our volumes were far to high for COTS, thus the custom HW and subsequently BSP19:43
frayIn our case, if the BSP follows the YP design.  Often times we can incorporate support for the BSP as well.  However, a lot of the time the BSP ignores the 'linux-yocto' kernel and provides it's own custom support.. We don't support that with our standard product offerings.  (others might)19:44
frayIn those cases, it usually requires a custom agreement19:44
*** falk0n <falk0n!~falk0n@a79-168-122-55.cpe.netcabo.pt> has quit IRC19:46
sveinseMy picture of a YP provider, is someone who maintains all middle-ware layers, excluding kernel (and BSP related packages) and customer applications. So essentially the distro in an extended sense19:46
frayYa, the kernel is usually included as many defects are related to kernel bugs.. (specifically crashes and various device interactions)19:48
zarzar1what is the "workspace" directory for? can i remove its contents?19:49
frayThe alternative (for our customers) is that they must reproduce there bugs on a default kernel (often QEMU) and then we will work to resolve them..19:49
fraythat meets the needs of many folks, and avoids additional cost for 'custom' support19:49
fray(I don't know how my competitors work with this, but I'm sure they have different support requirements and models then the company I work for)19:50
fray(that is part of what makes the YP commercial ecosystem really good.  It allows different companies to work together, as well as compete..)19:50
sveinseThe output is a image that can be used for anything, right. Not images purpose built for a single-use (customer) application?19:55
frayit's the regular Yocto Project build environment, etc...19:55
frayso you can build 'anything' (within reason).. SDKs, images, kernels, etc..19:56
*** joshuagl <joshuagl!joshuagl@nat/intel/x-clyevpotllpbqooj> has quit IRC19:56
*** bemo <bemo!68840555@gateway/web/freenode/ip.> has quit IRC19:59
rburtonzarzar1: its where devtool unpacks stuff20:00
*** dave0x6d <dave0x6d!uid190567@gateway/web/irccloud.com/x-vfbeetvkojbxjfox> has joined #yocto20:00
*** lazyape <lazyape!~lazyape@athedsl-244581.home.otenet.gr> has quit IRC20:03
*** harisokanovic <harisokanovic!~harisokan@> has quit IRC20:03
*** lazyape <lazyape!~lazyape@athedsl-244581.home.otenet.gr> has joined #yocto20:03
*** harisokanovic <harisokanovic!~harisokan@> has joined #yocto20:04
*** harisokanovic <harisokanovic!~harisokan@> has joined #yocto20:04
*** harisokanovic <harisokanovic!~harisokan@> has quit IRC20:06
*** bemo <bemo!68840555@gateway/web/freenode/ip.> has joined #yocto20:06
*** harisokanovic <harisokanovic!~harisokan@> has joined #yocto20:06
*** bemo <bemo!68840555@gateway/web/freenode/ip.> has quit IRC20:08
*** luc4 <luc4!~luc4@93-46-89-64.ip106.fastwebnet.it> has joined #yocto20:08
*** t0mmy <t0mmy!~tprrt@fs-93-93-41-87.fullsave.info> has quit IRC20:11
*** bemo <bemo!68840555@gateway/web/freenode/ip.> has joined #yocto20:12
*** curie <curie!~curie@cpe-70-113-31-17.austin.res.rr.com> has joined #yocto20:25
*** stephano <stephano!~stephano@> has quit IRC20:26
zarzar1oh ok20:26
*** Snert <Snert!~LoginName@106-24-237-24.gci.net> has quit IRC20:26
zarzar1rburton: i thought so, i removed it to clean up but bitbake complained20:26
*** VoxPenguin <VoxPenguin!~VoxPengui@www.wanderingwalrus.com> has joined #yocto20:29
*** learningc <learningc!~User@> has quit IRC20:30
*** learningc <learningc!~User@> has joined #yocto20:31
*** xthundermobilex <xthundermobilex!~androirc@> has quit IRC20:35
*** sjolley <sjolley!~sjolley@> has quit IRC20:38
*** majuk <majuk!~majuk@> has joined #yocto20:38
*** Snert <Snert!~LoginName@106-24-237-24.gci.net> has joined #yocto20:42
*** marka <marka!~masselst@> has quit IRC20:47
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto20:57
*** sjolley <sjolley!~sjolley@> has joined #yocto21:09
*** gtristan <gtristan!~tristanva@> has quit IRC21:10
*** lazyape <lazyape!~lazyape@athedsl-244581.home.otenet.gr> has quit IRC21:16
*** lazyape <lazyape!~lazyape@athedsl-244581.home.otenet.gr> has joined #yocto21:16
*** clement <clement!~clement@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC21:21
*** zarzar1 <zarzar1!~zarzar@216-136-13-242.static.twtelecom.net> has quit IRC21:26
*** clement <clement!~clement@static-css-ccs-204145.business.bouyguestelecom.com> has joined #yocto21:32
*** curie <curie!~curie@cpe-70-113-31-17.austin.res.rr.com> has quit IRC21:42
*** armpit <armpit!~armpit@> has quit IRC21:47
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC21:47
-YoctoAutoBuilder- build #716 of nightly-x86-lsb is complete: Success [build successful] Build details are at https://autobuilder.yocto.io/builders/nightly-x86-lsb/builds/71621:51
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto21:52
*** pohly <pohly!~pohly@p54BD5DCA.dip0.t-ipconnect.de> has quit IRC22:05
*** stephano <stephano!~stephano@> has joined #yocto22:12
*** stephano <stephano!~stephano@> has quit IRC22:13
*** bodangly <bodangly!~bodangly@c-24-218-194-93.hsd1.ct.comcast.net> has quit IRC22:16
*** Chris__ <Chris__!189fd2fe@gateway/web/freenode/ip.> has joined #yocto22:30
*** JaMa <JaMa!~martin@> has quit IRC22:32
Chris__Any thoughts on whether this commit is appropriate for a stable release like rocko? https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=rocko&id=aa5127d27933a2662ebaa054e35fb1f5262804bb22:32
Chris__A project I was working on was dependent on the previous behavior of the --label parameter with rawcopy sources so the commit broke it22:34
*** Chris__ <Chris__!189fd2fe@gateway/web/freenode/ip.> has quit IRC22:48
sveinseWhat's a good generic MACHINE for yocto? qmeux86? or are there native intel machines which is well suited? Preferrably out of box22:49
*** Chris__ <Chris__!189fd2fe@gateway/web/freenode/ip.> has joined #yocto22:51
paulgMACHINE ?= "genericx86-64"22:51
paulgdon't let the name confuse you.  ;-)22:51
rburtoni'd suggest qemux86-6422:51
rburtonthe qemu machines have the advantage of a well defined target, the genericx86 ones are a bit vague22:52
rburtonalso everyone has the qemu machine, only people with meta-yocto-bsp have genericx8622:52
rburtontldr: the genericx86* machines are lame, and i can say that as i wrote them22:52
paulgyah, that latter point is probably the key.22:53
sveinselol. thanks rburton22:53
rburtonsveinse: really depends what you mean by good and generic22:53
rburtonfor build testing? the qemu machines are great.22:54
rburtongenericx86*'s goal is "at least boot on most x86 hardware"22:54
* paulg prefers using a crappy piece of bush era e-waste over using qemu.22:55
sveinserburton: yeah, was a vague question. For build testing. For testing build artefacts. Not so much for running actually.22:55
paulgand no, I can't justify that.22:55
rburtonpaulg: i've discovered that systemd-nspawn will boot a intel-corei7-64 .wic image in about two seconds22:55
sveinseOr, perhaps my little gobject showdown should convince me to have a vanilla system running22:55
rburtonsveinse: definitely the qemu machines.  trivial to test, solid base.22:56
rburtonsveinse: oh i posted "python-pygobject: skip the package if gobject-introspection is disabled" earlier :)22:56
rburtonpaulg: nspawn can read efi partition tables so does the right thing with a wic image, it's great22:57
rburtonuserspace only, obviously, but good enough for "does python work"22:57
sveinserburton: yea, I see that. I wasn't sure if pygobject had any other functions when gobject-introspect-data isn't installed22:58
paulgthe beauty of 2008 vintage e-waste is that I need not concern myself with uEFI boot.  :)22:58
rburtonsveinse: preeeety sure its useless.  you had it breaking with gobject, which is the lowest part of it22:58
rburtoncan't do the test in gobject-introspection, as that is needed to build stuff, even if g-i is then disabled22:59
sveinseI'm not overy comforted that gobject-introspection-data requires a functional qemu to be able to generate the proper artefacts and that's why you can take it away23:00
-YoctoAutoBuilder- build #178 of nightly-musl-x86-64 is complete: Success [build successful] Build details are at https://autobuilder.yocto.io/builders/nightly-musl-x86-64/builds/17823:00
*** dreyna <dreyna!~dreyna@> has quit IRC23:00
*** Chris__ <Chris__!189fd2fe@gateway/web/freenode/ip.> has quit IRC23:02
*** bodangly <bodangly!~bodangly@c-24-218-194-93.hsd1.ct.comcast.net> has joined #yocto23:05
*** bodangly_ <bodangly_!~bodangly@c-24-218-194-93.hsd1.ct.comcast.net> has joined #yocto23:08
*** bodangly <bodangly!~bodangly@c-24-218-194-93.hsd1.ct.comcast.net> has quit IRC23:10
*** bodangly_ <bodangly_!~bodangly@c-24-218-194-93.hsd1.ct.comcast.net> has quit IRC23:22
*** luc4 <luc4!~luc4@93-46-89-64.ip106.fastwebnet.it> has quit IRC23:23
sveinsedoes it exist any (good?) opengl libs for qmeu in yocto?23:27
*** lamego <lamego!lamego@nat/intel/x-yitlzizzfpzuicoz> has quit IRC23:27
*** armpit <armpit!~armpit@2601:202:4000:1184:242f:c14a:feac:fa0c> has joined #yocto23:35
*** agust <agust!~agust@p4FCB4189.dip0.t-ipconnect.de> has quit IRC23:36
rburtonsveinse: g-i *needs* to run code at build time.  iirc it was only some mips that didn't work23:41
*** ctwr <ctwr!~catalin@> has quit IRC23:42
rburtonsveinse: as to gl in qemu23:43
rburtonmesa can go software rendering, which is lame but sort of works23:44
rburtonturn on llvmpipe and youll get better rendering, been meaning to do this for ages. the packageconfig exists, just needs to be turned on.23:44
rburtonif you actually want good performance then ask jama for his experiments with using the virtio patches to use the host GPU23:45
rburton(but thats more work)23:45
rburtonllvmpipe should be the best bang-per-buck23:45
rburtonespecially if you run qemux86-64 with kvm enabled23:45
sveinserburton: that all requires x, right?23:48
rburtonshouldn't do23:48
*** rburton <rburton!~textual@home.burtonini.com> has quit IRC23:49
sveinseCould be interesting to see if our Qt eglfs app would run on qemu. Of course llvmpipe is fast but if it works then I got what I need23:49
*** stephano <stephano!~stephano@> has joined #yocto23:50
*** toanju <toanju!~toanju@x55b420f5.dyn.telefonica.de> has quit IRC23:51

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