Thursday, 2015-04-23

*** egavin <egavin!> has quit IRC00:04
*** miandonmenmian <miandonmenmian!~miandonme@> has quit IRC00:07
*** miandonmenmian <miandonmenmian!~miandonme@> has joined #yocto00:09
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC00:10
*** egavin <egavin!> has joined #yocto00:11
*** behanw <behanw!~behanw@> has quit IRC00:30
*** nicktick <nicktick!~john@unaffiliated/nicktick> has joined #yocto00:32
*** paulg_ <paulg_!> has quit IRC00:57
*** sjolley <sjolley!~sjolley@> has joined #yocto00:58
*** smartin <smartin!> has quit IRC01:16
*** neur0Fuzzy <neur0Fuzzy!> has joined #yocto01:20
*** smartin <smartin!> has joined #yocto01:22
*** lyang0 <lyang0!~lyang001@> has quit IRC01:23
*** lyang0 <lyang0!~lyang001@> has joined #yocto01:27
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC01:30
*** neur0Fuzzy <neur0Fuzzy!> has quit IRC01:30
*** _jmleo <_jmleo!> has quit IRC01:34
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto01:34
*** jmleo <jmleo!> has joined #yocto01:34
*** roxell_ <roxell_!> has joined #yocto01:36
*** roxell <roxell!~roxell@linaro/roxell> has quit IRC01:36
*** geheimnis` <geheimnis`!~geheimnis@> has quit IRC02:07
*** behanw <behanw!~behanw@> has joined #yocto02:25
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC02:48
*** hsychla <hsychla!> has quit IRC03:04
*** hsychla <hsychla!> has joined #yocto03:14
*** miandonmenmian <miandonmenmian!~miandonme@> has quit IRC03:16
*** miandonmenmian <miandonmenmian!~miandonme@> has joined #yocto03:27
*** miandonmenmian <miandonmenmian!~miandonme@> has quit IRC03:33
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto03:35
*** miandonmenmian <miandonmenmian!~miandonme@> has joined #yocto03:51
*** hamis <hamis!~irfan@> has joined #yocto03:56
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC04:00
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto04:01
*** dmoseley <dmoseley!> has quit IRC04:06
*** dmoseley <dmoseley!> has joined #yocto04:06
*** miandonmenmian <miandonmenmian!~miandonme@> has quit IRC04:25
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto04:28
*** miandonmenmian <miandonmenmian!~miandonme@> has joined #yocto04:30
*** jaeckel <jaeckel!~jaeckel@unaffiliated/jaeckel> has quit IRC04:30
*** Crofton|work <Crofton|work!> has quit IRC04:55
*** Crofton <Crofton!> has quit IRC04:56
*** Crofton|work <Crofton|work!> has joined #yocto05:08
*** varibull <varibull!> has quit IRC05:09
*** varibull <varibull!> has joined #yocto05:09
*** agust <agust!> has joined #yocto05:11
*** dmoseley1 <dmoseley1!> has joined #yocto05:20
*** dmoseley <dmoseley!> has quit IRC05:21
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC05:22
*** e8johan <e8johan!> has joined #yocto05:26
*** AndersD <AndersD!~anders@> has joined #yocto05:29
*** blueness <blueness!> has joined #yocto05:34
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto05:34
*** SorenHolm <SorenHolm!> has joined #yocto05:38
*** ntl <ntl!> has quit IRC05:42
*** SorenHolm <SorenHolm!> has quit IRC05:44
*** AndersD <AndersD!~anders@> has quit IRC05:46
*** ntl <ntl!> has joined #yocto05:55
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC06:07
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto06:07
*** hsychla <hsychla!> has quit IRC06:10
*** behanw <behanw!~behanw@> has quit IRC06:12
*** miandonmenmian <miandonmenmian!~miandonme@> has quit IRC06:24
*** wadim_ <wadim_!> has joined #yocto06:24
*** SorenHolm <SorenHolm!~quassel@> has joined #yocto06:33
*** jku <jku!jku@nat/intel/x-exahskvriylzaqra> has joined #yocto06:44
*** TobSnyder <TobSnyder!> has joined #yocto06:48
*** hsychla <hsychla!> has joined #yocto06:48
*** vmeson <vmeson!> has quit IRC06:50
*** vmeson <vmeson!> has joined #yocto06:51
*** ant_work <ant_work!> has joined #yocto06:54
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto06:56
*** hsychla <hsychla!> has quit IRC07:00
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has joined #yocto07:04
*** jbrianceau_away is now known as jbrianceau07:04
*** diego_r <diego_r!> has joined #yocto07:09
*** Luming <Luming!luyu@nat/intel/x-aixrvwzyqsxvhwuc> has quit IRC07:15
*** Luming <Luming!luyu@nat/intel/x-pmfuwiconblnhcks> has joined #yocto07:15
*** Crofton|work <Crofton|work!> has quit IRC07:30
*** hsychla <hsychla!> has joined #yocto07:41
*** Crofton|work <Crofton|work!~balister@> has joined #yocto07:43
*** hitlin37 <hitlin37!uid16371@gateway/web/> has joined #yocto07:49
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC07:58
*** ntl <ntl!> has quit IRC08:09
*** florian_kc is now known as florian08:11
*** ntl <ntl!> has joined #yocto08:22
*** hundeboll <hundeboll!> has quit IRC08:37
*** hundeboll <hundeboll!> has joined #yocto08:39
*** bluelightning <bluelightning!~paul@> has joined #yocto08:39
*** bluelightning <bluelightning!~paul@> has quit IRC08:39
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:39
*** nighty-_ <nighty-_!> has joined #yocto08:44
*** tasslehoff <tasslehoff!~Tasslehof@> has joined #yocto08:48
*** belen <belen!Adium@nat/intel/x-xkehjoelvsagxmss> has joined #yocto08:52
bluelightningmorning all08:58
*** wv <wv!> has joined #yocto09:00
wvHello, how can I make sure everything gstreamer1.0-related is build in stead of gstreamer0.10?09:01
*** ah <ah!> has joined #yocto09:04
*** tsramos <tsramos!tsramos@nat/intel/x-mgaaxrnbixxjmvrz> has joined #yocto09:12
*** nicktick <nicktick!~john@unaffiliated/nicktick> has quit IRC09:15
*** jimBaxter <jimBaxter!> has joined #yocto09:15
chankitwv: you mean built as in just generating the package or including it inside the image?09:16
wvwell, I have this a recipe for an image09:21
wvand as I remember it correct (it has been build a while ago) It said something like:09:21
wvgstreamer0.10 build because it was requested later then gstreamer1.0 ...09:22
wvsomething like that09:22
wvdon't know which package requires this gstreamer0.1009:22
wvbut I prefer all gstreamer1.0 related packages though...09:22
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC09:27
*** tsramos <tsramos!tsramos@nat/intel/x-mgaaxrnbixxjmvrz> has quit IRC09:29
*** tsramos <tsramos!tsramos@nat/intel/x-piccxcgwuwwryxmy> has joined #yocto09:29
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto09:32
lpappgood morning09:32
*** belen1 <belen1!~Adium@> has joined #yocto09:32
*** belen <belen!Adium@nat/intel/x-xkehjoelvsagxmss> has quit IRC09:32
lpappbluelightning: why do I have kernel_3.2.1-r16_foo.ipk as well as kernel-3.2.1-r16_3.2.1-r16_foo.ipk? What is the difference?09:33
*** tsramos <tsramos!tsramos@nat/intel/x-piccxcgwuwwryxmy> has quit IRC09:34
bluelightninglpapp: I'm not sure09:34
*** belen1 <belen1!~Adium@> has quit IRC09:35
bluelightningthat looks like something went wrong with the naming09:35
*** jaeckel <jaeckel!~jaeckel@unaffiliated/jaeckel> has joined #yocto09:35
lpapppossibly, yeah, one is emptier than the other.09:35
lpappbluelightning: perhaps this is because the naming changed between dylan and daisy?09:36
lpappit is not in the migration guide, so I would need to compare the line defining the pattern both in dylan and daisy09:41
lpapphmm, does not seem to have changed.09:46
*** kanupatar <kanupatar!79f4c042@gateway/web/freenode/ip.> has joined #yocto09:47
kanupatarhi guys09:47
*** vdehors <vdehors!> has joined #yocto09:48
kanupatarhi guys, can anybody point me the u-boot,kernel and fs version coming with following releases? dylan,dora,daisy,dizzy,fido of yocto?09:48
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:50
LetoThe2ndkanupatar: as this is highly dependent on the platform you are actually interested in, there's little use in naming numbers....09:52
kanupatarI am havin arm arch for R-Car H2 board09:52
kanupatarit is from Renesas09:52
LetoThe2ndkanupatar: then look at the layer of the board that you use, and which revisions it uses for the releases.09:53
LetoThe2ndkanupatar: the versions are usually defined by the board support package, not be the yocto release.09:53
kanupatarLetoThe2nd: where can I see the releases?09:53
kanupatarLetoThe2nd: sorry, where can I see man?09:54
LetoThe2ndkanupatar: look into the board support package, and its recipes. like its recipes-bsp and recipes-kernel directories.09:54
kanupatarLetoThe2nd: I am planning to dump all versions for my board09:55
kanupatarthis is for fast boot analysis09:55
kanupatarLetoThe2nd: I need to download all versions right?09:55
LetoThe2ndkanupatar: whatever, the answer is still the same over and over again: look into the board support package that you use.09:55
kanupatarto check the folder?09:55
kanupatarLetoThe2nd: May I know the revisions of yocto releases?09:56
LetoThe2ndnaming versions of kernel/u-boot is totally pointless, so i just won't do it.09:56
kanupatarLetoThe2nd: okay.09:57
kanupatarLetoThe2nd: so, I need to download all releases from dylan09:57
kanupatarLetoThe2nd: any links for that?09:57
LetoThe2ndno, you need to look at your board support package09:57
LetoThe2ndthis is in absolutely no way related to whats in the packages provided by the yocto project09:58
LetoThe2ndif you don't have the BSP, contact your vendor and/or documentation on how to get it09:58
kanupatarLetoThe2nd: bsp comes in yocto?09:59
LetoThe2ndplease, read the documentation for your board.09:59
LetoThe2ndtalk to the person/vendor that gave it to you09:59
LetoThe2ndthose are technically obliged to give you the sources that have been used (if its running u-boot and linux)10:00
kanupatarLetoThe2nd: I have the working yocto for dylan10:00
*** jku <jku!jku@nat/intel/x-exahskvriylzaqra> has quit IRC10:00
kanupatarthey given that10:00
LetoThe2ndwell then look at the recipes in the BSP10:00
kanupatarbut I need to update the revision10:01
LetoThe2ndi don't get your problem, to be honest.10:01
kanupatarLetoThe2nd: I have dylan branch of yocto working in board and I checked out it10:01
kanupatarnow, I am planning to check new versions of u-boot and kernel10:01
LetoThe2ndkanupatar: and you certainly had to add *SOMETHING* to the official dylan download by the yocto project in oder to make it work, right?10:02
LetoThe2ndkanupatar: so please look at that *SOMETHING*10:02
kanupatarLetoThe2nd: yes yes10:02
kanupataris that meta-bsp?10:03
LetoThe2ndand once you have looked at that *SOMETHING* and found your version numbers inside that *SOMETHING*, you can change them in that *SOMETHING*10:03
LetoThe2ndits all in that *SOMETHING*, thats usually called a BSP10:03
kanupatarLetoThe2nd: I though BSP is like u-boot,kernel and drivers10:03
LetoThe2ndthose highly board specific things like kernel and u-boot are *NOT* defined by the yocto project, but by that BSP10:04
LetoThe2ndkanupatar: yes so why don't you just look at your BSP and then change it to your needs?10:04
*** jku <jku!> has joined #yocto10:04
kanupatarLetoThe2nd: let me check10:04
kanupatarLetoThe2nd: thanks for your inpus10:05
*** nicktick <nicktick!~john@unaffiliated/nicktick> has joined #yocto10:08
lpapphmm, updating the kernel from package works, but flashing the image gets a stuck kernel... with the booting process10:20
lpappI wonder what the actually means in terms of recipe rules, etc.10:20
*** xulfer <xulfer!~xulfer@2001:41d0:2:5ee0::> has quit IRC10:24
*** xulfer <xulfer!~xulfer@2001:41d0:2:5ee0::> has joined #yocto10:35
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC10:47
*** nerdboy <nerdboy!> has joined #yocto10:52
*** Saur <Saur!pkj@nat/axis/x-xvpuhicetgxkbgmi> has quit IRC10:57
*** Saur <Saur!pkj@nat/axis/x-vjigbrrpinghcldd> has joined #yocto10:58
*** nerdboy <nerdboy!> has quit IRC10:59
*** patrickz1 <patrickz1!~Thunderbi@> has joined #yocto11:06
*** patrickz <patrickz!~Thunderbi@> has quit IRC11:07
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto11:07
*** rich_b <rich_b!> has joined #yocto11:09
*** belen <belen!~Adium@> has joined #yocto11:16
*** m0t0ro <m0t0ro!> has joined #yocto11:17
*** tanuk_ <tanuk_!> has joined #yocto11:36
zamanI am getting the warning "WARNING: [kernel]: An auto generated BSP description was used, this normally indicates a misconfiguration.11:36
zamanCheck that your machine (quark) has an associated kernel description."11:36
*** tanuk <tanuk!> has quit IRC11:37
*** jku <jku!> has quit IRC11:38
zamanI have scc file as SRC_URI += "file://quark-standard.scc" with contents11:39
m0t0rohello everyone!11:39
m0t0roI'm having some trouble with the mraa and pwm with intel edison, maybe anyone could help me out?11:42
*** _4urele_ <_4urele_!> has quit IRC11:56
*** tsramos <tsramos!~tsramos@> has joined #yocto12:02
*** _4urele_ <_4urele_!> has joined #yocto12:02
*** varibull <varibull!> has quit IRC12:03
*** varibull <varibull!> has joined #yocto12:03
*** dshwang <dshwang!~dshwang@> has quit IRC12:05
*** dshwang <dshwang!~dshwang@> has joined #yocto12:06
*** tasslehoff <tasslehoff!~Tasslehof@> has quit IRC12:06
*** tsramos <tsramos!~tsramos@> has quit IRC12:06
*** jchonig <jchonig!> has quit IRC12:07
*** jchonig <jchonig!> has joined #yocto12:07
*** vmeson <vmeson!> has quit IRC12:08
*** _4urele_ <_4urele_!> has quit IRC12:12
*** Crofton <Crofton!~balister@> has joined #yocto12:12
*** _4urele_ <_4urele_!> has joined #yocto12:15
*** tsramos <tsramos!~tsramos@> has joined #yocto12:23
*** mago_ <mago_!~mago@> has quit IRC12:23
*** mago_ <mago_!~mago@> has joined #yocto12:24
*** vmeson <vmeson!~rmacleod@> has joined #yocto12:25
*** pidge <pidge!~pidge@2a02:8084:0:3000:c1d7:873a:d0c4:fb6b> has joined #yocto12:25
bluelightningarfoll_: ^12:27
*** StMartin81 <StMartin81!2eedef23@gateway/web/freenode/ip.> has joined #yocto12:29
*** _4urele_ <_4urele_!> has quit IRC12:31
*** patrickz <patrickz!~Thunderbi@> has joined #yocto12:31
*** belen <belen!~Adium@> has quit IRC12:32
*** belen <belen!~Adium@> has joined #yocto12:34
*** patrickz1 <patrickz1!~Thunderbi@> has quit IRC12:34
*** darkspike <darkspike!~darkspike@> has joined #yocto12:35
*** mimetonbo <mimetonbo!ca5311d2@gateway/web/freenode/ip.> has joined #yocto12:35
darkspikehi guys, if i have a recipe called  and then i create my own layer and in it a recipe called would bitbake use the higher version one ?12:36
mimetonbohi guys, Im working on a yocto build on an ARM9 processor board12:36
mimetonboAnyone have embedded linux experience here?12:36
mimetonboBasically I want to use the onboard uart peripheral on the board. I need some pointers regarding that12:37
*** dshwang <dshwang!~dshwang@> has quit IRC12:38
bluelightningdarkspike: assuming your layer has the same or higher layer priority, yes12:39
LetoThe2ndmimetonbo: depending on the board and kernel revision, you'd either have to modify the the board file, the device tree file, or both12:39
mimetonboWell I have a vague idea of what you are saying12:40
mimetonboSo the board file basically links the software to the hardware right?12:40
*** tsramos <tsramos!~tsramos@> has quit IRC12:40
mimetonboand the device tree also does something similar right?12:40
LetoThe2ndmimetonbo: very roughly, yes. thery both part of the kernel source12:41
*** tsramos <tsramos!~tsramos@> has joined #yocto12:41
darkspikebluelightning: cool, thanks !12:41
*** _4urele_ <_4urele_!> has joined #yocto12:41
LetoThe2ndmimetonbo: so my basic outline would be 1) manually rebuild the kernel in use 2) motify, tinker, test 3) reinsert your changes into recipes12:41
mimetonboLeto: is there a way I can read both while the system is running? the current board file and device tree file12:42
LetoThe2ndmimetonbo: nope12:43
LetoThe2ndusually you can get the device tree, but certainly not the board file. the board file is ordinary c source.12:43
mimetonbohmm... well in the yocto source where can I find these files?12:44
LetoThe2ndmimetonbo: not at all in the yocto sources.12:45
mimetonbooh well Im at my wits end12:45
LetoThe2ndmimetonbo: first i guess you mean poky, or some bsp layer that you use.12:45
*** tsramos <tsramos!~tsramos@> has quit IRC12:45
LetoThe2ndin there are recipes that tell the build process how to build the kernel12:45
LetoThe2ndin the recipe that builds your kernel, there basically is the description where the kernel sources are obtained, and which patches are applied12:46
LetoThe2ndmimetonbo: and these are the things to look at12:46
mimetonbohmm let me comprehend that a bit12:47
LetoThe2ndmimetonbo: basically i'd suggest to have a thorough look at the yocto project kernel development manual, as it should explain the steps to modify the kernel pretty nicely12:47
mimetonbookay gotchya! thanks!12:47
mimetonboIm on it12:47
*** belen <belen!~Adium@> has quit IRC12:48
*** rich_b <rich_b!> has quit IRC12:48
*** StMartin81 <StMartin81!2eedef23@gateway/web/freenode/ip.> has quit IRC12:48
*** StMartin81 <StMartin81!> has joined #yocto12:54
*** belen <belen!~Adium@> has joined #yocto12:54
StMartin81I've asked this question a few days ago on the general developer mailing unfortunately I didn't get any reply:12:55
StMartin81The Yocto Project ADT Eclipse plugin preferences offers two options for choosing a cross compiler toolchain: "Standalone pre-built toolchain" and "Build system derived toolchain".12:55
StMartin81When I select "Build system derived toolchain" after executing "bitbake meta-ide-support" I always get the error message "Specified toolchain directory does not contain a toolchain generated with "bitbake meta-ide-support"." no matter what directory I select.12:55
StMartin81If I select "Standalone pre-built toolchain" the plugin seems to be happy.12:55
StMartin81Now my question is if the "Build system derived toolchain" option is still valid and if so what the prerequisites are?12:56
LetoThe2ndStMartin81: AFAIK, the build system dereived toolchain is meant for you if you actually have done the complety poky build proess, and want to use the toolchain that got generated in the course of that12:57
*** mago_ <mago_!~mago@> has quit IRC12:58
*** belen <belen!~Adium@> has quit IRC12:59
*** mago_ <mago_!~mago@> has joined #yocto13:00
StMartin81LetoThe2nd: You mean the toolchain which gets built when I execute "bitbake  <image name>"?13:01
LetoThe2ndStMartin81: more like "bitbake <any kind of recipe that needs a cross toolchain>", but basically yes.13:02
StMartin81LetoThe2nd: Ok, thanks!13:06
StMartin81What's confusing me though is that the error message states that I should run "bitbake meta-ide-support" which will generate a toolchain which can be used with the "Standalone pre-built toolchain".13:08
LetoThe2ndwell according to what you said above, the message is correct, right?13:09
*** e8johan <e8johan!> has quit IRC13:09
StMartin81So my understanding is that if I have setup the poky build system on my computer I can simply select "Build system derived toolchain" so that Eclipse will use the same toolchain as bitbake is using.13:09
LetoThe2ndagain AFAIK, yes, thats the way its meant to be13:10
*** mimetonbo <mimetonbo!ca5311d2@gateway/web/freenode/ip.> has quit IRC13:11
*** SorenHolm <SorenHolm!~quassel@> has quit IRC13:11
*** hamis <hamis!~irfan@> has quit IRC13:12
StMartin81Ok, assume I build an image using "bitbake <my_image>". This should build a cross-toolchain which I want to use in Eclipse.13:14
StMartin81Now, what directory would I need to select if I selected "Build system derived toolchain" and why is the error message mentioning that I should build a toolchain using "bitbake meta-ide-support"?13:14
*** ant_work <ant_work!> has quit IRC13:15
LetoThe2ndno idea, sorry. its been some time since i dabbled with that. and the ADT is maintained not too well at the moment, from what i've heard13:16
arfoll_m0t0ro: move to #mraa13:17
*** belen <belen!~Adium@> has joined #yocto13:17
*** arfoll_ is now known as arfoll13:17
StMartin81Ok, thanks a lot! Considering the amount of information I've found during my search I was almost expecting that there is not too much interest in this plugin...13:18
*** SorenHolm <SorenHolm!~quassel@> has joined #yocto13:19
ericbuttershi.. i got: ERROR: QA Issue: No GNU_HASH in the elf binary -- this is with pre-build libs. how to solve?13:20
*** belen <belen!~Adium@> has quit IRC13:21
*** tsramos <tsramos!~tsramos@> has joined #yocto13:22
*** belen <belen!Adium@nat/intel/x-wekcvzwotnjraygi> has joined #yocto13:23
*** SorenHolm <SorenHolm!~quassel@> has quit IRC13:25
bluelightningericbutters: in this instance if the libs are built outside of our build system, you'd probably use INSANE_SKIP to disable the check13:26
*** jku <jku!jku@nat/intel/x-fheubxlaphlrymel> has joined #yocto13:28
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto13:28
ericbuttersbluelightning: i did: INSANE_SKIP_${PN} += "ldflags" -- but same errors13:30
bluelightningericbutters: is ${PN} the specific package in which those files are included?13:31
ericbuttersbluelightning: i added  INSANE_SKIP_${PN} to the recipe that installs/packages the files13:32
bluelightningericbutters: yes, I get that, but if those files are not in the main package for the recipe (i.e. ${PN}) then that would explain why adding ldflags to INSANE_SKIP_${PN} would not disable the warning...13:33
bluelightningin that case you would need to specify the package they were in fact in instead of ${PN} in that statement13:34
*** dshwang <dshwang!~dshwang@> has joined #yocto13:34
*** lamego <lamego!~jalamego@> has joined #yocto13:35
*** nicktick <nicktick!~john@unaffiliated/nicktick> has quit IRC13:38
*** tsramos <tsramos!~tsramos@> has quit IRC13:38
*** tsramos <tsramos!~tsramos@> has joined #yocto13:38
*** zeddii <zeddii!~ddez@> has quit IRC13:39
*** vmeson <vmeson!~rmacleod@> has quit IRC13:40
*** kscherer <kscherer!~kscherer@> has quit IRC13:40
*** vmeson <vmeson!~rmacleod@> has joined #yocto13:40
*** kscherer <kscherer!~kscherer@> has joined #yocto13:40
*** belen <belen!Adium@nat/intel/x-wekcvzwotnjraygi> has quit IRC13:40
*** zeddii <zeddii!~ddez@> has joined #yocto13:40
*** tsramos <tsramos!~tsramos@> has quit IRC13:43
ericbuttersbluelightning: i am still wondering why it is not working, but btw, i also do INHIBIT_PACKAGE_STRIP = "1" and there is a packages-split/ generated containing targetfs-genivi-dbg/ -> but i also set INHIBIT_PACKAGE_DEBUG_SPLIT = "1" ?!13:44
ericbuttersthe recipe ($PN) i set this is doing do_fetch do_unpack and do_install and simple unpack and install pre-build rootfs13:45
bluelightningericbutters: we are considering packages at this point, not the recipe13:46
*** sjolley <sjolley!~sjolley@> has quit IRC13:46
bluelightningericbutters: INHIBIT_PACKAGE_DEBUG_SPLIT = "1" doesn't stop the -dbg package existing, just whether or not the symbols get split out to that package13:46
*** JaMa <JaMa!> has joined #yocto13:46
*** dholland is now known as gagi13:47
*** gagi is now known as dholland13:47
bluelightningericbutters: the files that the GNU_HASH warning is complaining about - which directory do they appear in under packages-split ?13:48
ericbuttersbluelightning: -dev13:48
bluelightningericbutters: right, then you would need to do INSANE_SKIP_${PN}-dev += "ldflags" in that case13:48
ericbuttersbluelightning: yes, thanks! that solved it.. but i got one more: ERROR: QA Issue: my-package: Files/directories were installed but not shipped -- as i said i got a total rootfs, in packages-split/my-package i only see a subset of that rootfs13:53
ericbuttersso do i need to set FILES?13:53
bluelightningericbutters: either set/add to FILES_<package> to add those files to a package, or avoid them being installed in the first place, or delete them within do_install, whichever is appropriate13:55
ericbuttersbluelightning: i need them all, i just want bitbake to generate a roofs out of a pre-built rootfs. so i would need to set/add to FILES_<package>13:57
bluelightningericbutters: right yes13:59
ericbuttersbluelightning: i got everything in the package/ folder, but not in the packages-split/my-package -- so i tried: FILES_${PN} += "${PKGD}/*"14:03
*** munch_ <munch_!> has joined #yocto14:03
ericbuttersis ${PKGD} correct?14:03
*** munch_ is now known as Guest7870914:04
bluelightningericbutters: no, because you're now specifying the path on the host, FILES refers to the path as it would appear on the target14:06
bluelightningericbutters: for the hack you are doing you probably want to set PACKAGES = "${PN}" as well14:06
bluelightningericbutters: you're aware you are going to have problems if any of the packages install conflicting files, right?14:07
bluelightningin fact I suspect it may make this approach unworkable14:07
*** StMartin81 <StMartin81!> has left #yocto14:09
ericbuttersbluelightning: okay, thanks. what would you suggest? any idea you can share would be nice :) -- btw, PACKAGES = "${PN}" did not work14:09
*** chankit1 <chankit1!~oneam@> has joined #yocto14:09
bluelightningericbutters: you can't package an entire rootfs with conflicting files14:10
bluelightningericbutters: I'm guessing you'd need to do something like merge the old rootfs into the new one at the end of image construction, because doing it before is going to lead to similar issues where the package manager isn't expecting files to exist14:11
bluelightningto be honest thinking about doing this makes me feel somewhat ill...14:12
*** _jmleo <_jmleo!> has joined #yocto14:13
*** jmleo <jmleo!> has quit IRC14:13
ericbuttersbluelightning: my goal is to use yocto/bitbake without compiling any source, just use a pre-build rootfs and then copy binaries, header, config etc out of svn into this and let bitbake generate a rootfs out of it14:13
*** behanw <behanw!~behanw@> has joined #yocto14:13
ericbuttersbluelightning: ;)14:13
bluelightningericbutters: yes, I recall the discussion from the other day14:13
bluelightningit's just not a route I would ever choose to go down myself14:14
ericbuttersi know14:14
*** wadim_ <wadim_!> has quit IRC14:15
LetoThe2ndbluelightning: ++14:16
LetoThe2ndsouds androidish... grab some stuff, put binary blobs inside, ship it ;)14:16
*** sjolley <sjolley!~sjolley@> has joined #yocto14:19
*** dmoseley1 <dmoseley1!> has quit IRC14:22
*** dmoseley <dmoseley!> has joined #yocto14:22
kergothyou probably *could* package an entire rootfs in a recipe, or most of one, but if you build anything else, you'd have to have it PROVIDES everything it really provides, to avoid the conflicts bluelightning mentions. possible, not pretty, and not sure using bitbake in such a case even buys you much14:23
* kergoth yawns14:23
bluelightningkergoth: right, it's not impossible, just painful14:23
bluelightningbut then the whole thing is likely to be painful14:24
bluelightningmorning kergoth :)14:24
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto14:26
*** dmoseley <dmoseley!> has quit IRC14:27
*** jchonig <jchonig!> has quit IRC14:34
*** danielpavel <danielpavel!~danielpav@> has joined #yocto14:34
*** jchonig <jchonig!> has joined #yocto14:35
*** tlwoerner_ <tlwoerner_!> has joined #yocto14:36
*** tlwoerner_ <tlwoerner_!~tlwoerner@unaffiliated/tlwoerner> has joined #yocto14:36
danielpavelHello, I'm trying to find out what exact params are passed to uboot-mkimage during yocto build. I checked out logs (build/tmp/logs) and there's no output that can gives me the info i need. I'm trying about the task do_uboot_mkimage from kernel.bbclass. Is there a way to find out something about that ?14:37
danielpavelI'm talking *14:37
*** jku <jku!jku@nat/intel/x-fheubxlaphlrymel> has quit IRC14:38
*** roxell_ <roxell_!> has quit IRC14:39
*** ulf`_ is now known as ulf`14:39
*** roxell <roxell!~roxell@linaro/roxell> has joined #yocto14:39
*** madisox <madisox!> has joined #yocto14:40
*** dmoseley <dmoseley!> has joined #yocto14:41
*** behanw <behanw!~behanw@> has quit IRC14:42
*** khem` is now known as khem[away]14:48
kergothjust add set -x to the top of the task and look at the task log14:49
*** bradfa <bradfa!~andrew@> has quit IRC14:52
*** jku <jku!> has joined #yocto14:58
*** khem[away] is now known as khem`15:02
*** OutOfNoWhere <OutOfNoWhere!~rpb@> has quit IRC15:03
*** OutOfNoWhere <OutOfNoWhere!~rpb@> has joined #yocto15:04
ericbuttersQA Issue: non -dev/-dbg/-nativesdk package contains symlink .so15:07
kergothyou should probalby just disable all qa tests, given the hack you're doing15:10
kergothINSANE_SKIP_${PN} = "1"15:10
bluelightningI suspect INSANE_SKIP_${PN} = "1" won't actually do anything15:10
kergothoh, right, that's the one for specific tests, ignore me15:11
kergothinsufficient caffeine15:11
joshuaglany c++/cmake savvy folks in here? I'm trying to build a large piece of software which uses CMake and getting a bunch of failures like "fatal error: cstdlib:" - if I edit the .flags files by hand to add -isystem /srv/build/geh/tmp/sysroots/qemux86/usr/include/c++/4.9.2/15:11
joshuaglthings start to proceed15:11
joshuaglthat should be "fatal error: cstdlib: No such file or directory"15:12
bluelightningjoshuagl: is the sysroot being specified?15:12
ericbuttersso how to disable all qa tests?15:13
joshuaglbluelightning: oh, no it isn't :-/15:13
*** chankit1 <chankit1!~oneam@> has quit IRC15:13
bluelightningericbutters: I don't believe we have an actual option for that, having never deemed it a good idea... I would guess you could stub out do_package_qa() but I can't guarantee that will work15:14
joshuaglbluelightning: any ideas how that might have been removed?15:16
bluelightningjoshuagl: not sure, maybe it's simply not using CC / CXX15:17
bluelightningsince those have the --sysroot option specified15:17
joshuaglbluelightning: pro tip, thanks15:18
*** belen <belen!Adium@nat/intel/x-gsdngtygqajgvwgj> has joined #yocto15:20
*** jku <jku!> has quit IRC15:22
kergothericbutters: presumably you could empty ERROR_QA and WARN_QA in the recipe. normally those are distro policy, as to what to do when qa problems occur, but you could probably set it in the recipe to silence them all15:23
kergothuntested, obviously15:23
*** wv <wv!> has quit IRC15:24
*** belen <belen!Adium@nat/intel/x-gsdngtygqajgvwgj> has quit IRC15:27
ericbutterskergoth: i overwrite do_package_qa .. that worked.. it is all hacking for that approach, but i have to try this.. now i got the rpm in deploy-rpm, but baking my target image will use/install it?!15:28
ericbutterswill *not* ^15:29
ericbuttersi only get a subset in rootfs/ folder of the package15:30
*** e8johan <e8johan!> has joined #yocto15:33
joshuaglbluelightning: that was it, my hero!15:37
*** danielpavel <danielpavel!~danielpav@> has quit IRC15:38
bluelightningjoshuagl: \o/15:41
*** tsramos <tsramos!~tsramos@> has joined #yocto15:41
*** benjamirc <benjamirc!~besquive@> has joined #yocto15:45
*** e8johan <e8johan!> has quit IRC15:45
*** tsramos <tsramos!~tsramos@> has quit IRC15:45
*** nerdboy <nerdboy!> has joined #yocto15:57
*** nerdboy <nerdboy!> has quit IRC15:57
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto15:57
*** sarahsharp <sarahsharp!sarah@nat/intel/x-jnptkmsgffzhyznm> has joined #yocto15:58
*** behanw <behanw!~behanw@> has joined #yocto15:58
*** T0mW <T0mW!> has joined #yocto16:02
T0mWI've built a sato image on Daisy, matchbox comes up on the LCD, a mouse is available on /dev/psaux.  When I cat /dev/psaux I see mouse data.  However, the desktop does not see the mouse.  I tried linking /dev/psaux to /dev/mouse, but no mouse movement in matchbox.16:04
T0mWNo docs, as yet, on Yocto regarding the mouse.16:04
*** geheimnis` <geheimnis`!~geheimnis@> has joined #yocto16:11
*** jbrianceau is now known as jbrianceau_away16:18
bluelightningT0mW: I guess this is a generic X11 configuration issue, it's not something specific to us16:20
T0mWbluelightning: thanks16:20
*** TobSnyder <TobSnyder!> has quit IRC16:30
*** nicktick <nicktick!~john@unaffiliated/nicktick> has joined #yocto16:31
*** belen <belen!Adium@nat/intel/x-lmnfackwufjxpppf> has joined #yocto16:33
*** belen <belen!Adium@nat/intel/x-lmnfackwufjxpppf> has quit IRC16:36
*** belen <belen!Adium@nat/intel/x-jzbbouxozapoikex> has joined #yocto16:37
*** anselmolsm <anselmolsm!~anselmols@> has joined #yocto16:37
*** stryx`_ <stryx`_!~stryx@unaffiliated/stryx/x-3871776> has quit IRC16:39
*** belen <belen!Adium@nat/intel/x-jzbbouxozapoikex> has quit IRC16:39
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto16:40
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto16:41
*** khem` is now known as khem[away]16:41
*** khem[away] is now known as khem`16:41
*** belen <belen!Adium@nat/intel/x-ltsfkypodycnxytt> has joined #yocto16:42
*** ericbutters <ericbutters!~eric@> has quit IRC16:49
*** darkspike <darkspike!~darkspike@> has quit IRC16:49
*** ericbutters <ericbutters!~eric@> has joined #yocto16:49
*** darkspike <darkspike!~darkspike@> has joined #yocto16:49
*** diego_r <diego_r!> has quit IRC16:51
*** nicktick <nicktick!~john@unaffiliated/nicktick> has quit IRC17:09
*** btooth <btooth!> has joined #yocto17:12
*** khem` is now known as khem[away]17:23
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto17:24
*** belen <belen!Adium@nat/intel/x-ltsfkypodycnxytt> has quit IRC17:24
*** jmleo <jmleo!> has joined #yocto17:29
*** _jmleo <_jmleo!> has quit IRC17:31
*** khem[away] <khem[away]!~khem@unaffiliated/khem> has quit IRC17:34
*** OutOfNoWhere <OutOfNoWhere!~rpb@> has quit IRC17:35
*** fitzsim <fitzsim!~user@2001:420:284a:1300:6e0b:84ff:fe09:4e9f> has joined #yocto17:46
*** OutOfNoWhere <OutOfNoWhere!~rpb@> has joined #yocto17:50
*** paulg_ <paulg_!~paulg@> has joined #yocto17:52
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC18:04
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto18:09
*** jimBaxter <jimBaxter!> has quit IRC18:10
*** onoffon <onoffon!~khem@unaffiliated/khem> has joined #yocto18:12
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC18:13
*** onoffon <onoffon!~khem@unaffiliated/khem> has quit IRC18:16
*** ddalex1 <ddalex1!~ddalex@> has joined #yocto18:16
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto18:18
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has quit IRC18:18
*** varibull <varibull!> has quit IRC18:36
*** varibull <varibull!> has joined #yocto18:36
*** jimBaxter <jimBaxter!> has joined #yocto18:37
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC18:38
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto18:39
*** nicktick <nicktick!~john@unaffiliated/nicktick> has joined #yocto18:40
lpappB = "${WORKDIR}/linux-${MACHINE}-${LINUX_KERNEL_TYPE}-build" -> B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build" -> so this apparently changed?18:43
*** jimBaxter <jimBaxter!> has quit IRC18:45
*** nicktick <nicktick!~john@unaffiliated/nicktick> has quit IRC18:46
*** SorenHolm <SorenHolm!> has joined #yocto18:47
*** adelcast1 <adelcast1!~adelcast@> has left #yocto18:53
lpappkergoth: are you around?19:00
*** belen <belen!Adium@nat/intel/x-pvhclwvhtbpavoyy> has joined #yocto19:00
lpappkergoth: would it be possible that our forked kernel recipe would not work that well with daisy as it worked with dylan? I am still trying to figure out the root cause of the kernel boot issue.19:00
lpappand it is certainly not an image generation problem as updating the kernel from package also breaks.19:00
lpappI am just trying to make sure that our "old" recipe, which is just a slightly customized version of the meta-yocto kernel for the time is still OK with the daisy rules. If that is true, I am afraid that the only issue could be toolchain related.19:01
*** lamego <lamego!~jalamego@> has quit IRC19:01
*** adelcast <adelcast!~adelcast@> has joined #yocto19:01
kergothYeah, the kernel build process changed somewhat. the source tree and build dir are both in the sysroot now. it's possible, it depends on what all the recipe is doing19:04
lpapphmm, I was just about to paste our recipe for introspection.19:04
* kergoth honestly isn't 100% on the kernel build changes, never read the commits19:05
* paulg_ would be very surprosed of the work-shared changes could result in a bzImage that somehow was corrupted and unbootable.19:06
paulg_surprised, even.19:07
lpappkergoth: paulg_
lpappanything suspicious? This was working fine with dylan.19:10
*** lamego <lamego!jalamego@nat/intel/x-isqlujsjjcmqnvrm> has joined #yocto19:12
*** JaMa <JaMa!> has quit IRC19:13
paulg_I'm missing way too much context to even try to attempt to understand what you are trying to do here.19:13
paulg_like why are  you gluing an ancient 3.2 kernel into a modern yocto.19:15
kergothhe's taking a kernel recipe from dylan which worked, pulled it forward to the nxt release, and his kernel isn't booting. i suggested the most likely cause was something miscompiled with the new toolchain19:15
kergoth3.2? yikes19:15
paulg_yep, my thought exactly.19:15
*** belen <belen!Adium@nat/intel/x-pvhclwvhtbpavoyy> has quit IRC19:16
*** belen <belen!Adium@nat/intel/x-kipnnwewgyckkupa> has joined #yocto19:16
paulg_lpapp, the quick check is to compare the .config for both old and "new" -- assuming your kernel version is the same  for each.   And check what branch / head commit was built19:16
paulg_if you have the same src and the same .config (and same dts/dtb, if applicable) then you are kind of down to the toolchain at that point.19:17
lpappas you can see we ship our configs.19:18
lpappso unless there are incompatible changes, which I doubt in kernel land, it oughto to be comparably equal or at least very similar.19:19
lpappthe reason for 3.2 is not relevant here, but it is that we do not have enough resource nor expertise to update our huge changes on top of a new kernel version.19:19
paulg_ok, so let me rewind here a bit to fill in whatever discussion I missed.19:20
lpappmost of the extra 20K changes would not apply against the new kernel and the changes are really not upstreamable, nor do we have the time and money in this small company to make it so.19:20
paulg_a) on both the failing newer yocto, and the older working yocto, the same 3.2 source was used, correct?19:20
*** adelcast <adelcast!~adelcast@> has left #yocto19:20
lpappyes, as you can see it is verbatim in our meta-foo19:21
lpappour layer has not changed.19:21
*** adelcast1 <adelcast1!~adelcast@> has joined #yocto19:21
lpappmeta/, scripts/, and bitbake/ has changed19:21
lpappand the .tempconfig or how it is called in the root coming from Yocto again.19:21
paulg_yeah, forget all that and go right to the .config of the kernel build.19:22
lpappas in?19:24
lpappso as you can see on the pastebin site, we have this ./meta-foo/recipes-kernel/linux/linux-foo-3.2.1/defconfig. That is the configuration that is also carried on.19:24
paulg_well, I've NFI what board you are using, etc, but with the x86 stuff I'm poking at currently, and with the yocto-dev kernel, it would be here:19:24
paulg_the .config in that dir19:25
*** onoffon <onoffon!~khem@unaffiliated/khem> has joined #yocto19:25
lpappit is coming from ./meta-foo/recipes-kernel/linux/linux-foo-3.2.1/defconfig.19:25
lpappit is preconfigured and saved.19:26
lpappand then applied as a patch.19:26
paulg_yours will be tmp/work/<arch-mumble>/linux-yocto/....19:26
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC19:26
lpappyou can also see that in my recipe.19:26
paulg_doesn't matter where it is sourced from etc.  -- only thing that counts is the final .config in that build dir19:26
paulg_only by comparing the final two .config (working and non-working) will you be able to rule out a mangled config due to processing changes.19:27
lpappokay, thanks, I am vimdiffing them now.19:27
*** benjamirc <benjamirc!~besquive@> has quit IRC19:28
lpapppaulg_: I need to rebuild the kernel packages, I think19:29
lpappas I have used rm_work19:29
paulg_and that is a possibility, since use of defconfigs is actively discouraged vs. the normal workflow of config fragments, so it is possible that defconfigs inadvertently got handled differnetly19:30
paulg_imagine for example your config lost its uart settings -- instant silent boot death.19:30
lpappbut config fragments are difficult to grasp for me.19:31
lpapphmm, bitbake linux-foo did not regenerate the .config file.19:31
lpappI wonder why.19:31
lpappdo I need to clean first?19:31
lpappI just removed rm_work and I thought that ought to be enough to repopulate it.19:31
* lpapp is doing bitbake -c clean linux-foo19:32
paulg_cleanall or cleansstate perhaps...19:32
lpapphmm, I only have got: ./tmp/work/foo-linux-gnueabi/linux-foo/3.2.1-r16/sysroot-destdir/usr/src/kernel/.config19:33
lpappwhich is probably the right one, just after population the sysroot.19:33
lpappanyway, I am doing -c cleanall as you were hinting that above.19:33
*** belen <belen!Adium@nat/intel/x-kipnnwewgyckkupa> has quit IRC19:34
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:41
lpapppaulg_: zero difference according to the vimdiff output19:47
lpappnext thing to check?19:47
lpappthey are equal bit-by-bit.19:47
*** btooth <btooth!> has quit IRC19:48
*** varibull <varibull!> has quit IRC19:48
*** varibull <varibull!> has joined #yocto19:48
lpappI guess I could also unpack the .ipk packages and make some binary compare?19:48
paulg_lpapp, did you confirm both are building from the same source?19:51
paulg_again, don't just assume so from recipe X and bb Y.19:52
paulg_go in the build dir and  check19:52
tlwoerner_lpapp: as an aside, you can leave 'INHERIT += "rm_work"' and then just selectively turn off rm_work for given recipes using RM_WORK_EXCLUDE19:52
lpappthe source is equally the same, yes.19:52
paulg_see what git branch is checked out, see what commit is the top commit.19:52
lpapptlwoerner_: yeah, I think bluelightning mentioned that yesterday to me, thanks.19:52
lpapppaulg_: that is the same.19:53
paulg_and after you've done that, check dts/dtb if you are using one.19:53
lpappI do not.19:53
paulg_and finally are the resulting vmlinux/bzImage files comparable size19:54
lpappfrom which location are you suggesting to compare them?19:55
paulg_right in the build dirs ; don't be looking at possibly stale stuff in tmp/deploy/images19:55
paulg_same place where the .config files where that you compared.19:55
lpappboth are 5.7 MB19:57
lpappvmlinux, that is.19:57
lpappdoes that count as comparable size?19:58
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto20:01
*** paulg_ <paulg_!~paulg@> has quit IRC20:02
*** benjamirc <benjamirc!besquive@nat/intel/x-nsgjaxmroopojlpq> has joined #yocto20:04
lpapppaulg: ^20:04
*** onoffon <onoffon!~khem@unaffiliated/khem> has quit IRC20:04
*** paulg_ <paulg_!~paulg@> has joined #yocto20:06
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC20:19
*** vmeson <vmeson!~rmacleod@> has quit IRC20:23
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC20:32
*** btooth <btooth!> has joined #yocto20:46
*** varibull <varibull!> has quit IRC20:46
*** varibull <varibull!> has joined #yocto20:46
*** SorenHolm <SorenHolm!> has quit IRC20:53
*** btooth <btooth!> has quit IRC20:53
*** ddalex1 <ddalex1!~ddalex@> has quit IRC20:54
*** ant_home <ant_home!> has joined #yocto20:54
*** vmeson <vmeson!> has joined #yocto21:01
*** warthog9 <warthog9!~warthog9@> has left #yocto21:04
*** OutOfNoWhere <OutOfNoWhere!~rpb@> has quit IRC21:18
*** ddalex1 <ddalex1!~ddalex@> has joined #yocto21:20
chrgrff1I'm trying to build a Qt5 project with bitbake for deployment and SDK for development; in SDK, QT_SYSROOT isn't set but I have OECORE_TARGET_SYSROOT environment variable. In bitbake, QT_SYSROOT is set but OECORE_TARGET_SYSROOT is not. Is there one location the target sysroot is defined that I can reference in both cases?21:20
*** ntl <ntl!> has quit IRC21:24
*** Aethenelle <Aethenelle!~Aethenell@> has quit IRC21:29
*** OutOfNoWhere <OutOfNoWhere!~rpb@> has joined #yocto21:33
*** ntl <ntl!> has joined #yocto21:37
*** sri <sri!> has joined #yocto21:39
*** paulg_ <paulg_!~paulg@> has quit IRC21:39
*** nighty-_ <nighty-_!> has quit IRC21:40
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto21:59
*** challinan <challinan!> has quit IRC21:59
*** bfederau <bfederau!> has quit IRC22:01
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC22:01
*** bfederau <bfederau!> has joined #yocto22:01
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto22:06
*** lamego <lamego!jalamego@nat/intel/x-isqlujsjjcmqnvrm> has quit IRC22:30
*** tlwoerner_ <tlwoerner_!~tlwoerner@unaffiliated/tlwoerner> has quit IRC22:36
*** benjamirc <benjamirc!besquive@nat/intel/x-nsgjaxmroopojlpq> has quit IRC22:37
*** paulg_ <paulg_!> has joined #yocto22:38
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC22:39
*** pidge <pidge!~pidge@2a02:8084:0:3000:c1d7:873a:d0c4:fb6b> has quit IRC22:46
*** ant_home <ant_home!> has quit IRC22:53
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto22:55
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC22:56
*** ddalex1 <ddalex1!~ddalex@> has quit IRC22:56
*** Aethenelle <Aethenelle!~Aethenell@> has quit IRC22:59
*** agust <agust!> has quit IRC23:00
*** nicktick <nicktick!~john@unaffiliated/nicktick> has joined #yocto23:04
*** nicktick <nicktick!~john@unaffiliated/nicktick> has quit IRC23:08
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto23:12
*** anselmolsm <anselmolsm!~anselmols@> has quit IRC23:13
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC23:17
kergothSo, the problem where my ncurses is owned by the build user can be reproduced with a poky build, but only for ipk. rpm doesn't encounter the problem23:21
*** darknighte is now known as help23:25
*** help is now known as darknighte23:26
*** darknighte is now known as nohelp23:26
*** nohelp is now known as darknighte23:27
*** JaMa <JaMa!> has joined #yocto23:27
*** egavin <egavin!> has quit IRC23:31
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto23:32
*** m0t0ro <m0t0ro!> has quit IRC23:35
*** egavin <egavin!> has joined #yocto23:46
*** madisox <madisox!> has quit IRC23:49
kergothconfirmed, rebuilt it from scratch, the behavior with ipk is substantially different than with rpm. interesting23:54
*** denix <denix!> has quit IRC23:55

Generated by 2.11.0 by Marius Gedminas - find it at!