Wednesday, 2015-07-29

*** sjolley <sjolley!~sjolley@> has joined #yocto00:01
*** SoylentYellow <SoylentYellow!> has quit IRC00:09
*** evanp_ <evanp_!~evan@> has joined #yocto00:10
*** evanp <evanp!~evan@> has quit IRC00:10
*** dshwang_ <dshwang_!~dshwang@> has joined #yocto00:10
*** dshwang <dshwang!~dshwang@> has quit IRC00:10
*** alimon <alimon!alimon@nat/intel/x-khyfyplkmmmkrbaa> has quit IRC00:13
*** glfernando <glfernando!fernando@nat/intel/x-pnbsyuxctikxsdtf> has quit IRC00:13
*** ylouise1 <ylouise1!~yalouise@> has quit IRC00:13
*** loggerbox <loggerbox!todor@nat/intel/x-ewexqtrsffywmrqh> has quit IRC00:13
*** marquiz_ <marquiz_!~marquiz@> has quit IRC00:13
*** igor1 <igor1!Igor_Stopp@nat/intel/x-pzminpxeagrgkmwa> has quit IRC00:13
*** ulf` <ulf`!~ulf@> has quit IRC00:14
*** marquiz <marquiz!~marquiz@> has joined #yocto00:14
*** igor1 <igor1!~Igor_Stop@> has joined #yocto00:15
freeordieany pointers?  am i missing looking at the right documentation?00:15
*** jzhang <jzhang!~jzhang@> has quit IRC00:15
*** glfernando <glfernando!fernando@nat/intel/x-oixpnqkmdhazallj> has joined #yocto00:15
*** loggerbox <loggerbox!~todor@> has joined #yocto00:15
*** alimon <alimon!~alimon@> has joined #yocto00:15
*** ylouise <ylouise!yalouise@nat/intel/x-hptmmslrldedzebp> has joined #yocto00:15
*** afxez0r <afxez0r!~afxez0r@> has quit IRC00:16
*** zaman <zaman!zaman@nat/intel/x-epbbwkcifhkoyztw> has quit IRC00:16
*** clsulliv1 <clsulliv1!~clsulliv@> has joined #yocto00:16
*** jzhang <jzhang!~jzhang@> has joined #yocto00:16
*** aehs291 <aehs291!~aehernan@> has joined #yocto00:17
*** afxez0r <afxez0r!afxez0r@nat/intel/x-ogrdkkhvnbskybgt> has joined #yocto00:17
*** clsulliv <clsulliv!clsulliv@nat/intel/x-wpeebxmogrrarmmt> has quit IRC00:17
*** zaman <zaman!~zaman@> has joined #yocto00:17
*** aehs29 <aehs29!~aehernan@> has quit IRC00:17
*** clsulliv1 <clsulliv1!~clsulliv@> has quit IRC00:19
*** tripzero_ <tripzero_!~tripzero@> has quit IRC00:19
*** tripzero <tripzero!~tripzero@> has joined #yocto00:19
*** clsulliv <clsulliv!~clsulliv@> has joined #yocto00:20
*** alimon <alimon!~alimon@> has quit IRC00:20
*** igor1 <igor1!~Igor_Stop@> has quit IRC00:20
*** ulf` <ulf`!ulf@nat/intel/x-vlqlikbxhwyfulqu> has joined #yocto00:20
*** alimon <alimon!~alimon@> has joined #yocto00:20
*** igor1 <igor1!~Igor_Stop@> has joined #yocto00:21
*** loggerbox <loggerbox!~todor@> has quit IRC00:44
*** loggerbox <loggerbox!~todor@> has joined #yocto00:44
*** paulg <paulg!> has joined #yocto00:49
*** ambrosius <ambrosius!~textual@> has quit IRC00:53
*** munch_ <munch_!> has joined #yocto00:54
*** munch_ is now known as Guest9555300:54
*** aehs291 <aehs291!~aehernan@> has left #yocto00:57
*** alimon <alimon!~alimon@> has quit IRC00:58
*** igor1 <igor1!~Igor_Stop@> has quit IRC00:58
*** clsulliv <clsulliv!~clsulliv@> has quit IRC00:58
*** igor1 <igor1!~Igor_Stop@> has joined #yocto00:59
*** clsulliv <clsulliv!clsulliv@nat/intel/x-ilfvvqndkjpyjiwp> has joined #yocto00:59
*** Guest95553 <Guest95553!> has quit IRC00:59
*** alimon <alimon!alimon@nat/intel/x-nnvqenokytdxrydn> has joined #yocto01:00
*** Aethenelle <Aethenelle!> has joined #yocto01:40
*** paulg <paulg!> has quit IRC01:40
*** nighty^ <nighty^!> has quit IRC01:44
*** afxez0r <afxez0r!afxez0r@nat/intel/x-ogrdkkhvnbskybgt> has quit IRC02:11
*** SoylentYellow <SoylentYellow!~SoylentYe@> has joined #yocto02:15
*** simmel80___ <simmel80___!> has joined #yocto02:18
*** simmel80 <simmel80!> has quit IRC02:22
*** Aethenelle <Aethenelle!> has quit IRC03:03
*** pidge <pidge!~pidge@2a02:8084:0:3000:2996:e405:535e:239c> has quit IRC03:18
*** redengin <redengin!> has quit IRC03:51
*** redengin <redengin!> has joined #yocto03:52
-YoctoAutoBuilder- build #409 of nightly-rpm is complete: Failure [failed Running Sanity Tests] Build details are at
*** miandonmenmian <miandonmenmian!~miandonme@> has joined #yocto04:18
*** miandonmenmian_ <miandonmenmian_!~miandonme@> has joined #yocto04:18
*** miandonmenmian__ <miandonmenmian__!~miandonme@> has joined #yocto04:19
*** miandonmenmian <miandonmenmian!~miandonme@> has quit IRC04:33
*** miandonmenmian <miandonmenmian!~miandonme@> has joined #yocto04:35
*** hamis <hamis!~irfan@> has joined #yocto04:36
freeordiemaybe in initrdscripts is for installing on a drive?04:40
freeordiei am trying to figure how to partition/install on 250 Gb SSD04:41
*** aehs29 <aehs29!~aehernan@> has joined #yocto04:54
*** InHere <InHere!~rpb@> has joined #yocto05:05
*** freeordie <freeordie!d0573896@gateway/web/freenode/ip.> has quit IRC05:12
*** marek__ <marek__!> has joined #yocto05:13
*** grma <grma!> has joined #yocto05:20
*** behanw <behanw!~behanw@> has quit IRC05:25
*** ambrosius <ambrosius!> has joined #yocto05:48
*** TobSnyder <TobSnyder!> has joined #yocto06:20
*** wadim_ <wadim_!> has joined #yocto06:20
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has joined #yocto06:46
*** jbrianceau_away is now known as jbrianceau06:46
miandonmenmian__what is yocto project reference 1.7.2 kernel?06:51
*** avall <avall!~avalluri@> has joined #yocto07:00
*** ambrosius <ambrosius!> has quit IRC07:06
*** marek__ <marek__!> has quit IRC07:10
*** tmcguire <tmcguire!~tmcguire@> has joined #yocto07:11
*** Biliogadafr <Biliogadafr!> has joined #yocto07:11
*** marek__ <marek__!> has joined #yocto07:12
*** LocutusOfBorg1 <LocutusOfBorg1!> has joined #yocto07:18
*** ant_work <ant_work!> has joined #yocto07:19
*** mckoan|away is now known as mckoan07:23
mckoangood morning07:23
*** diego_r <diego_r!> has joined #yocto07:29
*** rburton <rburton!> has joined #yocto07:29
*** ionte <ionte!> has quit IRC07:45
*** ionte <ionte!> has joined #yocto07:50
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-tgiytbpiexezaqui> has joined #yocto07:56
*** nighty^ <nighty^!> has joined #yocto07:56
*** bluelightning <bluelightning!~paul@> has joined #yocto08:10
*** bluelightning <bluelightning!~paul@> has quit IRC08:10
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:10
bluelightningmorning all08:11
*** domidimi <domidimi!~dimi@> has joined #yocto08:21
*** sameo <sameo!~samuel@> has joined #yocto08:23
*** belen <belen!Adium@nat/intel/x-ioqghunfyqicssuq> has joined #yocto08:27
*** jimBaxter <jimBaxter!> has joined #yocto08:31
*** jonathanmaw <jonathanmaw!> has joined #yocto08:32
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-tgiytbpiexezaqui> has left #yocto08:42
RootertHi all, I have two packages providing the same virtual/package. Is there a way to make bitbake prefer one of the packages by default, if no PREFERRED_PROVIDER_virtual/package is set by the user? I am looking for functionality like DEFAULT_PREFERENCE = "-1" provides for different package versions. Thanks!08:44
miandonmenmian__Rootert: there are priorities for layers08:50
*** InHere <InHere!~rpb@> has quit IRC08:58
*** luyu__ <luyu__!luyu@nat/intel/x-ehpoxtrahdpebeiu> has quit IRC09:00
*** luyu__ <luyu__!luyu@nat/intel/x-txhirlymneyfuhpq> has joined #yocto09:00
*** Biliogadafr1 <Biliogadafr1!> has joined #yocto09:02
*** Biliogadafr <Biliogadafr!> has quit IRC09:05
*** tf <tf!> has quit IRC09:05
*** hamis <hamis!~irfan@> has quit IRC09:05
*** tf <tf!> has joined #yocto09:05
*** hamis <hamis!~irfan@> has joined #yocto09:07
*** egavinc <egavinc!> has joined #yocto09:08
*** Happycat <Happycat!6dbe7afa@gateway/web/freenode/ip.> has joined #yocto09:09
*** AzaToth_ <AzaToth_!~AzaToth__@wikipedia/AzaToth> has quit IRC09:09
*** AzaToth <AzaToth!> has joined #yocto09:09
*** AzaToth <AzaToth!> has quit IRC09:11
*** AzaToth <AzaToth!> has joined #yocto09:11
*** AzaToth <AzaToth!> has quit IRC09:12
*** AzaToth <AzaToth!~AzaToth__@wikipedia/AzaToth> has joined #yocto09:12
Rootertmiandonmenmian: Yes I am aware of that. Unfortunately, both packages are defined in the same layer. I have found some anonymous python script to effectively skip one package provider if the preferred provider is not set explicitly, but that feels a bit clumsy.09:13
bluelightningRootert: I think DEFAULT_PREFERENCE should work in this case then09:18
Rootertbluelightning: That was my first guess too, but it didn't seem to work when I tried it. I will give it some more testing then. Thanks.09:20
*** AzaToth <AzaToth!~AzaToth__@wikipedia/AzaToth> has quit IRC09:20
*** AzaToth <AzaToth!> has joined #yocto09:21
*** AzaToth <AzaToth!> has quit IRC09:22
*** AzaToth <AzaToth!> has joined #yocto09:22
*** AzaToth <AzaToth!~AzaToth__@wikipedia/AzaToth> has joined #yocto09:23
*** dlan_ <dlan_!~dennis@gentoo/developer/dlan> has quit IRC09:30
*** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto09:31
HappycatHi, i'm having problems to build my kernel with yocto (i'm using meta-xilinx for ZC-702) and i need a 3.8 kernel, i have all the patches, the config and the git. But creating the same directory structure (starting from recipes-kernel) and setting prefered version doesn't work, is the kernel version setted somewhere else ? or am i using the wrong solution to get my kernel build instead of the default for the zc-702 ?09:32
*** yann <yann!540e35c2@gateway/web/freenode/ip.> has joined #yocto09:33
LetoThe2ndHappycat: there are some points to it. the kernel recipe has to mark itself as compatible for the machine, for example09:34
*** yann is now known as Guest2505109:34
Guest25051Hi! I'd like to know if one can specify LINUX_KERNEL_TYPE inside an image recipe?09:35
Happycatoh yes you are right, i saw that and forgot it. thanks ! , but the why does the prefered version doesn't throw an error ?09:35
LetoThe2ndHappycat: AFAIK preferred != required.09:36
bluelightningHappycat: PREFERRED_VERSION or PREFERRED_PROVIDER on something that isn't available will throw a warning09:36
LetoThe2ndnot even from a linguistic point of view.09:36
ndecGuest25051: nope. it's variable used in the kernel recipe.09:36
bluelightningHappycat: you may also find your PREFERRED_VERSION or PREFERRED_PROVIDER are being overridden - bitbake -e | less will tell you for sure09:36
HappycatOk i'll see all of that , i just added the COMPATIBLE_MACHINE. thanks for the help once again :)09:38
Guest25051ndec: OK. So is there a way to specify that an image recipe depends on a tiny kernel other than depending on linux-yocto-tiny (I'd like to still depend on virtual/kernel)?09:38
ndecnope. it's a distro setting.09:39
Rootertmiandonmenmian, bluelightning: Found a solution :) Apparently, DEFAULT_PREFERENCE is not taken into account when weighing providers. A package provider named exactly the same as the virtual package will be preferred though, and it gives me the opportunity to explicitly set a different provider if I want to. Thank you both for your help.09:39
ndecGuest25051: an image recipe just aggreates packages already built. Distro settings can impact how these packages get built in the first place.09:40
Rootertmiandonmenmian__: Sorry, i only just noticed the underscore suffix in your nick. See above.09:42
Guest25051ndec: OK. So there is no way to build a normal image with a standard kernel and a recovery image with a tiny kernel using the same local.conf?09:42
ndecGuest25051: well, that's an interesting use case.. i would say no at first sight. but i could be wrong..09:47
*** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC09:48
bluelightningthe tiny kernel for the recovery image would have to be substantially modified so it did not stage the files a normal kernel recipe does09:48
bluelightningit should be possible, but it's not a use case we support out of the box09:49
*** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto09:49
*** khem <khem!~khem@unaffiliated/khem> has quit IRC09:50
*** rperier <rperier!~quassel@ubuntu/member/rperier> has quit IRC09:50
Guest25051bluelightning: for the moment, the tiny kernel would be the same as the other but configured differently using the tiny kernel type09:50
*** rperier <rperier!~quassel@2001:41d0:52:100::44a> has joined #yocto09:51
Guest25051It's unfortunate this use case is not supported but I'll do it differently if I have to ;-)09:51
*** rperier <rperier!~quassel@2001:41d0:52:100::44a> has quit IRC09:51
*** rperier <rperier!~quassel@ubuntu/member/rperier> has joined #yocto09:51
bluelightningGuest25051: without those modifications, you'll get errors because the system expects there to be only one kernel staging the kernel source, headers and artifacts09:51
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto09:51
bluelightning(which are used for other recipes that need those things)09:51
Guest25051ndec: bluelightning: thanks for your answers! If someone has a solution, feel free to tell me ;-)09:52
ndecthe answer is that you need 2 machines, and built separately. which should be fine, anyways, since all binaries would be reused from the sstate09:53
*** sameo <sameo!~samuel@> has quit IRC10:00
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC10:00
*** TobSnyder <TobSnyder!> has quit IRC10:00
*** alimon <alimon!alimon@nat/intel/x-nnvqenokytdxrydn> has quit IRC10:00
*** varibull_ <varibull_!> has quit IRC10:00
*** DarkKnight <DarkKnight!> has quit IRC10:00
*** LetoThe2nd <LetoThe2nd!~jd@unaffiliated/letothe2nd> has quit IRC10:00
*** jwessel <jwessel!~jwessel@> has quit IRC10:00
*** tlwoerner <tlwoerner!~trevor@unaffiliated/tlwoerner> has quit IRC10:00
*** grummund <grummund!~user@unaffiliated/grummund> has quit IRC10:00
*** LetoThe2nd <LetoThe2nd!> has joined #yocto10:00
*** varibull_ <varibull_!> has joined #yocto10:00
*** bluelightning <bluelightning!~paul@> has joined #yocto10:01
*** bluelightning <bluelightning!~paul@> has quit IRC10:01
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto10:01
*** sameo <sameo!~samuel@> has joined #yocto10:01
*** jwessel <jwessel!~jwessel@> has joined #yocto10:01
*** TobSnyder <TobSnyder!> has joined #yocto10:01
*** alimon <alimon!~alimon@> has joined #yocto10:01
*** DarkKnight <DarkKnight!> has joined #yocto10:02
*** tlwoerner <tlwoerner!> has joined #yocto10:03
*** tlwoerner <tlwoerner!~trevor@unaffiliated/tlwoerner> has joined #yocto10:03
*** diego_ <diego_!> has joined #yocto10:03
*** diego_r <diego_r!> has quit IRC10:03
*** diego_ is now known as diego_r10:03
*** tripzero_ <tripzero_!~tripzero@> has joined #yocto10:04
*** SoylentYellow <SoylentYellow!~SoylentYe@> has quit IRC10:05
*** tripzero <tripzero!~tripzero@> has quit IRC10:05
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC10:07
*** bluelightning_ <bluelightning_!~paul@> has joined #yocto10:07
*** bluelightning_ <bluelightning_!~paul@> has quit IRC10:07
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto10:07
*** bluelightning_ is now known as bluelightning10:07
*** grummund <grummund!~user@unaffiliated/grummund> has joined #yocto10:09
*** roric <roric!> has joined #yocto10:15
*** roric <roric!> has quit IRC10:21
miandonmenmian__Rootert: great, thanks for noticing and sharing. I had several layers, and had a similar issue. but i just disabled one of them :P10:26
*** _jmleo <_jmleo!> has joined #yocto10:36
*** jmleo <jmleo!> has quit IRC10:36
*** _jmleo is now known as jmleo10:37
*** Guest25051 <Guest25051!540e35c2@gateway/web/freenode/ip.> has quit IRC10:43
abelalhi guys10:43
*** pohly <pohly!~pohly@> has joined #yocto10:43
abelalI have a variable in the local.conf which I then use in recipes to trigger updates to do_install10:46
abelalinitially the variable is set to 'x' and things work fine10:47
abelali change the variable to 'y' and it works fine again10:47
abelalbut then if I change the variable back to 'x' the intended behavior does not occur10:47
abelalcan anyone help on that?10:48
abelalbluelightning: ping... can you please comment?10:54
bluelightningabelal: I would assume what's happening is that the output produced when the value was 'x' is being restored from the sstate cache the second time10:55
bluelightningabelal: in most cases that's the correct behaviour; if it's not then the inputs to the task aren't adequately defined10:55
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-erwxfemzrofzaite> has joined #yocto10:55
abelalbluelightning: I am checking the variable in do_install_prepend() to make things change10:56
*** Net147 <Net147!~Net147@unaffiliated/net147> has quit IRC10:56
*** pohly <pohly!~pohly@> has quit IRC10:56
abelalbluelightning: shouldn't that be enough to trigger a re-run of do_install?10:57
*** pohly <pohly!> has joined #yocto10:57
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-erwxfemzrofzaite> has left #yocto10:57
*** Net147 <Net147!~Net147@unaffiliated/net147> has joined #yocto10:59
bluelightningabelal: with no other information, since you've already run it with that value, you just get the result of the tasks that follow it (e.g. do_package_write_*) - because it has seen the signature for do_install and therefore all tasks that depend on it before, it assumes it can use the previous output for those tasks10:59
abelalbluelightning: thanks a lot :)11:02
*** pohly <pohly!> has quit IRC11:07
*** anselmolsm <anselmolsm!anselmolsm@nat/intel/x-rwfnynuesdixdqdr> has joined #yocto11:08
*** pohly <pohly!~pohly@> has joined #yocto11:26
*** yann <yann!540e35c2@gateway/web/freenode/ip.> has joined #yocto11:31
*** yann is now known as Guest6096111:31
*** JaMa <JaMa!> has joined #yocto11:33
*** miandonmenmian__ <miandonmenmian__!~miandonme@> has quit IRC11:36
*** miandonmenmian <miandonmenmian!~miandonme@> has quit IRC11:38
*** miandonmenmian_ <miandonmenmian_!~miandonme@> has quit IRC11:40
*** [Sno] <[Sno]!> has quit IRC11:40
*** [Sno] <[Sno]!> has joined #yocto11:41
*** pidge <pidge!~pidge@2a02:8084:0:3000:b19c:b85a:cf80:39de> has joined #yocto11:48
*** Guest60961 <Guest60961!540e35c2@gateway/web/freenode/ip.> has quit IRC11:57
*** pohly <pohly!~pohly@> has quit IRC12:02
*** vmeson <vmeson!> has quit IRC12:06
*** varibull_ <varibull_!> has quit IRC12:08
*** varibull_ <varibull_!> has joined #yocto12:09
*** ylouise <ylouise!yalouise@nat/intel/x-hptmmslrldedzebp> has quit IRC12:23
Ox4guys, I have a problem with kernel modules, as usual :)12:26
Ox4when I just flashed an image, the kernel modules are inserted automatically after booting12:27
Ox4but if I reboot the board, they aren't12:27
clopezwhen two layers have different recipes for the same package... which one gets used? the first one to be listed in local.conf or the last one? in other words... which layer gets more priority in local.conf.. the ones at the top or the bottom ?12:27
Ox4clopez: in the top12:28
*** ericbutters <ericbutters!~eric@> has quit IRC12:36
*** libv <libv!> has joined #yocto12:45
libvwhat bitbake command lists the DESCRIPTION field of a package?12:47
*** ericbutters <ericbutters!~eric@> has joined #yocto12:47
*** tsramos <tsramos!~tsramos@> has joined #yocto12:48
libvalternatively, what bitbake command shows the recipe path that describes a given package?12:49
bluelightninglibv: there isn't such a command, notout of the box at least12:50
bluelightninglibv: bitbake-layers show-recipes mostly gives you the latter though12:51
libvbluelightning: hrm, wouldn't such a command make the whole thing a lot more intuitive?12:52
clopezok, thanks Ox4 :)12:52
bluelightninglibv: maybe, but in terms of "find me a recipe for xyz" we do have the layer index -
bluelightningthat covers all layers, not just the ones in your configuration12:53
bluelightningall public layers whose maintainers have added them to the index, that is12:53
libvbitbake -i <packagename>12:53
bluelightningit's worth noting, there is a distinction between recipes and packages12:54
AzaTothpidge, hello12:55
libvbluelightning: i wish i was that lucky to actually get to use yocto directly :)12:55
libvthat would severely solve a lot of problems with this broken project i am in :)12:55
pidgeAzaToth, hi12:56
bluelightninglibv: well, if there's missing functionality that prevents you from moving then do let us know - I know it's often not that simple though12:57
libvbluelightning: yeah, but bitbake -s gets package names, description fields are afaict also tied to packages, it would be quite intuitive to get both the description and the path and name of the recipe with another command :)12:57
AzaTothpidge, did you get time to look into the issue?12:58
libvbluelightning: it's old style embedded mindset and processes that prevent progress here :)12:58
*** vmeson <vmeson!~rmacleod@> has joined #yocto12:59
pidgeAzaToth, no, I didn't. I will try to look at it this week. I've been working on some other things.13:01
*** hamis <hamis!~irfan@> has quit IRC13:09
darkspikeHi All13:12
darkspikeI am trying to remove some rpms from being installed in the rootfs. IMAGE_INSTALL_remove = " foo bar " in local.conf or in do no seem to have an effect.13:12
*** behanw <behanw!~behanw@> has joined #yocto13:12
darkspikeIs it because the foo and bar rpms do not exist in the IMAGE_INSTALL as strings, but get pulled as dependencies ?13:12
rink_probably; you can use -g (iirc) to generate a dependency graph13:13
darkspikeI need the foo and bar packages to be compiled for another package.13:13
bluelightningdarkspike: almost certainly13:13
darkspikecan i do something about it ? to actually remove them13:13
bluelightningbuildhistory's dependency graphs are the way to track down the dependency chain that pulls in the packages:
bluelightningyou can use PACKAGE_EXCLUDE, but all that's likely to do is give you an error telling you the first-level dependency preventing the package from being removed13:14
darkspikebluelightning: i did check the dependency graphs, an i found that foo and bar are just a build dependency. They are not needed at runtime.13:15
bluelightningdarkspike: buildhistory or bitbake -g ?13:16
darkspikebluelightning: bitbake -g -u depexp13:16
bluelightningdarkspike: right, that's probably not going to be sufficient13:16
bluelightningbuildhistory's graphs show the runtime dependencies as the package manager saw it when constructing the image13:17
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-sxlgegrqiyyudfdv> has joined #yocto13:18
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-sxlgegrqiyyudfdv> has left #yocto13:18
darkspikebluelightning: where do i get theese "buildhistory's graphs" ?, is it from reading the log files in the temp folder ?13:18
bluelightningdarkspike: see the link I pasted just a few lines above, it describes how to enable buildhistory and what it gives you13:19
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto13:21
darkspikebluelightning, rink_ thanks for your help guys !!13:22
*** realBigfoot <realBigfoot!~realBigfo@> has joined #yocto13:26
*** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC13:36
*** sameo <sameo!~samuel@> has quit IRC13:38
*** jmleo <jmleo!> has quit IRC13:41
*** jmleo <jmleo!> has joined #yocto13:42
*** dlan_ <dlan_!~dennis@gentoo/developer/dlan> has joined #yocto13:42
*** dfaught <dfaught!> has joined #yocto13:45
*** jku <jku!> has joined #yocto13:46
*** ant_work <ant_work!> has quit IRC13:46
*** gabrbedd <gabrbedd!> has quit IRC13:47
*** gabrbedd <gabrbedd!> has joined #yocto13:50
*** dfaught <dfaught!> has quit IRC13:54
*** marek__ <marek__!> has quit IRC13:55
*** munch_ <munch_!> has joined #yocto13:56
*** belen2 <belen2!> has joined #yocto13:56
*** munch_ is now known as Guest338513:56
*** jmleo <jmleo!> has quit IRC13:58
*** jmleo <jmleo!> has joined #yocto13:59
*** belen2 <belen2!> has quit IRC14:01
*** xulfer <xulfer!~xulfer@2001:41d0:2:5ee0::> has quit IRC14:03
*** el_robin <el_robin!> has quit IRC14:04
*** belen2 <belen2!> has joined #yocto14:04
*** ndec <ndec!~ndec@linaro/ndec> has quit IRC14:04
*** rperier <rperier!~quassel@ubuntu/member/rperier> has quit IRC14:04
*** tingleby_ <tingleby_!> has quit IRC14:04
*** clopez <clopez!> has quit IRC14:05
*** madisox <madisox!> has joined #yocto14:05
*** Hauke <Hauke!> has quit IRC14:06
*** Hauke <Hauke!~Hauke@> has joined #yocto14:06
*** el_robin <el_robin!~el_robin@> has joined #yocto14:07
*** belen2 <belen2!> has quit IRC14:08
*** clopez <clopez!~tau@> has joined #yocto14:11
*** skfax <skfax!c147b472@gateway/web/freenode/ip.> has quit IRC14:18
*** aehs291 <aehs291!~aehernan@> has joined #yocto14:18
*** ndec <ndec!~ndec@linaro/ndec> has joined #yocto14:20
*** aehs29 <aehs29!~aehernan@> has quit IRC14:21
*** xulfer <xulfer!~xulfer@2001:41d0:2:5ee0::> has joined #yocto14:21
*** rperier <rperier!~quassel@2001:41d0:52:100::44a> has joined #yocto14:21
*** rperier <rperier!~quassel@2001:41d0:52:100::44a> has joined #yocto14:23
*** tingleby <tingleby!> has joined #yocto14:24
*** rperier <rperier!~quassel@2001:41d0:52:100::44a> has quit IRC14:24
*** rperier <rperier!~quassel@ubuntu/member/rperier> has joined #yocto14:24
*** Aethenelle <Aethenelle!~Aethenell@> has quit IRC14:34
*** roric <roric!> has joined #yocto14:34
*** afxez0r <afxez0r!afxez0r@nat/intel/x-vnfzgjguwexmnjdv> has joined #yocto14:35
*** roric <roric!> has quit IRC14:35
*** roric <roric!> has joined #yocto14:37
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC14:37
*** lamego <lamego!lamego@nat/intel/x-vjloeclldfixcoai> has joined #yocto14:38
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto14:38
*** behanw <behanw!~behanw@> has quit IRC14:51
*** avall <avall!~avalluri@> has quit IRC14:55
*** ftonello <ftonello!~felipe@> has quit IRC14:58
*** ftonello <ftonello!~felipe@> has joined #yocto14:58
*** belen2 <belen2!~Adium@> has joined #yocto15:00
*** robher <robher!sid20343@gateway/web/> has quit IRC15:02
*** flynn378 <flynn378!sid63564@gateway/web/> has quit IRC15:02
*** smurray <smurray!sid98062@gateway/web/> has quit IRC15:02
*** aoibhinn <aoibhinn!sid95825@gateway/web/> has quit IRC15:02
*** jbrianceau <jbrianceau!uid10952@gateway/web/> has quit IRC15:02
*** belen <belen!Adium@nat/intel/x-ioqghunfyqicssuq> has quit IRC15:02
*** aehs291 <aehs291!~aehernan@> has left #yocto15:02
*** leowt <leowt!> has joined #yocto15:04
*** aurelihein <aurelihein!> has joined #yocto15:13
*** TobSnyder <TobSnyder!> has quit IRC15:21
*** twirck-user-1320 <twirck-user-1320!~twirck-us@> has joined #yocto15:24
*** paulg <paulg!~paulg@> has joined #yocto15:26
twirck-user-1320howdy folks. Can anyone tell me a command to display MACHINE_FEATURES?15:27
twirck-user-1320I am trying to set HAVE_TOUCHSCREEN=1, but it does not seem to "take", and I can't figure out how to debug it15:28
kergothbitbake -e is your friend :)15:32
kergothI wonder if it'd be useful to try a custom bitbake scheduler which just prioritizes do_clean* before all other tasks, so you could run bitbake foo:do_clean foo to clean & rebuild it in one pass15:32
* kergoth ponders15:33
twirck-user-1320thanks, I did run on the recipe: bitbake -e core-image-sato > sato.txt. Searching the file, I see the following: # $MACHINE_FEATURES [4 operations]15:39
twirck-user-1320I looked up line 276 of the referenced documentation, but it does not provide a list of features. Is this a command that can be run?15:39
*** afxez0r <afxez0r!afxez0r@nat/intel/x-vnfzgjguwexmnjdv> has quit IRC15:40
*** leowt <leowt!> has quit IRC15:44
kergoththere's no official set list of available machine or distro features. there are parts of the metadata that check to see if features are set, that's it15:48
kergoththe yocto docs might list some of it, though it could potentially be out of date15:48
kergothnot certain15:48
*** dfaught <dfaught!> has joined #yocto15:49
*** berton <berton!~fabio@> has joined #yocto15:49
*** lamego <lamego!lamego@nat/intel/x-vjloeclldfixcoai> has quit IRC15:50
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto15:52
twirck-user-1320thanks. MACHINE_FEATURES go in the machine.conf (beaglebone.conf above), and DISTRO_FEATURES go where?15:53
*** aehs29 <aehs29!~aehernan@> has joined #yocto15:54
frayinto the distribution configuration file(s)15:54
frayusually they live in conf/distro/* with the main confgiuration selected by the DISTRO = value15:54
frayif you look at poky, you can find some examples15:55
*** behanw <behanw!~behanw@> has joined #yocto15:55
frayin the poky case, 4 different distributions have been defined15:56
*** benjamirc <benjamirc!~besquive@> has joined #yocto15:57
*** dfaught <dfaught!> has quit IRC15:59
*** belen1 <belen1!Adium@nat/intel/x-hrecvenoeqbftrrl> has joined #yocto15:59
*** belen2 <belen2!~Adium@> has quit IRC15:59
*** AzaToth <AzaToth!~AzaToth__@wikipedia/AzaToth> has quit IRC16:00
*** AzaToth_ <AzaToth_!> has joined #yocto16:00
*** bluelightning_ <bluelightning_!~paul@> has joined #yocto16:03
*** bluelightning_ <bluelightning_!~paul@> has quit IRC16:03
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto16:03
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC16:03
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto16:06
*** jbrianceau <jbrianceau!uid10952@gateway/web/> has joined #yocto16:06
lpapphi, the yocto sdk installs the environment setup script that in turn puts this into CXXFLAGS: -O2 -pipe -g -feliminate-unused-debug-types16:06
lpappthis is almost always wrong and not what a user wants16:06
lpappis there an easy way to drop -O2 -g from there and let the SDK users decide about the optimization and debug levels?16:06
kergoththat's the same default flags that are used by the yocto build. no different in the sdk than in our builds16:06
*** bluelightning_ is now known as bluelightning16:07
lpappI think it is saner for Yocto not to give any default16:07
*** lamego <lamego!~lamego@> has joined #yocto16:08
lpappotherwise it is difficult to append in software buildsystems16:08
lpappin this case, override CXXFLAGS = ..., but if I use -O0 -ggdb for debug, the output will be cluttered even thoug I think it will pick up my override as that comes last in the command.16:08
*** aurelihein <aurelihein!> has quit IRC16:08
*** lamego <lamego!~lamego@> has quit IRC16:09
kergothpresumably you could just override it entirely rather than appending to it, no?16:09
* kergoth shrugs16:09
*** lamego <lamego!lamego@nat/intel/x-zpxwrbjhfowmpltw> has joined #yocto16:09
*** lamego <lamego!lamego@nat/intel/x-zpxwrbjhfowmpltw> has quit IRC16:10
*** lamego <lamego!~lamego@> has joined #yocto16:10
*** jonathanmaw <jonathanmaw!> has quit IRC16:10
lpappI could, but the problem is that CXXFLAGS is not just about debug options.16:10
lpappI would prefer keeping the default except the debug flags16:10
lpappI do not think -O2 -g is sane16:11
*** lamego <lamego!lamego@nat/intel/x-nlljzmsatnqiyets> has joined #yocto16:11
lpappit is not good for a release16:11
lpappand it is not good for debugging either because of -O216:11
lpapp(not good for release because of -g)16:11
lpappand I believe there is no sane default16:11
lpappbecause any combination will make it difficult to nicely append16:11
lpappI think this ought to be the sdk users in their software.16:12
lpappup to*16:12
*** lamego <lamego!lamego@nat/intel/x-nlljzmsatnqiyets> has quit IRC16:12
*** lamego <lamego!~lamego@> has joined #yocto16:12
*** robher <robher!sid20343@gateway/web/> has joined #yocto16:12
lpappso as long as I can adjust it by some configuration, I will be happy.16:12
kergothwe don't use the flags variables for essential arguments like tuning, only for extra bits like optimizations and debugging. the only flag not related to those two is -pipe16:13
*** lamego <lamego!~lamego@> has quit IRC16:15
lpappnot sure if this is it:
*** lamego <lamego!lamego@nat/intel/x-vodpgqaivffgjkyj> has joined #yocto16:16
lpappecho 'export CXXFLAGS="${TARGET_CXXFLAGS}"' >> $script16:18
lpappfrom meta/classes/toolchain-scripts.bbclass16:18
lpappso I believe it is enough to modify TARGET_CXXFLAGS in the distro conf then?16:19
lpappto have it only, say: -pipe16:19
lpappI eventually start thinking that the SDK cxxflags generated and the target flags to build for the target ought to be decoupled.16:20
lpappthey are not necessarily the same.16:20
lpappalthough it is not unreasonable to have them the same either.16:21
kergothlike i said, it's using the same flags we use in our build, so yes, if you change the flags used in our build by altering TARGET_CXXFLAGS, yes, it would affect the sdk too16:21
lpappok, I am happy with this, so I have to override TARGET_CXXFLAGS.16:21
lpappsure, thanks.16:21
lpappyou were right of course :)16:21
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC16:22
kergothheh, wasn't looking for validation, just trying to explain :) but yes, i could see value in finding a way to expose our OPTIMIZATION variables independently. if you look at bitbake.conf, see SELECTED_OPTIMIZATION16:22
kergoththe problem of course is at the point the sdk is being emitted, TARGET_CXXFLAGS is one thing, its components aren't known, the variable is already expanded, so we'd have to filter out the optimization part and re-add it via the shell variable for the optimization16:23
kergothbut doable16:23
*** afxez0r <afxez0r!afxez0r@nat/intel/x-cgbezxkrbunasgzr> has joined #yocto16:34
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC16:35
*** sjolley <sjolley!~sjolley@> has quit IRC16:36
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto16:37
*** mckoan is now known as mckoan|away16:39
*** sjolley <sjolley!~sjolley@> has joined #yocto16:42
* mario-goulart wonders why they didn't quote "roposotory"16:46
mario-goulartoops "reposotory"16:46
*** sjolley <sjolley!~sjolley@> has quit IRC16:46
frayergoth, umm.. wow16:47
fraywow.. Fox Business.. about as credible as Faux News16:47
kergoth is the video16:48
kergothi'm thinking a roposotory must be a repository of rope16:49
*** lamego <lamego!lamego@nat/intel/x-vodpgqaivffgjkyj> has quit IRC16:51
*** lamego <lamego!~lamego@> has joined #yocto16:51
*** flynn378 <flynn378!sid63564@gateway/web/> has joined #yocto16:52
*** varibull_ <varibull_!> has quit IRC16:52
*** varibull_ <varibull_!> has joined #yocto16:52
*** Biliogadafr1 <Biliogadafr1!> has quit IRC16:56
jbrianceaukergoth: wow, thanks for sharing this :)16:58
kergotha bit of humor for your wednesday16:58
*** belen2 <belen2!Adium@nat/intel/x-zcghfdmcueftirzk> has joined #yocto16:58
*** belen1 <belen1!Adium@nat/intel/x-hrecvenoeqbftrrl> has quit IRC16:58
*** ambrosius <ambrosius!~textual@> has joined #yocto17:01
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC17:01
kergothHmm, wonder if we should have a way to indicate packageconfigs which are required in particular contexts. libelf in rpm-native for example is required to get debugedit, which is required by our packaging17:01
*** bluelightning <bluelightning!~paul@> has joined #yocto17:05
*** bluelightning <bluelightning!~paul@> has quit IRC17:05
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto17:05
*** zenx <zenx!~quassel@> has joined #yocto17:09
*** zenx is now known as Guest1991317:09
paulgwow, kergoth that really is tragic and hilarious at the same time.17:09
*** sjolley <sjolley!~sjolley@> has joined #yocto17:10
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:10
*** aoibhinn <aoibhinn!sid95825@gateway/web/> has joined #yocto17:13
*** smurray_ <smurray_!sid98062@gateway/web/> has joined #yocto17:15
*** jbrianceau is now known as jbrianceau_away17:19
twirck-user-1320kinds folks, I am still struggling with getting touchscreen to work in core-image-sato. I have added the MACHINE_FEATURES "touchscreen" to beaglebone.conf, and verified that it gets picked up via bitbake -e core-image-sato. I created a machconfig file in meta/recipes-bsp/formfactor/files/beaglebone/ with the HAVE_TOUCHSCREEN=1 entry, which seems to have no impact on bitbake -e environment variables.17:23
*** smurray_ is now known as smurray17:25
twirck-user-1320dmesg shows no touchscreen input device, and I dont see included libs like tslib that should get picked up for the touchscreen MACHINE_FEATURE17:26
*** atoztoa <atoztoa!~atoztoa@> has joined #yocto17:28
atoztoahi techs17:28
atoztoanew to irc17:28
paulgtwirck-user-1320, presumably for your hardware there is a kernel .config option for the device ;  might be worth checking if that is set and then if not, who you'd expect to set if for you and work backwards from there.17:28
paulgat least that is how I'd do it, but then again I'm more a kernel person than a bitbake person.17:28
atoztoaQ: is there a difference between using a blank do_compile() or no_exec[compile] = '1' ?17:29
twirck-user-1320thanks paulg. I will investigate kernel .config. The touchscreen is detected and comes right up with stock debian, so I should be able to use that to figure out which kernel modules are needed17:31
*** atoztoa <atoztoa!~atoztoa@> has quit IRC17:40
*** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto17:40
*** belen2 <belen2!Adium@nat/intel/x-zcghfdmcueftirzk> has quit IRC17:41
*** atoztoa <atoztoa!~atoztoa@> has joined #yocto17:42
kergothJaMa: what's the best bet for doing builds with an external toolchain whose binutils isn't patched to add armv5e support? revert the ARMPKGSFX_THUMB portion of fe66853/3e76003, or just override DEFAULTTUNE on a per-machine basis?17:43
kergothqemuarm fails to build with meta-sourcery at the moment17:44
paulgtwirck-user-1320,  yeah, i cant recall if we (yocto) enable /proc/config.gz by default, but if not you can find it in tmp/work/..../linux-yocto/4.1/....17:46
paulg(i.e.  in the build dir)17:46
*** lexano <lexano!> has quit IRC17:49
JaMakergoth: can you give a bit more context about the binutils armv5e issue?17:51
*** lexano <lexano!> has joined #yocto17:51
kergothgcc supports armv5e, but binutils doesn't. we carry a patch to add it, but upstream has rejected it17:52
twirck-user-1320thanks paulg, I dont see a .config anywhere in /tmp/work except for the following:17:52
kergothit's not being applied to binutils in the sourcery g++ builds at hte moment (though i might be able to ask them about that)17:52
JaMaso you need it to be armv5te?17:52
kergothsee meta/recipes-devtools/binutils/binutils/0007-Add-the-armv5e-architecture-to-binutils.patch17:52
kergothi think that's the case, yeah17:52
kergoththat's why i asked you about it, since afaik you made it only add the t suffix when ARM_INSTRUCTION_SET isn't arm by obeying ARM_M_OPT. so was asking if is hould revert that in this case, or just override DEFAULTTUNE directly17:53
paulgtwirck-user-1320, so in the build I have laying around here, i've got tmp/work/genericx86_64-overc-linux/linux-yocto-dev/4.1-rc++gitAUTOINC+45393dd54f_1c72757dbf-r0/linux-genericx86_64-standard-build/.config17:54
paulgyours will have a different path tmp/work/<distro-layer>/linux-yocto/<autorev>/<board-bsp>/.config17:55
* kergoth clearly isn't an expert on the arm tuning or instruction sets, hence the question17:55
paulglinux-yocto vs linux-yocto-dev 'cause I'm using the development kernel17:55
paulgtwirck-user-1320, this assumes you've actually built a kernel and not reclaimed one from sstate or similar magic.17:56
twirck-user-1320tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14.36+gitAUTOINC+162dfe3bb0_dbe5b52e93-r0 is empty...17:57
JaMakergoth: ok, so it's failing for you when building recipes which set ARM_INSTRUCTION_SET to arm, right?17:57
*** ambrosius <ambrosius!~textual@> has quit IRC17:57
*** belen1 <belen1!> has joined #yocto17:58
kergothI think so, since in that case it'll try to pass -march=armv5e. I don't recall offhand which recipe was failing in particular, but gcc accepts it, then the assembler chokes17:58
JaMakergoth: I'm a bit tired today, so excuse me, but I still don't see how binutils's as gets armv5e.. because IIRC my patches didn't change the CCARGs (or any *FLAGS)17:58
JaMaonly made the TUNE_PKGARCH to match with the options used in the build17:58
kergothTUNE_CCARGS=${@bb.utils.contains("TUNE_FEATURES", "armv5", " -march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)}...17:58
kergothit obeys ARMPKGSFX_THUMB17:58
kergothfor the -march17:58
JaMaso that ARM_INSTRUCTION_SET=arm recipe doesn't have "t" in PKGARCH17:59
JaMaright, that reminds me of this
kergothwhich is unintuitive, given the variable name is ARMPKGSFX_THUMB, explicitly mentioning PKG, but ..18:00
JaMachanging DEFAULTTUNE probably won't help, because DEFAULTTUNE only says which features are available for MACHINEs18:00
JaMaso ARM_INSTRUCTION_SET will still win (you can only disable thumb completely by selecting DEFAULTTUNE without thumb)18:01
JaMayou can also remove "arm" from TUNE_FEATURES to say that you never want to drop -mthumb (and "t" from ARMPKGSFX_THUMB), but that will break recipes which really fail to build with thumb18:02
*** belen1 <belen1!> has quit IRC18:02
JaMaso probably the best option would be to set only ARMPKGSFX_THUMB_armv5 in the tcmode*.inc file used by meta-sourcery with comment that binutils always expects armv5te even when building without -mthumb18:03
kergothif -mthumb is removed, but march is armv5te rather than armv5e, will that work fine, indicating that thumb is available, we just aren't using it?18:03
kergothokay, thats similar to what i was thinking18:04
kergothi'll go that direction, thanks18:04
JaMayes it should work18:04
kergoththat'll probably be a concern for any external toolchain, not just the sourcery one.. i should really separate what's specific and what's generic in meta-sourcery..18:04
JaMado you have some stats how many people are still interested in armv[45618:05
kergothso ARMPKGSFX_THUMB_armv5 = "${ARM_THUMB_SUFFIX}" should probably do it, i think18:05
kergothhmm, not offhand18:05
JaMawe're using own external toolchain, but I was never hit by this issue, because we're building only armv7a18:06
kergothah, that makes sense18:06
paulgtwirck-user-1320, "bitbake -c configure linux-yocto"18:06
paulgshould populate that dir and get you a .config file18:07
frayre arm.. arm 4..  very few.. but there are still a few arm 920T designs..  armv5, I still see a lot.. not sure about 618:08
kergothJaMa: actually, I get failures on more than just the ARM_INSTRUCTION_SET=arm recipes with qemuarm, even libtool-cross passes -march=armv5e and fails the do_configure compiler tests, as ARM_THUMB_OPT is arm whenever ARM_INSTRUCTION_SET isn't thumb, and i didn't set ARM_INSTRUCTION_SET globally to thumb.18:11
kergothjust as an fyi18:11
kergothi wonder if we shouldn't move to newer arm instruction set with qemuarm at some point18:11
kergothJaMa: btw, DEFAULTTUNE is viable without removing thumb if you don't need dsp, since armv5t == -march=armv5, which is supported by binutils upstream, it's just armv5e that isn't :)18:17
kergothbut the other solution is more general and is cleaner, so i'll do that :)18:17
*** atoztoa <atoztoa!~atoztoa@> has quit IRC18:17
*** ambrosius <ambrosius!~textual@> has joined #yocto18:20
twirck-user-1320paulg, strange, i ran bitbake -c configure linux-yocto, but never see a .config file generated. I did run "bitbake linux-yocto -c menuconfig", saved the file, and then ran "bitbake linux-yocto -c diffconfig" and get a good fragment file with the touchscreen modules, but I just never can find a .config being generated anywhere18:21
paulgodd.  not sure wtf is going on there.18:22
kergothare you looking in ${S} rather than ${B}, perhaps?18:23
paulgyeah, the kernel source is in work-shared, and the build is in work.18:23
kergothfolks are still getting used to that :)18:23
twirck-user-1320i take it back, I see a .config file here: tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14.36+gitAUTOINC+162dfe3bb0_dbe5b52e93-r0/linux-beaglebone-standard-build18:23
paulgthere you go, all is well with the world then.  :)18:24
twirck-user-1320thanks paulg. reading the docs now to see how to incorporate my changes in the .config (or include the fragment) and rebuild kernel18:28
*** berton <berton!~fabio@> has quit IRC18:34
*** berton <berton!~fabio@> has joined #yocto18:35
*** varibull_ <varibull_!> has quit IRC18:41
*** varibull_ <varibull_!> has joined #yocto18:41
*** Guest19913 <Guest19913!~quassel@> has quit IRC18:50
*** domidimi_ <domidimi_!~Dimitar@> has joined #yocto19:06
*** Guest3385 <Guest3385!> has quit IRC19:12
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has quit IRC19:26
*** alimon <alimon!~alimon@> has quit IRC19:36
*** alimon <alimon!alimon@nat/intel/x-lmmbnwulpbnuwsxe> has joined #yocto19:36
*** Jefro <Jefro!> has joined #yocto19:43
*** belen1 <belen1!> has joined #yocto19:57
*** hugovs <hugovs!~hugo@> has quit IRC20:01
*** belen1 <belen1!> has quit IRC20:06
*** vmeson <vmeson!~rmacleod@> has quit IRC20:13
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto20:17
*** JaMa <JaMa!> has quit IRC20:19
*** twirck-user-1320 <twirck-user-1320!~twirck-us@> has quit IRC20:20
kergothIt'd really be nice if task logging messages automatically included recipe and task name, so we don't have to do so manually, and inconsistently, in many cases.20:27
kergothwould be straightforward to implement..20:27
kergothcould do it in the UI since we already associate messages with task ids, iirc, or in bitbake via a logging adapter/filter20:27
* kergoth ponders20:28
*** zenx <zenx!~quassel@> has joined #yocto20:30
*** zenx is now known as Guest8920020:30
*** jimBaxter <jimBaxter!> has quit IRC20:35
*** staylor <staylor!> has joined #yocto20:37
fraywould be nice at least on the display side, since so many parallel activities can create a lot of output20:38
*** abelloni <abelloni!> has quit IRC20:41
*** grma <grma!> has quit IRC20:41
*** abelloni <abelloni!> has joined #yocto20:48
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:51
*** berton <berton!~fabio@> has quit IRC20:54
aehs29how would you do a conditional DEPENDS?20:54
aehs29could it be something like DEPENDS_foo and DEPENDS_bar?20:54
kergoththe same way you do conditionals anywhere else20:56
bluelightningaehs29: if it's conditional on something in OVERRIDES yes, otherwise it would be DEPENDS = "${@,,,}" with a python expression inside20:56
*** sid11 <sid11!0c1b4722@gateway/web/cgi-irc/> has joined #yocto20:59
sid11i am trying to get local instance of toaster working in analysis mode, while I type local host and port in browser it gives 501 error, im using ubuntu 14.1020:59
sid11any idea what could be wrong20:59
sid11i followed manual 3 times, still its ends up with same error, Am i missing some configuration ?21:00
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto21:00
*** lamego <lamego!~lamego@> has quit IRC21:01
*** vmeson <vmeson!> has joined #yocto21:01
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC21:02
*** lamego <lamego!~lamego@> has joined #yocto21:02
*** roric <roric!> has quit IRC21:02
*** ambrosius <ambrosius!~textual@> has quit IRC21:05
*** ambrosius <ambrosius!~textual@> has joined #yocto21:05
*** Jefro <Jefro!> has quit IRC21:06
kergothbluelightning_: hmm, have you seen a `ln: invalid option -- 'r'` in install_tools in populate_sdk_ext?21:06
*** domidimi_ <domidimi_!~Dimitar@> has quit IRC21:07
kergothah, i see. old host, it should be using poky's lnr script instead21:08
* kergoth tests that21:09
*** dmoseley <dmoseley!> has joined #yocto21:11
*** behanw <behanw!~behanw@> has quit IRC21:14
*** aehs29 <aehs29!~aehernan@> has left #yocto21:16
*** aehs29 <aehs29!~aehernan@> has joined #yocto21:17
*** sid11 <sid11!0c1b4722@gateway/web/cgi-irc/> has quit IRC21:18
kergoth made me sad21:18
kergothstill not ideal, makes a number of assumptions. ideally, we'd probably name the packages based on the actual locale name rather than the name of the subdir in locales, or have it automatically rename the dir based on the locale name from LC_NAME or whatever that file is..21:19
kergothsince afaict while the names of the subdirs might affect the list in `locale -a`, its their actual names in the files they include that controls when they're loaded21:20
kergothI really need to stop the hardcoded SUPPORTED bits with external toolchains as well in favor of programmatically determining what locales are supported by it21:21
*** sid11 <sid11!0c1b4722@gateway/web/cgi-irc/> has joined #yocto21:22
*** ambrosius <ambrosius!~textual@> has quit IRC21:32
*** ambrosius <ambrosius!~textual@> has joined #yocto21:39
*** sid11 <sid11!0c1b4722@gateway/web/cgi-irc/> has quit IRC21:41
*** lamego <lamego!~lamego@> has quit IRC21:43
*** nighty^ <nighty^!> has quit IRC21:44
*** aehs29 <aehs29!~aehernan@> has quit IRC21:50
*** SoylentYellow <SoylentYellow!> has joined #yocto21:50
*** aehs29 <aehs29!aehernan@nat/intel/x-mytaebncvsceivtw> has joined #yocto21:51
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC21:52
*** bfederau <bfederau!> has quit IRC22:01
*** bfederau <bfederau!> has joined #yocto22:01
*** tsramos_ <tsramos_!~tsramos@> has joined #yocto22:04
*** tsramos <tsramos!~tsramos@> has quit IRC22:07
*** tsramos_ <tsramos_!~tsramos@> has quit IRC22:09
*** lamego <lamego!~lamego@> has joined #yocto22:10
*** blueness_ <blueness_!~blueness@gentoo/developer/blueness> has quit IRC22:17
*** sameo <sameo!samuel@nat/intel/x-dzgloxsueebpymdn> has joined #yocto22:19
*** rburton <rburton!> has quit IRC22:33
*** bluelightning_ <bluelightning_!~paul@2001:8b0:258:7d7a:2ad2:44ff:fe40:9209> has joined #yocto22:34
*** bluelightning_ <bluelightning_!~paul@2001:8b0:258:7d7a:2ad2:44ff:fe40:9209> has quit IRC22:34
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto22:34
*** behanw <behanw!~behanw@> has joined #yocto22:42
*** DriverCoder <DriverCoder!mdrustad@nat/intel/x-gwgbnohkvbhnquwc> has joined #yocto22:47
*** realBigfoot <realBigfoot!~realBigfo@> has quit IRC22:52
*** anselmolsm <anselmolsm!anselmolsm@nat/intel/x-rwfnynuesdixdqdr> has quit IRC22:55
*** lamego <lamego!~lamego@> has quit IRC22:57
*** sjolley <sjolley!~sjolley@> has quit IRC22:59
*** aehs29 <aehs29!aehernan@nat/intel/x-mytaebncvsceivtw> has quit IRC23:02
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC23:03
*** sameo <sameo!samuel@nat/intel/x-dzgloxsueebpymdn> has quit IRC23:04
*** bluelightning <bluelightning!~paul@2001:8b0:258:7d7a:2ad2:44ff:fe40:9209> has joined #yocto23:04
*** bluelightning <bluelightning!~paul@2001:8b0:258:7d7a:2ad2:44ff:fe40:9209> has quit IRC23:04
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto23:04
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC23:07
*** aehs29 <aehs29!~aehernan@> has joined #yocto23:16
*** madisox <madisox!> has quit IRC23:17
*** aehs29 <aehs29!~aehernan@> has left #yocto23:22
*** DriverCoder <DriverCoder!mdrustad@nat/intel/x-gwgbnohkvbhnquwc> has quit IRC23:22
paulgcrap.  X segfaults in libpthread with latest builds on master ; only on intel gfx though, it seems.23:26
paulgdiffing logs between my last known working binary and today's, i see this:23:27
paulg-X.Org X Server 1.17.123:27
paulg-Release Date: 2015-02-1023:27
paulg+X.Org X Server 1.17.223:27
paulg+Release Date: 2015-06-1623:27
paulg...should be fun to track down.  :-/23:27
* paulg assumes from a yocto POV, this change came in as a single commit, so bisecting is out.23:28
*** sjolley <sjolley!~sjolley@> has joined #yocto23:31
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC23:34
kergothpresumably you could create a git recipe on the right tag, at each bisect adjust SRCREV to that?23:34
*** sjolley <sjolley!~sjolley@> has quit IRC23:36
paulgyeah, doing the google search 1st to see if anyone else has hit this already; if not I'll have to try sth like that tomorrow,.23:37
paulgthis looks similar ; will investigate more tomorrow.
*** paulg <paulg!~paulg@> has quit IRC23:40
*** sjolley <sjolley!~sjolley@> has joined #yocto23:48
*** staylor <staylor!> has quit IRC23:51

Generated by 2.11.0 by Marius Gedminas - find it at!