Thursday, 2014-08-14

*** smartin_ <smartin_!> has quit IRC00:03
*** maxtothemax <maxtothemax!~maxtothem@> has quit IRC00:04
*** sjolley <sjolley!sjolley@nat/intel/x-wknvrlujwhvnrtrt> has quit IRC00:05
*** pidge <pidge!pidge@nat/intel/x-stayggovgbwzmita> has quit IRC00:05
*** munch <munch!> has quit IRC00:13
*** maxtothemax <maxtothemax!~maxtothem@> has joined #yocto00:14
WarheadsSEnerdboy: in hilarity, sure enough, same build root, right after that failure, turn around a build a more featured image? Wham, works. *facepalm* Go back to "problematic" one? Boom. Fail. *facedesk*00:15
kergothbetter than it succeeding when you went back to the problematic one00:17
*** fgretief <fgretief!> has quit IRC00:19
* nerdboy looks for a pillow...00:19
*** EddyLaiTW <EddyLaiTW!> has quit IRC00:23
*** sjolley <sjolley!sjolley@nat/intel/x-jpteksttpppgrjit> has joined #yocto00:47
*** Nitin <Nitin!nakamble@nat/intel/x-yfqvgclisydjvxww> has joined #yocto00:53
*** Nitin <Nitin!nakamble@nat/intel/x-yfqvgclisydjvxww> has quit IRC00:58
*** fgretief <fgretief!> has joined #yocto01:01
*** sunzun <sunzun!43357602@gateway/web/freenode/ip.> has joined #yocto01:09
*** Squix <Squix!> has joined #yocto01:18
*** flihp <flihp!> has joined #yocto01:20
*** Squix <Squix!> has quit IRC01:45
*** fgretief <fgretief!> has quit IRC01:47
*** fray <fray!> has quit IRC02:00
*** fray <fray!> has joined #yocto02:01
*** rcw <rcw!> has joined #yocto02:06
*** rcw <rcw!> has quit IRC02:21
*** LynnCyrin <LynnCyrin!~LCyrin@2607:fb90:40c:29da:5f39:896d:200:7ed0> has joined #yocto02:42
*** LCyrin <LCyrin!~LCyrin@2607:fb90:270a:b754:14c4:900c:cfab:e402> has quit IRC02:44
*** Jefro <Jefro!> has joined #yocto02:45
*** LynnCyrin <LynnCyrin!~LCyrin@2607:fb90:40c:29da:5f39:896d:200:7ed0> has quit IRC02:55
*** LCyrin <LCyrin!~LCyrin@2607:fb90:2709:33d9:c94a:ba28:c411:c836> has joined #yocto02:56
*** Jefro <Jefro!> has quit IRC02:58
*** hsychla_ <hsychla_!> has quit IRC03:04
*** Jefro <Jefro!> has joined #yocto03:09
*** armpit <armpit!~akuster@2601:c:9380:601:f465:994a:7e40:209f> has quit IRC03:17
*** armpit <armpit!~akuster@2601:c:9380:601:f465:994a:7e40:209f> has joined #yocto03:18
*** slips <slips!> has quit IRC03:34
*** fitzsim` <fitzsim`!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has joined #yocto03:48
*** alphago`` <alphago``!> has joined #yocto03:48
*** phragment_ <phragment_!> has joined #yocto03:49
*** awafaa_ <awafaa_!sid716@gateway/web/> has joined #yocto03:49
*** tobiash_ <tobiash_!> has joined #yocto03:49
*** evanp_ <evanp_!evan@nat/intel/x-zuxnwkeenqwwlvde> has joined #yocto03:49
*** ndec_ <ndec_!~ndec@linaro/ndec> has joined #yocto03:49
*** diego_ <diego_!> has joined #yocto03:50
*** diego_r <diego_r!> has quit IRC03:50
*** diego_ is now known as diego_r03:50
*** zbr <zbr!> has joined #yocto03:51
*** tf_ <tf_!> has joined #yocto03:51
*** Daemon405 <Daemon405!> has joined #yocto03:52
*** abelloni_ <abelloni_!> has joined #yocto03:52
*** ionte_ <ionte_!> has joined #yocto03:52
*** mckoan_ <mckoan_!~marco@unaffiliated/mckoan> has joined #yocto03:52
*** Anarky <Anarky!> has quit IRC03:52
*** madisox <madisox!~madisox@nat/cisco/x-xrcwfrlypytivhfr> has quit IRC03:52
*** halfhalo <halfhalo!halfhalo@nasadmin/webteam/halfhalo> has quit IRC03:52
*** zibri <zibri!> has quit IRC03:52
*** YoctoAutoBuilder <YoctoAutoBuilder!> has quit IRC03:52
*** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has quit IRC03:52
*** awafaa <awafaa!sid716@gateway/web/> has quit IRC03:52
*** tf <tf!> has quit IRC03:52
*** joeythesaint <joeythesaint!~joe@> has quit IRC03:52
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has quit IRC03:52
*** tobiash <tobiash!> has quit IRC03:52
*** mckoan|away <mckoan|away!~marco@unaffiliated/mckoan> has quit IRC03:52
*** ionte <ionte!> has quit IRC03:52
*** abelloni <abelloni!> has quit IRC03:52
*** alphago` <alphago`!> has quit IRC03:52
*** phragment <phragment!> has quit IRC03:52
*** ka6sox <ka6sox!ka6sox@nasadmin/ka6sox> has quit IRC03:52
*** ftonello <ftonello!> has quit IRC03:52
*** ndec <ndec!~ndec@linaro/ndec> has quit IRC03:52
*** evanp <evanp!evan@nat/intel/x-gkzyswoiocfitzro> has quit IRC03:52
*** YoctoAutoBuilder <YoctoAutoBuilder!> has joined #yocto03:52
*** madisox <madisox!~madisox@nat/cisco/x-cjdlyxoikogpjqrh> has joined #yocto03:52
*** Anarky <Anarky!> has joined #yocto03:53
*** awafaa_ is now known as awafaa03:53
*** halfhalo <halfhalo!halfhalo@nasadmin/webteam/halfhalo> has joined #yocto03:54
*** joeythesaint <joeythesaint!~joe@> has joined #yocto03:54
*** ka6sox <ka6sox!ka6sox@nasadmin/ka6sox> has joined #yocto03:56
*** hsychla <hsychla!> has joined #yocto04:05
*** Jefro <Jefro!> has quit IRC04:08
*** Jefro <Jefro!> has joined #yocto04:18
*** Nitin <Nitin!nakamble@nat/intel/x-fkvrnvuhvbptlqhj> has joined #yocto04:30
*** Nitin <Nitin!nakamble@nat/intel/x-fkvrnvuhvbptlqhj> has quit IRC04:35
*** [Sno] <[Sno]!~Sno]> has quit IRC04:37
*** ka6sox is now known as ka6sox-away04:54
*** ka6sox-away is now known as ka6sox04:59
*** phantomD <phantomD!> has quit IRC05:04
*** phantom <phantom!> has joined #yocto05:04
*** LynnCyrin <LynnCyrin!~LCyrin@2607:fb90:40c:7208:5689:dabd:bc93:b8e7> has joined #yocto05:08
*** LCyrin <LCyrin!~LCyrin@2607:fb90:2709:33d9:c94a:ba28:c411:c836> has quit IRC05:11
*** roric <roric!> has joined #yocto05:14
*** phantom is now known as phantoxeD05:26
*** stiandre <stiandre!~stiandre@> has joined #yocto05:30
*** agust <agust!> has joined #yocto05:30
*** ecdhe <ecdhe!> has quit IRC05:33
*** ecdhe <ecdhe!> has joined #yocto05:35
khemsgw_: what is /usr/bin/perl version ?05:40
*** kroon <kroon!> has quit IRC05:46
*** roric <roric!> has quit IRC05:56
*** florin_ <florin_!~florin@> has joined #yocto06:01
*** florin_ <florin_!~florin@> has left #yocto06:01
*** [Sno] <[Sno]!~Sno]> has joined #yocto06:02
*** gebreselaisi <gebreselaisi!~florin@> has joined #yocto06:03
gebreselaisihi everybody06:03
gebreselaisidoes anyone have an idea on how to enable the build of the qttestbrowser using the qtwebkit recipe in meta-qt?06:04
gebreselaisiseems to me the build is a production build which skips compilation of qttestbrowser06:04
*** ecdhe <ecdhe!> has quit IRC06:05
gebreselaisiTools/qmake/mkspecs/features/configure.prf already has build_testbrowser and build_qttestsupport in WEBKIT_TOOLS_CONFIG variable but that does not help06:05
*** gebreselaisi <gebreselaisi!~florin@> has quit IRC06:08
*** LCyrin <LCyrin!~LCyrin@2607:fb90:270e:fa2d:dc75:4e94:488f:3224> has joined #yocto06:08
*** ecdhe <ecdhe!> has joined #yocto06:09
*** roric <roric!> has joined #yocto06:10
*** LynnCyrin <LynnCyrin!~LCyrin@2607:fb90:40c:7208:5689:dabd:bc93:b8e7> has quit IRC06:12
*** roric <roric!> has quit IRC06:15
*** fray <fray!> has quit IRC06:20
*** fray <fray!> has joined #yocto06:22
*** ecdhe <ecdhe!> has quit IRC06:31
*** TobSnyder <TobSnyder!> has joined #yocto06:36
*** ecdhe <ecdhe!> has joined #yocto06:37
*** TobSnyder <TobSnyder!> has quit IRC06:39
*** kroon <kroon!> has joined #yocto06:39
*** ddom <ddom!> has quit IRC06:40
*** ecdhe <ecdhe!> has quit IRC06:49
*** soderstrom <soderstrom!~soderstro@> has joined #yocto06:50
*** ivanstojanovic <ivanstojanovic!> has quit IRC06:52
*** TobSnyder <TobSnyder!> has joined #yocto06:53
*** ecdhe <ecdhe!> has joined #yocto06:53
*** ecdhe <ecdhe!> has quit IRC07:02
*** silviof <silviof!~silviof@unaffiliated/silviof> has joined #yocto07:04
*** TobSnyder <TobSnyder!> has quit IRC07:07
*** ecdhe <ecdhe!> has joined #yocto07:07
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto07:11
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has joined #yocto07:12
*** jbrianceau_away is now known as jbrianceau07:13
*** roric <roric!~roric@> has joined #yocto07:16
*** EddyLaiTW <EddyLaiTW!> has joined #yocto07:18
*** elinuxer <elinuxer!~elinux1@> has joined #yocto07:21
*** roric <roric!~roric@> has quit IRC07:22
*** ant_work <ant_work!> has joined #yocto07:24
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto07:25
elinuxerhai yocto, After boot the kernel its hang up over "at91sam9x5ek login:" i couldn't login or enter the user name . How can i resolve this?07:25
*** TobSnyder <TobSnyder!> has joined #yocto07:27
*** zerus <zerus!> has joined #yocto07:31
*** TobSnyder <TobSnyder!> has quit IRC07:31
*** TobSnyder <TobSnyder!> has joined #yocto07:36
*** ddom <ddom!> has joined #yocto07:37
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC07:39
*** elmi82 <elmi82!> has joined #yocto07:47
*** belen <belen!> has joined #yocto07:50
*** roric <roric!~roric@> has joined #yocto07:50
*** roric <roric!~roric@> has quit IRC07:59
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto08:00
lpappgood morning08:00
EddyLaiTWgood afternoon08:00
*** ecdhe <ecdhe!> has quit IRC08:00
*** elmi82 <elmi82!> has quit IRC08:04
*** ecdhe <ecdhe!> has joined #yocto08:06
*** elmi82 <elmi82!> has joined #yocto08:16
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC08:16
*** tasslehoff <tasslehoff!~Tasslehof@> has joined #yocto08:19
*** Jefro <Jefro!> has quit IRC08:22
*** LocutusOfBorg1 <LocutusOfBorg1!> has quit IRC08:25
*** elmi82 <elmi82!> has quit IRC08:29
*** sameo <sameo!~samuel@> has joined #yocto08:32
*** LocutusOfBorg1 <LocutusOfBorg1!> has joined #yocto08:33
*** ddom_ <ddom_!> has joined #yocto08:39
*** lyang0 <lyang0!~lyang001@> has quit IRC08:43
*** ddom <ddom!> has quit IRC08:43
*** lyang0 <lyang0!~lyang001@> has joined #yocto08:43
*** rburton <rburton!> has quit IRC08:48
*** roric <roric!~roric@> has joined #yocto08:48
*** rburton <rburton!> has joined #yocto08:49
*** Ramos <Ramos!c058a901@gateway/web/freenode/ip.> has joined #yocto08:55
*** elmi82 <elmi82!> has joined #yocto08:55
RamosHow qemu dtb file is compiled from Yocto source?08:55
*** roric <roric!~roric@> has quit IRC08:56
*** seezer <seezer!quassel335@quassel/developer/seezer> has quit IRC08:57
*** seezer <seezer!test@quassel/developer/seezer> has joined #yocto08:59
[Sno]how can I change the deployed web-server from lighttpd to nginx (lighttpd comes with packagegroup-core-full-cmdline which is required by core-image-lsb)09:00
lpapp[Sno]: do you still need busybox ?09:00
*** qt-x <qt-x!~ionel@> has joined #yocto09:03
RamosHow dtb file is compiled from qemu recipe file?09:06
*** jimBaxter_uk <jimBaxter_uk!> has joined #yocto09:09
*** stuartw_ <stuartw_!~stuartw@> has joined #yocto09:09
[Sno]lpapp: I'd like to keep it, yes09:09
*** belen <belen!Adium@nat/intel/x-bywzgdsoroykvshh> has joined #yocto09:10
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC09:10
[Sno]lpapp: the image is there:
[Sno]likely I can do it better ;)09:13
*** rburton <rburton!> has quit IRC09:22
*** rburton <rburton!> has joined #yocto09:23
*** roric <roric!~roric@> has joined #yocto09:44
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto09:48
*** Ramos <Ramos!c058a901@gateway/web/freenode/ip.> has quit IRC09:52
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:54
*** zbr is now known as zibri10:07
*** elinuxer <elinuxer!~elinux1@> has quit IRC10:08
*** blitz00 <blitz00!stefans@nat/intel/x-ofxaxzdzwkudnapk> has joined #yocto10:42
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has joined #yocto10:42
silviof(cross from #oe) I have the problem that with a yocto/oe toolchain (created with meta-toolchain-sdk) I can not start the menuconfig for kernel configuration (after source .../environment-setup-...). I have found the problem and a solution (please read this short thread Can someone test this patch that "-c menuconfig" is still functional.10:52
*** EddyLaiTW <EddyLaiTW!> has quit IRC10:55
*** LynnCyrin <LynnCyrin!~LCyrin@2607:fb90:2701:8459:586a:a4e3:1eea:7ee9> has joined #yocto11:00
*** LCyrin <LCyrin!~LCyrin@2607:fb90:270e:fa2d:dc75:4e94:488f:3224> has quit IRC11:03
*** zerus <zerus!> has quit IRC11:04
*** elmi82 <elmi82!> has quit IRC11:06
*** manuel___ <manuel___!> has joined #yocto11:10
*** tmpsantos <tmpsantos!~tmpsantos@> has joined #yocto11:15
*** zerus <zerus!> has joined #yocto11:40
[Sno]lpapp: do you have a recommendation without busybox?11:54
*** LCyrin <LCyrin!~LCyrin@2607:fb90:40a:9692:2564:bd63:f148:2645> has joined #yocto12:00
*** LynnCyrin <LynnCyrin!~LCyrin@2607:fb90:2701:8459:586a:a4e3:1eea:7ee9> has quit IRC12:04
lpapp[Sno]: cannot you exclude it (_remove or something)?12:15
lpappit seems that my foo-git package is not rebuilt even though the git repository got new commits. Shouldn't it automatically rebuild stuff after fetching the new commits?12:15
lpappI have SRCREV = "${AUTOREV}" there.12:17
*** roric <roric!~roric@> has quit IRC12:17
JaMagdo you have SRCPV in PV?12:20
*** elmi82 <elmi82!> has joined #yocto12:27
lpappJaMa: nope12:27
lpappJaMa: is that mandatory for getting the new commits automatically?12:33
[Sno]lpapp: we recognized that it updates automatically when you include the rev in SRC_URI="git://...;rev=deadbeef"12:42
[Sno]lpapp: how should such a _remove line look like?12:42
*** roric <roric!~roric@> has joined #yocto12:42
lpapp[Sno]: but then you hard code the revision.12:43
lpapp[Sno]: I do not know the syntax, but it was added pro-dylan iirc based on _append, it is something like _exclude/remove or something.12:45
*** elmi82 <elmi82!> has quit IRC12:46
JaMalpapp: afaik yes12:52
*** tomz_ <tomz_!tomz@nat/intel/x-jwpgpypraovyayal> has quit IRC12:58
*** elmi82 <elmi82!> has joined #yocto13:00
*** LocutusOfBorg1 <LocutusOfBorg1!> has quit IRC13:02
blloydWith Fedora 20, I am seeing a lot of screen pauses.  (Typed all before this aside before seeing any on screen)  They are frequent and annoying and I don't see any CPU spikes or any logging to explain them.  Where else can I look for a culprit?13:11
*** elmi82 <elmi82!> has quit IRC13:16
*** alimon <alimon!~alimon@> has joined #yocto13:20
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC13:28
*** fitzsim` is now known as fitzsim13:32
*** oneQubit <oneQubit!~oneQubit@> has joined #yocto13:51
*** sjolley <sjolley!sjolley@nat/intel/x-jpteksttpppgrjit> has quit IRC13:57
ndec_lpapp: yes, you need to have SRCPV in PV, otherwise PV doesn't change, so you recipe is not rebuilt14:00
*** LynnCyrin <LynnCyrin!~LCyrin@2607:fb90:408:c30c:78ad:49da:d4b3:7187> has joined #yocto14:00
*** Nitin <Nitin!nakamble@nat/intel/x-rycntuvfcllcvxcv> has joined #yocto14:03
fray_ndec_ that's not -strictly- true.. the change of the SRCPV will trigger a rebuild, and with the PR service enable will cause the PR number to increment...  however without the SRCPV, it's unclear to other developers it's a SCM based recipe..14:03
fray_this PV is modified to include SRCPV so the developers know it's an SCM based recipe, and the change of the SRCPV will make it to clear to the system and developers the version has changed (without making them manage anything themselves)14:04
lpappJaMa: ndec_ ok, thanks, but I think there could be a sane default in Yocto, namely: PV = "${SRCPV}" when AUTOREV is specified.14:04
ndec_hmm. PR.. that's something i don't use ;-)14:04
*** kroon <kroon!> has quit IRC14:04
*** LCyrin <LCyrin!~LCyrin@2607:fb90:40a:9692:2564:bd63:f148:2645> has quit IRC14:04
*** ant_work <ant_work!> has quit IRC14:04
fray_Ya, when you use an autorev scheme.. it may be required.. I'm not sure14:04
*** munch <munch!> has joined #yocto14:05
fray_I do have some recipes that use SCM backends, but don't list SRCPV.. but that is because I'm pointing to specific commit that represents a release point14:05
ndec_lpapp: well, not sure what a sane default would be.. PV is rarely just SRCPV14:05
ndec_but something like 1.0+gitSRCPV14:05
fray_correct.. it's usually "basever+scmSRCPV"14:05
*** ndec_ is now known as ndec14:06
fray_and only the recipe developer knows hwat basever is..14:06
lpappndec_: then you override, done.14:06
lpappndec: but for people like me, I would not need to do anything special.14:06
JaMafray_: I think that without SRCPV in PV the do_fetch task doesn't have the AUTOREV value in signature -> isn't reexecuted when there is new change14:06
ndecPV=SRCPV would be quite bad for git where commits aren't in 'increasing' order. not sure it would be a good default14:06
fray_the default PV comes from the recipe filename..14:06
fray_so you shouldn't globally set PV=SRCPV or you'll brake that assumption..14:07
fray_JaMa, ya the AUTOREV may be unique.. I haven't explored that enought to know the edge conditions14:07
JaMandec: SRCPV should be increasing, thanks to the prefix added by PR service14:07
lpappndec: it is a good default since it does not break your picky case, yet it will work for me who could not care less about a simple name.14:07
JaMaI'm sure it was behaving like this in dylan, I think it wasn't changed since then14:07
lpappndec: 1.0+gitSRCPV is a very bad idea for _me_ because the whole point is not to maintain the version... it will break at 1.1 and 2.0...14:09
lpappor even 1.0.1 to be fair.14:09
ndecwell, i was not proposing to make my suggestion a default..14:09
JaMalpapp: then you can set it to just SRCPV if you _want_, but it shouldn't be default14:09
lpappJaMa: why not?14:10
lpappwhat does it break?14:10
JaMaversioning between builders not sharing the same PR service for example14:10
lpappcause clearly, it makes some people happy, so what breakage would it cause for others as a disadvantage?14:10
fray_if it's broken for -you- it does not mean it's broken for everyone else..14:10
fray_changing build versions causes havoc for people trying to do on-target package upgrades.. even between a 1.6 to 1.7 release time..14:11
lpappthat is irrelevant, we are talking about autorev.14:11
fray_some of the decisions made in the past don't make sense anymore -- but we're stuck with them, and they cause little issue14:11
lpappnot all the case.14:11
lpappnot to mention I have never mentioned it is broken for everyone, so I must decline that assumption.14:11
lpappJaMa: is this PR service some new thing?14:12
fray_PR service was introduced in 1.3 or 1.414:13
lpappyeah, relatively new, OK, well, I was not aware of it.14:14
lpappwhen I started reading the manuals, it was not there yet.14:14
lpappI must read upon that before I can reply.14:14
lpappwhen I was making the recipes, I was told just to remove the PR field, and everything will be alright.14:15
fray_yes, the PR server is what automatically increments them14:16
fray_uses the base PV, and PR numbers... as well as the checksum of parts of the recipe to determine if an existing PR number has been issued or if a new one is to be generated..14:16
fray_it generates them in increasing order to facilitiate on-target package upgrades14:16
*** tasslehoff <tasslehoff!~Tasslehof@> has quit IRC14:18
*** stiandre <stiandre!~stiandre@> has quit IRC14:18
*** sjolley <sjolley!~sjolley@> has joined #yocto14:19
*** [Sno] <[Sno]!~Sno]> has quit IRC14:21
lpappso what is wrong about having localhost always the PR service?14:21
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto14:24
manuel___so i have an out-of-tree kernel module, and i can bitbake it just fine. however, for iterative development, i would like to just “make” it with the toolchain, what’s the best way to do that?14:28
manuel___the kernel development manual mentions how to do it on the target, i want to do it on the host14:28
fray_one way is setup a recipe..  then use bitbake -c devshell recipe14:31
lpapp(and why is localhost:0 not the default PR service?)14:33
manuel___that will have the toolchain setup (trying out right now, taking a while)14:34
JaMalpapp: because PR service is disabled by default14:35
manuel___fray: that gives me an error about M= file not found, that doesn’t seem good (after running make)14:36
fray_I'm not sure.. if you can find Zeddii, he'd be the one to ask14:37
manuel___ah it’s missing KERNEL_SRC i guess14:37
sgw_khem: good morning, noticed you ping'ed me late last night: Perl version: v5.16.314:39
lpappJaMa: why is that?14:41
fray_for people who are NOT doing on target package upgrades, the PR service is extra overhead14:41
lpappit is only overhead for building.14:42
lpappis it non-negligible?14:42
*** Jefro <Jefro!> has joined #yocto14:43
JaMaand for people who cares about on target upgrades, they usually want to use PR service provided by their distro -> so there cannot be good default14:43
lpappI am not convinced about the constant "there is no default for the majority, so there should be none approach", but ok.14:44
lpappI will put it into our local.conf sample, thanks. (localhost:0)14:45
JaMathere is reasonable default "disabled"14:45
lpappwell, we will agree to disagree whether that is reasonable :)14:45
lpappIMHO, setting the default to localhost:0 is ok for many people, and the one who would like to have custom, they will need to provide their way either way.14:46
lpappregardless of the default, but it would help the people who are happy with localhost.14:46
lpappthe current default does not help even those people.14:46
JaMait won't help people who are happy without PR service14:47
lpappdisabling does not seem to help there either, so it is the same, no?14:47
lpappit is a bit like if we cannot help 60% (I am not convinced that a correct measure for custom anyway), we do not help 30% either.14:49
lpappanyway, for fact, this is a regression since it did use to work without enabling it explicitly. Now, we got all of this broken all of a sudden, apparently.14:51
lpappthis is regression*14:51
JaManothing is broken when PR service is disabled14:51
JaMaand it's probably more like 30% custom, 30% disabled, 30% localhost, 10% doesn't care14:52
lpappok, I think it would be better to clarify what "PR service disabled" means. What happens if I do not use PR in the recipe? Will it automatically incremented?14:52
ndecthe main issue is that this reasoning can be applied to pretty much *any* configuration. oe/yocto is a toolset to help you build/make your own distro/builds. you cannot make defaults for every config that will satisfy everyone.. better let people do their own config..14:52
JaMano it wont be automatically increamented (and it wasn't before) so it's no regression14:53
lpappI sure was told it was.14:53
lpappone of my patches was even rejected for that nitpicky reason that it had the PR in.14:53
lpappthe suggestion was "Remove it because it will be incremented automatically".14:53
lpapp(I can look up the email if you want)14:54
JaMafor poeple you're using PR service14:54
JaMano need to look it up.. I've wrote many replies like that myself14:54
lpappso the suggestion was to break the recipe for people not using PR service?14:55
lpapp(i.e. when the PR service is disabled - default)14:55
bluelightningif you're not using the PR service, you aren't the kind of person who cares if PR is incremented14:56
manuel___fray: does Zeddii hang around here?14:56
lpappbut what I am saying is the opposite: I would like to use it since it is error-prone to manually increment blabla, but I do not agree with the overhead of a custom service. I prefer KISS which means auto-increment by one here, not to force me to manually keep track of it by default.14:57
manuel___i’ve figure my thing out, i wonder if there’s a way to have the toolchain set KERNEL_SRC, i can always add it to the environment source by hand14:57
*** dv_ <dv_!> has joined #yocto14:59
*** dv__ <dv__!> has quit IRC14:59
*** LynnCyrin <LynnCyrin!~LCyrin@2607:fb90:408:c30c:78ad:49da:d4b3:7187> has quit IRC14:59
lpappso with the current system in place: I can only do this, right? echo 'PRSERV_HOST = "localhost:0"' >> ../meta-foo/conf/local.conf.sample?14:59
lpapp(based on my need above)14:59
rburtonpersonally i have that it my site.conf15:01
JaMawebos-ports and SHR have it in setup scripts (using remove PR service)15:01
lpapprburton: thanks, fair enough, I will move it there.15:02
ndecrburton: you say this, as you have 1 'site.conf' for all workspace.. is that correct? if so, how do you globablly set your site.conf?15:03
*** rcw <rcw!~rwoolley@> has joined #yocto15:03
lpappso the PR service only steps in if there is no PR specified in the recipe?15:04
lpappor it is always overriding that?15:04
rburtonlpapp: if the recipe doesn't set a PR then the default is r015:05
lpappand then r1, r2, etc?15:05
lpapp(with localhost:0, that is)15:05
rburton(see bitbake.conf)15:05
rburtonthe PR service adds a .x15:06
rburtonso you get r0.1, r0.215:06
lpappnever reaches r1?15:06
rburtonthis lets you use the PR service and explicit PRs at the same time15:06
lpappwell, it is just packaging version, isn't it?15:07
lpappPV remains the same anyway, right?15:07
lpapp(if that is correct, I could not care less what PR is)15:07
lpapp(as long as it is not the same and somehow incremented)15:07
rburtonthe PR is embedded in the package name and versioning15:07
lpappyes, but not in the software version itself.15:08
lpappgood, so yeah, thanks.15:08
rburtonthats PV and isn't touched15:08
rburtoneg i have sato-icon-theme_0.4.1-r6.1_all.ipk in my deploy/ipk15:08
lpappso you have a custom PR service?15:08
lpappor your localhost is customized?15:09
rburtonnot at all15:09
rburtonas i said, i takes the PR and adds .x15:09
lpappbut r6.1 > r0.X15:09
rburtonand sato-icon-theme has an explicit PR=r615:09
lpappI see what you mean.15:09
rburton(that was a carefully chosen example)15:10
lpappso what happens if you do not specify PR, 1,2,3,4?15:10
lpappah, no, r015:10
lpappyou said that above.15:10
*** TobSnyder <TobSnyder!> has quit IRC15:20
*** seebs <seebs!> has quit IRC15:26
*** seebs <seebs!> has joined #yocto15:28
*** dv__ <dv__!> has joined #yocto15:34
*** forcev <forcev!> has joined #yocto15:36
*** stuartw_ <stuartw_!~stuartw@> has quit IRC15:38
*** dv_ <dv_!> has quit IRC15:40
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC15:40
lpappis it a general practice that people use an ipkg folder in projects similarly to the good old "debian" for in-project packaging?15:42
lpappthat would spare us going to Yocto for every single local change.15:43
lpappI could just say make ipkg and the package is generated that I can install on the rootfs.15:43
lpappI have only done this many times with debian/ subfolder, but I wonder if some bitbake/ subfolder with the recipe and bitbake in there could also do it somehow?15:43
lpappthe alternative is to set up a local directory URL which cannot be committed to our Yocto repository for obvious reasons, etc.15:44
lpappwhereas a "bitbake/" directory could be easily committed to the project repository.15:44
*** vagrant4ever <vagrant4ever!a6821a3a@gateway/web/freenode/ip.> has joined #yocto15:46
rburtonif you wanted to drive opkg directly you'd need to write opkg-native packaging15:47
lpappcannot we get yocto generate that for us and sync?15:47
rburtonyou could15:48
rburtonpackage_ipk obviously generates it15:48
*** jbrianceau is now known as jbrianceau_away15:48
vagrant4everI am new to the yocto project. I am trying to build an image for a beaglebone with bluez5 (for low power bluetooth). I have added this to my local.conf file but the build complains that bluez4 is still included. Anything I can try to fix this?15:49
lpapprburton: ok, well, that sounds like a plan, based on my experience with debian/, it is probably not something that some other people will not follow.15:49
lpappI mean, probably some people already are doing it.15:49
rburtonlpapp: maybe, not aware of any myself15:49
*** starship <starship!~duracrisi@unaffiliated/duracrisis> has joined #yocto15:49
lpapprburton: well, it makes sense for CI, too.15:50
rburtonsurely CI should be done in yocto15:50
lpappfor interim builds, I am not sure.15:50
lpappfor release builds, sure.15:50
rburtonpeople i know that do tight hack-compile-install-test cycles tend to use the devshell or adt and copies binaries directly to the target, avoiding packages15:50
*** kkh <kkh!~duracrisi@unaffiliated/duracrisis> has quit IRC15:50
lpappthat is a very bad approach15:51
lpappit disrespects security, let alone the error prone process when you have many files to put to many places.15:51
*** ddom_ <ddom_!> has quit IRC15:51
lpappbut for some it might work for simple things.15:51
lpappI would not allow my embedded system accept unsigned random files :)15:52
sunzunhey guys. I have a question about compiling opencv with yocto. when I do bitbake opencv, it gets hung up on trying to compile the eigen library, with the following error code. I'm wondering if there is a known fix for this. Let me know if you need more info15:52
lpappalso, doing manually the packaging might be just reinventing the package, when you need more than just a binary in /usr/bin, e.g. man pages, configuration into /etc/, libraries, tools, etc.15:52
rburtonlpapp: exactly15:53
lpappsunzun: eigen is a header-only template, it is not compiled on its own15:53
lpappyou mean when it is compiled against opencv?15:53
lpapprburton: exactly which part?15:53
rburtonlpapp: reinventing all the packaging15:54
rburtonsunzun: looks like the eigen recipe hasn't been tested for ages and is broken with the "recent' (several months ago) cmake changes15:54
lpapprburton: yes, but isn't it simpler to sync the result of package_ipk to avoid the reinventing?15:54
lpappsunzun: the error report seems to be clear to me.15:54
*** sjolley <sjolley!~sjolley@> has quit IRC15:55
lpappsunzun: in-source builds are bad, so you will need to figure out why it is doing it.15:55
rburtonlpapp: its simpler to use bitbake to build the package in the first place surely.15:55
*** Jefro <Jefro!> has quit IRC15:55
lpapprburton: why? That requires Yocto knowledge for every developer, not just the system builder.15:56
sunzunlpapp: yeah, it says that you can't build in source, but I'm not quite sure where i would go to fix this. I've taken a look at the eigen recipe, and I'm not sure how to patch it to fix it, nor can I find a patch that's available15:56
lpapplike I said, eigen is a template-header, it is not built on its own15:56
lpapp(at least it was last time I checked in its core mission)15:56
lpappyou need to fix whatever is trying to use it, assuming opencv here.15:57
*** qt-x <qt-x!~ionel@> has quit IRC15:57
lpapprburton: also, how would you arrange local hack trials with Yocto? It cannot be checked into the mainline repository of our Yocto stuff15:58
*** sjolley <sjolley!~sjolley@> has joined #yocto15:58
lpapprburton: and every developer might have different local path, and I would rather leave it that way with their preference. I am not a unity purist.15:58
rburtonlpapp: not sure i understand what you mean by local hack trials15:58
lpapprburton: but if there is an ipkg folder, they just run make ipkg15:58
lpapprburton: modifying the source code locally to attempt to add a feature or fix a bug, and then would like to ship it onto the target for testing.15:58
lpapphow would you do that with Yocto that is better than make ipkg?15:59
rburtonsunzun: you should probably check that you're using the latest libeigen recipe, the commit log shows a commit in june that fixing build problems15:59
*** madisox <madisox!~madisox@nat/cisco/x-cjdlyxoikogpjqrh> has quit IRC16:00
rburtonlpapp: not even bother with a package and rsync to the target16:00
*** munch <munch!> has quit IRC16:00
lpapprburton: why not?16:01
sunzunlpapp: yeah I figure the issue is more with cmake and opencv than with eigen itself.all of the stuff I find on google regarding cmake and yocto is somewhat old, and as you mentioned, this may be a recent change that broke it16:01
*** belen <belen!Adium@nat/intel/x-bywzgdsoroykvshh> has quit IRC16:01
sunzunrburton: yeah, double checked that I am. the patch that fixed this bug perviously no longer works16:01
lpapplibeigen? :)16:01
lpappwhat is that?16:01
*** madisox <madisox!~madisox@nat/cisco/x-jqrdpspujvosskaq> has joined #yocto16:02
lpappAFAIK it does not generate any library.16:02
rburtonlpapp: that's the name of the recipe though16:02
lpapprburton: what is wrong about make ipkg (which also does the scp)?16:02
rburtonlpapp: nothing16:03
lpappgood, and how would it be better with Yocto?16:03
*** munch <munch!> has joined #yocto16:03
lpappI cannot reasonably imagine testing local stuff with yocto.16:03
*** belen <belen!Adium@nat/intel/x-secembqbncfozday> has joined #yocto16:03
sunzunthat's the recipe I'm using16:03
sunzunafaik, that's the latest version?16:03
lpappyes and no16:04
lpappthe recipe might be latest, eigen nope.16:04
rburtonsunzun: right, should have worked :/16:05
*** belen1 <belen1!Adium@nat/intel/x-eaymkcdbwqiifapj> has joined #yocto16:05
sunzunrburton: yeah, I know. it's weird that it's showing a bug that a previous patch should have fixed16:05
lpapprburton: currently, I made a foo-git package and CI (Jenkins) does not clean the workspace between runs, but it feels hackish.16:06
lpappobviously, rebuilding the whole system is too long to be an option.16:07
lpappthat is why I think life would be better with ipk/16:07
*** belen <belen!Adium@nat/intel/x-secembqbncfozday> has quit IRC16:08
sunzunlpapp: yeah, I can see that eigen is header only. but it uses cmake to install. I guess I need to change the way yocto uses cmake (basically just need to figure out how to make it "build" outside the source directory as per the error message lol). any suggestions on where to start? I'm pretty new to yocto itself16:08
*** Jefro <Jefro!> has joined #yocto16:09
lpappsunzun: your problem is build, not install.16:09
lpappsunzun: meta/classes/cmake.bbclass, maybe.16:09
sunzunhmm okay. I'll start looking into it. thanks.16:09
*** belen1 <belen1!Adium@nat/intel/x-eaymkcdbwqiifapj> has quit IRC16:09
lpappsunzun: well, first I would check the logs in temp/16:10
rburtonsunzun: the class does builds in a build/ dir by default, unless you've got a non-current cmake.bbclass16:11
rburtonsunzun: actually, do you have meta-oe master but an old oe-core?16:11
lpappso is it possible to install our SDK (core-image-minimal pretty much) and run bitbake through a recipe in the application repository?16:11
*** roric <roric!~roric@> has quit IRC16:11
sunzunlpapp: the logs are basically what I pasted. no other information.16:11
lpappand bitbake picking up the deps from the SDK?16:11
sunzunrburton: I cloned both yocto and everything else in the last two days. unless things have changed since then, it should be up to date. I'll double check though; I've already had to change a bunch of other things that were broken (and shouldn't have been), so this might be another one16:13
*** belen <belen!~Adium@> has joined #yocto16:13
lpappsunzun: heh, you are having fun, I hear you :-)16:14
rburtonsunzun: probably best to mail oe-devel, it's probably a simple fix for someone with the time to look at it (not me, in meetings right now)16:15
sunzunhey, what do you know, when I meld the current cmake.bbclass and the one i have, there are several differences. makes sense. complete sense.16:17
sunzunlpapp: you know it. :D16:17
rburtonsunzun: sounds like you've got a messed up clone?16:18
sunzunrburton: we're required to use a certain branch; sounds like the branch we're supposed to use clearly doesn't work with some stuff, but since it's the only version that works with our software, I'm just going to have to go through everything manually and fix things myself as they come up16:20
rburtonsunzun: if you want to use eg daisy of oe-core, then ensure you also use the daisy meta-oe branch16:21
rburtonsunzun: as meta-oe master depends on oe-core master16:21
sunzunrburton: hmm... you're right. I forgot to switch over the meta-oe branch since I cloned that separately16:22
sunzundoesn't fix my issue though, although it probably saved a lot of future headache16:23
kergothvagrant4ever: re: bluez4 vs bluez5, it's not very easy to switch at the moment. at mentor we switched to bluez5 by default and added bits to make it a little easier to switch, but it's not merged. a new virtual provide has to be added, and software that can support both need its deps adjusted to the virtual. it has to be done carefully, as not all software supports both. software that uses libbluetooth will work with both, as will software16:31
kergoth adjusted to work with both dbus apis, but then there's the question of how to handle the runtime dependency, so really need both a new virtual provide and a new virtual-runtime. see meta-mel in meta-mentor to see how we're handling it. I intend to submit to oe-core, but haven't gotten to it yet16:31
*** belen <belen!~Adium@> has quit IRC16:32
*** belen <belen!Adium@nat/intel/x-ykhyhlxswvgwhfvq> has joined #yocto16:33
kergothi also have a prototype private layer which replaces the internal bluetooth implementation with a no-op third party implementation, to make it easier to drop in a commercial bluetooth implementation (additional runtime virtuals coupled with carefully disabling packagegroups and excluding packages that unconditionally pull in bluez to remove the internal default implementation)16:34
kergoththat said, i'm not 100% happy with it, hence not pushing much of that stuff yet16:34
*** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto16:34
vagrant4everkergoth: thanks for the information. Being new to this build environment seems like it will be tough to switch. At this time I really only care about interacting with BLE devices. Would it be possible/smart to go with a minimalist build, add bluez5 and  only packages I will need?16:43
*** staylor <staylor!> has joined #yocto16:43
kergoththe only concern there is that bluez4 might still be pulled in via dependencies. you can certainly give that a shot, though, it'd be a reasonable starting point16:43
fray_I usually "whack" the dependency issue by blacklisting bluez4  ... that way if something requires it, I get a nice list and can try to deal with it16:44
kergothyeah, that's exactly what i did too :)16:44
fray_PNBLACKLIST[bluez4] = "We support bluez5 now."16:44
kergothblacklist is handy for that16:44
vagrant4everfray, kergoth: thanks I will give that a try.16:48
kergothwe should think about moving to bluez5 by default and making 4 an optional switch, but it might be too late to consider such a thing for this release. i really need to do a better job of working within the yocto process, but it's tough to find time, i tend to have to focus on getting crap working for mentor, and then play catch up after the release16:49
*** blloyd <blloyd!> has quit IRC16:49
*** manuel___ <manuel___!> has quit IRC16:50
*** sjolley <sjolley!~sjolley@> has quit IRC16:53
*** armpit <armpit!~akuster@2601:c:9380:601:f465:994a:7e40:209f> has quit IRC16:54
*** belen1 <belen1!Adium@nat/intel/x-jawvnnfncabdohlx> has joined #yocto16:55
*** sjolley <sjolley!sjolley@nat/intel/x-fohtbmgfokkcryck> has joined #yocto16:55
*** belen <belen!Adium@nat/intel/x-ykhyhlxswvgwhfvq> has quit IRC16:56
*** belen <belen!Adium@nat/intel/x-adogbjuqzxbhtkfj> has joined #yocto16:58
*** belen1 <belen1!Adium@nat/intel/x-jawvnnfncabdohlx> has quit IRC16:59
*** khem___ <khem___!cc0ff166@gateway/web/freenode/ip.> has joined #yocto17:03
khemkergoth: I share same pain17:07
*** belen <belen!Adium@nat/intel/x-adogbjuqzxbhtkfj> has quit IRC17:09
*** belen <belen!Adium@nat/intel/x-zxcnmmkregqkdmox> has joined #yocto17:10
*** cristianiorga <cristianiorga!~cristiani@> has quit IRC17:13
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has quit IRC17:15
*** Nitin <Nitin!nakamble@nat/intel/x-rycntuvfcllcvxcv> has quit IRC17:18
*** ddom_ <ddom_!> has joined #yocto17:22
*** Daemon405 is now known as Daemon40417:24
*** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has joined #yocto17:25
*** stiandre <stiandre!> has joined #yocto17:25
kergothman, the unexpected rebuild of everything from scratch is SO PAINFUL17:33
kergothexpect a quick build to test something, and suddenly blocked for an hour17:33
kergothwhats worse is when -S printdiff says nothing changed17:34
kergothyet everything is rebuilding from scratch anyway17:34
khem___printdiff is like a balm17:38
nerdboykergoth: pretty sure the outside world is still there...  maybe this is your chance...17:39
nerdboymake a run for the door, quick!17:39
* kergoth looks longingly toward the front window of the coffee shop17:40
kergothprintidff is great, when it actually works17:40
darknightenerdboy: no encouraging slacking!17:40
kergothwhich admittedly is usually the case, but not always17:40
darknighteunless I get to slack off too!  :)17:40
kergothi've seen builds where everything rebuilt from scratch, and the resulting sstate archives *have the exact same signatures and filenames as the ones i already had*17:40
kergothhaven't nailed that behavior down yet, though17:40
* nerdboy "blocked" by webkit17:40
nerdboytime to talk to the wife...17:41
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto17:43
lpapphas anyone successfully managed to use gdbserver here with Yocto for debugging, like ever?17:43
*** belen <belen!Adium@nat/intel/x-zxcnmmkregqkdmox> has quit IRC17:45
lpappit is such a painful territory even without Yocto, so I wonder if someone had already written a good tutorial about it.17:45
fray_I have, but not within the last few months..17:46
lpappI cannot get it work properly with Yocto, I do not know why.17:46
fray_I usually have to look up the steps when I do it17:47
lpappI wrote a script so that I can use myprogram17:48
lpappbut the script is not the point, I am just showing what I am trying17:48
lpappso basically getting the stripped binary from the image rootfs and getting the symbol file from the -dbg package's packages-split sub-directory17:48
fray_target remote is just one of many.. before that you normally configure where the -dbg symbols are.. etc..17:49
lpappon the target, I am just running gdbserver foo17:49
fray_ya, that sounds correct17:49
lpappand I have this in my ~/.gdbinit file:17:49
lpappset sysroot ./tmp/work/foo-foo-linux-gnueabi/foo-core-image/1.0-r0/rootfs/17:49
lpappI will add that sysroot step to my script later.17:49
lpappbut that is about what I am trying to do; I observe random behavior :)17:50
fray_I usually construct a special rootfs that has the debug and set it there..17:50
fray_I don't generally use the tmp/work version17:50
lpappsometimes a breakpoint is not hit even the code path is hit; sometimes it jumps forth and back in the code even though I use -O0 and -g, etc.17:50
*** pidge <pidge!pidge@nat/intel/x-wqeugevbovufkdpx> has joined #yocto17:52
lpappwell, hand-crafting a custom rootfs... I am not sure that is good... you better use the SDK then if you do not like the Yocto environment's internal rootfs.17:53
kergothHmm, do we have a bitbake argument to exit after the sstates are fetched / after the runqueue is prepared, but before the build starts?17:53
kergothi'm guessing probably not17:53
kergothwonder if that'd be worth adding, to pre-fetch your sstates without doing so manually17:53
sgw_khem___: any ideas on the eglibc issue?17:54
khem___sgw_: I tried to reproduce it on my end but did not happen17:55
khem___I was using ubuntu 12.04 for this17:55
sgw_khem___: I am on my F19 machine, let me check my 13.10 machine17:56
fray_I create a parallel 'rootfs' that only incudes the -dbg packages..  it's simple enough to do and doesn't require any special work17:57
*** Nitin <Nitin!nakamble@nat/intel/x-skjdpoycobcilfgx> has joined #yocto17:57
fray_alternatively you run the image generation twice, the second time with the pkg-dbgs enabled17:57
lpappthat is not an option17:58
seebsI sent a patch for that PREFERRED_PROVIDER problem I was having.17:58
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has quit IRC17:58
lpappthat would be quite cumbersome to switch forth and back IMO17:58
*** diego_r <diego_r!> has quit IRC17:58
lpappfor every single developer17:58
fray_it's simple..17:58
lpappsome people do not even know Yocto, and they should not.17:58
lpappthey get a ready-made rootfs17:58
fray_ require image.bb17:58
lpappwhich is non-debug17:58
fray_  IMAGE_FEATURES += "pkg-dbgs"17:58
fray_bitbake image image-dbg17:59
fray_you get two images.. one for the system and one for the debugger17:59
kergothfor the rootfs with only -dbg packages, we have pending patches to do that automatically when a var is set, in meta-mentor,
fray_otherise I just look at what I'm dbeugging and extract the -dbg packages myself17:59
lpappfray_: the process is straight-forward, but not simple17:59
* kergoth grumbles17:59
lpappit involves lots of steps, including image reflash17:59
lpappthat is very complex an environment for debugging.18:00
lpappa little program18:00
fray_you do NOT flash the target with the dbeug image, ever..18:00
fray_it's not requried18:00
fray_gdbserver and gdb (cross) will connect the dots..18:00
seebsI was assuming the debugger would run elsewhere, not on the target.18:00
lpappoh, sometimes it is required, like now18:00
lpappwhen I got fedup with gdbserver, and putting gdb onto the target.18:00
lpapp(using NFS)18:00
sgw_khem___: yup it happens on my 13.10 machine also, which has perl 5.14.218:01
lpappanyway, I will call it a bad day18:01
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC18:01
fray_kergoth, I'm all for that patch.. we've got a similar hack in our stuff to generate a -dbg only FS.. it's a pain18:01
kergothits handy either to hand to the local gdb with a remote gdbserver, or to write onto a usb stick for on-target18:02
fray_the one we wrote (1.5 time frame-ish) simply iterated over the install set and installed the dbg into a separate directory.. but it was too much of a hack to submit..18:03
fray_a python based approach for that is significantly better18:03
*** Nitin1 <Nitin1!~nakamble@> has joined #yocto18:03
*** Nitin <Nitin!nakamble@nat/intel/x-skjdpoycobcilfgx> has quit IRC18:03
* nerdboy thought the wall was chipping away, but has apparently been quickly shored up18:07
kergothdoes anyone know offhand if PATH only contains the pattern, or the entire path?18:07
kergothe.g. file://foo/.*
kergothdoes that fetch bar/foo/blah, or bar/blah?18:07
* kergoth constructs a test mirrors var and cranks up fetch debugging18:08
*** Nitin1 <Nitin1!~nakamble@> has quit IRC18:10
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC18:12
*** Nitin <Nitin!~nakamble@> has joined #yocto18:13
*** khem___ <khem___!cc0ff166@gateway/web/freenode/ip.> has quit IRC18:14
*** jimBaxter_uk <jimBaxter_uk!> has quit IRC18:22
*** [Sno] <[Sno]!~Sno]> has joined #yocto18:24
*** jimBaxter_uk <jimBaxter_uk!> has joined #yocto18:25
*** alimon <alimon!~alimon@> has quit IRC18:26
sgw_khem: I can easily reproduce it with the conf command that gets run during the config process KCONFIG=<config> <sysroot path>/usr/bin/conf --oldaskconfig option-groups.def18:30
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto18:32
kergothhah. create a build dir called `build-PATH`, then add a file://${TOPDIR}/ path to MIRRORS. prepare to be amused18:42
kergothwe should have had some sort of token marker for those replacements, ${} or %{} or something :)18:42
kergothgah, the verbosity of a -DDD build is still absolutely insane. forgot how bad that was :)18:45
*** belen <belen!> has joined #yocto18:45
*** flihp <flihp!> has quit IRC18:46
mranostayhi kergoth18:49
kergothhey mranostay18:50
mranostaykergoth: how are the bits baking?18:51
nerdboyspilling on the floor, sounds like...18:53
*** kkh <kkh!~duracrisi@unaffiliated/duracrisis> has joined #yocto18:54
kergotharguing with bitbake again :)18:55
kergothmostly losing18:55
*** starship <starship!~duracrisi@unaffiliated/duracrisis> has quit IRC18:58
*** JYDawg <JYDawg!> has quit IRC18:58
*** JYDawg <JYDawg!> has joined #yocto18:59
darknightehmm, anyone know what the status of Qt5 on i.MX6 is on Daisy?19:12
*** smartin_ <smartin_!> has joined #yocto19:22
nerdboyokay, what exactly is the relationship between poky/meta and oe-core/meta ?19:24
nerdboythey're almost identical (but not quite)19:24
nerdboyare they manually synced at some interval?19:24
nerdboyother than the *.conf.sample files in oe-core the only differences i see are mine19:28
nerdboyyet the other day there was difference (upstream) in a bbclass file...19:28
JaManerdboy: poky/meta is created with combo-layer tool19:28
nerdboyfrom oe-core and other stuff?19:28
nerdboythat last difference is still confusing me...  just a commit timing thing?19:29
nerdboyJaMa: how often does that happen and get committed to the poky repo?19:30
JaMadon't know19:31
kergothat least in the past, there were local changes that hadn't yet gone into bitbake/oe-core, despite the use of combo-layer, but hopefully that's not the case anymore :)19:31
nerdboyi guess i'll know when bleeding-edge gstreamer shows up in poky?19:31
nerdboythat sounds like the other direction...19:32
nerdboyit goes both ways?19:32
JaMacombo-layer allows to split patches, but I think that it's used only one-way19:33
nerdboyi'm assuming this isn't documented anywhere yet?19:33
darknighteJaMa: you know what the status of Qt5(via directFB) support  on i.MX6 on the daisy release is?19:34
JaMaOE @ ~/extras/poky $ diff -rq meta ~/openembedded-core/meta19:35
JaMaOnly in /OE/openembedded-core/meta/conf: bblayers.conf.sample19:35
JaMaOnly in /OE/openembedded-core/meta/conf: local.conf.sample19:35
JaMaOnly in /OE/openembedded-core/meta/conf: local.conf.sample.extended19:35
JaMaOnly in /OE/openembedded-core/meta/conf: site.conf.sample19:35
JaMaI don't see any other difference19:36
JaMadarknighte: no idea19:36
nerdboyyup, pulled on master again and got the new gstreamer stuff19:36
nerdboywasn't there when it broke latest (upstream) rpi updates19:36
nerdboytiming is everything, apparently...19:37
darknighteJaMa: rats. thx anyway19:37
JaMaRP: is there some reason why conf.sample files are in poky only in ./meta-yocto/conf/?19:37
JaMalocal.conf.sample.extended site.conf.sample are identical, bblayers.conf.sample local.conf.sample are a bit different19:39
*** forcev <forcev!> has quit IRC19:41
*** kkh <kkh!~duracrisi@unaffiliated/duracrisis> has quit IRC19:43
*** kkh <kkh!~duracrisi@unaffiliated/duracrisis> has joined #yocto19:43
*** blloyd <blloyd!> has joined #yocto19:45
*** rcw <rcw!~rwoolley@> has quit IRC19:46
*** rcw <rcw!~rwoolley@> has joined #yocto19:47
*** smartin <smartin!~smartin@> has quit IRC19:48
*** smartin <smartin!~smartin@> has joined #yocto19:52
*** rburton <rburton!> has quit IRC19:52
*** rburton <rburton!> has joined #yocto19:53
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has left #yocto19:59
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto19:59
blloydanyone know why gdb would be compiled with --with-ncurses and --disable-tui?  Seems funny because I thought it only used ncurses for tui mode.20:00
*** stiandre <stiandre!> has quit IRC20:00
khemsgw_: Does it happen with poky-tiny config or normal poky config for you20:01
khemJaMa: meta-yocto actually is the poky distro layer20:03
Crofton|workmv meta-yocto meta-poky to increase clarity20:04
khemI asked for it during ELC 201120:04
kergoththatd be nice, would definitely reduce confusion20:05
khemI agree, but the fact that poky uses combo-layer makes it a bit different setup then others do e.g. others use layers as they are and add a setup layer and a distro layer to form the complete set20:07
khemso meta-yocto kind of looses the significance of being a distro layer there20:07
khemthis is a different approach but some folks want it this way20:08
khemwhere all metadata is under single git repo20:08
*** belen <belen!> has quit IRC20:09
kergothmeh, I'd like to leverage the internal setup scripts more, rather than rolling our own so much, but the core ones are still rather limited20:11
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto20:14
JaMakhem: yes, but that doesn't explain why their were removed from meta subdirectory (unless something requires them to be uniq)20:26
*** rburton <rburton!> has quit IRC20:28
*** rburton <rburton!> has joined #yocto20:29
*** flihp <flihp!~flihp@> has joined #yocto20:35
*** rburton <rburton!> has quit IRC20:40
*** rburton <rburton!> has joined #yocto20:41
nerdboymaybe a "repo" repo/manifest instead20:42
nerdboyie, one for poky (sans hand-made layer tool), one for oe-core, etc20:43
nerdboyplus document using them20:43
*** ant__ <ant__!> has joined #yocto20:44
nerdboysome (non-core) setups already do that...20:44
nerdboybut yeah, i thought the main difference/intent of poky repo was to provide yocto-bsp, poky/meta, demo images, etc, all in one repo20:46
sgw_khem: normal configuration multiple build machines and different MACHINE settings (arm/x86)20:47
nerdboyoh, and yocto reference kernel and default machine support for a handful of machines20:47
lpappgood morning20:55
*** rcw <rcw!~rwoolley@> has quit IRC21:06
*** ant_home <ant_home!> has joined #yocto21:11
*** ant__ <ant__!> has quit IRC21:14
*** jkridner|work is now known as jkridner21:14
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto21:14
*** ddom_ <ddom_!> has quit IRC21:14
*** ddom_ <ddom_!> has joined #yocto21:15
*** theguy <theguy!> has joined #yocto21:16
theguyHey everybody21:16
theguyCan anyone help me with a udev issue?21:17
*** rburton <rburton!> has quit IRC21:17
*** rburton <rburton!> has joined #yocto21:18
sgw_theguy: depends on what it is21:18
lpapptheguy: what issue21:19
khemsgw_: hmm ok. I will try to reproduce it with OE-Core tonight21:19
*** sjolley <sjolley!sjolley@nat/intel/x-fohtbmgfokkcryck> has quit IRC21:19
nerdboyudev problem as in installing your own custom rule perhaps?21:21
*** ddom_ <ddom_!> has quit IRC21:21
*** ddom_ <ddom_!> has joined #yocto21:21
sgw_khem: Ok, I will be back around after 8 - 9ish or so tonight.21:22
RPJaMa: they got filtered out mainly to reduce confusion21:22
RPand yes, that layer should have been called meta-poky21:22
RPI still sometimes wonder about changing the name21:22
*** sjolley <sjolley!sjolley@nat/intel/x-jyuolqdihloucavb> has joined #yocto21:23
*** ddom_ <ddom_!> has quit IRC21:24
khemRP: master-next is missing 1 gcc patch21:24
khemfrom me21:24
*** sameo <sameo!~samuel@> has quit IRC21:25
khem and
*** LocutusOfBorg1 <LocutusOfBorg1!> has joined #yocto21:29
*** vagrant4ever <vagrant4ever!a6821a3a@gateway/web/freenode/ip.> has quit IRC21:29
RPkhem: I was waiting for Peter to rebase them21:30
*** smartin_ <smartin_!> has quit IRC21:30
*** LocutusOfBorg1 <LocutusOfBorg1!> has quit IRC21:33
hbruceNew to Yocto. Using daisy release, but meta-java doesn't have daisy branch. Should i take dora or master?21:34
khemhe did I think21:35
khemhbruce: master21:35
RPkhem: right, but not when I last built -next ;-)21:36
RPkhem: I'm updating21:36
*** jmpdelos__ <jmpdelos__!> has joined #yocto21:37
*** jmdelos_ <jmdelos_!> has quit IRC21:37
*** ftonello <ftonello!> has joined #yocto21:39
khemRP: ok here is the rebased versions on top of master-next
*** flihp <flihp!~flihp@> has quit IRC21:40
theguyActually no, udev problem where my drive does not disappear from /dev when I remove it21:40
nerdboyis there something in fstab?21:41
nerdboyrelated to whatever the device is...21:41
nerdboyso you get something like a stale /dev/sdb,/dev/sdb1 ?21:43
theguyNothing in fstab21:43
nerdboyi have seen that lately, but on my desktop after a usb bus hiccup21:43
theguyAnd exactly.  It's /dev/sda and /dev/sda121:43
nerdboy3.13.6 gentoo-sources and <urp> udev-212-r121:45
theguyIt works fine for a while, then suddenly after a reboot /dev/sda is there when it shouldn't be21:45
nerdboyreboot with device still inserted?21:45
theguyI'm running 3.0.3521:45
theguywith the freescale 4.0.0 bsp21:45
theguyIf I insert and remove the drive, udev still detects it and mounts/unmounts it automatically21:46
theguyBut it just doesn't remove /dev/sda anymore21:47
nerdboybeen using 3.15/patched mainline and bleeding-edge u-boot on wand/udoo21:47
nerdboytheguy: you mean with the stale /dev file there?21:47
theguyYeah. The file /dev/sda stays whether the drive is inserted or not, but udev seems happy and it mounts/unmounts correctly21:48
nerdboythen it detects/mounts as sdb if sda is stale...  at least it should...21:48
theguyIt still gets used as /dev/sda21:48
nerdboynot with (systend) udev...21:49
theguyYeah it's weird.  I've seen it on my desktop before where it will increment the letter if one goes stale, but in this case it keeps using /dev/sda. It's just that the file doesn't go away when the drive is removed.21:49
nerdboyoe uses 18x-something i belivee21:49
theguyudev version?21:50
nerdboyas opposed to 20x21:50
nerdboywell, 212 on my desktop and it's behind...21:50
theguyOh yeah - 182-r721:50
nerdboypretty sure that's still udev source before it "merged" with systemd21:51
nerdboynot to say the behavior doesn't change like my underwear...21:51
theguyMy system doesn't use systemd, so I assume it would have to be before that?21:51
theguyIs there a forum or chat room that might have a lot of knowledge on udev?  If I could figure out exactly where udev creates/deletes that file I could try and debug it21:52
nerdboymy gentoo builds leave out systemd as well (just openrc stuff is fine) but udev has been assimilated afaik21:54
nerdboythe rules are on your system21:54
hbrucekhem: Thx. Using meta-java master but getting build errors in xerces-j-native. Anyone seen this?21:54
khemRP: I have consolidated Peter's and mine patches on top of master here
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC21:55
theguyI don't think it's an issue with the rules. It works fine for a while and then stops working randomly until I recreate my rootfs21:56
theguyAs far as I can tell the creation of /dev/sdx is built into udev as well21:56
nerdboyit should be in the default rules21:57
nerdboyuse opkg/rpm/apt to list the rule files21:57
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto21:57
khemhbruce: what errors ?21:58
nerdboyso you're plugging in a device, unmounting, change partitions, mkfs and remount?21:58
theguyOh, how do I do that? I've looked through the rule files in /etc/udev/rules.d but I don't see anything about creating /dev/sdx files21:58
theguyWhen it breaks? All I do is reboot a few times with the drive inserted.21:59
*** Nitin1 <Nitin1!~nakamble@> has joined #yocto21:59
nerdboyopkg list-installed | grep udev (for package names)21:59
theguyAlthough it seems to happen after I do a "system update" by copying a duplicate root filesystem from a USB drive onto my device22:00
nerdboyopkg files udev (to list files in a package)22:00
nerdboythere's another place for rules22:00
nerdboylook in /lib/udev/rules.d/22:00
*** bfederau <bfederau!> has quit IRC22:01
khemRP: current master-next which you rebased few min ago is still missing one patch
*** bfederau <bfederau!> has joined #yocto22:01
nerdboythat's for opkg packages anyway...22:01
theguyI have dpkg, I'll look up the command22:01
theguyI'll take a look through there thanks22:02
*** Nitin <Nitin!~nakamble@> has quit IRC22:03
theguyAs far as I can tell, the rules files don't change between when it works and when it doesn't22:03
*** Nitin1 <Nitin1!~nakamble@> has quit IRC22:04
theguyAlthough I should verify that22:05
nerdboyto be safe, if you change the partition table you should remove/reinsert the device or run partprobe22:05
nerdboythe rules files don't change on their own...22:05
nerdboythe stale device file is an artifact of udev not handling something very well22:05
nerdboysomething you're doing/not doing is my guess, or the device/reader is flakey22:06
theguyThe partition table is never changed.  I do mount/unmount the drive and read data from it.  At some point, I copy a duplicate root filesystem from the USB drive over top of my root filesystem and then reboot.  It seems to work until another one or two reboots after that.22:07
theguyI have an application running that monitors /dev/sda... I wonder if that is somehow preventing it from being deleted.22:07
nerdboymaybe sync after untar and see if that helps22:07
theguyI'll give that try thanks22:08
nerdboyor might be flakey hardware/driver getting saturated during heavy i/o and taking a dump22:08
theguyIt could be.  Once it22:08
theguyOnce it's broken though, the file /dev/sda is created on boot whether the drive is inserted or not.  And the continues until I re-flash the root filesystem.  Even if I delete the file manually and reboot it returns.22:09
nerdboyit's stale so it's a real file there when udev starts (which it sees and won't create the device)22:10
theguyI delete it and reboot, without ever inserting the drive, it gets created on boot again22:11
nerdboyyou could wipe /dev on boot/reboot but you'd need to provide/create /dev/{console,null,zero} at a minimum22:11
RPkhem: thanks, added22:11
nerdboybut it guarantee clean /dev startup22:11
theguyOh would I have to wipe all of /dev instead of just the one file?22:11
theguyOk I'll give that a try22:12
khemRP: cool. so once this goes into master, I will be able to announce availability of meta-musl
nerdboyjust the stale ones, although the problem might just make new stale ones...22:12
theguyThat's what happens.  If I delete the stale file /dev/sda and then reboot, it gets created again. Even if I never inserted the drive.22:13
nerdboynow *that* sounds really weird...22:13
nerdboydoes your build have a default device tarball?22:14
RPkhem: there is quite a queue in master-next so its going to need an autobuilder run and so on22:14
nerdboyrpi boots off /dev/mmcblk0 so i have no sda unless i plug something else in22:14
theguySame with me.  Boot is from /dev/mmcblk0 and /dev/sda is only created when I plug in a USB drive22:15
nerdboyif you have a /dev/sda with no physical device then something else is going on22:15
nerdboyassuming this is accurate/correct: <theguy> That's what happens.  If I delete the stale file /dev/sda and then reboot, it gets created again. Even if I never inserted the drive.22:16
hbrucekmem: Java build error src/org/apache/html/dom/ (at line 28)22:16
khemRP: yes, true22:16
nerdboythat should not happen with a default udev setup22:16
theguyYep that's what happens.  USB drive is /dev/sda, but after a few reboots that file starts to appear even when the drive isn't inserted.22:17
hbrucekhem: sorry got your handle wrong22:17
khemRP: I am going to work on glibc 2.20 now as a part of that I am planning on renaming eglibc recipes to be called glibc22:17
theguySo my application thinks a USB drive is inserted when it actually isn't.22:17
nerdboyminimal static devices are the three above, whether they get plopped there by initramfs or they're just static22:17
khemhbruce: thats ok you can use ashmem too :) I do android too22:18
khemhbruce: pastebin the full build log somewhere22:18
theguyI never make /dev/sda static. At some point it starts getting created on boot.  If I delete it and reboot it comes back again.22:18
theguySo I'd like to figure out what's placing it there on boot.22:18
khemRP: that reminds me of glibc -> eglibc transition now in reverse order22:18
nerdboy"after a few reboots" meaning the device was plugged in at least once and later you get a stale (normal) device/partition file in dev22:19
khemsince we did not remove glibc provides I am hoping this to be simpler22:19
RPkhem: yes, lets hope so. Did we get anywhere with configuration of glibc?22:19
theguyYep. After the device has been plugged in a few times, and the board is rebooted a few times, that file starts showing up even when it shouldn't.22:19
khemupstreaming ?22:19
RPkhem: yes22:19
nerdboycan you make it happen while you watch dmesg?22:20
khemnowhere yet I am thinking bring the port to 2.20 will help in that22:20
RPkhem: ok22:20
nerdboyseem like there should be a udev log entry that at least smells funny...22:20
khemso end of this month if all is ok I will propose it for 2.2122:20
theguyI've looked through the logs when it's working properly and when it isn't, but I can't seem to find any differences22:21
khemRP: after I have had good results with 2.20 on master that is22:21
theguyIt's a weird issue. I've been working on it for a few days now22:21
theguyI'll look a bit more closely at my application - maybe it's creating the file somehow by accident.22:22
nerdboywhat usb hardware/drivers?  using usb-gadget? otg? other?22:22
RPkhem: sounds good22:23
nerdboytheguy: strace your app22:23
nerdboyshould be clear whether it does or not22:23
theguyIt's an i.MX6, the freescale bsp supplied the drivers.  I believe it's a USB host but I'd have to double check.22:24
*** munch <munch!> has quit IRC22:24
nerdboysounds normal enough, notwithstanding you could've found an actual bug22:25
theguyActually once the problem starts, even if I never run the app, the file still appears on boot. Although the app could be starting the problem in the first place22:25
hbrucekhem: Build output at
theguyI wonder! It feels like a bug, but there are many times where I think it's a bug and it turns out to be my code :/22:26
nerdboyif it's a stale file it will always be there unless /dev is mounted volatile22:26
theguyWould udev give an error if it couldn't remove the file when the drive was removed?22:26
nerdboybug in your code/upstream bug, bug is abug...22:26
nerdboyit should in theory22:27
nerdboynot sure how quiet you can make it22:28
theguyDo you know where I could look for that error? I've looked in /var/log/messages after setting the log priority to info but I see no mention of /dev/sda at all22:28
theguyOh sorry that's not true. I see mention of it but nothing to say when it is created/deleted22:28
nerdboycan you determine for sure if it's just a stale file created once and subsequently ignored bu udev?22:28
theguyIf I do a "rm /dev/sda", it goes away. udev then works properly until I reboot, at which point /dev/sda magically appears again22:29
nerdboyyou should see the usual udev/usb device messages in dmesg and the kernel log22:30
nerdboyit should not magically reappear on its own22:30
nerdboysomeone is putting it there, and that's not "typical" udev behavior22:30
theguyI'll try and break it again and then look at the kernel logs after a reboot22:31
theguyYeah. I just can't figure out what's putting it there22:31
theguyJust doing an update now, which should break it.  And then I'll see if the logs mention it on reboot.22:32
nerdboyokay, not that i've had a reason to look before, but the default is empty /dev dir is empty when not in a running system22:35
*** Nitin <Nitin!~nakamble@> has joined #yocto22:35
nerdboyeverybody's different...22:35
*** zerus <zerus!> has quit IRC22:36
*** rburton <rburton!> has quit IRC22:36
theguyOk I broke it again. I'll take a look at the log files.22:37
*** rburton <rburton!> has joined #yocto22:38
theguySo dmesg | grep sda shows nothing, but the file is there22:39
theguyI'll rm /dev/sda and reboot22:39
theguyAfter reboot, /dev/sda is back.  The drive is not inserted.22:40
theguyI can't find anything that would be creating that file22:42
nerdboywhat gets it back to normal?  cold boot?22:45
theguyCold boot doesn't work.  I end up reflashing the SD card from scratch with a fresh root filesystem22:46
*** rburton <rburton!> has quit IRC22:47
*** rburton <rburton!> has joined #yocto22:48
*** PMC-Sierra <PMC-Sierra!d144a0f1@gateway/web/freenode/ip.> has joined #yocto22:48
nerdboysync didn't help?22:48
nerdboyare you preserving the proper permissions on what comes out of the tarball?22:49
theguyShould I do a sync after removing /dev/sda?22:49
nerdboywhen sync returns everything is flushed22:50
theguyOk, so I'll do sync, then rm /dev/sda, then reboot22:50
nerdboyso if it still pukes that would eliminate incomplete writes to the card22:50
theguyAlright one sec22:51
theguyLooks like the file still gets created on boot22:51
theguynerdboy thanks a lot for the help. I've got to head off now.22:53
theguyBut you've given me a bunch of things to look at so I'll investigate them further.22:53
nerdboydon't forget to report back...22:54
theguyWill do!  I'm back tomorrow so I'll sign in here and give you an update22:54
theguyReally appreciate it! Cheers22:55
*** theguy <theguy!> has quit IRC22:55
*** rburton <rburton!> has quit IRC22:56
*** rburton <rburton!> has joined #yocto22:57
* nerdboy kinda feels like the sales guy who sends people across the street for a better deal22:58
*** PMC-Sierra <PMC-Sierra!d144a0f1@gateway/web/freenode/ip.> has quit IRC23:00
*** agust <agust!> has quit IRC23:02
*** ant_home <ant_home!> has quit IRC23:03
*** staylor <staylor!> has quit IRC23:04
nerdboyprobably why i'm not a sales guy...23:05
-YoctoAutoBuilder- build #206 of nightly-intel-gpl is complete: Failure [failed BuildImages BuildImages_1] Build details are at
*** seebs <seebs!> has quit IRC23:30
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC23:32
*** jkridner <jkridner!> has joined #yocto23:33
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto23:33
-YoctoAutoBuilder- build #204 of nightly-non-gpl3 is complete: Failure [failed BuildImages] Build details are at
-YoctoAutoBuilder- build #199 of poky-tiny is complete: Failure [failed BuildImages] Build details are at
-YoctoAutoBuilder- build #203 of nightly-fsl-ppc-lsb is complete: Failure [failed BuildImages] Build details are at
*** seebs <seebs!> has joined #yocto23:52

Generated by 2.11.0 by Marius Gedminas - find it at!