| *** kaspter <kaspter!~Instantbi@115.216.26.110> has quit IRC | 00:02 | |
| *** kaspter <kaspter!~Instantbi@115.216.26.110> has joined #yocto | 00:03 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 00:13 | |
| *** bodangly <bodangly!~bodangly@2601:18a:c780:27a0:a4b8:dfad:f2dd:40f1> has joined #yocto | 00:16 | |
| *** rcwoolley <rcwoolley!~rcwoolley@45.72.233.195> has quit IRC | 00:25 | |
| *** learningc <learningc!~User@175.141.43.42> has quit IRC | 00:26 | |
| *** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC | 00:36 | |
| *** mr_science_ <mr_science_!~sarnold@cpe-45-37-179-170.nc.res.rr.com> has quit IRC | 00:36 | |
| *** lamego <lamego!~lamego@192.55.54.38> has quit IRC | 00:41 | |
| *** learningc <learningc!~User@mti-37-145.tm.net.my> has joined #yocto | 00:51 | |
| *** kaspter <kaspter!~Instantbi@115.216.26.110> has quit IRC | 01:29 | |
| *** kaspter <kaspter!~Instantbi@115.216.26.110> has joined #yocto | 01:31 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 01:39 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 01:49 | |
| *** batman_ <batman_!95c73efe@gateway/web/freenode/ip.149.199.62.254> has quit IRC | 01:50 | |
| *** scottrif <scottrif!~scottrif@47.39.44.219> has quit IRC | 01:54 | |
| -YoctoAutoBuilder- build #721 of nightly-musl is complete: Failure [failed BuildImages] Build details are at https://autobuilder.yocto.io/builders/nightly-musl/builds/721 | 01:58 | |
| *** Snert <Snert!~LoginName@106-24-237-24.gci.net> has quit IRC | 02:01 | |
| *** Snert <Snert!~LoginName@106-24-237-24.gci.net> has joined #yocto | 02:03 | |
| *** nighty- <nighty-!~nighty@s229123.ppp.asahi-net.or.jp> has quit IRC | 02:04 | |
| *** nighty- <nighty-!~nighty@s229123.ppp.asahi-net.or.jp> has joined #yocto | 02: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/715 | 02:06 | |
| *** nighty-- <nighty--!~nighty@kyotolabs.asahinet.com> has joined #yocto | 02: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/696 | 02:13 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 02:40 | |
| *** sgw <sgw!~swold@192.55.54.45> has quit IRC | 02:47 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 03:18 | |
| *** learningc <learningc!~User@mti-37-145.tm.net.my> has quit IRC | 03:30 | |
| *** learningc <learningc!~User@mti-37-145.tm.net.my> has joined #yocto | 03:31 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 03:49 | |
| *** hamis <hamis!~irfan@110.93.212.98> has joined #yocto | 03:59 | |
| *** dv_ <dv_!~dv@62-178-118-86.cable.dynamic.surfer.at> has quit IRC | 04: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/177 | 04: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/692 | 04: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/707 | 04:16 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 04:19 | |
| *** dv_ <dv_!~dv@62-178-118-86.cable.dynamic.surfer.at> has joined #yocto | 04:25 | |
| *** bananadev <bananadev!~onlyester@118.70.128.150> has joined #yocto | 04:41 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 04:45 | |
| *** kaspter <kaspter!~Instantbi@115.216.26.110> has quit IRC | 05:03 | |
| *** kaspter <kaspter!~Instantbi@115.216.26.110> has joined #yocto | 05:04 | |
| *** TheSeven <TheSeven!~quassel@rockbox/developer/TheSeven> has quit IRC | 05:07 | |
| *** fjay <fjay!~jay@icryed.org> has quit IRC | 05:10 | |
| *** bananadev <bananadev!~onlyester@118.70.128.150> has quit IRC | 05:24 | |
| *** bananadev <bananadev!~onlyester@118.70.128.150> has joined #yocto | 05:27 | |
| *** agust <agust!~agust@p4FCB4189.dip0.t-ipconnect.de> has joined #yocto | 05:30 | |
| *** sgw <sgw!~swold@c-73-180-42-186.hsd1.or.comcast.net> has joined #yocto | 05:36 | |
| *** TheSeven <TheSeven!~quassel@rockbox/developer/TheSeven> has joined #yocto | 05:41 | |
| *** gtristan <gtristan!~tristanva@110.11.179.89> has quit IRC | 05: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/708 | 05:45 | |
| *** mbourhis <mbourhis!~mbourhis@glo44-1-82-67-130-147.fbx.proxad.net> has quit IRC | 05:46 | |
| *** clement <clement!~clement@lns-bzn-39-82-255-32-23.adsl.proxad.net> has quit IRC | 05:46 | |
| *** TheSeven <TheSeven!~quassel@rockbox/developer/TheSeven> has quit IRC | 05:46 | |
| *** clement <clement!~clement@static-css-ccs-204145.business.bouyguestelecom.com> has joined #yocto | 05:47 | |
| *** mbourhis <mbourhis!~mbourhis@glo44-1-82-67-130-147.fbx.proxad.net> has joined #yocto | 05:47 | |
| *** sgw <sgw!~swold@c-73-180-42-186.hsd1.or.comcast.net> has quit IRC | 05:48 | |
| *** sgw <sgw!~swold@134.134.139.75> has joined #yocto | 05:50 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-eronghvsqthsjhdr> has quit IRC | 05:55 | |
| *** gtristan <gtristan!~tristanva@175.193.206.20> has joined #yocto | 06:09 | |
| *** t0mmy <t0mmy!~tprrt@ram31-1-82-234-79-177.fbx.proxad.net> has quit IRC | 06:19 | |
| *** TheSeven <TheSeven!~quassel@rockbox/developer/TheSeven> has joined #yocto | 06:38 | |
| *** TheSeven <TheSeven!~quassel@rockbox/developer/TheSeven> has quit IRC | 06: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/755 | 06:44 | |
| *** chinhuat <chinhuat!c0c693a5@gateway/web/freenode/ip.192.198.147.165> has joined #yocto | 06:56 | |
| *** hamis <hamis!~irfan@110.93.212.98> has quit IRC | 06:59 | |
| *** hamis <hamis!~irfan@110.93.212.98> has joined #yocto | 07:03 | |
| *** pohly <pohly!~pohly@p54BD5DCA.dip0.t-ipconnect.de> has joined #yocto | 07:03 | |
| *** open-nandra <open-nandra!~marek@81.89.61.168.host.vnet.sk> has joined #yocto | 07:07 | |
| *** TheSeven <TheSeven!~quassel@rockbox/developer/TheSeven> has joined #yocto | 07:08 | |
| *** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto | 07:10 | |
| -YoctoAutoBuilder- build #693 of nightly-world is complete: Failure [failed BuildImages] Build details are at https://autobuilder.yocto.io/builders/nightly-world/builds/693 | 07: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/716 | 07:34 | |
| *** hamis <hamis!~irfan@110.93.212.98> has quit IRC | 07:36 | |
| -YoctoAutoBuilder- build #782 of nightly is complete: Failure [failed] Build details are at https://autobuilder.yocto.io/builders/nightly/builds/782 | 07:36 | |
| *** hamis <hamis!~irfan@110.93.212.98> has joined #yocto | 07:37 | |
| *** t0mmy <t0mmy!~tprrt@217.114.201.133> has joined #yocto | 07:40 | |
| *** Kakounet <Kakounet!~Thunderbi@LFbn-1-11962-248.w90-93.abo.wanadoo.fr> has joined #yocto | 07:42 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 07:42 | |
| *** sagner <sagner!~ags@2001:1620:c6e::127> has quit IRC | 07:44 | |
| *** hamis <hamis!~irfan@110.93.212.98> has quit IRC | 07:47 | |
| *** hamis <hamis!~irfan@110.93.212.98> has joined #yocto | 07:48 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 07:55 | |
| *** hamis <hamis!~irfan@110.93.212.98> has quit IRC | 08:00 | |
| *** maxin <maxin!maxin@nat/intel/x-qcrkrlcdvzvcolje> has joined #yocto | 08:00 | |
| *** hamis <hamis!~irfan@110.93.212.98> has joined #yocto | 08:04 | |
| *** ctwr <ctwr!~catalin@89.121.200.102> has quit IRC | 08:07 | |
| *** hamis <hamis!~irfan@110.93.212.98> has quit IRC | 08:12 | |
| *** grma <grma!~gruberm@80.93.38.128> has joined #yocto | 08:13 | |
| *** hamis <hamis!~irfan@110.93.212.98> has joined #yocto | 08:13 | |
| *** fl0v0 <fl0v0!~fvo@i5E86303A.versanet.de> has joined #yocto | 08:13 | |
| *** ctwr <ctwr!~catalin@89.121.200.102> has joined #yocto | 08:18 | |
| *** JaMa <JaMa!~martin@217.30.68.212> has joined #yocto | 08:18 | |
| *** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC | 08:19 | |
| *** mdnneo <mdnneo!~umaucher@217.89.178.116> has joined #yocto | 08:20 | |
| *** hnje <hnje!~hnje@81.216.59.226> has joined #yocto | 08:22 | |
| *** sagner <sagner!~ags@46.140.72.82> has joined #yocto | 08:23 | |
| *** Snert <Snert!~LoginName@106-24-237-24.gci.net> has quit IRC | 08:27 | |
| *** Snert <Snert!~LoginName@106-24-237-24.gci.net> has joined #yocto | 08:30 | |
| *** hamis <hamis!~irfan@110.93.212.98> has quit IRC | 08:32 | |
| *** hamis <hamis!~irfan@110.93.212.98> has joined #yocto | 08:32 | |
| *** vdehors <vdehors!~vdehors@91-162-62-2.subs.proxad.net> has joined #yocto | 08:37 | |
| *** hnje <hnje!~hnje@81.216.59.226> has quit IRC | 08:40 | |
| *** hnje <hnje!~hnje@193.106.123.182> has joined #yocto | 08:42 | |
| *** ed21 <ed21!~Adium@192.198.151.44> has joined #yocto | 08:46 | |
| *** hamis <hamis!~irfan@110.93.212.98> has quit IRC | 08:49 | |
| *** joshuagl <joshuagl!joshuagl@nat/intel/x-clyevpotllpbqooj> has joined #yocto | 08:56 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 08:57 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 08:57 | |
| *** hamis <hamis!~irfan@110.93.212.98> has joined #yocto | 08:57 | |
| aurele | hi everyone | 08:58 |
|---|---|---|
| xthunderheartx | good morning | 08:58 |
| aurele | I'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 |
| aurele | should I call the bootstrap.sh in a do_configure_append? or just override aclocal (how can I do that?) | 09:01 |
| xthunderheartx | aurele: It may be a little early for the folks who could answer with authority | 09:03 |
| aurele | xthunderheartx, I will try some things, and maybe come back later ;) | 09:04 |
| xthunderheartx | At least US folks anyway. It will liven up in a few hours | 09:05 |
| xthunderheartx | As an asterisk fan from *way back* I wish you luck ... you'll need it. | 09:06 |
| xthunderheartx | Or awesome skillz ... those will do as well :) | 09:07 |
| *** chinhuat <chinhuat!c0c693a5@gateway/web/freenode/ip.192.198.147.165> has quit IRC | 09:09 | |
| LetoThe2nd | aurele: 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 |
| LetoThe2nd | aurele: or prepending it. | 09:13 |
| *** cisasystems <cisasystems!547c4608@gateway/web/freenode/ip.84.124.70.8> has joined #yocto | 09:13 | |
| cisasystems | Hello everybody!! | 09:13 |
| *** ranran <ranran!59ed719b@gateway/web/freenode/ip.89.237.113.155> has joined #yocto | 09:16 | |
| ranran | what is the purpose of sysroot ? | 09:16 |
| ranran | Is it for kernel headers ? | 09:16 |
| xthunderheartx | https://stackoverflow.com/questions/39920712/what-is-a-sysroot-exactly-and-how-do-i-create-one | 09:17 |
| *** mckoan|away is now known as mckoan | 09:17 | |
| LetoThe2nd | ranran: 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 |
| ranran | Is it that a package which depends on another one for the build, find the other package (header/library) in sysroot ? | 09:22 |
| ranran | I mean, does the sysroot also used during build of packages to resolve dependency ? | 09:22 |
| LetoThe2nd | ranran: basically, yes. but what is it that you are *ACTUALLY* trying to do? | 09:23 |
| cisasystems | How can I set the owner of the config files ? | 09:24 |
| ranran | LetoThe2nd, I just try to have better understanding of sysroot. Is sysroot used for the build process or only for the sdk package ? | 09:24 |
| LetoThe2nd | ranran: it is especially used in the build process. | 09:24 |
| LetoThe2nd | cisasystems: meaning... what? | 09:25 |
| LetoThe2nd | ranran: https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html | 09:25 |
| ranran | Thank you. | 09:26 |
| *** toanju <toanju!~toanju@185.27.182.30> has joined #yocto | 09:28 | |
| *** ranran <ranran!59ed719b@gateway/web/freenode/ip.89.237.113.155> has quit IRC | 09:32 | |
| *** skz81 <skz81!~SKZ@80.169.81.126> has joined #yocto | 09:33 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-gihdzyyidjlteikx> has joined #yocto | 09:59 | |
| *** lazyape <lazyape!~lazyape@athedsl-244581.home.otenet.gr> has joined #yocto | 10:03 | |
| *** alinucs <alinucs!~abo@bgn92-1-82-67-207-244.fbx.proxad.net> has quit IRC | 10:16 | |
| lukma | Good morning, | 10:25 |
| lukma | I do have a question regarding devtool | 10:25 |
| lukma | is it possible to have verbose output of devtool build <recipe> ? | 10:25 |
| lukma | something like bitbake -v <recipe> | 10:26 |
| lukma | I do find devtool as a good developer's tool, but I would like to see the detailed output of compilation - including errors and warnings | 10:26 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 10:36 | |
| *** ipuustin <ipuustin!~ipuustin@dyn9kkyrcj-m---xk12qy-3.rev.dnainternet.fi> has joined #yocto | 10:46 | |
| *** learningc <learningc!~User@mti-37-145.tm.net.my> has quit IRC | 10:56 | |
| *** rburton <rburton!~textual@home.burtonini.com> has joined #yocto | 10:57 | |
| *** rburton <rburton!~textual@home.burtonini.com> has quit IRC | 10:59 | |
| *** rburton <rburton!~textual@home.burtonini.com> has joined #yocto | 11:00 | |
| *** alinucs <alinucs!~abo@bgn92-1-82-67-207-244.fbx.proxad.net> has joined #yocto | 11:01 | |
| ttllkk | lukma: maybe bitbake package -DDD ? | 11:03 |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 11:12 | |
| *** acrap <acrap!~andrey@host-85-237-33-147.dsl.sura.ru> has joined #yocto | 11:17 | |
| acrap | hi, guys! | 11:17 |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 11:32 | |
| *** nighty-- <nighty--!~nighty@kyotolabs.asahinet.com> has quit IRC | 11:32 | |
| *** sjolley <sjolley!~sjolley@192.55.54.44> has quit IRC | 11:32 | |
| *** sjolley <sjolley!~sjolley@134.134.139.72> has joined #yocto | 11:33 | |
| aurele | hi again I have updated my layers and I have the folowing issue : https://pastebin.com/rBnFCYh8 | 11: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 #yocto | 11:44 | |
| aurele | sorry for bothering everyone but a simple cleanall did the trick | 11:58 |
| rburton | cleanall isn't simple, just clean would have worked | 12:05 |
| *** RP <RP!~richard@5751f4a1.skybroadband.com> has quit IRC | 12:09 | |
| *** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto | 12:13 | |
| aurele | rburton, 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 directly | 12:14 |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 12:15 | |
| *** ed21 <ed21!~Adium@192.198.151.44> has quit IRC | 12:24 | |
| *** ed21 <ed21!~Adium@192.198.151.44> has joined #yocto | 12:24 | |
| rburton | aurele: cleanall will delete the working tree (same as clean), and all sstate objects (same as cleansstate), and all tarballs downloaded | 12:25 |
| rburton | unless you want to remove objects from sstate, clean is sufficient | 12:25 |
| *** cisasystems <cisasystems!547c4608@gateway/web/freenode/ip.84.124.70.8> has quit IRC | 12:28 | |
| *** bananadev <bananadev!~onlyester@118.70.128.150> has quit IRC | 12:33 | |
| *** learningc <learningc!~User@175.141.43.42> has joined #yocto | 12:42 | |
| *** learningc <learningc!~User@175.141.43.42> has quit IRC | 12:44 | |
| *** learningc <learningc!~User@175.141.43.42> has joined #yocto | 12:44 | |
| *** kaspter <kaspter!~Instantbi@115.216.26.110> has quit IRC | 12:44 | |
| *** learningc <learningc!~User@175.141.43.42> has quit IRC | 12:45 | |
| *** learningc <learningc!~User@175.141.43.42> has joined #yocto | 12:45 | |
| *** learningc <learningc!~User@175.141.43.42> has quit IRC | 12:47 | |
| *** learningc <learningc!~User@175.141.43.42> has joined #yocto | 12:47 | |
| *** hamis <hamis!~irfan@110.93.212.98> has quit IRC | 13:02 | |
| *** marka <marka!~masselst@128.224.252.2> has joined #yocto | 13:20 | |
| rburton | anyone who uses cmake, i've just sent a RFC to the oe-core list | 13:26 |
| *** kanavin <kanavin!ak@nat/intel/x-pgniaimzpcokeuwo> has quit IRC | 13:27 | |
| *** kanavin <kanavin!~ak@192.198.151.37> has joined #yocto | 13:27 | |
| *** xthundermobilex <xthundermobilex!~androirc@184.75.233.58> has joined #yocto | 13:45 | |
| *** stephano <stephano!~stephano@134.134.139.76> has joined #yocto | 13:48 | |
| *** gtristan <gtristan!~tristanva@175.193.206.20> has quit IRC | 13:53 | |
| sveinse | ANyone 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 start | 13:53 |
| sveinse | (and gobject / glib is apparently not the easiest beast) | 13:54 |
| rburton | sveinse: sounds like something we need to add to sanity testing... | 13:55 |
| rburton | pastebin the error? | 13:55 |
| xthunderworkx | rburton | 13:55 |
| xthunderworkx | Geez ... connect fingers to brain | 13:56 |
| xthunderworkx | rburton: So I have a working recipe for dbus-cxx and I be happy to submit it. | 13:56 |
| xthunderworkx | One 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 |
| xthunderworkx | The library version information seems to never change though the package version *has* been diligently updated. | 13:59 |
| rburton | i'd just report a bug upstream to tell them to library version | 13:59 |
| rburton | you can't do anything | 13:59 |
| xthunderworkx | Yeah, 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 |
| xthunderworkx | Not sure it is getting much attention | 14:00 |
| rburton | fork it! :) | 14:00 |
| xthunderworkx | I thought about that ... | 14:01 |
| joshuagl | I 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 |
| sveinse | rburton, I will paste the error and what I've investigated. Hold on | 14:03 |
| zarzar1 | rburton: i added sanity.conf | 14:03 |
| xthunderworkx | Well, 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 |
| rburton | indeed, dbus is good. its a shame dbus-cxx is unmaintained | 14:05 |
| xthunderworkx | Well 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 IRC | 14:06 | |
| rburton | a 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 start | 14:09 |
| rburton | then learn library versioning and do that | 14:09 |
| sveinse | dbus might be good, but alas I've been having my troubles with the event loops glib or gobject | 14:10 |
| xthunderworkx | Yep, 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 |
| rburton | pick a layer (meta-oe sounds right), then submit a patch to the relevant list (openembedded-devel@lists.openembedded.org) | 14:11 |
| xthunderworkx | I did smoke over library versioning lastnight and I think I have a grasp of the idea. | 14:11 |
| xthunderworkx | Ross you are the Yocto dbus guy (maintainer) right? | 14:13 |
| xthunderworkx | So you would likely review it? | 14:13 |
| rburton | i certainly hope not | 14:13 |
| rburton | i might glance at the odd patch for meta-oe but i don't review them all | 14:14 |
| xthunderworkx | LOL! "Sato/GTK/Dbus - Ross Burton" ... not you? | 14:14 |
| rburton | damnit where does it say that | 14:14 |
| xthunderworkx | Come on now! | 14:14 |
| rburton | RECIPE_MAINTAINER_pn-dbus = "Chen Qi <Qi.Chen@windriver.com>" | 14:14 |
| rburton | not me! :) | 14:14 |
| xthunderworkx | Coffee just spewed out of my nose ... | 14:15 |
| *** gtristan <gtristan!~tristanva@110.11.179.89> has joined #yocto | 14:15 | |
| rburton | if thats from the web site then we know its out of date and there's a replacement on the way | 14:15 |
| xthunderworkx | https://www.yoctoproject.org/about/governance/technical-leadership | 14:15 |
| xthunderworkx | That's the top response to google "rburton yocto" | 14:16 |
| xthunderworkx | Just assumed it was you. | 14:17 |
| *** aratiu1 <aratiu1!~adi@80.97.64.55> has joined #yocto | 14:20 | |
| *** aratiu <aratiu!~adi@80.97.64.55> has quit IRC | 14:20 | |
| sveinse | rburton: https://bpaste.net/show/be2b530702cc. Works on pyro, fails on rocko. | 14:21 |
| sveinse | I 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 dependency | 14:23 |
| rburton | sveinse: presumably you're adding your own python-gobject? | 14:23 |
| sveinse | rburton: no. why? | 14:25 |
| rburton | ah, there's a recipe in meta-oe still | 14:26 |
| rburton | presumably you're using that then | 14:26 |
| sveinse | It's supposed to listen on dbus events from udisks | 14:26 |
| rburton | sveinse: easy test: have you tried with py3? | 14:26 |
| rburton | what with us doing everything we can to delete py2 from oe-core knowing if it works in py3 would be useful | 14:27 |
| *** toanju <toanju!~toanju@185.27.182.30> has quit IRC | 14:27 | |
| sveinse | rburton: 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 |
| rburton | so... is the introspection typelib present? :) | 14:28 |
| sveinse | rburton: I honestly don't know what I'm looking for | 14:29 |
| rburton | i guess gobject is a special one | 14:29 |
| *** sgw <sgw!~swold@134.134.139.75> has quit IRC | 14:29 | |
| sveinse | As 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 py3 | 14:30 |
| rburton | building stuff here now | 14:34 |
| rburton | need to add a test case for this to ensure it doesn't regress | 14:34 |
| sveinse | I'm fine-reading the manifest-diff now | 14:35 |
| rburton | most likely a proper bug and not a manifest issue | 14:36 |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 14:37 | |
| *** stephano <stephano!~stephano@134.134.139.76> has quit IRC | 14:38 | |
| *** aratiu1 <aratiu1!~adi@80.97.64.55> has quit IRC | 14:40 | |
| sveinse | meanwhile, I should perhaps see after other approaches for dbus access from python | 14:40 |
| *** aratiu <aratiu!~adi@80.97.64.55> has joined #yocto | 14:41 | |
| rburton | sveinse: >>> GObject.glib_version | 14:48 |
| rburton | (2, 54, 2) | 14:48 |
| rburton | works for me | 14:48 |
| sveinse | rburton: right. tested on what machine? | 14:49 |
| rburton | x86-64 | 14:49 |
| sveinse | I need to get a qemu environment up so I can test too. I must read the docs how one does that | 14:51 |
| rburton | set MACHINE=qemuwhatever when doing a build, then use runqemu | 14:52 |
| yocti | New 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@193.106.123.182> has quit IRC | 14:57 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 15:03 | |
| *** ntl <ntl!~nathanl@65-36-80-8.dyn.grandenetworks.net> has joined #yocto | 15:05 | |
| *** lamego <lamego!lamego@nat/intel/x-yitlzizzfpzuicoz> has joined #yocto | 15:06 | |
| zarzar1 | i 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 in | 15:06 |
| zarzar1 | is there an image that would pull in uboot file? | 15:07 |
| rburton | zarzar1: that image will, assuming you picked a machine which uses uboot | 15:13 |
| *** dave0x6d <dave0x6d!uid190567@gateway/web/irccloud.com/x-vefedeutfrqowsxv> has quit IRC | 15:13 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 15:14 | |
| zarzar1 | rburton: hmmm, seems like very few source files were pulled in, not sure what the deal is | 15:14 |
| rburton | where are you looking? | 15:14 |
| zarzar1 | rburton: https://pastebin.com/ZmP0z69B | 15:15 |
| rburton | thats not where downloads go | 15:15 |
| rburton | also downloads are tarballs, not unpacked | 15:15 |
| zarzar1 | oh ok | 15:15 |
| rburton | look in whatever you've set DL_DIR to | 15:15 |
| zarzar1 | dang, i didn't set DL_DIR | 15:16 |
| rburton | theres a default value | 15:17 |
| *** falk0n <falk0n!~falk0n@a79-168-122-55.cpe.netcabo.pt> has quit IRC | 15:17 | |
| *** falk0n <falk0n!~falk0n@a79-168-122-55.cpe.netcabo.pt> has joined #yocto | 15:19 | |
| zarzar1 | ok | 15:19 |
| zarzar1 | rburton: so that's not good, tarballs of code, I mainly pulled code in order to use find and grep on the source files for uboot | 15:22 |
| *** open-nandra <open-nandra!~marek@81.89.61.168.host.vnet.sk> has quit IRC | 15:22 | |
| *** stephano <stephano!~stephano@134.134.139.82> has joined #yocto | 15:22 | |
| sveinse | bitbake -c unpack u-boot ? | 15:23 |
| sveinse | Probably need some building to get there | 15:23 |
| zarzar1 | can i run unack on an image? like i did with fetchall | 15:24 |
| zarzar1 | building takes up too much disk space, trying to avoid a full build but just want to look at sources | 15:25 |
| zarzar1 | could i run a build then delete tmp folder without losing sources? | 15:25 |
| sveinse | not sure when bitbake populates the recipe's DEPENDS when building, so I'm not sure if do_unpack is run prior to this | 15:26 |
| sveinse | But are you using a shared sstate cache? | 15:27 |
| zarzar1 | no sahred sstate cache that i know of | 15:28 |
| sveinse | zarzar1: That will surely save you a ton and a half, both with respect to compile time and disk space | 15:29 |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 15:30 | |
| sveinse | Set 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 #yocto | 15:32 | |
| zarzar1 | devtool modify <recipename> ? | 15:40 |
| rburton | yeah that | 15:40 |
| zarzar1 | found that here: https://wiki.yoctoproject.org/wiki/TipsAndTricks/Patching_the_source_for_a_recipe | 15:40 |
| rburton | you said you wanted all sources, so were told how to do that (fetchall) | 15:40 |
| zarzar1 | rburton: true, i did not know they would be tar ablled | 15:41 |
| rburton | upstream sources are almost all either git repos or tarballs | 15:41 |
| zarzar1 | error: recipe is an image, and therefore is not supported by this tool | 15:41 |
| zarzar1 | dang | 15:41 |
| rburton | yeah you can't modify images as they don't have sources | 15:42 |
| rburton | you said uboot, so modify uboot | 15:42 |
| zarzar1 | oh ok | 15:42 |
| *** skz81 <skz81!~SKZ@80.169.81.126> has quit IRC | 15:42 | |
| *** skz81_ <skz81_!~SKZ@80.169.81.126> has joined #yocto | 15:42 | |
| zarzar1 | that worked | 15:42 |
| zarzar1 | is it possible to find all recipes in an image? | 15:44 |
| sveinse | zarzar1: an image generates a manifest, that is the list of all packages installed in it | 15:45 |
| zarzar1 | what's the diff between package and recipe? | 15:45 |
| zarzar1 | is it possible to find all recipes in an image? | 15:46 |
| rburton | a recipe generates packages | 15:46 |
| zarzar1 | for devtool modify i need recipes | 15:46 |
| rburton | a recipe (say, glib) will generate many packages (libglib, libglib-dev, libglib-doc, libglib-locale-*, etc) | 15:46 |
| zarzar1 | i don't think i need packages for devtool modify | 15:46 |
| rburton | correct, you tell it what recipe | 15:46 |
| rburton | recipes make packages, images are collections of packages | 15:47 |
| zarzar1 | so can i get the recipes use by an image or no? | 15:47 |
| rburton | bitbake imagename -g will write pn-buildlist, which lists all recipes it will be building to satisfy the requirements | 15:49 |
| *** jku <jku!~jku@dyj-skyylh9rf8bj5n84y-3.rev.dnainternet.fi> has joined #yocto | 15:50 | |
| zarzar1 | holy moly | 15:53 |
| zarzar1 | i'll just run a build and delete tmp after | 15:53 |
| zarzar1 | is there an email list for feature requests? | 15:57 |
| *** jku <jku!~jku@dyj-skyylh9rf8bj5n84y-3.rev.dnainternet.fi> has quit IRC | 15:58 | |
| *** xthundermobilex <xthundermobilex!~androirc@184.75.233.58> has quit IRC | 16:06 | |
| ttllkk | Where can I check the list of packages upgraded on a new yocto version | 16:07 |
| ttllkk | ? | 16:07 |
| *** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC | 16:10 | |
| *** ed21 <ed21!~Adium@192.198.151.44> has quit IRC | 16:14 | |
| *** ulf` <ulf`!ulf@nat/intel/x-talrourfsiiajtks> has joined #yocto | 16:15 | |
| *** stephano <stephano!~stephano@134.134.139.82> has quit IRC | 16:24 | |
| *** stephano <stephano!~stephano@134.134.139.82> has joined #yocto | 16:24 | |
| sveinse | rburton: 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 #yocto | 16:31 | |
| *** Nilesh_ <Nilesh_!uid116340@gateway/web/irccloud.com/x-hrkxlciwyxeaibgo> has joined #yocto | 16:36 | |
| *** t0mmy <t0mmy!~tprrt@217.114.201.133> has quit IRC | 16:36 | |
| *** mbourhis <mbourhis!~mbourhis@glo44-1-82-67-130-147.fbx.proxad.net> has quit IRC | 16:37 | |
| *** tripzero <tripzero!tripzero@nat/intel/x-xrkmoqwtatbtzejk> has joined #yocto | 16:37 | |
| kergoth | Hmm, 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 incremental | 16:39 |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 16:41 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 16:46 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 16:48 | |
| *** skz81_ <skz81_!~SKZ@80.169.81.126> has quit IRC | 16:49 | |
| *** vmeson <vmeson!~rmacleod@192-0-133-4.cpe.teksavvy.com> has quit IRC | 16:52 | |
| rburton | sveinse: haha | 16:54 |
| rburton | sveinse: 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 #yocto | 16:55 | |
| rburton | kergoth: patches welcome! personally, never heard of that flag before | 16:55 |
| *** paulg <paulg!~paulg@198-84-239-75.cpe.teksavvy.com> has joined #yocto | 16:58 | |
| *** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 16:59 | |
| *** armpit <armpit!~armpit@2601:202:4000:1184:94e2:24fc:6a2d:d1a9> has quit IRC | 17:01 | |
| *** mdnneo <mdnneo!~umaucher@217.89.178.116> has quit IRC | 17:03 | |
| *** bavery_fn1 <bavery_fn1!bavery@nat/intel/x-lcbomczbtzsilbty> has joined #yocto | 17:04 | |
| *** bavery_fn <bavery_fn!bavery@nat/intel/x-iwoitaxkaskqlcxq> has quit IRC | 17:05 | |
| *** bavery_fn1 <bavery_fn1!bavery@nat/intel/x-lcbomczbtzsilbty> has quit IRC | 17:08 | |
| *** mattsm <mattsm!~mattsm@75.13.95.234> has quit IRC | 17:12 | |
| *** mckoan is now known as mckoan|away | 17:15 | |
| *** fl0v0 <fl0v0!~fvo@i5E86303A.versanet.de> has quit IRC | 17:19 | |
| *** vdehors <vdehors!~vdehors@91-162-62-2.subs.proxad.net> has quit IRC | 17:23 | |
| *** stephano <stephano!~stephano@134.134.139.82> has quit IRC | 17:26 | |
| *** sjolley <sjolley!~sjolley@134.134.139.72> has quit IRC | 17:28 | |
| *** stephano <stephano!~stephano@134.134.139.82> has joined #yocto | 17:31 | |
| *** Kakounet <Kakounet!~Thunderbi@LFbn-1-11962-248.w90-93.abo.wanadoo.fr> has quit IRC | 17:31 | |
| *** RP1 <RP1!~richard@5751f4a1.skybroadband.com> has joined #yocto | 17:39 | |
| *** batman_ <batman_!95c73efe@gateway/web/freenode/ip.149.199.62.254> has joined #yocto | 17:42 | |
| *** RP1 is now known as RP | 17:44 | |
| *** sagner <sagner!~ags@46.140.72.82> has quit IRC | 17:46 | |
| kergoth | http://mesonbuild.com/Unity-builds.html the potential crash issue probably makes it not worth enabling globally, though | 17:46 |
| kergoth | s/crash/clash/ | 17:46 |
| *** scottrif <scottrif!~scottrif@47.39.44.219> has joined #yocto | 17: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 #yocto | 17:59 | |
| *** xthundermobilex <xthundermobilex!~androirc@184.75.233.58> has joined #yocto | 17:59 | |
| *** t0mmy <t0mmy!~tprrt@fs-93-93-41-87.fullsave.info> has joined #yocto | 17:59 | |
| batman_ | Let me rephrase the question: "Where can I check logs of even handlers?" | 18:03 |
| batman_ | *event handlers? | 18:03 |
| kergoth | event handlers most likely log to the bitbake console log only | 18:04 |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-ygdzxzyeuriifkcw> has joined #yocto | 18:05 | |
| *** stephano <stephano!~stephano@134.134.139.82> has quit IRC | 18:10 | |
| *** stephano <stephano!stephano@nat/intel/x-vyjdtgsmbofcrfca> has joined #yocto | 18:11 | |
| *** bavery_fn <bavery_fn!bavery@nat/intel/x-rnrtzatyuehqnkqb> has quit IRC | 18:13 | |
| sveinse | kergoth, rburton: Found this more informative: https://lists.yoctoproject.org/pipermail/yocto/2016-April/029579.html | 18:13 |
| kergoth | nice, that should probably go in the yocto docs somewhere if it isn't already | 18:13 |
| sveinse | Honestly 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 qemu | 18:14 |
| batman_ | kergoth: Thanks for clarifying that. | 18:15 |
| *** bodangly <bodangly!~bodangly@c-24-218-194-93.hsd1.ct.comcast.net> has joined #yocto | 18:15 | |
| sveinse | but that's clearly not the case. A little wiser today! | 18:15 |
| kergoth | afaik introspection is when it actually has to run the target binary to get info about the target binary, or something? | 18:15 |
| kergoth | possibly similar to help2man? | 18:15 |
| kergoth | no clue | 18:15 |
| kergoth | :) | 18:15 |
| kergoth | batman_: np | 18:15 |
| kergoth | batman_: so you should be able to find it in tmp/log/ | 18:15 |
| kergoth | might be worth improving event handler logging int he future, feel free to open an issue in bugzilla | 18:16 |
| kergoth | hmm | 18:16 |
| *** mattsm <mattsm!~mattsm@75.13.95.234> has joined #yocto | 18:18 | |
| *** sjolley <sjolley!~sjolley@134.134.139.73> has joined #yocto | 18:18 | |
| sveinse | I 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 nods | 18:19 | |
| *** stephano <stephano!stephano@nat/intel/x-vyjdtgsmbofcrfca> has quit IRC | 18:20 | |
| sveinse | But 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 clue | 18:21 |
| sveinse | rburton: Perhaps this should be discussed on the mail lists? | 18:21 |
| *** hmwel <hmwel!~hmw@zimbra.welvaarts.com> has quit IRC | 18:22 | |
| *** stephano <stephano!~stephano@134.134.139.82> has joined #yocto | 18:23 | |
| sveinse | Ahh, 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 |
| sveinse | Alas, 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 :D | 18:26 |
| *** hmwel <hmwel!~hmw@zimbra.welvaarts.com> has joined #yocto | 18:33 | |
| xthunderworkx | I need a way to make certain that the toolchain bitbake uses is a specific version. | 18:36 |
| *** clsulliv <clsulliv!~clsulliv@134.134.139.74> has quit IRC | 18:37 | |
| xthunderworkx | Basically because we need to build a FIPs 140-2 compliant image. | 18:37 |
| fray | The toolchain itself is not usually a requirement of FIPS 140-2.. | 18:37 |
| *** toanju <toanju!~toanju@x55b420f5.dyn.telefonica.de> has joined #yocto | 18:37 | |
| fray | it's the crypto itself that is the issue.. | 18:38 |
| xthunderworkx | And how the crypto is built | 18:38 |
| fray | Are you focusing on a particular cryptographic engine (or engines)? | 18:38 |
| fray | OpenSSL 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 |
| fray | The 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 |
| xthunderworkx | Right. So then bitbake could use the toolchain in there right? | 18:39 |
| fray | Use bitbake to construct an SDK.. | 18:40 |
| fray | use the SDK to build the openssl-fips module, following the guide.. | 18:40 |
| fray | tar up the resulting binaries, as well as the logs for external verification.. | 18:40 |
| fray | create a recipe that replaces the OpenSSL package with one that includes the BINARY openssl w/ fips module.. | 18:41 |
| fray | the 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 |
| xthunderworkx | Hmmmm ... that makes sense. | 18:41 |
| fray | The binaries become immutable to OE/YP.. | 18:41 |
| fray | since 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 #yocto | 18:42 | |
| xthunderworkx | So our hardware vendor (Digi) is responsible getting their OE attached to one of the existing OpenSSL certs | 18:42 |
| xthunderworkx | iMX6ul OE | 18:43 |
| fray | for the OpenSSL fips module certificate, you need a corresponding architecture, and compiler version (at a minimum).. | 18:43 |
| fray | there are ones that are in the list hat would be compatible with the i.mx6, but perhaps not as optimized.. | 18:43 |
| xthunderworkx | Yep but old kernels | 18:43 |
| fray | if 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 |
| fray | The kernel does not matter for OpenSSL-fips.. (at least last time I checked) | 18:44 |
| xthunderworkx | Yep, Digi is submitting to OpenSSL and paying the ransom | 18:44 |
| fray | yes, that is the right way to do this | 18:44 |
| *** Nilesh_ <Nilesh_!uid116340@gateway/web/irccloud.com/x-hrkxlciwyxeaibgo> has quit IRC | 18:45 | |
| xthunderworkx | There is an OE on the cert now ... but it is Dizzy/Daisy kernel rev. (3.14) which fell off LTS in Octobe. | 18:45 |
| xthunderworkx | The G don't like that. | 18:45 |
| xthunderworkx | So Digi will submit the Morty kernel etc. | 18:46 |
| fray | Certing against teh YP is going to continue that to happen.. as the YP only supports for roughly 1 year at a time.. | 18:46 |
| kergoth | it'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 |
| fray | you (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 |
| fray | There 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 |
| fray | that 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 |
| xthunderworkx | Yep 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 |
| xthunderworkx | The G never runs out of money. | 18:50 |
| fray | ok | 18:50 |
| xthunderworkx | But those are good points and I will definitely push up to the Suits | 18:50 |
| * fray works for a commercial YP vendor.. so I'm familiar with all of these problems.. | 18:51 | |
| fray | but 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@50.233.148.156> has joined #yocto | 18:52 | |
| xthunderworkx | Dood, I love to store your 411. If the thing works, we may definitely need your help. | 18:52 |
| *** dreyna <dreyna!~dreyna@70.214.101.157> has joined #yocto | 18:53 | |
| *** rburton <rburton!~textual@home.burtonini.com> has quit IRC | 18:53 | |
| *** rburton <rburton!~textual@home.burtonini.com> has joined #yocto | 18:53 | |
| xthunderworkx | So build the binaries using the rulez, stash them in a repo and pull them into the image with bitbake. | 18:55 |
| fray | yes, 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 requested | 18:55 |
| *** xthundermobilex <xthundermobilex!~androirc@184.75.233.58> has quit IRC | 18:59 | |
| *** xthundermobilex <xthundermobilex!~androirc@184.75.233.58> has joined #yocto | 18:59 | |
| *** stephano <stephano!~stephano@134.134.139.82> has quit IRC | 19:02 | |
| *** stephano <stephano!~stephano@134.134.139.82> has joined #yocto | 19:02 | |
| *** rewitt <rewitt!rewitt@nat/intel/x-acccdgrsxyrniqsh> has joined #yocto | 19:19 | |
| xthunderworkx | kergoth: 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 |
| xthunderworkx | In the context of that conversation I meant "Operational Environment" not OpenEmbedded, but yeah they provide YP based releases for their SOMs. | 19:22 |
| xthunderworkx | I actually like Digi ... they have been pretty good so far even though we squeezed them on the budget. | 19:24 |
| kergoth | ah | 19:30 |
| sveinse | fray, out of curiosity, what does a commercial YP provider deliver exactly? | 19:35 |
| fray | long term support beyond the regular Yocto Project life cycle | 19:35 |
| fray | so if you want 2 years of support on a release, maybe 5.. or even say 15.. many of the commercial providers can do this | 19:35 |
| fray | if 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 |
| sveinse | The 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 |
| sveinse | We track poky releases more or less | 19:36 |
| fray | additional 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 |
| fray | it'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 |
| fray | one or all of those often justifies a commercial provider | 19:38 |
| sveinse | So 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 IRC | 19:40 | |
| fray | it 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 #yocto | 19:40 | |
| fray | a lot of our customers use COTS boards and skip the HW vendor part.. | 19:40 |
| fray | we 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 |
| fray | often 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 |
| sveinse | fray: you don't happen to work for a Brazillian company? ;) | 19:42 |
| fray | nope | 19:42 |
| fray | I know we have customers in Brazil though.. | 19:42 |
| sveinse | anyhow, our volumes were far to high for COTS, thus the custom HW and subsequently BSP | 19:43 |
| fray | In 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 |
| fray | In those cases, it usually requires a custom agreement | 19:44 |
| *** falk0n <falk0n!~falk0n@a79-168-122-55.cpe.netcabo.pt> has quit IRC | 19:46 | |
| sveinse | My 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 sense | 19:46 |
| fray | Ya, the kernel is usually included as many defects are related to kernel bugs.. (specifically crashes and various device interactions) | 19:48 |
| zarzar1 | what is the "workspace" directory for? can i remove its contents? | 19:49 |
| fray | The 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 |
| fray | that meets the needs of many folks, and avoids additional cost for 'custom' support | 19: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 |
| sveinse | The output is a image that can be used for anything, right. Not images purpose built for a single-use (customer) application? | 19:55 |
| fray | correct.. | 19:55 |
| fray | it's the regular Yocto Project build environment, etc... | 19:55 |
| fray | so you can build 'anything' (within reason).. SDKs, images, kernels, etc.. | 19:56 |
| *** joshuagl <joshuagl!joshuagl@nat/intel/x-clyevpotllpbqooj> has quit IRC | 19:56 | |
| *** bemo <bemo!68840555@gateway/web/freenode/ip.104.132.5.85> has quit IRC | 19:59 | |
| rburton | zarzar1: its where devtool unpacks stuff | 20:00 |
| *** dave0x6d <dave0x6d!uid190567@gateway/web/irccloud.com/x-vfbeetvkojbxjfox> has joined #yocto | 20:00 | |
| *** lazyape <lazyape!~lazyape@athedsl-244581.home.otenet.gr> has quit IRC | 20:03 | |
| *** harisokanovic <harisokanovic!~harisokan@130.164.62.119> has quit IRC | 20:03 | |
| *** lazyape <lazyape!~lazyape@athedsl-244581.home.otenet.gr> has joined #yocto | 20:03 | |
| *** harisokanovic <harisokanovic!~harisokan@130.164.62.119> has joined #yocto | 20:04 | |
| *** harisokanovic <harisokanovic!~harisokan@130.164.62.119> has joined #yocto | 20:04 | |
| *** harisokanovic <harisokanovic!~harisokan@130.164.62.119> has quit IRC | 20:06 | |
| *** bemo <bemo!68840555@gateway/web/freenode/ip.104.132.5.85> has joined #yocto | 20:06 | |
| *** harisokanovic <harisokanovic!~harisokan@130.164.62.119> has joined #yocto | 20:06 | |
| *** bemo <bemo!68840555@gateway/web/freenode/ip.104.132.5.85> has quit IRC | 20:08 | |
| *** luc4 <luc4!~luc4@93-46-89-64.ip106.fastwebnet.it> has joined #yocto | 20:08 | |
| *** t0mmy <t0mmy!~tprrt@fs-93-93-41-87.fullsave.info> has quit IRC | 20:11 | |
| *** bemo <bemo!68840555@gateway/web/freenode/ip.104.132.5.85> has joined #yocto | 20:12 | |
| *** curie <curie!~curie@cpe-70-113-31-17.austin.res.rr.com> has joined #yocto | 20:25 | |
| *** stephano <stephano!~stephano@134.134.139.82> has quit IRC | 20:26 | |
| zarzar1 | oh ok | 20:26 |
| *** Snert <Snert!~LoginName@106-24-237-24.gci.net> has quit IRC | 20:26 | |
| zarzar1 | rburton: i thought so, i removed it to clean up but bitbake complained | 20:26 |
| *** VoxPenguin <VoxPenguin!~VoxPengui@www.wanderingwalrus.com> has joined #yocto | 20:29 | |
| *** learningc <learningc!~User@175.141.43.42> has quit IRC | 20:30 | |
| *** learningc <learningc!~User@175.141.43.42> has joined #yocto | 20:31 | |
| *** xthundermobilex <xthundermobilex!~androirc@184.75.233.58> has quit IRC | 20:35 | |
| *** sjolley <sjolley!~sjolley@134.134.139.73> has quit IRC | 20:38 | |
| *** majuk <majuk!~majuk@174.255.130.14> has joined #yocto | 20:38 | |
| *** Snert <Snert!~LoginName@106-24-237-24.gci.net> has joined #yocto | 20:42 | |
| *** marka <marka!~masselst@128.224.252.2> has quit IRC | 20:47 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 20:57 | |
| *** sjolley <sjolley!~sjolley@134.134.139.83> has joined #yocto | 21:09 | |
| *** gtristan <gtristan!~tristanva@110.11.179.89> has quit IRC | 21:10 | |
| *** lazyape <lazyape!~lazyape@athedsl-244581.home.otenet.gr> has quit IRC | 21:16 | |
| *** lazyape <lazyape!~lazyape@athedsl-244581.home.otenet.gr> has joined #yocto | 21:16 | |
| *** clement <clement!~clement@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC | 21:21 | |
| *** zarzar1 <zarzar1!~zarzar@216-136-13-242.static.twtelecom.net> has quit IRC | 21:26 | |
| *** clement <clement!~clement@static-css-ccs-204145.business.bouyguestelecom.com> has joined #yocto | 21:32 | |
| *** curie <curie!~curie@cpe-70-113-31-17.austin.res.rr.com> has quit IRC | 21:42 | |
| *** armpit <armpit!~armpit@50.233.148.156> has quit IRC | 21:47 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 21: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/716 | 21:51 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 21:52 | |
| *** pohly <pohly!~pohly@p54BD5DCA.dip0.t-ipconnect.de> has quit IRC | 22:05 | |
| *** stephano <stephano!~stephano@134.134.139.82> has joined #yocto | 22:12 | |
| *** stephano <stephano!~stephano@134.134.139.82> has quit IRC | 22:13 | |
| *** bodangly <bodangly!~bodangly@c-24-218-194-93.hsd1.ct.comcast.net> has quit IRC | 22:16 | |
| *** Chris__ <Chris__!189fd2fe@gateway/web/freenode/ip.24.159.210.254> has joined #yocto | 22:30 | |
| *** JaMa <JaMa!~martin@217.30.68.212> has quit IRC | 22: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=aa5127d27933a2662ebaa054e35fb1f5262804bb | 22: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 it | 22:34 |
| *** Chris__ <Chris__!189fd2fe@gateway/web/freenode/ip.24.159.210.254> has quit IRC | 22:48 | |
| sveinse | What's a good generic MACHINE for yocto? qmeux86? or are there native intel machines which is well suited? Preferrably out of box | 22:49 |
| *** Chris__ <Chris__!189fd2fe@gateway/web/freenode/ip.24.159.210.254> has joined #yocto | 22:51 | |
| paulg | MACHINE ?= "genericx86-64" | 22:51 |
| paulg | don't let the name confuse you. ;-) | 22:51 |
| rburton | i'd suggest qemux86-64 | 22:51 |
| rburton | the qemu machines have the advantage of a well defined target, the genericx86 ones are a bit vague | 22:52 |
| rburton | also everyone has the qemu machine, only people with meta-yocto-bsp have genericx86 | 22:52 |
| rburton | tldr: the genericx86* machines are lame, and i can say that as i wrote them | 22:52 |
| paulg | yah, that latter point is probably the key. | 22:53 |
| sveinse | lol. thanks rburton | 22:53 |
| rburton | sveinse: really depends what you mean by good and generic | 22:53 |
| rburton | for build testing? the qemu machines are great. | 22:54 |
| rburton | genericx86*'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 | |
| sveinse | rburton: yeah, was a vague question. For build testing. For testing build artefacts. Not so much for running actually. | 22:55 |
| paulg | and no, I can't justify that. | 22:55 |
| rburton | paulg: i've discovered that systemd-nspawn will boot a intel-corei7-64 .wic image in about two seconds | 22:55 |
| sveinse | Or, perhaps my little gobject showdown should convince me to have a vanilla system running | 22:55 |
| rburton | sveinse: definitely the qemu machines. trivial to test, solid base. | 22:56 |
| sveinse | great | 22:56 |
| rburton | sveinse: oh i posted "python-pygobject: skip the package if gobject-introspection is disabled" earlier :) | 22:56 |
| rburton | paulg: nspawn can read efi partition tables so does the right thing with a wic image, it's great | 22:57 |
| rburton | userspace only, obviously, but good enough for "does python work" | 22:57 |
| sveinse | rburton: yea, I see that. I wasn't sure if pygobject had any other functions when gobject-introspect-data isn't installed | 22:58 |
| paulg | the beauty of 2008 vintage e-waste is that I need not concern myself with uEFI boot. :) | 22:58 |
| rburton | sveinse: preeeety sure its useless. you had it breaking with gobject, which is the lowest part of it | 22:58 |
| rburton | can't do the test in gobject-introspection, as that is needed to build stuff, even if g-i is then disabled | 22:59 |
| sveinse | I'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 away | 23: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/178 | 23:00 | |
| *** dreyna <dreyna!~dreyna@70.214.101.157> has quit IRC | 23:00 | |
| *** Chris__ <Chris__!189fd2fe@gateway/web/freenode/ip.24.159.210.254> has quit IRC | 23:02 | |
| *** bodangly <bodangly!~bodangly@c-24-218-194-93.hsd1.ct.comcast.net> has joined #yocto | 23:05 | |
| *** bodangly_ <bodangly_!~bodangly@c-24-218-194-93.hsd1.ct.comcast.net> has joined #yocto | 23:08 | |
| *** bodangly <bodangly!~bodangly@c-24-218-194-93.hsd1.ct.comcast.net> has quit IRC | 23:10 | |
| *** bodangly_ <bodangly_!~bodangly@c-24-218-194-93.hsd1.ct.comcast.net> has quit IRC | 23:22 | |
| *** luc4 <luc4!~luc4@93-46-89-64.ip106.fastwebnet.it> has quit IRC | 23:23 | |
| sveinse | does it exist any (good?) opengl libs for qmeu in yocto? | 23:27 |
| *** lamego <lamego!lamego@nat/intel/x-yitlzizzfpzuicoz> has quit IRC | 23:27 | |
| *** armpit <armpit!~armpit@2601:202:4000:1184:242f:c14a:feac:fa0c> has joined #yocto | 23:35 | |
| *** agust <agust!~agust@p4FCB4189.dip0.t-ipconnect.de> has quit IRC | 23:36 | |
| rburton | sveinse: g-i *needs* to run code at build time. iirc it was only some mips that didn't work | 23:41 |
| *** ctwr <ctwr!~catalin@89.121.200.102> has quit IRC | 23:42 | |
| rburton | sveinse: as to gl in qemu | 23:43 |
| rburton | mesa can go software rendering, which is lame but sort of works | 23:44 |
| rburton | turn 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 |
| rburton | if you actually want good performance then ask jama for his experiments with using the virtio patches to use the host GPU | 23:45 |
| rburton | (but thats more work) | 23:45 |
| rburton | llvmpipe should be the best bang-per-buck | 23:45 |
| rburton | especially if you run qemux86-64 with kvm enabled | 23:45 |
| sveinse | rburton: that all requires x, right? | 23:48 |
| rburton | shouldn't do | 23:48 |
| *** rburton <rburton!~textual@home.burtonini.com> has quit IRC | 23:49 | |
| sveinse | Could 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 need | 23:49 |
| *** stephano <stephano!~stephano@134.134.139.76> has joined #yocto | 23:50 | |
| *** toanju <toanju!~toanju@x55b420f5.dyn.telefonica.de> has quit IRC | 23:51 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!