Monday, 2016-08-22

kergothsveinse: perhaps we should have a SRC_URI ??= "". then the default is applied late, so we know it's always set.00:13
*** sameo <sameo!~samuel@192.55.54.44> has quit IRC00:15
*** Biliogadafr <Biliogadafr!~pin@nat2-minsk-pool-46-53-194-120.telecom.by> has quit IRC00:17
*** Biliogadafr <Biliogadafr!~pin@nat2-minsk-pool-46-53-194-120.telecom.by> has joined #yocto00:17
sveinseno, now it failed again. This time with wiped tmp but with populated sstate00:18
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC00:19
sveinseBut it did warn with the "WARNING: Unable to get checksum for sp SRC_URI entry oe-workdir: [Errno 2] No such file or directory" for both oe-workdir and oe-logs.00:20
kergothafaik devtool modify -x sets those up, but externalsrc should work with manually set up external dirs too..00:21
* kergoth shrugs00:21
sveinseMy hunch (and I just proved my previous to be false) is that when tmp/ is wiped, the oe-workdir/ and oe-logs/ become dangling symlinks. When bitbake then is re runned, these dangling link cause bitbake to croak00:23
sveinseRunning bitbake on a wiped tmp/, with oe-logs/ present. It now warned of oe-workdir&oe-logs missing. Let's see if it dies00:25
sveinseThen I'll retry the same thing, but this time erase oe-logs and oe-workdir prior to running bb00:26
*** nighty <nighty!~nighty@d246113.ppp.asahi-net.or.jp> has joined #yocto00:29
*** bluelightning <bluelightning!~paul@50-39-168-205.bvtn.or.frontiernet.net> has joined #yocto00:34
*** bluelightning <bluelightning!~paul@50-39-168-205.bvtn.or.frontiernet.net> has quit IRC00:34
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto00:34
sveinsejup, the former failed, the latter succeeds.00:44
*** mastier <mastier!~mastier@mastier.pl> has quit IRC01:08
*** Biliogadafr <Biliogadafr!~pin@nat2-minsk-pool-46-53-194-120.telecom.by> has quit IRC01:17
*** Nilesh_ <Nilesh_!uid116340@gateway/web/irccloud.com/x-vycddjoistwxanet> has joined #yocto01:21
*** bananadev <bananadev!~onlyester@117.6.99.240> has joined #yocto01:22
*** vmeson <vmeson!~rmacleod@24-212-184-107.cable.teksavvy.com> has joined #yocto01:34
*** clopez <clopez!~tau@neutrino.es> has quit IRC02:24
*** clopez <clopez!~tau@neutrino.es> has joined #yocto02:31
*** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has quit IRC02:34
*** sgw_ <sgw_!~sgw_@134.134.139.77> has quit IRC02:34
*** sameo <sameo!~samuel@192.55.54.44> has joined #yocto03:02
*** vlad_b <vlad_b!~Vlad@modemcable114.129-37-24.static.videotron.ca> has quit IRC03:14
*** vladb <vladb!~Vlad@modemcable114.129-37-24.static.videotron.ca> has joined #yocto03:35
*** bananadev <bananadev!~onlyester@117.6.99.240> has quit IRC03:37
*** bananadev <bananadev!~onlyester@117.6.99.240> has joined #yocto03:39
*** vishy27 <vishy27!c0374fa5@gateway/web/freenode/ip.192.55.79.165> has joined #yocto03:50
*** aehs29 <aehs29!aehernan@nat/intel/x-dnfduwluihztcekl> has joined #yocto04:02
*** aehs29 <aehs29!aehernan@nat/intel/x-dnfduwluihztcekl> has quit IRC04:10
*** morphis_ <morphis_!~morphis@pD9ED6839.dip0.t-ipconnect.de> has joined #yocto04:25
*** sameo <sameo!~samuel@192.55.54.44> has quit IRC04:33
*** vishy27 <vishy27!c0374fa5@gateway/web/freenode/ip.192.55.79.165> has quit IRC04:40
*** sno <sno!~sno@b2b-78-94-80-58.unitymedia.biz> has quit IRC04:43
*** sno <sno!~sno@b2b-78-94-80-58.unitymedia.biz> has joined #yocto04:45
*** sujith_h <sujith_h!~toaster@kde/developers/sujithh> has joined #yocto04:52
*** qt-x <qt-x!~Thunderbi@217.10.196.2> has joined #yocto05:01
*** AndersD <AndersD!~anders@213-64-218-130-no126.business.telia.com> has joined #yocto05:11
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto05:11
*** agust <agust!~agust@p4FCB5FD5.dip0.t-ipconnect.de> has joined #yocto05:14
*** sno <sno!~sno@b2b-78-94-80-58.unitymedia.biz> has quit IRC05:20
*** Crofton <Crofton!~Crofton@88-111-155-240.dynamic.dsl.as9105.com> has quit IRC05:22
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has quit IRC05:30
*** melonipoika <melonipoika!~jose@194.9.252.237> has quit IRC05:47
*** Crofton <Crofton!~Crofton@88-111-155-240.dynamic.dsl.as9105.com> has joined #yocto05:54
*** hamis_lt_u <hamis_lt_u!~irfan@110.93.212.98> has joined #yocto05:56
*** sveinse <sveinse!~chatzilla@156.92-221-160.customer.lyse.net> has quit IRC06:16
*** townxelliot <townxelliot!~ell@176.249.240.35> has joined #yocto06:17
*** TuTizz <TuTizz!~TuTizz@46.18.96.158> has joined #yocto06:23
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto06:23
*** pohly <pohly!~pohly@p5DE8FF9F.dip0.t-ipconnect.de> has joined #yocto06:25
*** phatina <phatina!~phatina@82-119-96-90.static.chello.sk> has quit IRC06:25
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto06:26
*** sno <sno!~sno@62.157.143.22> has joined #yocto06:29
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has joined #yocto06:31
*** joseppc <joseppc!~josep@linaro/joseppc> has quit IRC06:33
*** eduardas_ <eduardas_!~eduardas_@213.197.143.19> has joined #yocto06:33
*** frsc <frsc!~frsc@80.149.173.67> has joined #yocto06:34
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has quit IRC06:37
*** Crofton <Crofton!~Crofton@88-111-155-240.dynamic.dsl.as9105.com> has quit IRC06:42
*** phatina <phatina!~phatina@82-119-96-90.static.chello.sk> has joined #yocto06:45
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC06:46
*** eduardas_ <eduardas_!~eduardas_@213.197.143.19> has quit IRC06:50
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has joined #yocto06:50
*** yann <yann!~yann@nan92-1-81-57-214-146.fbx.proxad.net> has quit IRC06:51
*** boucman_work <boucman_work!~boucman@bob75-2-81-56-46-209.fbx.proxad.net> has joined #yocto06:52
*** eduardas_ <eduardas_!~eduardas_@213.197.143.19> has joined #yocto06:52
*** csanchezdll <csanchezdll!~user@galileo.kdpof.com> has joined #yocto06:54
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has quit IRC06:55
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has joined #yocto06:59
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has joined #yocto07:00
boucman_workpidge: ping ?07:02
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has joined #yocto07:04
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has quit IRC07:05
*** Kakounet <Kakounet!~Thunderbi@che44-1-88-163-87-53.fbx.proxad.net> has joined #yocto07:06
*** joseppc <joseppc!~josep@linaro/joseppc> has joined #yocto07:06
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/irccloud.com/x-sgvzjlabzzddgvsf> has joined #yocto07:08
*** jbrianceau_away is now known as jbrianceau07:08
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has joined #yocto07:09
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has joined #yocto07:10
*** joshuagl <joshuagl!~joshuagl@192.198.151.43> has joined #yocto07:10
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has joined #yocto07:12
*** rajm <rajm!~robertmar@82-70-136-246.dsl.in-addr.zen.co.uk> has joined #yocto07:13
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has joined #yocto07:14
*** joseppc <joseppc!~josep@linaro/joseppc> has quit IRC07:16
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has joined #yocto07:18
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto07:20
*** jku <jku!jku@nat/intel/x-qlclylklktoentdq> has joined #yocto07:23
*** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has joined #yocto07:26
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has joined #yocto07:26
*** smartin_ is now known as smartin07:28
*** joseppc <joseppc!~josep@sestofw01.enea.se> has joined #yocto07:33
*** joseppc <joseppc!~josep@linaro/joseppc> has joined #yocto07:33
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has joined #yocto07:36
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has quit IRC07:36
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has joined #yocto07:37
*** frsc <frsc!~frsc@80.149.173.67> has quit IRC07:38
*** yann <yann!~yann@85-171-21-92.rev.numericable.fr> has joined #yocto07:38
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has joined #yocto07:39
*** frsc <frsc!~frsc@80.149.173.67> has joined #yocto07:39
*** grma <grma!~gruberm@80.93.38.128> has joined #yocto07:42
*** sveinse <sveinse!~chatzilla@79.160.140.131> has joined #yocto07:46
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has joined #yocto07:46
*** alexlarsson <alexlarsson!~alexl@213-66-155-112-no94.tbcn.telia.com> has quit IRC07:48
*** yann <yann!~yann@85-171-21-92.rev.numericable.fr> has quit IRC07:48
*** thaytan <thaytan!~thaytan@199.7.70.115.static.exetel.com.au> has quit IRC07:49
sveinseThe docs state nfs is better for sstate sharing than http, but at the same time I got the impression from discussion here on this channel that NFS is not optimal. Why is that? In what way?07:59
*** CTtpollard <CTtpollard!~tom@82-70-136-246.dsl.in-addr.zen.co.uk> has joined #yocto08:04
*** morphis_ <morphis_!~morphis@pD9ED6839.dip0.t-ipconnect.de> has quit IRC08:22
*** belen <belen!~Adium@134.134.137.73> has joined #yocto08:23
*** morphis_ <morphis_!~morphis@pD9ED6839.dip0.t-ipconnect.de> has joined #yocto08:24
boucman_workaaaand one more hardcoded reference to gcc (glibc this time)08:29
*** obsrwr_ <obsrwr_!~otp-amois@188.24.204.43> has joined #yocto08:29
*** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has quit IRC08:31
*** yann <yann!~yann@LFbn-1-3226-41.w90-79.abo.wanadoo.fr> has joined #yocto08:32
sveinsesstate only saves the hashsum of the recipe, not the actual contents, does it?08:37
sveinseIs it possible to see why a recipe is being rebuilt?08:38
Ulfalizersveinse: the sstate caches task output. the "key" is a hash of all the inputs (variables affecting) the task.08:38
Ulfalizersstate tasks just copy the output they want to cache in the sstate cache into a directory08:39
*** Girafferson <Girafferson!~Giraffers@2601:281:8500:95b0:5249:f3c:d4e2:30a9> has joined #yocto08:40
Ulfalizersveinse: there's a way to get a list of all the variables a task depends on, but it's currently not documented very well08:41
Ulfalizeri have a pending bug for it08:41
Ulfalizersee http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#usingpoky-viewing-dependencies as well08:41
sveinseI have a kernel recipe which is retriggered on builds. E.g. wipe tmp/ and it rebuilds, not loading from sstate like all the rest. This recipe opens with a warning "Unable to get checksum for linux-dr SRC_URI entry defconfig: file could not be found". I suspect that this might be the cause08:41
Ulfalizersveinse: my usual debugging technique is to remove stuff until it stops rebuilding, and then working backwards from there :)08:43
Ulfalizersveinse: if you don't remove tmp/ and rebuild, does it say that no tasks needed to be rerun?08:43
*** rubdos <rubdos!~rubdos@host-85-27-50-55.dynamic.voo.be> has joined #yocto08:44
sveinseUlfalizer: Yes, I know about the -g option, but it (or -e) cannot show the vars in which is stored into sstate, can it?08:44
sveinseUlfalizer: Rerunning bb without erasing /tmp does not rebuild the kernel08:45
sveinse*err erasing tmp/... Huuuge difference08:45
Ulfalizersveinse: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10141 has instructions for how to see what variables went into creating the input checksum08:46
yoctiBug 10141: normal, Medium, 2.2, srifenbark, NEW , Suggested fleshing out of the sigdata/siginfo documentation08:46
rubdosSomething changed on the pypi front? I'm gonna submit a patch for python-cassandra-driver, but seems that the pypi default url doesn't work or something like that08:47
sveinseoh, perhaps it does. .siginfo contains the vars in a pickled (?) object. So I need something that can diff them between sstate and the current recipe then08:48
Ulfalizersveinse: short version is to find the siginfo file for the task in SSTATE_DIR and run bitbake-dumpsig on it08:48
Ulfalizerthere's bitbake-diffsigs as well for comparing the signature between different versions08:49
sveinseUlfalizer: Yeah, I'm reading the bug report now. Looks promising08:49
Ulfalizeri think the doc maintainer is on vacation. should hopefully go in after that. :)08:49
*** Crofton <Crofton!~Crofton@217.41.227.99> has joined #yocto09:02
sveinseI think I'm ready to conclude:  If you are using EXTERNALSRC, please note that bb leaves two symlinks in the path, oe-workdir and oe-logs. Please be aware that these two symlinks must be deleted if tmp/ is erased, otherwise bb will bork when generating sstate cache for that recipe.09:09
sveinse^^ is there a place this information should be put? E.g. bug report?09:12
Ulfalizersveinse: https://bugzilla.yoctoproject.org/enter_bug.cgi09:14
sveinseSo this /is/ a bug?09:14
Ulfalizeri have no idea. i've never used EXTERNALSRC. ;)09:14
sveinseLucky you. It's either EXTERNALSRC or fixup hg-support for our part.09:15
Ulfalizeryou could send an email to one of https://www.yoctoproject.org/tools-resources/community/mailing-lists as well09:16
Ulfalizerasking if what you're seeing is intended behavior09:16
Ulfalizerand suggesting improvements, etc.09:16
Ulfalizerthat has the advantage of being visible to google. the bugzilla doesn't seem to be. :/09:16
sveinseok, I will. (Personally not to fond of email lists any more. It drowns in all the spam I get.)09:17
*** Hunk <Hunk!ce7a6654@gateway/web/freenode/ip.206.122.102.84> has joined #yocto09:19
HunkHello, I try to run PyQT without x11. Anyone has some experience with that?09:19
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC09:22
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto09:22
*** psnsilva <psnsilva!~psnsilva@193-126-29-154.net.novis.pt> has joined #yocto09:24
*** yann <yann!~yann@LFbn-1-3226-41.w90-79.abo.wanadoo.fr> has quit IRC09:27
*** Crofton <Crofton!~Crofton@217.41.227.99> has quit IRC09:28
*** fl0v0 <fl0v0!~fvo@pD9F6B7FA.dip0.t-ipconnect.de> has joined #yocto09:28
*** egavinc <egavinc!~egavinc@43.red-2-139-180.staticip.rima-tde.net> has joined #yocto09:30
neverpanicrubdos: I think pypi changed, yes. There's a different URL that can be used now, let me check.09:32
rubdosneverpanic, thanks. I was panic'ing. ;p09:33
rubdosI hardcoded the URL for now09:33
*** psnsilva <psnsilva!~psnsilva@193-126-29-154.net.novis.pt> has quit IRC09:34
neverpanicrubdos: https://bitbucket.org/pypa/pypi/issues/438/backwards-compatible-un-hashed-package09:39
*** yann <yann!~yann@LFbn-1-3226-41.w90-79.abo.wanadoo.fr> has joined #yocto09:40
*** vdehors <vdehors!~vdehors@bob75-2-81-56-46-209.fbx.proxad.net> has quit IRC09:40
neverpanicrubdos: seems files.pythonhosted.org/packages/source/${d.getVar('PYTHON_PACKAGE', True)[0]}/${PYTHON_PACKAGE}-${PV}.tar.gz is now the way to go09:40
rubdosreading the issue, it seems to me that the bitbake class should get changed?09:40
*** AndersD <AndersD!~anders@213-64-218-130-no126.business.telia.com> has quit IRC09:40
rubdosThere always was the convenient "import pypi" statement, which magically downloaded the tar.gz and compiled it... :P09:41
neverpanicrubdos: yes, is it not changed yet?09:41
*** nighty <nighty!~nighty@d246113.ppp.asahi-net.or.jp> has quit IRC09:42
rubdosDon't know for sure; I'll check it. I changed my cassandra version to 3.6 (coming from 3.0), and it didn't work out of the box09:42
rubdosPerhaps it's not backported to krogoth?09:42
*** nighty <nighty!~nighty@d246113.ppp.asahi-net.or.jp> has joined #yocto09:43
rubdosmmm, krogoth is the latest stable, so don't think that's the problem09:43
*** nighty <nighty!~nighty@d246113.ppp.asahi-net.or.jp> has quit IRC09:43
*** AndersD <AndersD!~anders@213-64-218-130-no126.business.telia.com> has joined #yocto09:45
rubdosseems like I didn't fully update my distro, I'll report back09:45
rubdosneverpanic, this is current pypi.bbclass: https://github.com/openembedded/meta-openembedded/blob/master/meta-python/classes/pypi.bbclass09:47
rubdos(in master)09:47
rubdosfor reference: http://cgit.openembedded.org/cgit.cgi/meta-openembedded/tree/meta-python/classes/pypi.bbclass?h=master09:47
*** yann <yann!~yann@LFbn-1-3226-41.w90-79.abo.wanadoo.fr> has quit IRC09:49
*** rburton <rburton!~Adium@home.burtonini.com> has joined #yocto09:50
rubdosI'm sorry, that url has been changed indeed09:52
rubdoswow. I'm slow today09:52
rubdosDoesn't seem to be backported to krogoth though09:53
rubdoshttp://cgit.openembedded.org/meta-openembedded/tree/meta-python/classes/pypi.bbclass?h=krogoth09:53
rubdoshttp://cgit.openembedded.org/meta-openembedded/tree/meta-python/classes/pypi.bbclass?h=krogoth-next same for krogoth-next09:53
rubdosIt's in master, but not yet in krogoth09:54
neverpanicrubdos: So suggest a backport on the list, then?09:54
rubdosYes, I'll dothat09:54
rubdos(fill in spaces where needed)09:54
*** vdehors <vdehors!~vdehors@bob75-2-81-56-46-209.fbx.proxad.net> has joined #yocto10:02
*** yann <yann!~yann@LFbn-1-3226-41.w90-79.abo.wanadoo.fr> has joined #yocto10:02
*** nemunaire <nemunaire!~nemunaire@ra.nemunai.re> has quit IRC10:05
*** melonipoika <melonipoika!~jose@194.9.252.237> has joined #yocto10:24
*** yann <yann!~yann@LFbn-1-3226-41.w90-79.abo.wanadoo.fr> has quit IRC10:25
*** sveinse <sveinse!~chatzilla@79.160.140.131> has quit IRC10:33
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC10:46
*** nighty <nighty!~nighty@s229123.ppp.asahi-net.or.jp> has joined #yocto10:50
Hunkello, I try to run PyQT without x11. Anyone has some experience with that?11:10
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto11:11
rubdosHunk, so... Wayland? :P11:11
rubdosOr just the non-gui elements? Either case I cannot help... Just trying to gather information for the guys that can.11:12
*** yann <yann!~yann@85-171-21-92.rev.numericable.fr> has joined #yocto11:13
Hunknever installed wayland with yocto. Is that complicated?11:14
CTtpollardno, it's provided by poky11:14
boucman_workHunk: I think you just need to add that to distro features, if it's not in there...11:14
Hunkwhat is the package name? The problem is that pyqt require x1111:15
rburtondoes it really need x11 or does it need qt, on something11:16
rburtonas qt5 can run on wayland11:16
rburtoni guess the real question is "do you need graphics at all"11:16
*** bananadev <bananadev!~onlyester@117.6.99.240> has quit IRC11:16
Hunkyes i need11:17
*** psadro <psadro!~Thunderbi@216.234.148.134> has quit IRC11:17
rburtonso what were you going to replace x11 with11:17
rburtonas this isn't a choice to make without any planning11:17
*** psadro <psadro!~Thunderbi@216.234.148.134> has joined #yocto11:17
HunkI used the default QWS before11:18
Hunkfor qt c++11:18
Hunkthat work well11:18
Hunkbut pyqt needs x1111:18
Hunk# depends on qt4-x11-free REQUIRED_DISTRO_FEATURES = "x11"11:18
rburtonoh right, qt4.  i believe qt4 does need x11 yes.11:18
boucman_workso... I finally compiled yocto without gcc, and now I need to upstream patches to glibc, busybox and the kernel :P11:18
rburtonboucman_work: \o/11:18
*** fl0v0 <fl0v0!~fvo@pD9F6B7FA.dip0.t-ipconnect.de> has quit IRC11:18
rburtonHunk: port pygt to qt-embedded?11:19
CTtpollardHunk: can you switch to meta-qt5?11:19
boucman_work(tbh, busybox and the kernel have the same bug, it's in the kconfig infrastructure...)11:19
*** morphis_ <morphis_!~morphis@pD9ED6839.dip0.t-ipconnect.de> has quit IRC11:19
HunkI use meta-qt511:20
Hunkbut pyqt is inside meta-openembedded11:21
rburtongoogle says pyqt for qt5 exists, so maybe you just need to write a recipe or something11:22
*** morphis_ <morphis_!~morphis@pD9ED6839.dip0.t-ipconnect.de> has joined #yocto11:22
CTtpollardmy system uses pyqt, on qt511:23
CTtpollardwith wayland11:23
CTtpollardHunk: https://github.com/GENIVI/meta-genivi-dev/blob/9649b132ca5d6ed0b03565ff3642a035fd87891e/meta-genivi-dev/recipes-devtools/python/python-pyqt_5.3.1.bb11:25
rburtontsk tsk that should be in meta-qt5 or something ;)11:25
CTtpollardI can't comment on the origin, but yes I agree11:28
*** fl0v0 <fl0v0!~fvo@pD9F6B7FA.dip0.t-ipconnect.de> has joined #yocto11:29
*** T_UNIX <T_UNIX!d4d3bd3c@gateway/web/freenode/ip.212.211.189.60> has joined #yocto11:34
*** boucman_work <boucman_work!~boucman@bob75-2-81-56-46-209.fbx.proxad.net> has quit IRC11:35
quiteYow, I have trouble building chromium for my image (OOM killer, or so). I got the built rpm from a colleague, can I override the build systems to just use it? dropped it in tmp/deploy/... is not enough..11:36
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@31.159.129.167> has joined #yocto11:37
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has joined #yocto11:37
Hunkthank you i will check it :)11:38
*** berton <berton!~fabio@177.127.4.56> has joined #yocto11:39
darwishHello, my poky version has two versions of the mesa recipe: mesa_git.bb and mesa_10.6.3.bb11:40
darwishmesa_git.bb has DEFAULT_PREFERENCE = "-1"11:40
darwishand in my local.conf I set PREFERRED_VERSION_mesa = "10.6.3"11:41
darwishSo everything should be set that bitbake chooses the 10.6.3 version11:41
darwishNonetheless I get the following warnings, then the build fails:11:42
darwish   NOTE: preferred version 10.6.3 of mesa not available (for item libegl)11:42
darwish   NOTE: versions of mesa available: 2:10.5.4+gitAUTOINC+ea0d1f575c11:42
*** boucman_work <boucman_work!~boucman@bob75-2-81-56-46-209.fbx.proxad.net> has joined #yocto11:43
darwishI've checked the dependencies of libegl, and it does _not_ specify any mesa version to depend on11:43
darwishSo what's really the problem here? I've been trying to debug it with no luck :-(11:43
CTtpollardthe mesa..bb will require the .git file11:45
darwishCTtpollard, sorry; could you elaborate further? :-)11:45
CTtpollardactually maybe not11:45
darwishhmmm ...11:46
CTtpollardit's common for recipes to depend on a related .git file, but mesa.bb's pull in tarballs11:46
*** sameo <sameo!~samuel@192.55.55.41> has joined #yocto11:46
darwishCTtpollard, yes .. it's an http tarball fetcher11:47
darwishCTtpollard, what's really frustrating is that if I just remove mesa-git.bb .. everything work as expected without any errors!11:48
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC11:48
*** thaytan <thaytan!~thaytan@199.7.70.115.static.exetel.com.au> has joined #yocto11:50
darwishcorrection: mesa_git.bb ..11:50
CTtpollarddarwish: are you sure there's nothing else in your system that is explicitly setting the version in meta_git as required? it might also be useful to use the mesa-megadriver11:57
darwishCTtpollard, how can another recipe explicitly state the version? I can grep that expression if there's one11:58
CTtpollardor the preferred provider of libegl somewhere11:58
darwish(that is, how a recipe mandates using a certain version of a dependency)11:58
*** istarilucky <istarilucky!~rlucca@189.112.127.225> has joined #yocto11:58
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto11:59
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has quit IRC12:02
jkudarwish: it seems to be telling you it can't find the 10.6.3 recipe at all12:02
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has joined #yocto12:04
darwishjku, it's there .. at the end bitbake complains that its sees both mesa_git and mesa_10.6.3 and that I must choose one12:05
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC12:05
darwishjku, and I've already chosen one using PREFERRED_PROVIDER, and it's showing in bitbake -e :-(12:05
jkuhuh12:06
darwishjku, yeah .. it claims that some other dependencies are pulling for mesa_git, and I've chosen mesa_10.6.3 .. and thus it gets confused12:08
darwish(two mesa versions included in the same build)12:08
darwishHow can I see if some random recipe is pulling mesa_git.bb version (instead of mesa_10.6.3.bb) behind my back?12:09
darwishCan even a recipe mandate a certain version!?12:09
*** jkridner|pd <jkridner|pd!~jkridner@pdpc/supporter/active/jkridner> has quit IRC12:10
darwishAnd if any recipe really depends on mesa_git.bb instead of mesa_10.6.3.bb .. why just removing mesa_git.bb makes everything succeed (the mysterious recipe should've bailed out instead I guess?)12:16
*** anticom <anticom!~timo.m@217.6.33.234> has joined #yocto12:18
*** dmoseley <dmoseley!~dmoseley@6532158hfc157.tampabay.res.rr.com> has joined #yocto12:20
joshuagldoesn't mesa offer multiple PROVIDES ? is the _git version providing something 10.6.3 doesn't?12:25
darwishhmmmm12:25
joshuagla recipe can't mandate a specific version of a dependency, that's a distro-level policy decision12:25
*** caiortp <caiortp!~inatel@131.221.240.204> has joined #yocto12:26
darwishgreat; I'll diff the two12:26
darwishjoshuagl, both include the same include file with the same provides :-(12:27
darwishhttps://github.com/01org/luv-yocto/blob/master/meta/recipes-graphics/mesa/mesa_10.6.3.bb12:27
darwishhttps://github.com/01org/luv-yocto/blob/master/meta/recipes-graphics/mesa/mesa_git.bb12:28
*** challinan <challinan!~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net> has joined #yocto12:29
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has quit IRC12:37
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto12:47
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has joined #yocto12:49
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has joined #yocto12:52
joshuagldarwish: hmm, not entirely sure what's going on tbh12:53
darwishyeah, neither do I :-( :-(12:53
joshuaglsame error for different MACHINE?12:53
darwishwill try12:54
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has joined #yocto12:57
*** istarilucky <istarilucky!~rlucca@189.112.127.225> has quit IRC12:58
*** jku <jku!jku@nat/intel/x-qlclylklktoentdq> has quit IRC12:58
*** istarilucky <istarilucky!~rlucca@177.159.144.73> has joined #yocto12:59
*** lamego <lamego!~jose@134.134.139.82> has joined #yocto13:04
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC13:05
*** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has joined #yocto13:08
*** morphis_ <morphis_!~morphis@pD9ED6839.dip0.t-ipconnect.de> has quit IRC13:13
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has joined #yocto13:17
*** morphis_ <morphis_!~morphis@pD9ED6839.dip0.t-ipconnect.de> has joined #yocto13:18
*** vladb <vladb!~Vlad@modemcable114.129-37-24.static.videotron.ca> has quit IRC13:27
*** ncgs <ncgs!~ncgs@mail.dev.rtsoft.ru> has joined #yocto13:28
*** boucman_work <boucman_work!~boucman@bob75-2-81-56-46-209.fbx.proxad.net> has quit IRC13:31
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto13:32
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC13:32
*** Biliogadafr <Biliogadafr!~pin@nat2-minsk-pool-46-53-194-120.telecom.by> has joined #yocto13:33
*** georgem <georgem!~georgem@216-21-169-52.slc.googlefiber.net> has quit IRC13:36
*** JaMa <JaMa!~martin@ip-89-176-104-169.net.upcbroadband.cz> has joined #yocto13:37
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto13:38
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC13:40
*** georgem <georgem!~georgem@216-21-169-52.slc.googlefiber.net> has joined #yocto13:41
*** vmeson <vmeson!~rmacleod@24-212-184-107.cable.teksavvy.com> has quit IRC13:43
*** vmeson <vmeson!~rmacleod@24-212-184-107.cable.teksavvy.com> has joined #yocto13:44
*** boucman_work <boucman_work!~boucman@bob75-2-81-56-46-209.fbx.proxad.net> has joined #yocto13:51
*** dfrey <dfrey!~dfrey@d50-92-227-235.bchsia.telus.net> has quit IRC13:53
*** dfrey <dfrey!~dfrey@d50-92-227-235.bchsia.telus.net> has joined #yocto13:55
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto13:58
*** madisox <madisox!~madison@12.30.244.5> has joined #yocto13:58
*** AndersD <AndersD!~anders@213-64-218-130-no126.business.telia.com> has quit IRC13:59
*** igor3 <igor3!~igor@177.159.144.73> has joined #yocto13:59
*** rcw <rcw!~rwoolley@128.224.252.2> has joined #yocto14:03
*** boucman_work <boucman_work!~boucman@bob75-2-81-56-46-209.fbx.proxad.net> has quit IRC14:04
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC14:05
*** billr <billr!~wcrandle@134.134.137.71> has joined #yocto14:11
*** Guest3872 is now known as davis14:14
davishello14:14
*** dv__ <dv__!~quassel@62.178.118.86> has joined #yocto14:17
*** dv <dv!~quassel@62-178-118-86.cable.dynamic.surfer.at> has quit IRC14:17
davisI want to give someone a archive of the cross development sdk. I did bitbake -c populate_sdk myimgname and it did indeed build a sdk which my coworker could install, but it created an archive which is looking for file in my /home dir where I built the code.  This url http://www.yoctoproject.org/docs/1.6.1/adt-manual/adt-manual.html does not say anything about the environment file have references to where the14:18
davisbuild is made or how to remove the references. ie. other options to provide.14:18
joshuaglthat sounds like a bug, the SDK should be able to be installed independently of the build location14:20
*** boucman_work <boucman_work!~boucman@193.56.60.161> has joined #yocto14:22
davisnvm, yah one thing I need try14:22
*** benjamirc <benjamirc!~besquive@134.134.139.82> has joined #yocto14:23
*** bluelightning <bluelightning!~paul@c-71-63-217-65.hsd1.or.comcast.net> has joined #yocto14:23
*** bluelightning <bluelightning!~paul@c-71-63-217-65.hsd1.or.comcast.net> has quit IRC14:23
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto14:23
*** sgw_ <sgw_!sgw_@nat/intel/x-xszacyeeuduybavk> has joined #yocto14:24
LetoThe2ndwell 1.6 is really outdated by now. you might consider looking into a recent release, which also offers the extensible sdk facilities.14:24
davisno, i confirmed, he took the .tgz i gave him, sourced the script, it built the code and put in an install dir, in the install dir there is a env script.14:26
davis. ./the-env-script14:27
davisand to test we tried to build something and it complained that th ecompiler oculd not make exe's.14:27
davisi look at the env script and it definitely has refs to my dir with -f directives14:28
*** qt-x <qt-x!~Thunderbi@217.10.196.2> has quit IRC14:29
*** boucman_work1 <boucman_work1!~boucman@bob75-2-81-56-46-209.fbx.proxad.net> has joined #yocto14:29
davisok, perhaps I screwed up.14:29
davisi tar'd deploy/glibc/sdk and I gave him that. I should have sourced the script and give him the results.14:30
davisnvm, let me build it on my box and give him the output.14:30
davismy bad14:30
*** boucman_work <boucman_work!~boucman@193.56.60.161> has quit IRC14:30
*** csanchezdll <csanchezdll!~user@galileo.kdpof.com> has left #yocto14:31
*** Biliogadafr <Biliogadafr!~pin@nat2-minsk-pool-46-53-194-120.telecom.by> has quit IRC14:36
davishmm. no14:37
*** alimon1 <alimon1!~alimon@134.134.139.77> has joined #yocto14:39
*** radzy <radzy!~radzy@unknown-216-194.windriver.com> has joined #yocto14:41
*** ciccatrix <ciccatrix!cebf2f82@gateway/web/freenode/ip.206.191.47.130> has joined #yocto14:47
*** anselmolsm <anselmolsm!~anselmols@192.55.55.39> has joined #yocto14:48
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC14:49
*** anselmolsm <anselmolsm!~anselmols@192.55.55.39> has quit IRC14:51
*** boucman_work1 <boucman_work1!~boucman@bob75-2-81-56-46-209.fbx.proxad.net> has quit IRC14:52
*** grma <grma!~gruberm@80.93.38.128> has quit IRC14:52
*** aurele <aurele!~aurele@srvmsg.castel.fr> has joined #yocto14:58
aurelehi everyone14:58
HyP3rhi aurele14:58
*** sgw_ <sgw_!sgw_@nat/intel/x-xszacyeeuduybavk> has quit IRC14:58
aureleis it possible to build a 32bit sdk on a 64 bit machine14:59
kergothdarwish: recipes don't control versions of dependencies. versions are specified using PREFERRED_VERSION14:59
joshuaglaurele: it is http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#var-SDKMACHINE15:00
darwishkergoth, yeah .. which makes me wonder why Yocto is not able to recognize PREFERRED_VERSION_mesa = "10.6.3" :-(15:00
*** [Sno] <[Sno]!~sno@62.157.143.22> has joined #yocto15:00
kergothfirst, use bitbake -e to confirm its set the way you think it is, and wasnt overridden by a config file parsed after local.conf, like distro or machine15:00
kergothbitbake -e | grep PREFERRED_VERSION_mesa=15:00
*** sno <sno!~sno@62.157.143.22> has quit IRC15:00
aurele(I have a build error with qt5/qtwebengine seems to be due to address space and "oomkiller",  but only on 32 bit machines)15:01
aurelejoshuagl thanks15:02
*** anselmolsm <anselmolsm!anselmolsm@nat/intel/x-chljwlefpzyspebh> has joined #yocto15:02
rburtonaurele: that would be because webkit can be bigger than 4gb when linking, so good luck holding that in memory on a 32-bit host.   using gold as linker may help, or pass —no-keep-memory to the linker15:03
*** sveinse <sveinse!~chatzilla@79.160.140.131> has joined #yocto15:05
*** hamis_lt_u <hamis_lt_u!~irfan@110.93.212.98> has quit IRC15:06
aurelerburton, many thanks I knew there was something but can't retrieve it, I will try this15:06
*** Biliogadafr <Biliogadafr!~pin@nat2-minsk-pool-46-53-194-120.telecom.by> has joined #yocto15:06
*** nillerbrun <nillerbrun!~nathani@mail.validmanufacturing.com> has joined #yocto15:07
*** boucman_work <boucman_work!~boucman@bob75-2-81-56-46-209.fbx.proxad.net> has joined #yocto15:08
nillerbrunhaving trouble with BB_ENV_EXTRAWHITE, anyone used this? Trying to import CVSROOT environment variable from outside bitbake15:08
kergothrburton, aurele: you can also adjust the compiler options to make it consume less ram at link time, we have a workaround of that sort in meta-mentor. not always enough, but might help. see https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mentor-staging/recipes-sato/webkit/webkitgtk_%25.bbappend15:09
kergothnillerbrun: adding a var to BB_ENV_EXTRAWHITE should get it into the metadata, but won't re-export it. check bitbake -e to see if it's set there. also, iirc oe-init-build-env sets it, it doesn't append it, so your alterations to it have to be done after sourcing that15:10
kergothat least that was the case in older versions, i think that's improved somewhat15:10
kergoths/sets it/sets BB_ENV_EXTRAWHITE/15:11
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC15:12
nillerbrunThanks kergoth, I'll check. I have a custom build-env supplied by my hardware manufacturer, perhaps that's my problem.15:13
kergothah, could very well be15:13
*** sgw_ <sgw_!sgw_@nat/intel/x-znugicdxmrmufrxz> has joined #yocto15:13
*** T_UNIX <T_UNIX!d4d3bd3c@gateway/web/freenode/ip.212.211.189.60> has quit IRC15:15
sveinseWhat alternatives are there to a upload syncing of sstate without using NFS? Would a manual additive rsync work?15:16
*** boucman_work <boucman_work!~boucman@bob75-2-81-56-46-209.fbx.proxad.net> has quit IRC15:18
kergothsstate is just a pile of tar files15:18
kergothso yes, rsync can handle it fine15:18
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto15:26
aurelekergoth, thanks I will try --no-keep-memory first as I would like to keep debug symbols, but it worth the try15:29
* kergoth nods15:29
*** boucman_work <boucman_work!~boucman@193.56.60.161> has joined #yocto15:34
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC15:34
sveinseI notice that my local SSTATE use a mix of two hex-prefix and a lot that is put there without any prefix. I won't push the latter to the server. I used to have two-letter only, what have I done?15:34
sveinseI have SSTATE_DIR ?= "/srv/yocto/sstate" and SSTATE_MIRRORS ?= "file://.* http://our-sstate.local/yocto/sstate/PATH"15:36
*** frsc <frsc!~frsc@80.149.173.67> has quit IRC15:37
kergothsveinse: if you use PATH on the remote side, it'll include the path prefix15:38
sveinsekergoth: So no PATH then? I'll find the 8a/ dirs itself without PATH?15:39
kergothI don't understand the question15:39
kergothif your remote server doesnt' include the prefix, then you don't want to use PATH in the mirror, you'd adjust the mirror replacement to replace the subdir. if the remote server does include the prefix, then you're fine and don't need to do anything15:40
sveinseWhat is an example of a prefix in this context?15:40
sveinseMy question is two-fold: When rebuilding with a blank sstate cache locally, I see some setscenes, but I also do a lot of rebuilds. So I'm wondering if I got the mirror statement right15:42
kergoththe only prefix we've mentioned is the subdir hte sstates are in15:43
kergoth8a in your example15:43
kergothi didn't pull a random prefix out of nowhere15:43
kergothyou referred to it as a prefix in your own question 10 minutes ago15:43
sveinseSecondly, if this is because my machine is different from the build server, I want to push my cache up to the server. But I see now that my sstate cache no longer i divided into two-hex letter dirs, so the structure don't match up with the servers15:43
kergothlocal sstate_dir is always broken up into subdirs15:44
*** rcwoolley_ <rcwoolley_!~rwoolley@128.224.252.2> has joined #yocto15:44
sveinsenot mine apparently15:44
kergothit's possible you have sstate archives both at the root of SSTATE_DIR and symlinked into the prefix dirs depending on what yocto version you're using (i.e. old)15:44
kergothin which case you should add ;downloadfilename=PATH to your SSTATE_MIRRORS, to make it download it directly inot the subdir paths rather than putting it at toplevel and symlinking it into those15:45
*** rcw <rcw!~rwoolley@128.224.252.2> has quit IRC15:45
kergothin either case a script to resolve the links to move them out of topdir would be trivial to write15:45
kergothto correct the current sstate_dir15:45
kergoths/inot/into/15:45
sveinseI'm running on krogoth (yeah, got this right this time), so it's new enough15:45
kergothby default the fetcher fetches into DL_DIR, and we force DL_DIR to SSTATE_DIR when fetching sstate. if the downloaded path doesnt' match expectations, it symlinks to resolve the mismatch15:45
kergothso 1. resolve the existing symlinks to fix your current sstate_dir, 2. add downloadfilename=PATH to fix future downloaded sstate archive paths15:46
kergothi think that should do it15:46
*** rajm <rajm!~robertmar@82-70-136-246.dsl.in-addr.zen.co.uk> has quit IRC15:46
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto15:47
kergothI misunderstood your question, i thought your sstate mirror wasn't organized by prefix subdir, but it sounds like the problem is local, not remote15:47
kergothin which case this should fix it15:47
darwishkergoth, sorry just noticed your message :-) .. Yes, bitbake -e | grep confirms that PREFERRED_VERSION_mesa = "10.6.3"15:47
sveinseyes, I'm retrying now  :D15:48
kergothdarwish: next step is to make sure 10.6.3 is even available. run bitbake -s | grep mesa. is the 10.6.3 version listed?15:48
kergothpreferred version to a version that isn't buildable won't do a thing15:48
*** Hunk <Hunk!ce7a6654@gateway/web/freenode/ip.206.122.102.84> has quit IRC15:49
aureleis it possible to set a compile flag depending on the build machine?15:51
*** reanguia1o is now known as reanguiano15:52
darwishkergoth,15:52
darwish   mesa                  2:10.6.3-r015:52
darwish   mesa-demos            :8.2.0-r015:52
darwishthat's interesting ..15:53
kergothgit isnt even listed..15:53
*** paulg <paulg!~paulg@192.190.0.143> has joined #yocto15:53
darwishhmm15:53
darwishmaybe because I force removed it earlier from the file system .. let's sanitize my environment15:54
darwishkergoth, "Multiple versions of mesa are due to be built (/home/darwish/projects/gen3/salvator-x/r-car-platform/build/../poky/meta/recipes-graphics/mesa/mesa_git.bb /home/darwish/projects/gen3/salvator-x/r-car-platform/build/../poky/meta/recipes-graphics/mesa/mesa_10.6.3.bb). Only one version of a given PN should be built in any given build. You likely need to set PREFERRED_VERSION_mesa to select the correct version or don't depend on multiple versions."15:55
neverpanicWhich recipe is supposed to provide 'ar' (for the host machine) in $PATH?15:55
neverpanicOr is that part of the host machine's requirements?15:55
kergothfor the host machine? nothing. your build server is expected to have a functional toolchain15:55
kergothar is part of binutils15:56
kergoththat said, if you're hitting an issue where it wants an unprefixed 'ar' but your machine has ${BUILD_PREFIX}ar, a fix for that hit the list recently, an expansion problem in sanity.bbclass15:56
*** aehs29 <aehs29!~aehernan@134.134.137.75> has joined #yocto15:58
neverpanicmy machine had /usr/bin/ar.single -> x86_64-linux-gnu-ar for reasons I don't understand; dpkg -L binutils clearly listed /usr/bin/ar15:59
HyP3rby default the yocto core-image provides connman as network manager, which is ok but the connman is has the problem that if one connection has successfull an network connection it doesn't try to connect other interfaces to the internet15:59
neverpanicreinstalling the package fixed the issue. Thanks, Debian, I guess?16:00
kergothhuh, werid16:00
neverpanicThat did uncover that 'bc' isn't using the cross-ar as it should, though.16:00
HyP3rIt seems like a default behaviour of connman, so I thinking about to switch to 'networkmanager'16:00
HyP3rDid someone tried this?16:00
HyP3rI just compiling networkmanager, but there is huge load of dependencys (e.g. libx11-native) which is crazy16:01
kergothmaybe see if there's a way to fix connman's behavior?16:02
* kergoth shrugs16:02
kergothgah, need to rebase shallow git support again due to the chdir fixups16:03
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto16:03
sveinsekergoth: downloadfilename worked, thanks!16:03
kergothnp16:03
HyP3rkergoth: well I talked to the developer of connman and he says that this is not easy to change this behaviour16:04
*** rcwoolley_ <rcwoolley_!~rwoolley@128.224.252.2> has quit IRC16:04
kergothah16:04
*** tlab_ <tlab_!~tlab@104.235.20.44> has quit IRC16:04
HyP3rwhat about systemd-networkd16:04
*** dfrey <dfrey!~dfrey@d50-92-227-235.bchsia.telus.net> has quit IRC16:05
*** jmesmon <jmesmon!~jmesmon@turntable.einic.org> has quit IRC16:05
*** boucman_work <boucman_work!~boucman@193.56.60.161> has quit IRC16:05
*** anticom <anticom!~timo.m@217.6.33.234> has quit IRC16:07
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC16:07
*** iskander <iskander!~iskander@81.171.81.151> has quit IRC16:07
*** joseppc <joseppc!~josep@linaro/joseppc> has quit IRC16:07
ciccatrixHey everyone, I have a small question... I was looking at this commit https://git.congatec.com/yocto/meta-openembedded/commit/45688928778ea5b3a6ed6d8ca614247772846b8f where ruby-native was added as a dependency for ruby in the bb, why is this required even though it was already in ruby's .inc file at the time? https://git.congatec.com/yocto/meta-openembedded/blob/45688928778ea5b3a6ed6d8ca614247772846b8f/meta-ruby/recipes-devtools/r16:09
ciccatrixsorry if it's a dumb question, it seemed to fix my problem so I'm wondering why it was necessary..16:12
rburtongood question, ask JaMa16:13
rburtonit was 3 years ago…16:13
*** bluelightning <bluelightning!paul@nat/intel/x-arzmugejjqwiyecu> has joined #yocto16:14
*** bluelightning <bluelightning!paul@nat/intel/x-arzmugejjqwiyecu> has quit IRC16:14
*** bluelightning <bluelightning!paul@pdpc/supporter/professional/bluelightning> has joined #yocto16:14
*** jmesmon <jmesmon!~jmesmon@turntable.einic.org> has joined #yocto16:14
ciccatrixfor now I'm stuck on danny so, haha, been looking at 3-year old stuff16:14
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto16:15
*** iskander <iskander!~iskander@81.171.81.153> has joined #yocto16:16
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has quit IRC16:19
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC16:20
*** fischerm <fischerm!~mfischer@207-114-172-147.static.twtelecom.net> has joined #yocto16:25
*** ciccatrix_ <ciccatrix_!cebf2f82@gateway/web/freenode/ip.206.191.47.130> has joined #yocto16:26
georgemHas anyone tried populate_sdk on machine with MULTILIBS configured? Unfortunately I need multilib:lib32 to build one recipe (but don't need it in the SDK). The sdk corei7-64-oe-linux sysroot is polluted with lib32 stuff.16:26
*** ciccatrix <ciccatrix!cebf2f82@gateway/web/freenode/ip.206.191.47.130> has quit IRC16:30
*** egavinc <egavinc!~egavinc@43.red-2-139-180.staticip.rima-tde.net> has quit IRC16:31
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto16:31
*** adelcast <adelcast!~adelcast@130.164.62.126> has quit IRC16:31
*** dfrey <dfrey!~dfrey@d50-92-227-235.bchsia.telus.net> has joined #yocto16:32
*** hweaving <hweaving!~ELROND@97-102-189-66.res.bhn.net> has joined #yocto16:33
*** t0mmy <t0mmy!~tprrt@ram31-1-82-234-79-177.fbx.proxad.net> has joined #yocto16:34
iskanderhello16:34
iskandera question regarding toaster16:34
iskanderis it possible to set PREMIRRORS variable in toaster ?16:35
iskanderi tried to add the variable in the toaster web interface but it failed16:35
iskanderspaces are not supported :(16:35
iskanderand the variable contains several ones16:35
darwishkergoth, Any recommended path I should follow? Why bitbake -s is not showing mesa_git, while bitbake itself complains of conflicts between mesa_git and mesa_10.6.316:36
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC16:37
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto16:38
*** [Sno] <[Sno]!~sno@62.157.143.22> has quit IRC16:39
* darwish is getting desperate about this .. maybe it's a bug within bitbake? will possibly post to the mailing list :-(16:39
*** Kakounet <Kakounet!~Thunderbi@che44-1-88-163-87-53.fbx.proxad.net> has quit IRC16:42
*** jbrianceau is now known as jbrianceau_away16:42
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC16:49
*** sveinse <sveinse!~chatzilla@79.160.140.131> has quit IRC16:50
beleniskander: sounds like we went a bit too far when validating variable values in Toaster :/ Could you open a bug in bugzilla.yoctoproject.org?16:50
*** moto-timo <moto-timo!ttorling@fsf/member/moto-timo> has quit IRC16:51
iskanderbelen: will do, how hard is it to fix ?16:52
*** joseppc <joseppc!~josep@c-e708e353.010-118-73746f7.cust.bredbandsbolaget.se> has joined #yocto16:53
*** joseppc <joseppc!~josep@linaro/joseppc> has joined #yocto16:54
beleniskander: thanks! shouldn't be too hard, although we are tight on resources of late. We will try in any case16:54
iskanderi'm a programmer and would like to fix it soon, therefore, i would appreciate any pointers16:55
beleniskander: excellent, although I've just tried and have been able to add a variable with spaces in the value. Could you tell me how you are trying to add it, and the Yocto Project version you are using?16:57
iskanderi use yocto 2.1 krogoth16:59
iskanderi created a new project16:59
iskanderand went to 'BitBake Variables' page16:59
iskanderthere is a filed to add a new variable16:59
iskanderfield*16:59
iskandername = PREMIRRORS17:00
iskandervalue = "git://.*/* http://<my-ip>/yocto-cache http://.*/* and so on"17:00
iskanderi tried to add it and it failed17:01
iskanderi copied PREMIRRORS from my local.conf17:01
iskanderso it should be fine17:01
iskanderit works without toaster17:01
iskanderanother question17:02
iskanderPREMIRRORS contains newlines too17:02
beleniskander: thanks. I think I can see the problem now. I get an error saying "too many values to unpack" :/17:02
iskanderbut toaster's value field allows only oneline17:02
iskanderbelen: yeah, that's the error i get17:02
iskanderi would like to use PREMIRRORS to save network bandwidth and speed things up17:03
*** rcw <rcw!~rwoolley@128.224.252.2> has joined #yocto17:05
beleniskander: sure. There is just something upsetting Toaster in that value for some reason. Definitely a bug.17:05
*** paulg <paulg!~paulg@192.190.0.143> has quit IRC17:10
*** Heitomos <Heitomos!cfb3940e@gateway/web/freenode/ip.207.179.148.14> has joined #yocto17:13
HeitomosHello.17:13
*** clsulliv <clsulliv!~clsulliv@134.134.139.82> has quit IRC17:14
HeitomosI have a question pertaining to Yocto, Mono, and MySQL, and was wondering if this might be the right place to ask?17:14
iskanderbelen, i submitted the bug report17:15
*** t0mmy <t0mmy!~tprrt@ram31-1-82-234-79-177.fbx.proxad.net> has quit IRC17:15
beleniskander: thanks for that17:15
iskanderif you have some patches to test then i'm ready17:16
*** fl0v0 <fl0v0!~fvo@pD9F6B7FA.dip0.t-ipconnect.de> has quit IRC17:18
*** clsulliv <clsulliv!~clsulliv@134.134.139.82> has joined #yocto17:23
*** stephano <stephano!~stephano@134.134.139.74> has joined #yocto17:25
*** belen <belen!~Adium@134.134.137.73> has quit IRC17:27
*** yann <yann!~yann@85-171-21-92.rev.numericable.fr> has quit IRC17:28
*** Biliogadafr <Biliogadafr!~pin@nat2-minsk-pool-46-53-194-120.telecom.by> has quit IRC17:29
*** bluelightning <bluelightning!paul@pdpc/supporter/professional/bluelightning> has quit IRC17:30
rburtonHeitomos: ask away, and see if you get a response17:31
HeitomosWell, I am working on a Yocto board, using a C# Mono Program, that's attempting to connect to the local MariaDB instance. From the Terminal, I can type 'mysql' and then my username and password, and get in to edit the database. However, when attempting to, from inside of mono, connection with a MySqlConnection object, it cannot connect to the host. I've tried turning on MySql error logging, but that didn't help, and I've otherwise s17:33
*** [Sno] <[Sno]!~sno@b2b-78-94-80-58.unitymedia.biz> has joined #yocto17:34
HeitomosSo I was wondering if anyone knew how to do that particular brand of connecting, or if I'm just missing something horrendously obvious?17:36
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC17:38
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto17:39
*** paulg <paulg!~paulg@70.52.193.89> has joined #yocto17:43
kergothhmm, think I'll add a reset-layers sub-command to bitbake-layers which resets BBLAYERS to the value from the template by looking at templateconf.cfg17:55
*** rcw <rcw!~rwoolley@128.224.252.2> has quit IRC17:55
*** rcw <rcw!~rwoolley@128.224.252.2> has joined #yocto17:55
kergoth(or falling back to just keeping the core layer, if templateconf.cfg is missing or invalid)17:55
kergothHmm, I can't decide whether I want to try to get bitbake-layers to stop parsing bitbake.conf. it'd be nice, since it'd be harder to get into a situation where its commands are unusable17:56
kergothwhich in turn would make it easier to keep small focused granular commands rather than putting everything into one to avoid a possibly broken intermediate state17:56
kergothhmm17:56
*** adelcast <adelcast!~adelcast@130.164.62.126> has joined #yocto18:00
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto18:04
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC18:08
*** obsrwr_ <obsrwr_!~otp-amois@188.24.204.43> has quit IRC18:09
*** sveinse <sveinse!~chatzilla@156.92-221-160.customer.lyse.net> has joined #yocto18:15
sveinseDoes yocto have any tools for uploading local sstate cache and/or DL to one of its mirror?18:16
sveinseOr is NFS the only approach for this?18:16
kergothnfs or rsync, as you've been told repeatedly18:16
sveinseSomeone here (and I don't remember who) claimed NFS to be iffy. Perhaps I misunderstood the statement. I suppose it's not you then, kergoth18:18
*** aehs29 <aehs29!~aehernan@134.134.137.75> has left #yocto18:19
kergothin the eyes of many, NFS is always iffy, for just about everything18:19
sveinseI'm writing the rsync scripts now, but ran into a little problem with file permission and time-syncing. A setgid directory and rsync is not the easiest approach apparently.18:20
sveinsePlanned on using rsync -rtlv. The -t is required for synchronizing the timestamps on file (preventing multiple uploads), yet it fails when trying to set timestamps on the dirs. And then colleague 2 comes along overwriting all the timestamps, and thus your rsync might behave differently the next time.18:23
sveinseSo I think it's needed to look at this syncing thing with a little more logic, so perhaps I'll write a py script for it18:23
HeitomosDoes anyone know much about using Mono and MySQL on Yocto?18:25
*** yann <yann!~yann@nan92-1-81-57-214-146.fbx.proxad.net> has joined #yocto18:30
*** rcwoolley_ <rcwoolley_!~rwoolley@128.224.252.2> has joined #yocto18:30
*** rcw <rcw!~rwoolley@128.224.252.2> has quit IRC18:31
neverpanicHeitomos: there is not much to know about specific components from a Yocto PoV other than "is there a recipe?", which can be answered by the layerindex18:31
*** ciccatrix_ <ciccatrix_!cebf2f82@gateway/web/freenode/ip.206.191.47.130> has quit IRC18:46
*** aehs29 <aehs29!aehernan@nat/intel/x-jemvfhqhzrcgvquo> has joined #yocto18:47
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/irccloud.com/x-sgvzjlabzzddgvsf> has quit IRC18:49
sveinseooi, what is the demographics of yocto users? What are the most common application areas for these projects? Anyone knows?19:00
*** fitzsim <fitzsim!~user@2001:420:284a:1300:6e0b:84ff:fe09:4e9f> has joined #yocto19:06
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/irccloud.com/x-itwfcmrkqaovnrkn> has joined #yocto19:08
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto19:11
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC19:16
*** joel__ <joel__!6d1d1298@gateway/web/freenode/ip.109.29.18.152> has joined #yocto19:16
*** iskander <iskander!~iskander@81.171.81.153> has quit IRC19:16
joel__hello all ! I have a question about yocto and kernel configuration throw bbappend. Is it the right place ?19:17
rubdossveinse, all over the world! I accidentially fell in one :D19:25
*** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has joined #yocto19:25
rubdos(Belgium)19:25
*** jedix__ is now known as jedix19:29
*** rubdos <rubdos!~rubdos@host-85-27-50-55.dynamic.voo.be> has quit IRC19:31
*** Heitomos <Heitomos!cfb3940e@gateway/web/freenode/ip.207.179.148.14> has left #yocto19:31
*** belen <belen!~Adium@134.134.137.73> has joined #yocto19:31
*** benjamirc <benjamirc!~besquive@134.134.139.82> has quit IRC19:33
*** Biliogadafr <Biliogadafr!~pin@nat2-minsk-pool-46-53-194-120.telecom.by> has joined #yocto19:35
*** iskander <iskander!~iskander@HSI-KBW-091-089-141-024.hsi2.kabel-badenwuerttemberg.de> has joined #yocto19:36
*** paulg <paulg!~paulg@70.52.193.89> has quit IRC19:37
*** Tenhi_ <Tenhi_!~tenhi@static.177.80.201.138.clients.your-server.de> has joined #yocto19:38
*** Tenhi_ <Tenhi_!~tenhi@static.177.80.201.138.clients.your-server.de> has quit IRC19:43
*** behanw <behanw!uid110099@gateway/web/irccloud.com/x-ljbrwspdbpcdvopt> has joined #yocto19:50
*** caiortp <caiortp!~inatel@131.221.240.204> has quit IRC19:56
rburtonkergoth: fwiw my bb fork has a "bb generated" command now19:57
kergothcool, will have to check it out19:58
*** dreyna <dreyna!~dreyna@unknown-216-201.windriver.com> has joined #yocto20:03
*** bluelightning <bluelightning!paul@nat/intel/x-qxfutggmcwcasama> has joined #yocto20:04
*** bluelightning <bluelightning!paul@nat/intel/x-qxfutggmcwcasama> has quit IRC20:04
*** bluelightning <bluelightning!paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:04
*** paulg <paulg!~paulg@72.1.195.9> has joined #yocto20:06
*** joseppc <joseppc!~josep@linaro/joseppc> has quit IRC20:06
*** jynik <jynik!~bragg@cpe-66-66-3-202.rochester.res.rr.com> has quit IRC20:08
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC20:15
*** townxelliot <townxelliot!~ell@176.249.240.35> has quit IRC20:19
davishello20:26
*** ftoth <ftoth!~quassel@145.132.48.198> has joined #yocto20:28
*** aboseley1 <aboseley1!~aboseley@220.57.96.58.static.exetel.com.au> has joined #yocto20:29
*** pohly <pohly!~pohly@p5DE8FF9F.dip0.t-ipconnect.de> has quit IRC20:30
*** aboseley1 <aboseley1!~aboseley@220.57.96.58.static.exetel.com.au> has joined #yocto20:30
*** aboseley1 <aboseley1!~aboseley@220.57.96.58.static.exetel.com.au> has joined #yocto20:31
davisI'm trying for the life of me to get my build to pull fresh source from git for a recipe I added. this works $ bitback -c fetch pcmx, but $ bitbake pcmx fails. Says do_unpack finished. error function failed Fetcher. reference is not a tree. I've been doing this between builds. $ bitbake -c cleanall pcmx; bitbake -c fetch pcmx; bitbake pcmx.  When it looked like it was not pullng fresh, I went into the20:32
davisbuild/tmp/..../pcmx/.../git and deleted all the subdirs pulled from git. Still i get the error when I try to build pcmx. My only known solution is rm -rf from the root dir and pull the project from git and do process from start. Surely there is a better way. Any tips?20:32
*** aboseley1 <aboseley1!~aboseley@220.57.96.58.static.exetel.com.au> has quit IRC20:32
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto20:34
*** aboseley1 <aboseley1!~aboseley@220.57.96.58.static.exetel.com.au> has joined #yocto20:34
*** aboseley1 <aboseley1!~aboseley@220.57.96.58.static.exetel.com.au> has joined #yocto20:35
*** Crofton <Crofton!~Crofton@ip-64-134-178-194.public.wayport.net> has joined #yocto20:36
*** aboseley1 <aboseley1!~aboseley@220.57.96.58.static.exetel.com.au> has quit IRC20:36
-YoctoAutoBuilder- build #887 of nightly-intel-gpl is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-intel-gpl/builds/88720:45
kergothdavis: cleanall should work just fine. what makes you say it 'looked like it was not pulling fresh'? did you heck the do_fetch task log?20:51
daviskergoth: no.20:56
davisfwiw, i rm -rf at top level. I'm doing a fresh build now. its just that its odd. Sometimes I can work with buidl, do work, build repeat. Other times no.20:56
*** Nilesh_ <Nilesh_!uid116340@gateway/web/irccloud.com/x-vycddjoistwxanet> has quit IRC20:57
davisi may have some issues with tree. Even when I do builds fresh, i'll get problems where it can not pull a repot. break. I just keep repeating after a break and it eventually works.20:59
davisit might due to network.20:59
*** hweaving <hweaving!~ELROND@97-102-189-66.res.bhn.net> has quit IRC21:01
*** moto-timo <moto-timo!~ttorling@134.134.139.74> has joined #yocto21:01
*** moto-timo <moto-timo!~ttorling@134.134.139.74> has quit IRC21:01
*** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has joined #yocto21:01
*** ftoth <ftoth!~quassel@145.132.48.198> has quit IRC21:01
*** radsquirrel <radsquirrel!bradleyb@nat/ibm/x-vkrshdyxuqbjjueb> has quit IRC21:02
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@2.43.232.111> has joined #yocto21:05
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has joined #yocto21:05
*** rcwoolley_ <rcwoolley_!~rwoolley@128.224.252.2> has quit IRC21:05
*** tomz_ <tomz_!tomz@nat/intel/x-uenlpdlguvmwptux> has quit IRC21:11
-YoctoAutoBuilder- build #297 of nightly-checkuri is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-checkuri/builds/29721:11
*** benjamirc <benjamirc!besquive@nat/intel/x-hfmnbowefswlhpez> has joined #yocto21:12
*** Crofton <Crofton!~Crofton@ip-64-134-178-194.public.wayport.net> has quit IRC21:13
*** berton <berton!~fabio@177.127.4.56> has quit IRC21:14
*** Crofton <Crofton!~Crofton@ip-64-134-178-194.public.wayport.net> has joined #yocto21:15
*** sameo <sameo!~samuel@192.55.55.41> has quit IRC21:22
*** Crofton <Crofton!~Crofton@ip-64-134-178-194.public.wayport.net> has quit IRC21:27
*** tomz_ <tomz_!~tomz@134.134.139.78> has joined #yocto21:29
*** radsquirrel <radsquirrel!bradleyb@nat/ibm/x-lpqnxnznxmxamypp> has joined #yocto21:29
kergothRP: if build_mirror_data fails, runfetchcmd will raise FetchError, which will result in mirror checking. using a different mirror won't fix the problem, however, if the problem was in tarring up what we've already fetched. long term I think we should split up mirror tarball construction into a separate method, possibly a separate task, but in the meantime I'm thinking when the fetch core calls build_mirror_data, it should catch FetchError and raise it21:29
kergoth as something else, i.e. SystemExit/bb.fatal, to prevent mirror checking from proceeding.21:29
kergothbluelightning: ^21:30
kergoththoughts?21:30
kergoththough rp is probably gone, he should see it later21:30
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC21:42
*** Biliogadafr <Biliogadafr!~pin@nat2-minsk-pool-46-53-194-120.telecom.by> has quit IRC21:42
bluelightningkergoth: I have to admit some of that error path is a still bit of a mystery to me, but what you're suggesting sounds sensible21:47
*** caiortp <caiortp!~caiortp@2001:470:f58c:ff04:e0c5:e14a:47cf:a7c9> has joined #yocto21:48
*** behanw <behanw!uid110099@gateway/web/irccloud.com/x-ljbrwspdbpcdvopt> has quit IRC21:59
*** fmeerkoetter <fmeerkoetter!~quassel@service.basyskom.com> has quit IRC22:01
*** bfederau <bfederau!~quassel@service.basyskom.com> has quit IRC22:01
*** aehs29 <aehs29!aehernan@nat/intel/x-jemvfhqhzrcgvquo> has left #yocto22:01
*** bfederau <bfederau!~quassel@service.basyskom.com> has joined #yocto22:01
*** fmeerkoetter <fmeerkoetter!~quassel@service.basyskom.com> has joined #yocto22:01
*** caiortp <caiortp!~caiortp@2001:470:f58c:ff04:e0c5:e14a:47cf:a7c9> has quit IRC22:07
joel__hello! I'm using yocto since few days now and trying to customize my kernel config. I do not manage to get fragment working in my kernel bbappend file. I'm on the fido branch and I have seen the same ind of issue browsing on google (particularly: https://lists.yoctoproject.org/pipermail/yocto/2015-June/025119.html). Any known issue on this subject ?22:09
*** lamego <lamego!~jose@134.134.139.82> has quit IRC22:09
khemjoel__: welcome to yocto world !. how are you adding the fragment to metadata22:16
khemis it via SRC_URI? if yes then you can specify like SRC_URI_append = " file://your_config"22:17
khemin you .bbappend for kernel recipe22:17
khemif you are using linux-yocto then there is a linux-yocto workflow available as well.22:18
joel__hello khem. thanks for reply. yes it is exactly what i'm doing, SRC_URI_append in my bbappend. the fragment is retrieved using bb menuconfig and diffconfig. At this moment, just to check my bbappend is read by bb, I have put the full kernel configuration in SRC_URI : SRC_URI_append = " file://defconfig". It works. But if I only put a fragment, it is not applied.22:20
joel__i'm not using linux-yocto22:21
joel__is it possible that something is wrong in the recipe linux-foo.bb I'm trying to patch with my linux-foo.bbapend ? something which prevent bb to apply fragment ?22:23
*** paulg <paulg!~paulg@72.1.195.9> has quit IRC22:24
*** caiortp <caiortp!~caiortp@131.221.243.1> has joined #yocto22:26
*** behanw <behanw!uid110099@gateway/web/irccloud.com/x-kzkpvcpvvwnhplok> has joined #yocto22:31
*** caiortp <caiortp!~caiortp@131.221.243.1> has quit IRC22:37
kergothjoel__: most kernel recipes don't support fragments at all.22:38
kergothonly specific ones do, off the top of my head linux-yocto and linux-qoriq22:39
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto22:40
kergothmost of the ones that don't can have support for them added, often via bbappend, but it depends on the recipe and how it sets up the config22:40
joel__hello kergoth. ok thanks for the info, that's good point to know :-) Yes I have used linux-yocto before and I have allready done fragment with it, it was working. Do you know what I can look for to get support of fragments ?22:42
*** igor3 <igor3!~igor@177.159.144.73> has quit IRC22:44
kergothbasically you have to add kern-tools-native to DEPENDS, then make sure merge_config.sh -m "${B}/.config" <list of fragment files in workdir> is run after defconfig is copied to .config22:45
kergoththe details vary, as there's no standard for when/where defconfig is copied to .config22:45
*** istarilucky <istarilucky!~rlucca@177.159.144.73> has left #yocto22:45
kergothdoing so from the recipe itself is usually easier than via bbappend, unless it relies on kernel.bbclass to copy defconfig to .config, otherwise you can end up with hacks like https://github.com/MentorEmbedded/meta-mentor/blob/46e62a22a61a996b04e5a0192476e241ab89cca5/meta-mel/fsl-arm/recipes-kernel/linux/linux-ls1_3.12.bbappend#L1-L1822:46
kergothsee also the busybox recipe and linux-yocto in oe-core, they both use merge_config.sh22:47
kergotherm, busybox does, anyway, i think linux-yocto uses its own tooling22:47
joel__ok looks great particularly this link22:48
joel__I was also reading http://www.yoctoproject.org/docs/1.8/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file. is it interesting for my issue ?22:48
kergoththose instructions only apply for linux-yocto, and isn't about using fragments, it's about how you use a defconfig from inside the source tree rather than from the metadata22:49
*** clsulliv1 <clsulliv1!~clsulliv@134.134.137.71> has joined #yocto22:50
*** clsulliv <clsulliv!~clsulliv@134.134.139.82> has left #yocto22:51
joel__ok22:51
kergothif the recipe is letting kernel.bbclass copy defconfig from WORKDIR to .config, then adding fragments is easier, you can just DEPENDS += "kern-tools-native"; do_configure_prepend () { cp -f ${WORKDIR}/defconfig .config; merge_config.sh -m .config ${@' '.join(s for s in src_patches(d, True) if s.endswith('cfg'))}; }22:51
kergoth(untested)22:51
kergothendswith('.cfg') is probably better than endswith('cfg'), though22:51
*** benjamirc <benjamirc!besquive@nat/intel/x-hfmnbowefswlhpez> has quit IRC22:51
joel__yes quite the same line that the one written in the bbappend you have just show me the link22:52
joel__yes agreed .cfg is probably better22:52
*** joshuagl <joshuagl!~joshuagl@192.198.151.43> has quit IRC22:52
kergoththe ${@} there just grabs the .cfg filenames from SRC_URI22:52
joel__yes22:54
kergothworth noting that linux-yocto sets ARCH for the kernel when calling merge_configs: ARCH=${ARCH} merge_config.sh -O ${B} ${config_flags} ${configs}22:54
kergothnot sure if that's needed or not, but it's a possibility22:55
kergoth(turns out it does use merge_configs, just calls scc --configs to get the fragments22:55
kergoth)22:55
joel__ok22:57
joel__all those info sounds good for me :-)22:57
kergothshould get you going the right direction, anyway :)22:57
joel__:)22:58
joel__thanks you very much for your help22:59
*** rburton <rburton!~Adium@home.burtonini.com> has quit IRC22:59
*** JaMa <JaMa!~martin@ip-89-176-104-169.net.upcbroadband.cz> has quit IRC23:00
-YoctoAutoBuilder- build #549 of nightly-rpm-non-rpm is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-rpm-non-rpm/builds/54923:03
kergothnp23:03
*** clsulliv1 <clsulliv1!~clsulliv@134.134.137.71> has quit IRC23:24
-YoctoAutoBuilder- build #876 of nightly-ipk is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-ipk/builds/87623:25
-YoctoAutoBuilder- build #921 of nightly-x86-64-lsb is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-x86-64-lsb/builds/92123:32
*** joel__ <joel__!6d1d1298@gateway/web/freenode/ip.109.29.18.152> has quit IRC23:32
*** agust <agust!~agust@p4FCB5FD5.dip0.t-ipconnect.de> has quit IRC23:34
*** nighty <nighty!~nighty@s229123.ppp.asahi-net.or.jp> has quit IRC23:34
*** bluelightning <bluelightning!paul@pdpc/supporter/professional/bluelightning> has quit IRC23:38
-YoctoAutoBuilder- build #249 of nightly-no-x11 is complete: Failure [failed BuildImages] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-no-x11/builds/24923:42
*** stephano <stephano!~stephano@134.134.139.74> has quit IRC23:46
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto23:48
-YoctoAutoBuilder- build #896 of nightly-qa-systemd is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-qa-systemd/builds/89623:49
*** sgw_ <sgw_!sgw_@nat/intel/x-znugicdxmrmufrxz> has quit IRC23:50
*** vmeson <vmeson!~rmacleod@24-212-184-107.cable.teksavvy.com> has quit IRC23:53
*** clsulliv <clsulliv!clsulliv@nat/intel/x-gggbdquunrttlbsl> has joined #yocto23:59
*** clsulliv <clsulliv!clsulliv@nat/intel/x-gggbdquunrttlbsl> has left #yocto23:59

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