Tuesday, 2013-07-23

*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC00:04
*** hollisb <hollisb!~hollisb@nat-wv.mentorg.com> has quit IRC00:04
*** cetola <cetola!~cetola@74-92-165-193-Oregon.hfc.comcastbusiness.net> has quit IRC00:07
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto00:17
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC00:22
*** joeythesaint <joeythesaint!~jjm@206-248-190-39.dsl.teksavvy.com> has quit IRC00:57
*** _julian_ <_julian_!~quassel@x2f17b6e.dyn.telefonica.de> has joined #yocto01:00
*** _julian <_julian!~quassel@x2f04625.dyn.telefonica.de> has quit IRC01:03
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto01:20
*** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto01:43
*** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC01:44
*** myopiate <myopiate!~myopiate@203-206-170-6.perm.iinet.net.au> has quit IRC01:52
*** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto02:06
*** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC02:09
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC02:10
*** silviof3 <silviof3!~silviof@host-188-174-200-171.customer.m-online.net> has joined #yocto02:16
*** silviof2 <silviof2!~silviof@ppp-93-104-17-108.dynamic.mnet-online.de> has quit IRC02:18
*** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto02:48
*** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC02:49
*** davest <davest!Adium@nat/intel/x-jflfxzcsbfizjyvv> has joined #yocto03:06
*** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto03:11
*** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC03:14
*** yzhao2_ <yzhao2_!~yzhao2@> has joined #yocto03:30
*** yzhao2 <yzhao2!~yzhao2@> has quit IRC03:33
*** davest <davest!Adium@nat/intel/x-jflfxzcsbfizjyvv> has quit IRC03:33
*** davest <davest!~Adium@> has joined #yocto03:33
*** doerrpau <doerrpau!~doerrpau@cpe-70-124-65-123.austin.res.rr.com> has quit IRC03:39
*** davest <davest!~Adium@> has quit IRC03:41
*** davest <davest!Adium@nat/intel/x-hhruvpimojzetalt> has joined #yocto03:52
*** davest <davest!Adium@nat/intel/x-hhruvpimojzetalt> has quit IRC04:00
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto04:53
*** zeeblex <zeeblex!~apalalax@> has joined #yocto05:16
*** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has quit IRC05:33
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto05:52
*** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has joined #yocto05:58
*** agust <agust!~agust@p4FC460FC.dip0.t-ipconnect.de> has joined #yocto05:58
*** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has joined #yocto06:01
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC06:04
lpappwhen having a bsp layer, it is better to use .bbappend if the kernel is not different, just having custom configuration?06:06
Croftonlpapp, I would say yes06:24
*** mihai <mihai!mihai@nat/intel/x-ikclvczxdjrydgyw> has joined #yocto06:27
*** elmi82 <elmi82!~timo@mail.bmw-carit.de> has joined #yocto06:38
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC06:38
lpappand if custom patches are needed, I would need to "replicate" the packages in my layer?06:42
lpappit is not worth putting custom patches into the meta and meta-yocto layers at all?06:46
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto06:55
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto06:58
*** Guest68081 is now known as volker07:01
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto07:05
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto07:05
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC07:08
*** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto07:09
*** mckoan|away <mckoan|away!~marco@host56-7-static.30-87-b.business.telecomitalia.it> has joined #yocto07:09
*** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC07:09
*** mckoan|away <mckoan|away!~marco@host56-7-static.30-87-b.business.telecomitalia.it> has quit IRC07:09
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto07:11
mckoangood morning07:11
*** tbn <tbn!~tbn@> has joined #yocto07:15
*** tbn is now known as Guest9872507:16
lpapp"However, the dependencies should also contain information regarding any other dependencies the BSP might have." -> where can I set that dependency?07:17
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto07:20
*** sameo <sameo!~samuel@> has joined #yocto07:24
*** yzhao2 <yzhao2!~yzhao2@> has joined #yocto07:30
*** yzhao2_ <yzhao2_!~yzhao2@> has quit IRC07:33
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC07:43
*** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has joined #yocto07:46
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto07:52
*** slaine <slaine!~slaine@> has joined #yocto07:54
*** eballetbo <eballetbo!~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net> has joined #yocto07:56
*** slaine <slaine!~slaine@> has quit IRC07:58
Croftonlpapp, do you have a source of that line? I'm on holiday right now, so reponse time is pretty slow for me :)07:58
lpappCrofton: https://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html08:07
*** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto08:09
*** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC08:09
lpappbluelightning: it is not worth putting custom patches into the meta and meta-yocto layers at all?08:10
bluelightningmorning all08:11
bluelightninglpapp: unless they're general changes you're planning to upstream, no - otherwise you'll have to rebase those changes when you upgrade08:11
bluelightninglpapp: we have the layer structure in part to avoid such difficulties08:12
lpappbluelightning: k, thanks.08:12
lpappwhat about the local and site configs? Should I have those in each layer?08:12
*** _Lucretia__ <_Lucretia__!~munkee@> has joined #yocto08:13
bluelightninglpapp: no, those shouldn't be in any layer08:13
lpappalso, what about about patches backported from master to denzil to build on archlinux? Should they go into the existing layers or custom?08:13
lpappbluelightning: inside the build folder then?08:14
bluelightninglpapp: that's a little different... in that case you probably want to be maintaining a branch08:14
bluelightninglpapp: yes08:14
*** _Lucretia_ <_Lucretia_!~munkee@pdpc/supporter/active/lucretia> has quit IRC08:14
lpappbluelightning: maintaning a branch means?08:16
bluelightninglpapp: of poky08:16
lpappbluelightning: not sure I follow, mind elaborating?08:16
bluelightninglpapp: when you're talking about mostly backports it makes sense to just use a branch of the existing repo rather than trying to split out the changes as bbappends in a different layer08:17
*** jackmitchell <jackmitchell!~Thunderbi@host217-34-104-101.in-addr.btopenworld.com> has quit IRC08:17
lpappbluelightning: I am not using branches08:18
lpappbluelightning: I am working independently from the poky repository.08:18
lpappbluelightning: I download the tarball, and I backport changes to that when packaging.08:18
*** slaine <slaine!~slaine@> has joined #yocto08:20
bluelightninglpapp: for this kind of thing I think you make things harder for yourself if you don't use git, but that's up to you...08:21
lpappbluelightning: sorry?08:22
lpapphave you seen other distributions packaging?08:22
bluelightninglpapp: packaging of... ?08:22
lpappthey use the release, and then they have stabilization patches backported.08:22
lpapponce they get a usable release, they will drop their patches.08:22
lpappbut as far as I know, people do not care in Yocto to actually maintain a feature release.08:23
lpappwhich is sad, but that is how it is anyway.08:23
bluelightninglpapp: that's not correct, we maintain at least two stable releases back08:23
lpappbluelightning: why don't I see proper bugfix releases for the feature releases then?08:24
lpappalso, "two" is a weak argument when they release cycle is 6 months.08:24
lpappso basically, the software is taken care of, maximum up to a year.08:24
lpappand then end users are screwed with those releases.08:25
lpappanyway, do you plan to release a stable denzil any soon for arch?08:25
*** silviof3 is now known as silviof08:25
bluelightninglpapp: http://article.gmane.org/gmane.linux.embedded.yocto.general/14529/08:25
bluelightninglpapp: http://comments.gmane.org/gmane.linux.embedded.yocto.announce/4708:26
lpappbluelightning: dylan is far from denzil.08:26
bluelightninglpapp: I don't think we have any further denzil releases planned, no08:26
*** jackmitchell <jackmitchell!~Thunderbi@host217-34-104-101.in-addr.btopenworld.com> has joined #yocto08:26
lpappor even danny.08:26
lpappbluelightning: then why would I bother with git?08:27
lpappif Yocto does not care to maintain and release it?08:27
bluelightninglpapp: maybe because it makes backporting and maintaining a patch series trivially easy?08:27
lpappin any case, even with a release, we would need a solution _now_.08:27
bluelightningand git works, now08:27
lpappno, it does not.08:27
lpappwhat actually the packagers do out there at large, is what I wrote already: they use the release and then patches locally.08:28
bluelightningwell, I personnally maintain the dylan branch using git. If I could not use git to do that my job would be quite a lot harder.08:28
bluelightningunnecessarily so since git does exist and works well for the job08:28
lpappnot really, no.08:29
lpappYocto is a project, foo is another.08:29
bluelightningI'm giving you my advice, advice which comes not just from me but others who also maintain stable branches + backports for their own internal purposes08:29
*** honschu_ <honschu_!~honschu@shackspace/j4fun> has quit IRC08:29
lpappactually, for debian, it is pretty simple to apply a patch locally.08:30
bluelightningif you don't want to take my advice, feel free not to, but don't be surprised that it's hard to do what you're doing08:30
lpapponly thing needed is copying that into the patches folder, and append it to the patch file, done.08:30
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto08:30
lpappbluelightning: why would it be hard?08:31
lpappdebian, arch, etc packagers have been doing that for decades.08:31
*** honschu <honschu!~honschu@p549EBDB5.dip0.t-ipconnect.de> has joined #yocto08:31
*** honschu <honschu!~honschu@shackspace/j4fun> has joined #yocto08:31
*** forcev <forcev!~quassel@wafaa.eu> has quit IRC08:34
ant_worklpapp: OE/Yocto is *not* a distribution. It's not about upgrading a binary package on host08:39
*** frank <frank!~qiang@> has joined #yocto08:39
lpappant_work: yes, we all know.08:39
ant_workthen why do you insist comparing pears with apples?08:40
lpappno any clue what you are talking about.08:40
lpappbluelightning: also, just out of the curiosity, could I get omnipotence in the denzil branch?08:41
lpappi.e. unlimited commit rights, not allowing others to commit in, etc?08:41
lpappI do not think it would work anyway, so we need full control over our software.08:41
bluelightninglpapp: no, but you can send patches08:41
rburtonand of course you have complete control over your own branches08:41
rburtonwhat with git being a distributed VCS08:42
lpappbluelightning: you can see yourself it would not fit the business model for many, including me.08:42
lpappbluelightning: companies need full control over their software.08:42
frankHi, anyone can tell me how the rpm spec generated in yocto ?08:42
lpappbluelightning: but that kinda is besides the point as I do not see how git would simplify anything after all.08:42
bluelightninglpapp: and, you can have that08:42
lpappto me, it would be a complication.08:43
bluelightningfrank: sure, the code that does it is in meta/classes/package_rpm.bbclass08:43
lpappbecause we could not use the release tarball after all.08:43
lpappyet another complication step.08:43
*** ivali <ivali!~ivali@unaffiliated/ivali> has joined #yocto08:44
frankbluelightning: Thanks a lot ! I'll take a look at the file.08:44
bluelightninglpapp: in the time you've been here arguing about it you could have cloned the repository, cherry-picked the patches you want and you'd be well on your way to starting a build08:45
ivaliHow can I make a global clean to poky?08:45
lpappbluelightning: except a few things:08:45
lpapp1) I do not have git access right now08:45
bluelightninglpapp: you don't need git access08:45
lpapp2) Monkey work only comes after a good decision which is hardly git.08:45
bluelightningivali: depends... if you want to clear everything out completely just delete TMPDIR (tmp/ under your build directory by default) and sstate-cache08:46
lpappit is usually a weak attempt to argue for doing monkey work instead of thinking and discussing the design.08:46
bluelightningivali: that's quite a drastic measure though, usually that's not necessary08:46
lpappwhich is for long term and good.08:46
ivalibluelightning, i can't figure out why poky is trying to use some old version of a .bb file, even though i modified it08:48
ivalirecompiling now ..08:48
lpappbluelightning: any plans to actually support a software and maintain it for more than maximum a year.08:49
lpappYou know, companies are a bit more interested in a product for more than a year ...08:49
lpappto me, this also differentiates ubuntu and co from Yocto.08:49
rburtonlpapp: yocto project isn't a company, there are many companies that offer commercial support for many years (up to 7, iirc)08:49
lpappThey at least care about maintaining the software for a while.08:49
lpappso their software will be reliable in two years time, too.08:50
bluelightningivali: if you want to be completely sure of which file is being used you can do bitbake -e recipe | grep ^FILE=08:50
lpapprburton: Actually, Yocto is under a foundation.08:50
lpappit employs people for money.08:50
ivalibluelightning, thanks08:50
lpappIntel also sponsors developers working on it.08:50
rburtonlpapp: yes. me.08:50
lpappnote how you get lts for ubuntu, linux kernel, etc.08:50
lpapprburton: I know.08:50
*** Stygia <Stygia!~gmpsaifi@0904ds6-noe.0.fullrate.dk> has joined #yocto08:54
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC08:56
*** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC08:56
*** zeeblex1 <zeeblex1!apalalax@nat/intel/x-gakyprcwjynfsqte> has joined #yocto08:56
*** zeeblex <zeeblex!~apalalax@> has quit IRC08:56
*** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto08:58
ndecthese discussions aren't going anywhere... i wonder how come this community is so nice under such circumstances... you guys definitely need some sort of reward, or at least public recognition for being *that* nice.08:58
ndecit would be a wonderful experience if that person ever start contribution/discussion on lkml.08:58
bluelightningndec: I'm told such a discussion did happen recently on LAKML09:00
ndecwell, that was i think a more valuable discussion than ours...09:01
bluelightningI didn't read it myself09:01
*** belen <belen!Adium@nat/intel/x-gtzrabjhoqijecrb> has joined #yocto09:01
ndecoh. lamkl... i thought you were referring to *the* lkml discussion from last week.09:01
bluelightningyeah, not the LKML one09:01
*** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto09:08
*** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC09:10
*** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has joined #yocto09:15
*** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC09:15
*** lpapp <lpapp!~lpapp@> has joined #yocto09:20
lpapphow can I list the dependencies for my own layer?09:21
frankI wonder how *.bbclass executed, they're mixed python and shell code, right ?09:21
rburtonfrank: <insert bitbake magic>09:23
lpappfrank: bitbake can handle shell and python as well, yeah.09:24
rburtonlpapp: bitbake-layers?09:24
lpapprburton: ?09:25
rburtonlpapp: i'm recommending a tool that might do what you want09:25
lpappcan you recommend a tool which at least has a help output?09:26
frankrburton: bitbake magic ? you mean insert python flag for python code sections as like ?09:26
rburtonlpapp: ah, works for me.  must have been broken in denzil, sorry. probably just a bad import, the error is clear.09:27
lpapprburton: maybe python 3 issue.09:28
rburtonfrank: bitbake has an internal shell parser and will emit sh functions into the run scripts it generates, and will eval() python blocks into functions it can call.09:28
zibrifrank: the python and shell fragments are extracted from the bb files and then executed.09:28
*** zerus <zerus!~epetmab@90-224-44-236-no67.tbcn.telia.com> has joined #yocto09:34
frankrburton and zibri : I see~~ bitbake firstly process the bbclass files to the tmp/work/***/PN-PR/temp/run.****, then execute from the generated file ?09:35
rburtonsort of.09:35
*** sameo <sameo!~samuel@> has quit IRC09:37
*** belen <belen!Adium@nat/intel/x-gtzrabjhoqijecrb> has quit IRC09:43
frankthanks, rburton09:44
lpappthis bitbake-layers is pretty untalkative tool09:55
lpappThe BBPATH variable is not set09:55
lpappwhat BBPATH, how, where, when?09:55
mihailpapp: source oe-init-build-env before using bitbake-layers09:58
lpappmihai: that happened09:58
mihailpapp: and set your default python to 2, instead of 309:58
lpappof course.09:58
lpappas I could not use bitbake without sourcing anyway09:58
lpappin any case, is there a hidden option to make it more talkative and dump more useful outputs?09:58
mihailpapp: what's listed in --help is all there is09:59
lpappso basically nothing.09:59
lpappsound ... :(09:59
*** belen <belen!~Adium@> has joined #yocto09:59
lpapphopefully these basic tools will improve in the future.10:00
lpapplike 1) Having a help output in the first place 2) Command outputs resulting something productive. etc10:00
rburtonlpapp: yes. patches welcome if you have a scratch to itch.10:00
ant_worklpapp: rpjday the author is surely interested to hear your comments for improvements10:00
rburtonlpapp: http://pastebin.com/BAuh8Kzk <-- this is what i see when i run it, so there is "help output"10:01
lpapprburton: there is no help output for me, no.10:01
lpappant_work: well, the first important fix would be to have a help output.10:01
rburtonlpapp: that was probably fixed in the last year, remember denzil is from april 2012.10:01
lpappant_work: perhaps the denzil bitbake-layers version is too old and hence buggy.10:01
bluelightningant_work: kergoth started it and I believe I wrote most of the rest of it with the exception of show-cross-depends (+ patches from others of course)10:02
lpapprburton: I am very surprised that help output was not the first feature implemented.10:02
lpapprburton: in fact, the cli parser module in python manages that for you by default.10:02
*** zerus <zerus!~epetmab@90-224-44-236-no67.tbcn.telia.com> has quit IRC10:03
lpappdenzil is probably useless to go for.10:04
frankanyone can tell me why libnfsidmap0 was made an rpm package instead of libnfsidmap, after I run "bitbake libnfsidmap" ?10:04
lpappI wish we could easily update, but it is a pain with a hardware adaptation layer... :(10:04
frankI wonder where the '0' comes from ?10:05
rburtonfrank: library version10:05
rburtonfrank: debian.bbclass does the renaming, if a package contains just a versioned library.10:06
lpappso any way to specify layer dependencies with denzil?10:06
lpappsee, this is exactly what I meant by no care about a bit more than one year old software10:06
lpappeven basic tools are broken.10:06
bluelightninglpapp: it produces help output perfectly fine here, I just tested it10:07
bluelightning(using denzil)10:07
lpappbluelightning: ok, but that does not make me work magically. :)10:07
frankrburton: it makes sense. thanks !10:07
lpappso is there a way to do it manually without the smart, but non-working tool?10:08
*** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto10:09
*** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC10:10
lpappor denzil does not support custom layers then, I take it?10:11
rburtonit does, oe-core always has supported layers.10:13
lpappif it did, it would work for mer.10:13
lpappso tell me how to make the help output work then.10:13
lpappif it does, you will know.10:14
lpappif if it is buggy, then it is more productive to be sincere, it does not fully support it, and I hit the "not fully" category.10:14
rburtonbluelightning said it worked for him, so either you've invoking it differently or there's a bug that I can't magically help without you giving me a login on your machine.10:15
lpappif it is invoked incorrectly, it *should* tell it.10:16
lpappwhich means there is a bug either way.10:16
lpappso for me, it does not quite qualify as usable, and something that can handle a custom layer.10:16
lpappit's been an hour I am trying to get it work10:16
lpappno clue how, really.10:16
lpappreading upon some information on the internet how to do it manually if that is even possible with this buggy denzil.10:17
rburtonbitbake-layers is just an introspection tool, you can still use layers without it.10:17
lpapphow ?10:18
rburtonwell, you already are. oe-core is a layer. meta-yocto is a layer.10:18
lpappLAYERDEPENDS maybe.10:18
lpappI am explicitly not talking about oe-core, nor meta-yocto10:19
lpappI am actually talking about a custom layer.10:19
rburtonthat's just semantics, oe-core and meta-yocto are not special in any way.10:20
lpappthey are.10:20
lpapp1) oe-core: it has no dependencies10:20
lpapp2) meta-yocto: it actually does not mention oe-core as dependency.10:20
lpappthey are special to my case as I would like to specify dependency layers.10:20
rburton1) that's just a statement.  2) we should fix that.10:21
lpappLAYERDEPENDS_hob = "core" -> that seems to be a good example.10:22
lpappI might send a patch against meta-yocto to depend on core similarly.10:23
rburtonsounds like a sensible thing to do indeed.10:23
JaMarburton: any idea why current weston doesn't recognize --disable-libunwind option?10:24
rburton"configure: WARNING: unrecognized options: --disable-android-compositor"10:25
rburtonworks for me10:25
rburtonshould remove that android option though )10:25
JaMa1.0.6, right?10:26
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto10:26
rburtonah, 1.1.010:26
rburtonunwind is new in 1.110:26
*** ErkiS <ErkiS!~erki@pro01.dcc.ttu.ee> has joined #yocto10:27
JaMaok, I'll backport it into 1.0.6 for dylan, because it autodetects libunwind10:28
rburtonhuh, i thought unwind itself was new in 1.110:28
JaMarburton: sorry for noise (I thought I've seen it in dylan too)10:28
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC10:28
rburtonah so it is10:29
JaMarburton: http://pastebin.com/AUETam3i10:29
JaMathe option to disable it is new10:29
rburtonyeah, so i see10:30
lpapprburton: the patch should go into the meta-yocto repository and master branch?10:32
lpappor master-next?10:32
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto10:33
rburtonlpapp: you just send the patch, don't worry about the workflow between that and it reaching master.10:33
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto10:35
lpapprburton: to be honest, I have not used git send-email lately.10:39
lpappand I do not have the sake to set up all the stuff for it to work.10:40
rburtonits just a matter of telling it your smtp server10:40
lpapprburton: well, it is a hassle to set up, especially with email aliases.10:41
lpapp1) I use archlinux.us which is a gmail based service, but different domain10:44
lpapp2) I use the lpapp@kde.org alias10:44
lpappgluing it all together is effort.10:44
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC10:45
*** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto10:50
lpapprburton: ok, ssmtp is set up.10:55
*** ivali <ivali!~ivali@unaffiliated/ivali> has quit IRC10:59
*** jwessel <jwessel!~jwessel@> has quit IRC10:59
*** erbo <erbo!~erik@host.> has quit IRC10:59
*** fray <fray!U2FsdGVkX1@gate.crashing.org> has quit IRC10:59
*** RP <RP!~richard@dan.rpsys.net> has quit IRC10:59
*** erbo <erbo!~erik@host.> has joined #yocto10:59
lpappwhich mailing list should I send the change to?10:59
*** RP <RP!~richard@dan.rpsys.net> has joined #yocto10:59
*** jwessel <jwessel!~jwessel@> has joined #yocto10:59
*** fray <fray!U2FsdGVkX1@> has joined #yocto10:59
lpappyocto@yoctoproject.org ?11:00
*** swex <swex!~swex@> has joined #yocto11:02
rburtonlpapp: for meta-yocto, poky@.11:05
*** swex__ <swex__!~swex@> has quit IRC11:05
lpapprburton: already sent to yocto@11:05
*** zerus <zerus!~epetmab@90-224-44-236-no67.tbcn.telia.com> has joined #yocto11:06
lpapprburton: I guess I cannot depend on a yocto layer right now either.11:07
lpappas it is not specified.11:07
lpappor I can?11:08
lpappI mean for my own bsp layer.11:08
rburtona bsp layer shouldnt depend on meta-yocto anyway11:08
rburtona BSP layer should be standalone from any distro layer, such as meta-yocto.11:08
lpappit is a BSP _and_ distribution layer.11:08
rburtonwe recommend that you split them11:08
rburtonyour choice, of course.11:09
lpappyeah, I appreciate the recommendation, but I will not for now.11:09
lpappso can something depend on meta-yocto without the dedicated entries?11:09
*** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto11:09
lpappis there a default "yocto" dependency by its name?11:09
lpappby its file name, etc, that is.11:09
*** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC11:10
*** ivali <ivali!~ivali@> has joined #yocto11:11
*** ivali <ivali!~ivali@unaffiliated/ivali> has joined #yocto11:12
rburtonlpapp: only bblayers.conf11:12
lpappso patches mentioned in the SRC_URI will be applied by default without an explicit intervention?11:12
lpapprburton: what do you mean?11:13
rburtonlpapp: the only places where layer filenames are is bblayers.conf11:13
rburtonlpapp: and yes, a .patch file will be applied automatically unless you tell it otherwise11:13
lpapprburton: do_patches is the way to tell it otherwise?11:14
rburtonlpapp: no, see apply in http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-SRC_URI11:14
lpapprburton: but how can I depend on meta-yocto in meta-foo then?11:14
lpappLAYERDEPENDS_foo = "yocto" -> can I use this already?11:15
rburtonlpapp: yes11:15
rburtonyou don't need the dependency from yocto->core to depend on yocto11:15
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC11:36
*** synthnassizer <synthnassizer!~quassel@> has joined #yocto11:39
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto11:40
*** joeythesaint <joeythesaint!~jjm@> has joined #yocto11:45
lpapprburton: shall I resubmit my change against poky@?11:47
lpapprburton: also, for that matter, perhaps the oe-core layer should have versioning as well?11:55
g0hl1nHello everybody,11:59
g0hl1nwhat's the best-practice way to change the splash screen?11:59
lpappg0hl1n: I am not sure what the best practice is, but12:00
lpappI put it into meta/recipes-core/psplash/12:00
lpapparguably, you could put it into your meta-$distro.12:01
lpappg0hl1n: but I do not know how to do that, and when I asked the same question here yesterday, I did not get any replies.12:02
*** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has quit IRC12:02
lpappprobably you will need a minor .bbapend, but do not take me seriously.12:02
g0hl1nlpapp: Thanks! ... but how can I put it into my meta directory? Copying the whole psplash?12:02
*** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has joined #yocto12:03
lpappg0hl1n: don't you yet have an own meta-$distro layer?12:03
g0hl1nlpapp: of course I have one.12:04
g0hl1nlpapp: but is the whole psplash folder of meta-core needed or would a bbappend be sufficient?12:05
lpappg0hl1n: I would use a .bbappend then with SRC_URI extended.12:05
lpappyou do not modify the script, so I think .bbappend is ok.12:05
lpappit is similar to when you create a custom bsp layer12:05
lpappand you have your own kernel config with .bbappend.12:06
lpappbut honestly, I am not an expert.12:06
lpappso you may want to hear others, too.12:06
g0hl1nlpapp: Thank you.12:06
g0hl1nlpapp: As long as it works it might be ok for me :)12:06
lpappg0hl1n: I am in the same boat.12:07
lpappI just need to do the work, but I will probably do what I explained. Of course, I will stand corrected if someone has a better idea.12:07
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC12:09
lpappso the patch order is the one they are mentioned in the SRC_URI?12:09
*** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto12:09
*** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has joined #yocto12:09
*** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC12:10
*** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has quit IRC12:10
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto12:10
bluelightninglpapp: yes12:11
bluelightningg0hl1n: have a look at what meta-yocto does, it uses a bbappend to change the splash screen12:12
g0hl1nbluelightning: thanks !12:15
bluelightningg0hl1n: as a slight difference, you can point to a .png file in SRC_URI rather than a header and that will be converted automatically12:16
lpappbluelightning: why do projects use header then?12:19
lpapplegacy reason or what?12:19
lpappbluelightning: I do not find any explanation for do_patch12:19
bluelightninglpapp: legacy, plus you avoid having to build gdk-pixbuf-native12:19
lpappand for any task, for that matter.12:19
lpappthat is actually a good reason why not to use png...12:20
lpappnot to slow the build down.12:20
*** sameo <sameo!samuel@nat/intel/x-gwkyzfpykwjckqyv> has joined #yocto12:22
lpappbluelightning: the psplash image though should go into the meta-$distro, right?12:22
bluelightninglpapp: correct12:23
lpappbluelightning: denzil does not use .bbappend for meta-yocto though when it comes to recipes-core/psplash. :/12:23
bluelightninglpapp: er... ??? it does here12:25
bluelightningeven the very first denzil release does12:25
lpappbluelightning: sounds all kind of weird then.12:25
bluelightningI'd have to agree12:25
lpappour guy patched that out12:26
lpapphe needs some punishment. :)12:26
bluelightningI see...12:26
TuTizzHi there, on file meta/classes/sanity.bbclass line 331,87 if I delete the " " I did not got the error "Your version of make 3.82 is broken. Please revert to 3.81 or install a patched version." again. Where should I propose this modification? I saw this patch http://patches.openembedded.org/patch/51937/ but I cannot comment12:27
lpappbluelightning: so with priority 6, my psplash will be preferred instead of the meta-yocto poky stuff?12:28
bluelightninglpapp: priority does not determine whether or not bbappends will be applied, it determines which recipe will be selected if two are in separate layers with different priorities and there is no PREFERRED_VERSION setting to override it12:31
bluelightninglpapp: also, it determines the order in which bbappends will be applied if more than one layer applies one to a recipe12:31
lpappyes, so the short is "yes" then.12:31
bluelightninglpapp: with priority 0 it would be applied, with priority 999 it would be applied; priority is not a factor12:32
lpappbluelightning: it is12:32
lpappbluelightning: because it means the poky psplash stuff is not picked up12:32
lpappoh, really?12:33
lpappthen, I am totally lost12:33
lpappI thought that is what priority is exactly for.12:33
lpappto pick up the package (even if just bbappend) which has a higher priority.12:33
bluelightningsee above for my explanation about exactly what the priority does12:33
*** roric <roric!~roric@194-237-7-146.customer.telia.com> has quit IRC12:33
lpappI cannot follow that, sorry.12:33
lpappyou need to rephrase or elaborate more.12:33
lpappyou are claiming that priority does matter which package is picked up.12:34
lpappthen you are claiming, priority does not matter because my recipe will be picked up all the time.12:34
bluelightninglpapp: you have abc_1.23.bb in meta-firstlayer and abc_1.23.bb in meta-secondlayer12:34
lpappthat is contradictory to me.12:34
bluelightninglpapp: in that case the priority will choose which one gets built, assuming there is no PREFERRED_VERSION to override that12:35
lpappmeta/recipes-core/psplash/psplash_git.bb exists.12:35
lpappand then there are bbappends in meta-firstlayer and meta-secondlayer12:36
lpappI wanna get rid of the append for firstlayer12:36
bluelightninglpapp: another example, we have meta-firstlayer with abc_1.23.bb, meta-secondlayer with abc_1.23.bbappend and meta-thirdlayer also with a abc_1.23.bbappend12:36
lpappand apply stuff from my custom secondlayer12:36
lpapphow can I do that?12:36
bluelightninglpapp: both of the two bbappends will be applied, in the order dictated by the relative priorities of the second two layers12:36
lpappsounds like a feature request then.12:37
bluelightninger, no...12:37
lpappit is definitely a valid use case to allow me to skip a bbappend12:38
lpappand apply mine12:38
lpappand only mine.12:38
bluelightningif you want yours applied, see the second example12:38
bluelightningor rather, if you want yours applied last12:38
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto12:39
lpappno no12:39
lpappI do not wanna get both applied12:39
lpappI wanna get mine applied, and only that.12:39
lpappI think it is a valid use case and hence feature.12:39
lpappI do not wanna get both applied12:39
lpappsurely, it is not a problem for small changes.12:39
lpappbut for huge changes, it is an unnecessary overhead, that is.12:40
lpappso as a workaround for now: the poky image is applied, and then mine, too?12:41
lpappand mine will be the last if the layer containing it, has a higher priority than meta-yocto?12:41
ndecyou could 'mask' the offending recipe too, perhaps, no?12:42
erenwhen we create hdimage, or "iso", can it be directly "dd"ed into compact flash drive?12:42
erenif not, how can we bring together isolinux, kernel, rootfs so that the only needed command is "dd" to compact flash or usb?12:42
lpappbluelightning: the problem is not when the second application can block the first12:42
lpappby overriding it.12:42
lpappbluelightning: the problem is that, when they are actually different changes.12:42
lpappbluelightning: and you do not wanna take that.12:43
bluelightningndec: BBMASK would work to exclude recipes or appends yes... I don't advocate its common usage though because it's a huge hammer and can lead to unresolved dependencies if used inappropriately12:43
lpappbluelightning: then you will be screwed.12:43
bluelightninglpapp: that's not going to be the case in this instance12:43
lpappbluelightning: not here, but I have places where it will be though.12:43
lpapphttp://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/tree/meta-yocto/recipes-core/psplash/psplash_git.bbappend -> PRINC = "1" was eliminated, interesting.12:44
*** roinn <roinn!~roinn@> has joined #yocto12:44
lpappok, semi-clear from the log.12:44
bluelightningeren: I'm not entirely sure, I suspect our iso's can't currently be used in that way12:45
bluelightningeren: hence why we have live images that can12:45
bluelightningeren: a lot of the deployment stuff is planned to be reworked very soon which should address these kinds of concerns12:46
erenbluelightning: so, I should chose "live" for image type?12:46
-YoctoAutoBuilder- build #221 of nightly-mips is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-mips/builds/22112:46
bluelightningeren: yes for something you can dd to a USB stick12:47
erenotherwise, I need to manually install "grub", copy sysroot and kernel etc12:47
lpappbluelightning: shsh, the guy put the custom image header into meta12:47
lpappnot even meta-yocto12:47
lpappdouble punishment. :)12:47
*** roinn <roinn!~roinn@> has quit IRC12:47
bluelightningeren: indeed12:47
erenbluelightning: ok, I have ALIX 3D3 board which is a regular x86-compatible device. I guess "live" image would be OK for it12:48
*** roinn <roinn!~roinn@> has joined #yocto12:48
lpappdo people use recipes-core/images a lot to create custom images?12:48
erenthe arch is i586, I even have a BSP for starting12:48
bluelightningeren: I would think so yes... occasionally there can be issues depending on what kind of BIOS the board has on it12:48
lpappthere are no fpga recipes around yet anywhere?12:49
bluelightninglpapp: as a basis, quite often I think12:49
erenokkie, I will try that, then12:49
lpappfor xilinx, altera, etc?12:49
bluelightninglpapp: xilinx provide their own layers for stuff, I think altera has something as well but I'm not sure of the details12:50
lpappyeah, just found that on layer index.12:51
*** JaMa <JaMa!~martin@ip-62-24-80-145.net.upcbroadband.cz> has quit IRC12:53
*** flynn378 <flynn378!80db310d@gateway/web/freenode/ip.> has joined #yocto12:55
*** flynn378 <flynn378!80db310d@gateway/web/freenode/ip.> has joined #yocto12:56
lpappbluelightning: what to do with ../../../meta-yocto/conf/foo-local.conf and ../../../meta-yocto/conf/site-foo.conf files we had?13:00
bluelightninglpapp: depends, what's in them that's not in the default unmodified local.conf?13:01
lpappbluelightning: I do not see default in here: http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/conf13:05
bluelightninglpapp: try: http://cgit.openembedded.org/openembedded-core/tree/meta/conf13:06
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-uwjfatdnkgfcybuj> has joined #yocto13:06
lpappbluelightning: I have not actually seen "meta" in here, http://cgit.openembedded.org/meta-openembedded/tree/13:07
lpappah, it is oe-core13:07
bluelightningTuTizz: sorry, which " " ?13:08
lpappbluelightning: interesting, the poky release do not come with examples.13:09
lpappbut that is probably OK ...13:09
bluelightninglpapp: in poky the equivalents are under meta-yocto/conf/13:09
lpappour site.conf is equal to the sample.13:10
lpappso is our local.conf to the sample (note, not extended).13:11
lpappbluelightning: so just copy those samples over to meta-foo/conf/?13:12
bluelightninglpapp: no, you shouldn't do that13:12
lpappbluelightning: then what?13:13
bluelightninglpapp: what are you trying to accomplish particularly if the files are the same as the sample ones?13:14
TuTizzbluelightning, this is the 87th char (with vi) : makefile_test.a( makefile_test_a.c makefile_test_b.c) become makefile_test.a(makefile_test_a.c makefile_test_b.c) no space between "(" and "m"13:15
bluelightningTuTizz: I'm not sure if that's there deliberately13:16
bluelightningTuTizz: if the test fails on your system it's likely you have the version of make 3.82 with one or more of the issues in it13:16
TuTizzbluelightning, ok, should I write something about it?13:17
bluelightningTuTizz: you can feel free to post a question to the mailing list13:17
TuTizzbluelightning, ok13:20
*** davest <davest!Adium@nat/intel/x-ejgjdmrxdeeegxed> has joined #yocto13:20
lpappbluelightning: porting an existing code to a more modularized13:22
lpappperhaps it had an intent13:22
lpappwhich needs to be revisited later.13:22
lpappbluelightning: I will just copy over for now.13:23
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has quit IRC13:25
*** JimNH2 <JimNH2!~jmchale@23-25-235-113-static.hfc.comcastbusiness.net> has joined #yocto13:25
lpappbluelightning: should I resubmit my yocto patch against poky@?13:26
bluelightninglpapp: it would be preferable yes13:27
*** JimNH3 <JimNH3!~jmchale@23-25-235-113-static.hfc.comcastbusiness.net> has quit IRC13:29
lpappbluelightning: done13:31
lpappbluelightning: do these make any sense in the layer conf? http://paste.kde.org/~lpapp/p63f02b8d/13:32
silvioferen: the meta-fsl-arm layer makes a sdcard image - you can look how they do it...13:32
erensilviof: okkie13:32
bluelightninglpapp: the setting of PATH and COREBASE sets off alarm bells13:34
bluelightninglpapp: if you're setting COREBASE and QEMUIMAGETESTS solely because that's what OE-Core's layer.conf does, don't do that13:35
*** walters <walters!walters@nat/redhat/x-rcqaayzvoidkhzrg> has joined #yocto13:36
rburtonmorning walters13:36
waltersrburton: good morning!13:37
erenthe moment that you cannot remember why you coded, add configuration in such a way13:37
lpappbluelightning: I agree.13:37
erennow I should read the kernel article from the start, check out kernel metadata and play with it13:37
lpappbluelightning: http://paste.kde.org/~lpapp/pb97a98de/ -> not sure if the first makes any sense13:40
lpappI saw this somewhere.13:40
lpappI mean it is already coded into the second line.13:40
bluelightninglpapp: the old convention was BBFILES := "${BBFILES} ..."; you should use BBFILES += "..." instead13:41
*** ruben__ <ruben__!~ruben@> has joined #yocto13:44
lpappbluelightning: yeah, so removing the first line13:45
lpappand s/:=/+=/ on the second.13:45
bluelightninglpapp: and remove ${BBFILES}13:45
ruben__hello, has anybody beaglebone black with yocto?13:45
lpappbluelightning: yes13:45
erenis there a problem with git repository?13:45
erenit is really slow13:45
lpappbluelightning: is it a common practice in third-party projects to check in downloaded files?13:46
lpappit seems to me.13:46
lpappit avoiding the downloading of lots of stuff.13:46
erenI'm in the university network, it has 20mbit of output13:46
bluelightninglpapp: not sure what you mean... ?13:46
ndeclpapp: not checked in per-say. but creating your local mirror, yes certainly a good practice.13:46
lpappbluelightning: downloads folder in the build foler.13:47
ndece.g. we have our own at linaro, http://snapshots.linaro.org/openembedded/sources. which is 'close' to the builders.13:47
*** JaMa <JaMa!~martin@ip-62-24-80-145.net.upcbroadband.cz> has joined #yocto13:47
erenoh damn, there is a huge lag to level3 network :(13:47
ndeclpapp: for the 'build' folder, you should not do anything with it. what is probably good practice is to mirror the sstate folder.13:48
ndecthough i have no idea what sstate was in denzil ;-)13:48
rburtonlpapp: putting downloads and sstate on a central server would be entirely sensible.  don't check them into a repo, just share the directory.13:49
ndecrburton: is there any standard tool to upade a sstate mirror at the end of a build?13:50
ndecor is it expected that the 'builder' has write access to sstate directly?13:50
rburtonndec: not afaik.  one option it just to use a NAS and nfs/smb mounts.13:50
lpapprburton: more work13:50
ndecrburton: sure.13:51
rburtonlpapp: checking into a vcs server your entire downloads directory would be ... odd.  you'd kill many systems for a start.13:51
lpapprburton: not entirely sure what you mean.13:51
ndeclpapp: i think you mentioned you don't want to use git for 'poky' release, so it would be even more odd to use git for the 'sources' ;-)13:52
lpappndec: no no13:52
lpappndec: I mentioned I do not wanna use the upstream git repository13:52
rburtoni'm just saying don't check into a VCS your downloads or sstate, because the files wouldn't suit that.  just http or nfs will do.13:52
lpapplet us not lose the important bits during the translation13:52
rburtonoh goodie "windows system support" have just called.13:53
lpapprburton: not sure what you mean13:54
lpappmany people have been doing that for ages, and it just works (tm)13:54
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC13:55
rburtonfine, do it if you know best.   personally I wouldn't put 21G of tarballs (my downloads) or 217G of tarballs (my sstate) into a git repo as large binary files are the pathological case for most VCS systems.13:56
lpappit is not about who knows best.13:57
lpappit is about that it works.13:57
lpappit is not best, but it is not worth the trouble either to do it urgently.13:57
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-uwjfatdnkgfcybuj> has quit IRC13:58
*** bluelightning_ <bluelightning_!~paul@> has joined #yocto14:00
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto14:00
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-mqgkazthmbohiacr> has joined #yocto14:00
*** mihai <mihai!mihai@nat/intel/x-ikclvczxdjrydgyw> has quit IRC14:00
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC14:00
*** bluelightning_ is now known as bluelightning14:00
*** sameo <sameo!samuel@nat/intel/x-gwkyzfpykwjckqyv> has quit IRC14:01
*** mihai <mihai!~mihai@> has joined #yocto14:01
lpappbluelightning: is it worth cleaning up the recipes?14:04
lpappat several places, there are multiple versions, like u-boot.14:04
lpappso how do the recipe writers update the checksums? Everyone manually invoking the tools, and copy pasting output, etc?14:05
lpappand then fixing bugs due to copy paste and other silly issues?14:05
bluelightninglpapp: so with u-boot I don't know why we have multiple versions14:05
lpappbluelightning: at least,  I should not copy the old versions to my layer as well, I guess.14:06
bluelightninglpapp: with some other recipes we do deliberately provide the most recent GPLv2 version when the license has been changed to GPLv3, for those who want to avoid GPLv3-licensed software in their images14:07
bluelightninglpapp: no, you'd just have one version since that's likely all you would need14:08
lpappbluelightning: ok, any reason why we do not have only a u-boot package rather than fw-utils, mkimage, etc?14:08
bluelightninglpapp: probably because the tools need to be built for the host whereas we want u-boot itself built for the target14:09
lpappbluelightning: yeah, but there are three packages instead of two, even then.14:10
bluelightninglike I said, I don't know why we have multiple versions of u-boot14:10
lpappbluelightning: it is not versions.14:10
lpappit is multiple packages for the same version.14:11
lpappfw-utils, mkimage, and u-boot.14:11
bluelightningu-boot is the bootloader, u-boot-mkimage is for creating the uimage file, no idea what u-boot-fw-utils is14:12
lpappyes, I know what they are.14:12
lpappI just do not understand why they need three packages.14:12
lpappanyway, how about the question above:14:13
lpappso how do the recipe writers update the checksums? Everyone manually invoking the tools, and copy pasting output, etc?14:13
lpappand then fixing bugs due to copy paste and other silly issues?14:13
bluelightningyes and in practice that's rarely a problem at least in my experience14:13
lpappwould not it be handy to just run a tool anyway?14:14
lpappcopy/paste errors not a problem in practice?14:14
lpappwell, look for programming forums all around.14:14
rburtonlpapp: automatically updated checksums would invalidate the point, which is a human being verified them.14:15
lpapprburton: I really do not know what you mean14:16
lpappthe checksum would come from the output of the tool14:16
lpappexactly what you do _manually_14:17
rburtonby manually you mean "run bitbake"14:17
rburtonfeel free to write a tool if you want though14:18
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has joined #yocto14:18
lpapprburton: nope14:18
lpappmanually, I mean md5, etc commands14:18
lpappwhich will provide you the crcs.14:18
rburtonyeah i don't think anyone does that - they run bitbake and it says they've changed (because the tarball version changed) and will tell you the new ones.14:18
lpappyou still need to copy them inside the file.14:19
lpappinstead of a tool updating the file.14:19
* rburton shrugs14:20
rburtonthat's two lines of copy and paste.14:20
lpappyes, exactly.14:20
lpappinstead of just using an option for bitbake.14:20
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has quit IRC14:22
lpappwhat is the difference between files/ and $PN_$PV/? The former is version agnostic, and the latter ones are changes for the $PV?14:22
*** pidge <pidge!~pidge@c-24-21-207-18.hsd1.or.comcast.net> has joined #yocto14:23
*** ruben__ <ruben__!~ruben@> has quit IRC14:24
*** tonghuix <tonghuix!~tonghuix@> has joined #yocto14:24
mario-goulartlpapp: you can have files (shared by all recipes in that dir), $PN (shared by all versions of recipe $PN in that dir) or $PN_$PV (used only by recipe $PN version $PV).14:25
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has joined #yocto14:26
lpappyeah, ok.14:26
lpappERROR: Failed to obtain CodeSourcery toolchain version: Execution of '/usr/local/arm-2009q1/bin/INVALID-oe-linux-gcc -v' failed: command not found14:32
lpappthat INVALID-oe-linux stuff looks kinda weird, no/14:33
lpappTCMODE = "external-csl"14:33
lpappEXTERNAL_TOOLCHAIN = "/usr/local/arm-2009q1"14:33
lpappTARGET_PREFIX = "arm-none-linux-gnueabi-"14:33
lpappI have this, and I have the toolchain installed right in there.14:34
*** davest <davest!Adium@nat/intel/x-ejgjdmrxdeeegxed> has quit IRC14:38
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-mqgkazthmbohiacr> has quit IRC14:41
*** Garibaldi|work <Garibaldi|work!~andydalt@> has joined #yocto14:46
*** walters <walters!walters@nat/redhat/x-rcqaayzvoidkhzrg> has quit IRC14:46
*** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has joined #yocto14:47
*** sameo <sameo!samuel@nat/intel/x-bvqszfjnhwoiinef> has joined #yocto14:49
*** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has quit IRC14:50
*** Song <Song!c0373629@gateway/web/freenode/ip.> has joined #yocto14:51
*** Song is now known as Song_Liu14:51
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto14:52
*** laur <laur!~lau@> has joined #yocto14:54
*** scottrif <scottrif!~scott-len@b482.ip17.netikka.fi> has joined #yocto14:56
*** belen <belen!~Adium@> has quit IRC14:57
*** Corneliu <Corneliu!c0c6972b@gateway/web/freenode/ip.> has joined #yocto14:58
lpappanyone got a clue about the error above?14:58
*** belen <belen!Adium@nat/intel/x-gpylnnimqnxxrekm> has joined #yocto14:59
sgw_YTPM: Saul Here15:00
pidgeYPTM: Beth is on the bridge15:00
CorneliuYPTM: Corneliu joined15:00
scottrifYPTM: Scott Rifenbark joined the call15:00
bluelightningYPTM: Paul Eggleton here15:00
*** Ramana_ <Ramana_!7aa6729b@gateway/web/freenode/ip.> has joined #yocto15:00
Song_LiuYPTM: Welcome to the technical team meeting, please let me know who's on the bridge15:00
belenYPTM: Belen joined15:00
jmpdelosYPTM: polk joined15:00
*** Guest91176 is now known as tomz15:00
lpappalso, mkimage and fw-utils get the u-boot packages from the ftp site15:00
lpappbut u-boot does not  ?!15:00
tomzYPTM: Tom Z here15:00
laurYPTM: LaurentiuP joined15:00
nitinkYPTM: nitin is dialing the bridge15:00
*** tomz is now known as Guest2518815:00
sgw_Yocto Project Tech Meeting:15:01
sgw_Dial-in number: 1.972.995.777715:01
sgw_US Toll Free number:    1.877.561.682815:01
sgw_Participant passcode:   4200107815:01
rburtonYPTM: ross here15:01
*** jzhang-laptop <jzhang-laptop!~jzhang16@> has joined #yocto15:02
jzhang-laptopYPTM: jzhang on the call15:02
sgw_Song_Liu: I think you should start posting the Dial info here in case people are on the ML yet15:02
rburtoni think we should do the irc back-channel in another room so we don't swamp any existing discussions15:03
Ramana_joined YPTM15:03
kergothYPTM: Chris Larson here15:03
Song_LiuYPTM: Any opens?15:03
yoctiBug 3252: enhancement, Low, 1.5 M3, venkatarg, IN PROGRESS DESIGN , Binary level package selection and configuration tool.15:04
*** BSDCat <BSDCat!unique@calvin.idempot.net> has joined #yocto15:04
BSDCatMatthew Weigel here15:04
zeddiiYPTM: Bruce here.15:08
sgw_pidge: yes, go ahead with your AB work, I am waiting on RP to pull, which I don't expect to happen until later today.15:12
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto15:19
mulhernYPTM: mulhern here15:20
*** slaine <slaine!~slaine@> has quit IRC15:30
halsteadoops. YPTM: Michael was there. :)15:34
*** belen <belen!Adium@nat/intel/x-gpylnnimqnxxrekm> has quit IRC15:35
*** scottrif <scottrif!~scott-len@b482.ip17.netikka.fi> has left #yocto15:36
lpappbluelightning: why do you think it is easier to backport patches with git?15:36
lpapptrying to backport this one for instance.15:36
lpappshould I back port it to the poky repository, btw?15:37
*** belen <belen!~Adium@> has joined #yocto15:38
kergothheh :)15:40
*** zenlinux_ <zenlinux_!~sgarman@> has joined #yocto15:40
*** Corneliu <Corneliu!c0c6972b@gateway/web/freenode/ip.> has quit IRC15:41
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto15:42
sgw_lpapp: what version of poky are you trying to patch?15:42
lpappbluelightning: http://paste.kde.org/~lpapp/pe272b5bd/15:43
lpappcherry-pick did not quite work out.15:43
*** jzhang-laptop <jzhang-laptop!~jzhang16@> has quit IRC15:43
lpappsgw_: denzil15:44
bluelightninglpapp: not really surprising I guess... you'll just have to go through and resolve the conflicts15:44
lpappbluelightning: thing is, I do not understand the conflict.15:44
*** TuTizz <TuTizz!~TuTizz@> has quit IRC15:45
lpappbluelightning: I guess it is somewhat due to the PR numbers.15:45
lpappbluelightning: http://paste.kde.org/~lpapp/p66d616be/15:47
lpappbluelightning: once I solve it, is it welcome in upstream?15:48
lpappor the denzil branch is frozen?15:48
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto15:48
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC15:49
*** bluelightning_ is now known as bluelightning15:49
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto15:49
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto15:49
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC15:50
*** ivali <ivali!~ivali@unaffiliated/ivali> has quit IRC15:59
*** eballetbo <eballetbo!~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net> has quit IRC16:01
*** zeeblex1 <zeeblex1!apalalax@nat/intel/x-gakyprcwjynfsqte> has left #yocto16:03
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto16:03
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC16:06
*** elmi82 <elmi82!~timo@mail.bmw-carit.de> has quit IRC16:07
*** mckoan is now known as mckoan|away16:09
*** dlern <dlern!~dlerner@> has joined #yocto16:11
lpappbluelightning: how do you solve conflicts in so many files?16:11
lpappit is a royal pain in the ass.16:11
bluelightninglpapp: it's just what you have to deal with when backporting16:11
lpappbluelightning: even git mergetool with vimdiff is super painful, and more importantly: overly error-prone.16:12
lpappbluelightning: I spent half an hour with it16:14
lpappand after the resolve, I got my content lost16:14
lpappI am not sure I would like to really backport it to the repository, and maintain it.16:14
lpappit is not really fun16:14
bluelightningit just takes practice16:14
bluelightningand yes, it's not fun16:14
lpappwell, you have not shared any practice yet.16:15
bluelightningthere's no magic to it16:15
lpappthat is bad16:16
lpappwe should have a git tool for it16:16
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC16:16
bluelightningsometimes it's easier just to look at what the patch does and make the appropriate changes yourself16:16
bluelightningI'm afraid this is just the kind of pain you'll have to deal with when using an old version on a very much bleeding edge host distro16:16
lpappwell, Intel should maintain it in the first place (tm). :)16:18
bluelightningwe did try to warn you...16:18
lpappwarn is highly productive16:19
lpappI mean, I was aware of it of course.16:19
lpappyet, someone has to do the work16:19
lpappbecause Intel is a big company16:19
lpappthey could know one year support for a software is nothing.16:19
bluelightningif only it were that simple...16:20
b1gtunagood morning! Has anyone seen dhclient.service failing to start on boot?16:20
lpappbluelightning: ?16:20
b1gtunaIt's failing because the interface isn't up yet16:21
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC16:21
bluelightninglpapp: within Intel it's actually quite a small team working full time on the Yocto Project16:21
bluelightninglpapp: not to mention, we're not the only organisation involved16:21
lpappbluelightning: small team means?16:22
bluelightninglpapp: as I said weeks ago we have to draw the line somewhere when it comes to host distro support; we already support a wide range of host distros and versions16:22
lpappwell, arch is a very popular distro.16:23
bluelightningit also changes more frequently than any other on our list which means it requires more support effort than any other on our list16:23
lpappI would not say that16:23
lpappI would claim the opposite personally.16:24
lpappit getsw new software16:24
lpappit gets bugfixes earlier16:24
lpapprather than ancient distributionsd.16:24
*** ErkiS <ErkiS!~erki@pro01.dcc.ttu.ee> has quit IRC16:24
bluelightningbugfixes and new versions of base tools we rely on (automake, autoconf, libtool, texinfo, ...) that lead to breakages16:24
lpappbluelightning: gd16:24
lpapp* Unmerged path meta/recipes-support/gnutls/gnutls_2.12.20.bb16:24
lpappwhat to do here?16:24
bluelightningnot sure, sorry16:26
*** levi <levi!~user@c-24-10-225-212.hsd1.ut.comcast.net> has quit IRC16:26
* lpapp cries16:26
lpappbluelightning: I will drop the cherry-pick thingie16:26
lpappit is a lot easier to write a patch from scratch16:27
rburtonyeah, bluelightning suggested that - often much easier to look at what the change does it do it yourself if the cherry-pick doesn't happen automatically.16:27
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto16:27
*** levi <levi!~user@c-24-10-225-212.hsd1.ut.comcast.net> has joined #yocto16:28
lpappyeah, but I will not give credit then whatsoever. :)16:28
lpappalso, it is patching stdio.in.h which is a generated file? I do not follow.16:28
lpapp+--- gettext- 12:56:12.000000000 -070016:29
lpapp++++ gettext- 22:42:21.292223316 -070016:29
lpappwhy would anyone patch a generated file?16:29
lpappoh, d'oh16:30
lpappit has already been fixed in denzil16:30
lpappit just has not been released16:30
lpappwhat is the point of fixing if it is not released?!16:30
*** Guest98725 <Guest98725!~tbn@> has quit IRC16:31
lpappprobably time to take the latest version from git ...16:31
rburtonlpapp: well, making a release after every commit would be crazy. so there's a few month cycle for fixes to build up, then run through autobuilder and QA, and then release.16:31
lpapprburton: you do realize there was no commit for about half a year?16:32
rburtonlpapp: branching off the release branch is a sensible thing to do - you get fixes earlier and the chance of breakage is slim16:32
rburtonlpapp: as a member of the community feel free to propose one final spin if there's numerous patches that are not in a release there16:32
lpappI do not think it is "final" whatever it means.16:33
rburtonor, just use the release branch.16:33
lpapppeople do not choose software for a few months.16:33
*** jzhang-laptop <jzhang-laptop!~jzhang16@> has joined #yocto16:34
lpappalthough now that I got my layer testable, I think there is no reason not to try the latest poky versionm16:34
lpappalso, that has bugs for arch, too, unfortunately.16:34
lpappI guess now that my layer got separated after 2-3 days work.16:35
lpappI think it should be easy to update poky?16:35
lpappbtw, are you trying to push changes upstream?16:39
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:40
*** cetola <cetola!~cetola@74-92-165-193-Oregon.hfc.comcastbusiness.net> has joined #yocto16:41
lpappWARNING: Failed to fetch URL http://www.zlib.net/zlib-1.2.7.tar.bz2, attempting MIRRORS if available16:43
lpappthat url looks broken.16:44
lpappok, so the poky releases have issue when upstream screws up the existing urls...16:47
lpappthat is good to know...16:47
lpappis there a fallback solution provided by Yocto?16:48
lpapplike a mirror for the released stuff?16:48
bluelightningsee the MIRRORS setting in meta-yocto/conf/distro/poky.conf16:49
lpappnaturally what?16:49
lpappI have just double checked the downloads.16:49
bluelightningnaturally we have a fallback16:49
lpappand zlib is there.16:49
lpapphow about updating poky?16:49
bluelightningwe do update it, regularly16:49
lpappno no16:49
lpappI mean, me updating from denzil to dylan16:49
lpappshould that be smooth?16:50
bluelightninglpapp: if you follow: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#migration16:50
pidgelpapp: yes. all sources that we utilize over the course of autobuilds are available, in perpetuity, via the autobuilder mirror.16:50
lpappok, how about my other question:16:52
lpappbtw, are you trying to push changes upstream?16:52
*** sameo <sameo!samuel@nat/intel/x-bvqszfjnhwoiinef> has quit IRC16:54
lpappbluelightning: it is 1.14, not 1.13 though.16:55
*** mihai <mihai!~mihai@> has quit IRC16:56
lpappis there a patch update tool?16:57
*** tonghuix <tonghuix!~tonghuix@> has quit IRC17:01
*** mulhern <mulhern!~mulhern@> has joined #yocto17:03
*** mulhern <mulhern!~mulhern@> has quit IRC17:04
lpappbluelightning: http://paste.kde.org/~lpapp/pa772324b/ dylan build issue with gcc17:04
lpappis that fixed in master?17:04
bluelightningfrankly, I thought it was fixed in dylan17:05
lpappbluelightning: ah, you are familiar with this issue?17:05
bluelightningI am yes, it came with the introduction of gcc 4.817:06
* lpapp is not using gcc 4.817:06
lpappso it is not the typical 4.8 cannot build 4.7 issue17:06
lpappgcc version 4.3.3 (Sourcery G++ Lite 2009q1-203)17:07
lpappnote, I do not use the arch toolchain.17:07
lpappit should use the cross compilation arm gnueabi one from code sourcery.17:08
bluelightninglpapp: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dylan&id=950f2e453a2bd31764e99eb09154768e0c5049a417:10
lpappbluelightning: yeah, I was just having that open17:10
lpappNet147 sent it 3 weeks ago or so17:10
lpappstill, I do not build with 4.817:10
lpappso I am not sure how it is relevant.17:10
bluelightninglpapp: your host compiler is gcc 4.8.x17:11
bluelightninglpapp: the fact that it's building gcc-cross-initial tells me that it's not using an external toolchain (correctly)17:11
lpappbluelightning: as I said, it should not use the host compiler at all.17:11
lpappI am building for arm.17:11
lpappit should use the arm toolchain specified.17:11
lpappright, so why is it not using the toolchain?17:11
bluelightningpresumably, because it's not configured correctly17:12
lpappmeans what exactly?17:12
bluelightningI can't personally help you configure it because I've never used the external CSL toolchain17:12
lpappnow this is where build/conf/local.conf is VERY annoying.17:13
lpappI forgot to copy paste that from another build17:13
lpappand now, I am getting it.17:13
lpappcan we reiterate ~/.yoctorc again please17:13
lpappit is a pain in the ass without.17:13
lpappI just wasted 1-2 hours17:14
lpappdue to it.17:14
bluelightningwe've already explained why it can't work17:14
bluelightningand I'm not going to do so again17:14
lpappit *can* work17:14
lpappand no one actually had a rebruttal for my argument why it could not.17:14
*** davest <davest!~Adium@> has joined #yocto17:14
lpappor not something that a mortar can understand.17:14
bluelightningfrankly I'm deep in the bowels of smart's transaction code and I need to find the bug there rather than discuss here stuff that's already been discussed17:15
lpappYour version of bblayers.conf was generated from an older/newer version of bblayers.conf.sample and there have been updates made to this file. Please compare the two files and merge any changes before continuing.17:15
lpappMatching the version numbers will remove this message.17:16
lpappI did not have any old/new?17:16
lpappit should have generated a new?17:16
lpappI am clueless what is happening?17:16
lpapphow can something be conflicting which does not even exist?17:18
lpappoh, I think the main problem is that bblayers.conf is not generated with my layer inside17:19
lpappwhy is it not?17:19
lpapphow can I get it autogenerated like that?17:19
lpappoh, the bblayers.conf stuff changed.17:20
lpappto COREBASE17:20
lpappwhat, it is not clear17:22
lpappERROR: Unable to parse ##COREBASE##/meta/conf/layer.conf: file ##COREBASE##/meta/conf/layer.conf not found in /home/lpapp/Projects/Yocto/poky-dylan-9.0.0/polatis-builds17:23
lpappwhat do I need to replace ##COREBASE## with?17:24
lpappReally, it is not written in the file.17:24
bluelightningthat's a placeholder which the oe-init-build-env script automatically replaces17:27
lpappit actually does not work17:27
mario-goulartlpapp: that ##COREBASE## string was supposed to be replaced by something meaninful when you run oe-init-build-env17:27
lpappbut then again: why is bblayers.conf not just generated right?17:27
lpappmario-goulart: then shit happened I guess.17:28
lpappI remove that file generated17:28
lpappand still getting the error pasted above.17:28
lpappshouldn't it just generate the right thing?17:28
lpappinstead of generating some mixed stuff?17:28
lpappbug in dylan?17:28
*** Stygia <Stygia!~gmpsaifi@0904ds6-noe.0.fullrate.dk> has quit IRC17:28
lpappis it a known bug in dylan?17:29
lpappHow should I proceed?17:29
*** zenlinux_ <zenlinux_!~sgarman@> has quit IRC17:30
lpapphmpf: meld conf/bblayers.conf17:30
lpappit should be $build/conf/bblayers.conf, no?17:30
lpappthe error reporting seems to be erroneous.17:30
lpappit should tell me that, I do not have such a file.17:31
lpappwhy is it not looking in the build folder by default?17:31
lpappwhat I am doing is this in the dylan root:17:31
lpapp. oe-init-build-env my-builds17:31
lpappbitbake core-image-minimal17:32
lpappI would kinda expect that, it is the right way17:32
mario-goulartAre you running bitbake from the build dir?17:33
*** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has quit IRC17:34
lpappmario-goulart: no17:34
mario-goulartCan you try that?17:34
lpappit worked with denzil with that two-liner script17:35
lpappwithout being in the build directory.17:35
lpappyocto is mysterious at times. :)17:36
lpappmario-goulart: btw, oe-init-build-env should take you into the build folder!17:37
lpappso yes, of course I was running it there.17:37
lpappand yes, trying it again, did not help.17:37
lpappis it really meant to be this buggy even with the newest versions? :O17:37
lpappany idea how to get the build started with dylan? Is it a known bug that the build cannot even be started without a workaround if any?17:39
*** dlern <dlern!~dlerner@> has left #yocto17:45
lpappI am still interested in why bblayers.conf is not generated with my layer inside, automatically?17:46
lpapphow could I make that happen?17:46
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:49
lpappor at the very least, how can I only execute a generation procedure without building with the obviously bblayers.conf content.17:49
sgw_lpapp, I think you can use a TEMPLATECONF directory, this might also help with your local.conf file, so when oe-init-build-env runs it will take the local.conf and bblayers.conf from your TEMPLATE_CONF directory.  I have not personally used this method17:52
lpappsgw_: ok, that sounds even more complex than without solving the problem.17:52
lpappso now, I would have two. :)17:53
lpappin any case, is there a generator command?17:53
lpappit is pretty silly to build with a wrong bblayers.conf17:53
lpappso the generation should obviously happen in a different step17:53
lpappso that I can edit (correct) it before the actual build.17:53
lpappotherwise the layer support is not that particularly mature for third parties.17:54
lpappor am I supposed to edit myself from the sample file?17:55
*** lpapp <lpapp!~lpapp@> has quit IRC17:56
sgw_lpapp just trying to help, You might also try the "yoctco-bsp" script in the scripts directory, again I have not used it personally17:59
sgw_missed him17:59
*** belen <belen!~Adium@> has quit IRC18:04
*** mihai <mihai!~mihai@> has joined #yocto18:04
*** b1gtuna <b1gtuna!~adam@s206-116-3-18.bc.hsia.telus.net> has quit IRC18:04
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC18:07
*** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has joined #yocto18:09
*** el_robin <el_robin!~el_robin@2a01:e0b:1:124:54be:d5e4:293e:5235> has quit IRC18:26
*** lpapp <lpapp!~lpapp@cpc11-cmbg15-2-0-cust30.5-4.cable.virginmedia.com> has joined #yocto18:28
lpapp"You should also have about 100 gigabytes of free disk space for building images."18:30
lpappa full (not core, minimal, basic, base, etc) build takes up that much space?18:31
*** el_robin <el_robin!~el_robin@2a01:e0b:1:124:ed70:49dd:bf2e:cfce> has joined #yocto18:33
*** b1gtuna <b1gtuna!~adam@> has joined #yocto18:35
b1gtunaudhcpc from busybox is conflicting with dhclient from NetworkManager. Anyone with this experience?18:36
rburtonlpapp: a full build takes up a surprising amount of space.  of course using an external toolchain saves you a bit, and you can use rm_work to save lots more.18:49
rburtonfor what its worth, my /data (solely yocto builds) is sitting at 766G used.18:49
lpapprburton: how many?18:53
rburtonhow many builds? one.  done many times a day in different configurations, and it hasn't been entirely purged in about six months.  consider it unusual :)18:53
rburton100G is a good starting point for space required for regular builds unless you want to start having to wipe everything to clear stale files.18:54
lpappwell, my partition table is not prepared for Yocto.18:56
lpappso I guess I need to use rm_work.18:56
lpappand it is probably a lesson learnt when I partition a new disk next time.18:57
lpappthat I should not be modest with 50-100 GB for the home.18:57
rburtoni never set more than 20G for / unless i know i'll need it for something special, everything else is "mine"19:02
rburtonand if/when you get a dedicated machine for yocto builds, put the build data on its own *disk*19:03
rburtonnot just partition19:03
lpappI was saying home intentionally, not root.19:07
lpappI do not have a dedicated machine, no.19:07
*** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has quit IRC19:11
*** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto19:15
*** eren <eren!~eren@unaffiliated/eren> has quit IRC19:15
*** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC19:16
*** sakoman <sakoman!~steve@static-74-41-60-154.dsl1.pco.ca.frontiernet.net> has quit IRC19:19
*** dompe <dompe!0fc3c958@gateway/web/freenode/ip.> has joined #yocto19:20
dompehi, I have a quick question about recipes: I'm creating a recipe libdbus-c++19:21
dompeI need a nativesdk version as well19:21
dompemy recipe is called19:21
dompebut my cross compiled package gets named libdbus-c++-1-0_0.9.0-r0_armv6k.ipk (with an extra -0 after the recipe name)19:22
dompehowever my nativesdk package gets named without the extra -019:22
lpappcan the yocto build system take MAKEFLAGS into account?19:22
dompeany idea why this happens?19:22
lpappdompe: should be libdbus-c++_1_0.9.0.bb19:23
lpappor you are creating a recipe for libdbus-c++-119:23
dompelpapp I'm creating for libdbus-c++-119:24
dompeversion is 0.9.019:24
dompemeaning the library is named libdbus-c++-1.so19:24
dompemy question is why the package gets the extra -019:25
dompeis this an expected behavior?19:25
*** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has joined #yocto19:25
*** Song_Liu <Song_Liu!c0373629@gateway/web/freenode/ip.> has quit IRC19:26
*** jzhang-laptop <jzhang-laptop!~jzhang16@> has quit IRC19:31
*** sakoman <sakoman!~steve@static-74-41-60-154.dsl1.pco.ca.frontiernet.net> has joined #yocto19:34
kergothsometimes i get the feeling we need the ability to backfill packageconfig19:36
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto19:39
lpappERROR: Failed to obtain CodeSourcery toolchain version: Execution of '/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found -> why is it looking for that?19:40
lpappTCMODE = "external-csl"19:40
lpappEXTERNAL_TOOLCHAIN = "/usr"19:40
lpappTARGET_PREFIX = "arm-none-linux-gnueabi-"19:40
lpappI have this.19:40
lpappit should look for /usr/bin/arm-none-linux-gnueabi-gcc, no?19:41
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC19:42
*** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto19:54
*** dlern <dlern!~dlerner@99-16-243-235.lightspeed.mrgvil.sbcglobal.net> has joined #yocto19:55
*** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC19:55
*** flihp <flihp!~flihp@> has quit IRC19:57
*** flihp <flihp!~flihp@> has joined #yocto19:57
*** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@autobuilder.yoctoproject.org> has quit IRC19:58
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto20:01
*** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@autobuilder.yoctoproject.org> has joined #yocto20:03
*** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@autobuilder.yoctoproject.org> has joined #yocto20:03
*** joeythesaint <joeythesaint!~jjm@> has quit IRC20:03
*** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has quit IRC20:04
*** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@autobuilder.yoctoproject.org> has quit IRC20:05
*** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@autobuilder.yoctoproject.org> has joined #yocto20:05
pidgefolks. we have build failure emails again! I've got it set to only send on poky, oe-core, and eclipse-poky failures for all branches. I can limit these by branches as well as repos now. If folks have comments/concerns let me know.20:07
*** dompe <dompe!0fc3c958@gateway/web/freenode/ip.> has quit IRC20:08
*** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has quit IRC20:11
*** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has joined #yocto20:11
*** jzhang-laptop <jzhang-laptop!~jzhang16@> has joined #yocto20:43
*** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has quit IRC20:43
*** dvhart <dvhart!dvhart@nat/intel/x-zzsimixjizlvtazk> has joined #yocto20:45
mulhernI want to build a package. The purpose of the package is not itself to be installed. What I actually want to install is the results of running the application; it downloads and rearranges some important data files. Is there an example of this kind of setup that I could take a look at?20:46
*** cetola <cetola!~cetola@74-92-165-193-Oregon.hfc.comcastbusiness.net> has quit IRC20:48
mulhernBut sometime in the future it might make sense to install the package itself.20:48
mulhernThings like that are in meta/recipes-devtools ?20:50
*** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has joined #yocto20:56
*** bluelightning <bluelightning!~paul@cpc13-lewi17-2-0-cust74.2-4.cable.virginmedia.com> has joined #yocto21:05
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto21:05
sgw_mulhern: not really, looking at some native tool might be helpful21:05
mulhernsgw_: It turns out that the plan of making a package for bitbake and using it to download rules is probably necessary. Because it's not just necessary to download the rules but also to reorganize and combine certain lookup tables used by different rulesets. For example, if you want both Snort community ruleset and emerging threats ruleset (which seems to be more up-to-date).21:07
mulhernNot bitbake, pulledpork.21:07
lpappanyone having a clue for the cross-compilation?21:07
mulhernsgw_: Btw, did you see my email about Sourcefire acquisition by Cisco?21:08
sgw_mulhern: so you really need a pulledpork-native that can be used during the do_install of snort, but also a pulledpork target recipe?21:09
sgw_mulhern: yes I saw your email21:10
lpappeveryone is doing native builds with yocto in here ? :)21:10
mr_sciencemmm...  pulledpork21:10
sgw_lpapp: possibly, I have not worked with external toolchain yet, other folks have done it though21:11
mulhernsgw_: Well, following your suggestion of using pulled pork to grab the rules during the install for Snort I just need native. But, if in future somebody want to download them regularly then it might be necessary to have a target. I'm happy to work on just a native recipe for now. The hard part is going to be to persuade the script to work, not to write the basic bitbake file, anyway.21:13
sgw_mulhern: you mean the target recipe. right?  Go ahead and write the target recipe now also then.21:14
mulhernsgw_: OK. I can use quilt as a model.21:15
lpappsgw_: the problem is that, I do not even find proper documentation about it.21:18
sgw_lpapp: is the example for external-sourcery not enough for you to by?21:23
sgw_I know it's not full documentation21:23
lpappsgw_: apparently, not.21:24
*** jzhang-laptop <jzhang-laptop!~jzhang16@> has left #yocto21:25
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC21:32
*** dlern <dlern!~dlerner@99-16-243-235.lightspeed.mrgvil.sbcglobal.net> has left #yocto21:37
*** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has quit IRC21:40
*** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has joined #yocto21:50
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto21:51
*** sameo <sameo!samuel@nat/intel/x-qsyfmyoziqmtdiqq> has joined #yocto21:51
*** Garibaldi|work <Garibaldi|work!~andydalt@> has quit IRC22:04
ndecvery nasty bug... if you have '-D' in your build folder name, subversion-native will fail to build. we lost quite a bit of time on that ;-) upstream does that SVN_NEON_INCLUDES=`$PKG_CONFIG neon --cflags | $SED -e 's/-D[^ ]*//g'`, and -I too, CFLAGS="$CFLAGS `$PKG_CONFIG neon --cflags | $SED -e 's/-I[^ ]*//g'`"22:05
ndecit's not an OE bug of couse.22:06
bluelightningndec: ugh...22:06
ndecthe symptom is that ne_xxx.h files aren't found when compiling subversion .c files.22:08
ndecthese files are in neon package22:08
*** ant_home <ant_home!~andrea@host133-7-dynamic.20-79-r.retail.telecomitalia.it> has joined #yocto22:09
ndecand it's subversion 1.7. so dylan and master are impacted.22:09
mr_sciencecould always link upstream svn to a local git repo as a workaround...22:11
ndecyou just need to 'not use -D or -I' in the folder name ;-)22:13
mr_sciencenever said it was an optimal workaround...22:15
*** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has quit IRC22:15
*** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has joined #yocto22:18
lpappsgw_: who is the author of the external stufF?22:26
lpappperhaps it is time to document it?22:26
mr_scienceit's typo day, just g0 with it...22:29
lpappwhich mailing list to bring the topic up, on?22:30
lpapppresumably oe-core?22:30
*** zerus <zerus!~epetmab@90-224-44-236-no67.tbcn.telia.com> has quit IRC22:32
sgw_lpapp: a number of people here and on the email list have contributed to the external-toolchain (tcmode) work.  Richard, kergoth, seebs among them, sure you can bring it up on oe-core or yocto@yoctoproject.org, I think Scott Rifenbark (the docs guy) might be working on it also.22:33
sgw_lpapp: as has been pointed out there is some material from ELC or Linuxcon that might help also.22:33
*** b1gtuna <b1gtuna!~adam@> has quit IRC22:34
lpappsgw_: as I wrote, that did not help.22:35
lpappbut feel free to suggest any fix based on that.22:35
sgw_lpapp: I have seen it on the yocto@ mailing list in the past, you can check the archives maybe something there will help.22:37
lpappsgw_: I think it is good to boost a documentation process regardless.22:38
lpappcross-compilation is probably the main power for Yocto22:38
lpappat least in my book.22:38
lpappfor me that is the pillar why Yocto exists. :)22:39
lpappit is very slow to build on embedded architecture.22:39
lpappand for desktop, we have got many more powerful distribution that yocto has ever been able to generate.22:40
*** agust <agust!~agust@p4FC460FC.dip0.t-ipconnect.de> has quit IRC22:40
*** b1gtuna <b1gtuna!~adam@> has joined #yocto22:41
bluelightninglpapp: it sounds like you think cross-compilation can't be done without an external toolchain, which isn't the case22:42
*** BSDCat <BSDCat!unique@calvin.idempot.net> has left #yocto22:43
lpappsgw_: email sent.22:45
lpappbluelightning: how do you internal for gnueabi ? Could you please englighten us?22:46
bluelightninglpapp: we can build a cross-compiler for anything that gcc supports, certainly including ARM gnueabi22:47
lpappwhy would you bother?22:47
lpappthere is little to no point in it.22:47
bluelightningthere's quite a lot of point in it22:47
lpappnot really, no.22:48
bluelightningreally, yes22:48
lpappand TI disagrees with you, too.22:48
lpappalongside many other people.22:48
lpappintel, etc22:48
lpappsimply there is no point in rebuiling a toolchain for a well proven distribution with dedicated packages.22:50
lpappfor the vast majority of the use casese.22:51
bluelightningwell, if you're convinced I won't try to change your mind22:51
lpappand even if there was, external has to be documented, no matter what.22:51
lpappin fact, I have never seen anyone building a cross-compiler toolchain in my 10+ years.22:52
lpappusually, it is coming from the vendor or the partner of the vendor in binary form to the developers.22:53
lpapponly gentoo was doing that as far as I can tell, but they rebuild everything after all.22:54
lpappalmost everything22:54
lpappbut I think even then, they had some convenience binary packages.22:54
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC23:03
*** dvhart <dvhart!dvhart@nat/intel/x-zzsimixjizlvtazk> has quit IRC23:05
*** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has quit IRC23:07
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC23:16
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC23:22
*** yzhao2_ <yzhao2_!~yzhao2@> has joined #yocto23:31
*** yzhao2 <yzhao2!~yzhao2@> has quit IRC23:34
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto23:39
*** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has quit IRC23:47

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