| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 00:04 | |
| *** hollisb <hollisb!~hollisb@nat-wv.mentorg.com> has quit IRC | 00:04 | |
| *** cetola <cetola!~cetola@74-92-165-193-Oregon.hfc.comcastbusiness.net> has quit IRC | 00:07 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 00:17 | |
| *** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC | 00:22 | |
| *** joeythesaint <joeythesaint!~jjm@206-248-190-39.dsl.teksavvy.com> has quit IRC | 00:57 | |
| *** _julian_ <_julian_!~quassel@x2f17b6e.dyn.telefonica.de> has joined #yocto | 01:00 | |
| *** _julian <_julian!~quassel@x2f04625.dyn.telefonica.de> has quit IRC | 01:03 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 01:20 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 01:43 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 01:44 | |
| *** myopiate <myopiate!~myopiate@203-206-170-6.perm.iinet.net.au> has quit IRC | 01:52 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 02:06 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 02:09 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 02:10 | |
| *** silviof3 <silviof3!~silviof@host-188-174-200-171.customer.m-online.net> has joined #yocto | 02:16 | |
| *** silviof2 <silviof2!~silviof@ppp-93-104-17-108.dynamic.mnet-online.de> has quit IRC | 02:18 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 02:48 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 02:49 | |
| *** davest <davest!Adium@nat/intel/x-jflfxzcsbfizjyvv> has joined #yocto | 03:06 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 03:11 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 03:14 | |
| *** yzhao2_ <yzhao2_!~yzhao2@128.224.252.2> has joined #yocto | 03:30 | |
| *** yzhao2 <yzhao2!~yzhao2@128.224.252.2> has quit IRC | 03:33 | |
| *** davest <davest!Adium@nat/intel/x-jflfxzcsbfizjyvv> has quit IRC | 03:33 | |
| *** davest <davest!~Adium@134.134.137.73> has joined #yocto | 03:33 | |
| *** doerrpau <doerrpau!~doerrpau@cpe-70-124-65-123.austin.res.rr.com> has quit IRC | 03:39 | |
| *** davest <davest!~Adium@134.134.137.73> has quit IRC | 03:41 | |
| *** davest <davest!Adium@nat/intel/x-hhruvpimojzetalt> has joined #yocto | 03:52 | |
| *** davest <davest!Adium@nat/intel/x-hhruvpimojzetalt> has quit IRC | 04:00 | |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto | 04:53 | |
| *** zeeblex <zeeblex!~apalalax@134.134.139.74> has joined #yocto | 05:16 | |
| *** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has quit IRC | 05:33 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 05:52 | |
| *** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has joined #yocto | 05:58 | |
| *** agust <agust!~agust@p4FC460FC.dip0.t-ipconnect.de> has joined #yocto | 05:58 | |
| *** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has joined #yocto | 06:01 | |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC | 06:04 | |
| lpapp | when having a bsp layer, it is better to use .bbappend if the kernel is not different, just having custom configuration? | 06:06 |
|---|---|---|
| Crofton | lpapp, I would say yes | 06:24 |
| *** mihai <mihai!mihai@nat/intel/x-ikclvczxdjrydgyw> has joined #yocto | 06:27 | |
| *** elmi82 <elmi82!~timo@mail.bmw-carit.de> has joined #yocto | 06:38 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 06:38 | |
| lpapp | and if custom patches are needed, I would need to "replicate" the packages in my layer? | 06:42 |
| lpapp | it is not worth putting custom patches into the meta and meta-yocto layers at all? | 06:46 |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 06:55 | |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto | 06:58 | |
| *** Guest68081 is now known as volker | 07:01 | |
| *** TuTizz <TuTizz!~TuTizz@46.18.96.158> has joined #yocto | 07:05 | |
| *** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto | 07:05 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 07:08 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 07:09 | |
| *** mckoan|away <mckoan|away!~marco@host56-7-static.30-87-b.business.telecomitalia.it> has joined #yocto | 07:09 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 07:09 | |
| *** mckoan|away <mckoan|away!~marco@host56-7-static.30-87-b.business.telecomitalia.it> has quit IRC | 07:09 | |
| *** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto | 07:11 | |
| mckoan | good morning | 07:11 |
| *** tbn <tbn!~tbn@84.55.160.118> has joined #yocto | 07:15 | |
| *** tbn is now known as Guest98725 | 07: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@1.202.252.122> has joined #yocto | 07:20 | |
| *** sameo <sameo!~samuel@192.55.54.41> has joined #yocto | 07:24 | |
| *** yzhao2 <yzhao2!~yzhao2@128.224.252.2> has joined #yocto | 07:30 | |
| *** yzhao2_ <yzhao2_!~yzhao2@128.224.252.2> has quit IRC | 07:33 | |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC | 07:43 | |
| *** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has joined #yocto | 07:46 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 07:52 | |
| *** slaine <slaine!~slaine@84.203.137.218> has joined #yocto | 07:54 | |
| *** eballetbo <eballetbo!~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net> has joined #yocto | 07:56 | |
| *** slaine <slaine!~slaine@84.203.137.218> has quit IRC | 07:58 | |
| Crofton | lpapp, do you have a source of that line? I'm on holiday right now, so reponse time is pretty slow for me :) | 07:58 |
| lpapp | Crofton: https://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html | 08:07 |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 08:09 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 08:09 | |
| lpapp | bluelightning: it is not worth putting custom patches into the meta and meta-yocto layers at all? | 08:10 |
| bluelightning | morning all | 08:11 |
| bluelightning | lpapp: unless they're general changes you're planning to upstream, no - otherwise you'll have to rebase those changes when you upgrade | 08:11 |
| bluelightning | lpapp: we have the layer structure in part to avoid such difficulties | 08:12 |
| lpapp | bluelightning: k, thanks. | 08:12 |
| lpapp | what about the local and site configs? Should I have those in each layer? | 08:12 |
| *** _Lucretia__ <_Lucretia__!~munkee@90.218.162.144> has joined #yocto | 08:13 | |
| bluelightning | lpapp: no, those shouldn't be in any layer | 08:13 |
| lpapp | also, what about about patches backported from master to denzil to build on archlinux? Should they go into the existing layers or custom? | 08:13 |
| lpapp | bluelightning: inside the build folder then? | 08:14 |
| bluelightning | lpapp: that's a little different... in that case you probably want to be maintaining a branch | 08:14 |
| bluelightning | lpapp: yes | 08:14 |
| *** _Lucretia_ <_Lucretia_!~munkee@pdpc/supporter/active/lucretia> has quit IRC | 08:14 | |
| lpapp | bluelightning: maintaning a branch means? | 08:16 |
| bluelightning | lpapp: of poky | 08:16 |
| lpapp | bluelightning: not sure I follow, mind elaborating? | 08:16 |
| bluelightning | lpapp: 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 layer | 08:17 |
| *** jackmitchell <jackmitchell!~Thunderbi@host217-34-104-101.in-addr.btopenworld.com> has quit IRC | 08:17 | |
| lpapp | bluelightning: I am not using branches | 08:18 |
| lpapp | bluelightning: I am working independently from the poky repository. | 08:18 |
| lpapp | bluelightning: I download the tarball, and I backport changes to that when packaging. | 08:18 |
| *** slaine <slaine!~slaine@84.203.137.218> has joined #yocto | 08:20 | |
| bluelightning | lpapp: 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 |
| lpapp | bluelightning: sorry? | 08:22 |
| lpapp | have you seen other distributions packaging? | 08:22 |
| bluelightning | lpapp: packaging of... ? | 08:22 |
| lpapp | they use the release, and then they have stabilization patches backported. | 08:22 |
| lpapp | once they get a usable release, they will drop their patches. | 08:22 |
| lpapp | but as far as I know, people do not care in Yocto to actually maintain a feature release. | 08:23 |
| lpapp | which is sad, but that is how it is anyway. | 08:23 |
| bluelightning | lpapp: that's not correct, we maintain at least two stable releases back | 08:23 |
| lpapp | bluelightning: why don't I see proper bugfix releases for the feature releases then? | 08:24 |
| lpapp | also, "two" is a weak argument when they release cycle is 6 months. | 08:24 |
| lpapp | the* | 08:24 |
| lpapp | so basically, the software is taken care of, maximum up to a year. | 08:24 |
| lpapp | and then end users are screwed with those releases. | 08:25 |
| lpapp | anyway, do you plan to release a stable denzil any soon for arch? | 08:25 |
| *** silviof3 is now known as silviof | 08:25 | |
| bluelightning | lpapp: http://article.gmane.org/gmane.linux.embedded.yocto.general/14529/ | 08:25 |
| bluelightning | lpapp: http://comments.gmane.org/gmane.linux.embedded.yocto.announce/47 | 08:26 |
| lpapp | bluelightning: dylan is far from denzil. | 08:26 |
| bluelightning | lpapp: I don't think we have any further denzil releases planned, no | 08:26 |
| *** jackmitchell <jackmitchell!~Thunderbi@host217-34-104-101.in-addr.btopenworld.com> has joined #yocto | 08:26 | |
| lpapp | or even danny. | 08:26 |
| lpapp | bluelightning: then why would I bother with git? | 08:27 |
| lpapp | if Yocto does not care to maintain and release it? | 08:27 |
| bluelightning | lpapp: maybe because it makes backporting and maintaining a patch series trivially easy? | 08:27 |
| lpapp | in any case, even with a release, we would need a solution _now_. | 08:27 |
| bluelightning | and git works, now | 08:27 |
| lpapp | no, it does not. | 08:27 |
| lpapp | what actually the packagers do out there at large, is what I wrote already: they use the release and then patches locally. | 08:28 |
| bluelightning | well, 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 |
| bluelightning | unnecessarily so since git does exist and works well for the job | 08:28 |
| lpapp | not really, no. | 08:29 |
| lpapp | Yocto is a project, foo is another. | 08:29 |
| bluelightning | I'm giving you my advice, advice which comes not just from me but others who also maintain stable branches + backports for their own internal purposes | 08:29 |
| *** honschu_ <honschu_!~honschu@shackspace/j4fun> has quit IRC | 08:29 | |
| lpapp | actually, for debian, it is pretty simple to apply a patch locally. | 08:30 |
| bluelightning | if 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 doing | 08:30 |
| lpapp | only 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 #yocto | 08:30 | |
| lpapp | bluelightning: why would it be hard? | 08:31 |
| lpapp | debian, arch, etc packagers have been doing that for decades. | 08:31 |
| *** honschu <honschu!~honschu@p549EBDB5.dip0.t-ipconnect.de> has joined #yocto | 08:31 | |
| *** honschu <honschu!~honschu@shackspace/j4fun> has joined #yocto | 08:31 | |
| *** forcev <forcev!~quassel@wafaa.eu> has quit IRC | 08:34 | |
| ant_work | lpapp: OE/Yocto is *not* a distribution. It's not about upgrading a binary package on host | 08:39 |
| *** frank <frank!~qiang@1.202.252.122> has joined #yocto | 08:39 | |
| lpapp | ant_work: yes, we all know. | 08:39 |
| ant_work | then why do you insist comparing pears with apples? | 08:40 |
| lpapp | no any clue what you are talking about. | 08:40 |
| lpapp | bluelightning: also, just out of the curiosity, could I get omnipotence in the denzil branch? | 08:41 |
| lpapp | i.e. unlimited commit rights, not allowing others to commit in, etc? | 08:41 |
| lpapp | I do not think it would work anyway, so we need full control over our software. | 08:41 |
| bluelightning | lpapp: no, but you can send patches | 08:41 |
| rburton | and of course you have complete control over your own branches | 08:41 |
| rburton | what with git being a distributed VCS | 08:42 |
| lpapp | bluelightning: you can see yourself it would not fit the business model for many, including me. | 08:42 |
| lpapp | bluelightning: companies need full control over their software. | 08:42 |
| frank | Hi, anyone can tell me how the rpm spec generated in yocto ? | 08:42 |
| lpapp | bluelightning: but that kinda is besides the point as I do not see how git would simplify anything after all. | 08:42 |
| bluelightning | lpapp: and, you can have that | 08:42 |
| lpapp | to me, it would be a complication. | 08:43 |
| bluelightning | frank: sure, the code that does it is in meta/classes/package_rpm.bbclass | 08:43 |
| lpapp | because we could not use the release tarball after all. | 08:43 |
| lpapp | yet another complication step. | 08:43 |
| *** ivali <ivali!~ivali@unaffiliated/ivali> has joined #yocto | 08:44 | |
| frank | bluelightning: Thanks a lot ! I'll take a look at the file. | 08:44 |
| bluelightning | lpapp: 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 build | 08:45 |
| ivali | How can I make a global clean to poky? | 08:45 |
| lpapp | bluelightning: except a few things: | 08:45 |
| lpapp | 1) I do not have git access right now | 08:45 |
| bluelightning | lpapp: you don't need git access | 08:45 |
| lpapp | 2) Monkey work only comes after a good decision which is hardly git. | 08:45 |
| bluelightning | ivali: depends... if you want to clear everything out completely just delete TMPDIR (tmp/ under your build directory by default) and sstate-cache | 08:46 |
| lpapp | it is usually a weak attempt to argue for doing monkey work instead of thinking and discussing the design. | 08:46 |
| bluelightning | ivali: that's quite a drastic measure though, usually that's not necessary | 08:46 |
| lpapp | which is for long term and good. | 08:46 |
| ivali | bluelightning, i can't figure out why poky is trying to use some old version of a .bb file, even though i modified it | 08:48 |
| ivali | recompiling now .. | 08:48 |
| lpapp | bluelightning: any plans to actually support a software and maintain it for more than maximum a year. | 08:49 |
| lpapp | You know, companies are a bit more interested in a product for more than a year ... | 08:49 |
| lpapp | to me, this also differentiates ubuntu and co from Yocto. | 08:49 |
| rburton | lpapp: yocto project isn't a company, there are many companies that offer commercial support for many years (up to 7, iirc) | 08:49 |
| lpapp | They at least care about maintaining the software for a while. | 08:49 |
| lpapp | so their software will be reliable in two years time, too. | 08:50 |
| bluelightning | ivali: if you want to be completely sure of which file is being used you can do bitbake -e recipe | grep ^FILE= | 08:50 |
| lpapp | rburton: Actually, Yocto is under a foundation. | 08:50 |
| lpapp | it employs people for money. | 08:50 |
| ivali | bluelightning, thanks | 08:50 |
| lpapp | Intel also sponsors developers working on it. | 08:50 |
| rburton | lpapp: yes. me. | 08:50 |
| lpapp | note how you get lts for ubuntu, linux kernel, etc. | 08:50 |
| lpapp | rburton: I know. | 08:50 |
| *** Stygia <Stygia!~gmpsaifi@0904ds6-noe.0.fullrate.dk> has joined #yocto | 08:54 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC | 08:56 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 08:56 | |
| *** zeeblex1 <zeeblex1!apalalax@nat/intel/x-gakyprcwjynfsqte> has joined #yocto | 08:56 | |
| *** zeeblex <zeeblex!~apalalax@134.134.139.74> has quit IRC | 08:56 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 08:58 | |
| ndec | these 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 |
| ndec | it would be a wonderful experience if that person ever start contribution/discussion on lkml. | 08:58 |
| rburton | ha | 09:00 |
| bluelightning | ndec: I'm told such a discussion did happen recently on LAKML | 09:00 |
| bluelightning | ;) | 09:00 |
| ndec | well, that was i think a more valuable discussion than ours... | 09:01 |
| bluelightning | I didn't read it myself | 09:01 |
| *** belen <belen!Adium@nat/intel/x-gtzrabjhoqijecrb> has joined #yocto | 09:01 | |
| ndec | oh. lamkl... i thought you were referring to *the* lkml discussion from last week. | 09:01 |
| bluelightning | yeah, not the LKML one | 09:01 |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 09:08 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 09:10 | |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has joined #yocto | 09:15 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 09:15 | |
| *** lpapp <lpapp!~lpapp@212.44.19.228> has joined #yocto | 09:20 | |
| lpapp | how can I list the dependencies for my own layer? | 09:21 |
| frank | I wonder how *.bbclass executed, they're mixed python and shell code, right ? | 09:21 |
| rburton | frank: <insert bitbake magic> | 09:23 |
| lpapp | frank: bitbake can handle shell and python as well, yeah. | 09:24 |
| rburton | lpapp: bitbake-layers? | 09:24 |
| lpapp | rburton: ? | 09:25 |
| rburton | lpapp: i'm recommending a tool that might do what you want | 09:25 |
| lpapp | http://paste.kde.org/~lpapp/pd35d87b5/ | 09:26 |
| lpapp | can you recommend a tool which at least has a help output? | 09:26 |
| frank | rburton: bitbake magic ? you mean insert python flag for python code sections as like ? | 09:26 |
| rburton | lpapp: ah, works for me. must have been broken in denzil, sorry. probably just a bad import, the error is clear. | 09:27 |
| lpapp | rburton: maybe python 3 issue. | 09:28 |
| rburton | frank: 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 |
| zibri | frank: 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 #yocto | 09:34 | |
| frank | rburton 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 |
| rburton | sort of. | 09:35 |
| *** sameo <sameo!~samuel@192.55.54.41> has quit IRC | 09:37 | |
| *** belen <belen!Adium@nat/intel/x-gtzrabjhoqijecrb> has quit IRC | 09:43 | |
| frank | thanks, rburton | 09:44 |
| lpapp | this bitbake-layers is pretty untalkative tool | 09:55 |
| lpapp | bitbake-layers | 09:55 |
| lpapp | The BBPATH variable is not set | 09:55 |
| lpapp | what BBPATH, how, where, when? | 09:55 |
| mihai | lpapp: source oe-init-build-env before using bitbake-layers | 09:58 |
| lpapp | mihai: that happened | 09:58 |
| mihai | lpapp: and set your default python to 2, instead of 3 | 09:58 |
| lpapp | of course. | 09:58 |
| lpapp | as I could not use bitbake without sourcing anyway | 09:58 |
| lpapp | in any case, is there a hidden option to make it more talkative and dump more useful outputs? | 09:58 |
| mihai | lpapp: what's listed in --help is all there is | 09:59 |
| lpapp | so basically nothing. | 09:59 |
| lpapp | sound ... :( | 09:59 |
| *** belen <belen!~Adium@134.134.139.74> has joined #yocto | 09:59 | |
| ant_work | http://www.crashcourse.ca/wiki/index.php/BitBake_layers | 10:00 |
| lpapp | hopefully these basic tools will improve in the future. | 10:00 |
| lpapp | like 1) Having a help output in the first place 2) Command outputs resulting something productive. etc | 10:00 |
| rburton | lpapp: yes. patches welcome if you have a scratch to itch. | 10:00 |
| ant_work | lpapp: rpjday the author is surely interested to hear your comments for improvements | 10:00 |
| rburton | lpapp: http://pastebin.com/BAuh8Kzk <-- this is what i see when i run it, so there is "help output" | 10:01 |
| lpapp | rburton: there is no help output for me, no. | 10:01 |
| lpapp | ant_work: well, the first important fix would be to have a help output. | 10:01 |
| rburton | lpapp: that was probably fixed in the last year, remember denzil is from april 2012. | 10:01 |
| lpapp | ant_work: perhaps the denzil bitbake-layers version is too old and hence buggy. | 10:01 |
| bluelightning | ant_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 |
| lpapp | rburton: I am very surprised that help output was not the first feature implemented. | 10:02 |
| lpapp | rburton: 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 IRC | 10:03 | |
| lpapp | denzil is probably useless to go for. | 10:04 |
| frank | anyone can tell me why libnfsidmap0 was made an rpm package instead of libnfsidmap, after I run "bitbake libnfsidmap" ? | 10:04 |
| lpapp | I wish we could easily update, but it is a pain with a hardware adaptation layer... :( | 10:04 |
| frank | I wonder where the '0' comes from ? | 10:05 |
| rburton | frank: library version | 10:05 |
| rburton | frank: debian.bbclass does the renaming, if a package contains just a versioned library. | 10:06 |
| lpapp | so any way to specify layer dependencies with denzil? | 10:06 |
| lpapp | see, this is exactly what I meant by no care about a bit more than one year old software | 10:06 |
| lpapp | even basic tools are broken. | 10:06 |
| bluelightning | lpapp: it produces help output perfectly fine here, I just tested it | 10:07 |
| bluelightning | (using denzil) | 10:07 |
| lpapp | bluelightning: ok, but that does not make me work magically. :) | 10:07 |
| frank | rburton: it makes sense. thanks ! | 10:07 |
| lpapp | so 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 #yocto | 10:09 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 10:10 | |
| lpapp | or denzil does not support custom layers then, I take it? | 10:11 |
| rburton | it does, oe-core always has supported layers. | 10:13 |
| lpapp | if it did, it would work for mer. | 10:13 |
| lpapp | me* | 10:13 |
| lpapp | so tell me how to make the help output work then. | 10:13 |
| lpapp | if it does, you will know. | 10:14 |
| lpapp | if 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 |
| rburton | bluelightning 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 |
| lpapp | if it is invoked incorrectly, it *should* tell it. | 10:16 |
| lpapp | which means there is a bug either way. | 10:16 |
| lpapp | so for me, it does not quite qualify as usable, and something that can handle a custom layer. | 10:16 |
| lpapp | it's been an hour I am trying to get it work | 10:16 |
| lpapp | no clue how, really. | 10:16 |
| lpapp | reading upon some information on the internet how to do it manually if that is even possible with this buggy denzil. | 10:17 |
| rburton | bitbake-layers is just an introspection tool, you can still use layers without it. | 10:17 |
| lpapp | how ? | 10:18 |
| rburton | well, you already are. oe-core is a layer. meta-yocto is a layer. | 10:18 |
| lpapp | LAYERDEPENDS maybe. | 10:18 |
| lpapp | I am explicitly not talking about oe-core, nor meta-yocto | 10:19 |
| lpapp | I am actually talking about a custom layer. | 10:19 |
| rburton | that's just semantics, oe-core and meta-yocto are not special in any way. | 10:20 |
| lpapp | they are. | 10:20 |
| lpapp | 1) oe-core: it has no dependencies | 10:20 |
| lpapp | 2) meta-yocto: it actually does not mention oe-core as dependency. | 10:20 |
| lpapp | they are special to my case as I would like to specify dependency layers. | 10:20 |
| rburton | 1) that's just a statement. 2) we should fix that. | 10:21 |
| lpapp | LAYERDEPENDS_hob = "core" -> that seems to be a good example. | 10:22 |
| lpapp | I might send a patch against meta-yocto to depend on core similarly. | 10:23 |
| rburton | sounds like a sensible thing to do indeed. | 10:23 |
| JaMa | rburton: any idea why current weston doesn't recognize --disable-libunwind option? | 10:24 |
| rburton | "configure: WARNING: unrecognized options: --disable-android-compositor" | 10:25 |
| rburton | works for me | 10:25 |
| rburton | should remove that android option though ) | 10:25 |
| JaMa | 1.0.6, right? | 10:26 |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto | 10:26 | |
| rburton | ah, 1.1.0 | 10:26 |
| rburton | unwind is new in 1.1 | 10:26 |
| *** ErkiS <ErkiS!~erki@pro01.dcc.ttu.ee> has joined #yocto | 10:27 | |
| JaMa | ok, I'll backport it into 1.0.6 for dylan, because it autodetects libunwind | 10:28 |
| rburton | huh, i thought unwind itself was new in 1.1 | 10:28 |
| JaMa | rburton: sorry for noise (I thought I've seen it in dylan too) | 10:28 |
| *** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC | 10:28 | |
| rburton | ah so it is | 10:29 |
| JaMa | rburton: http://pastebin.com/AUETam3i | 10:29 |
| JaMa | the option to disable it is new | 10:29 |
| rburton | yeah, so i see | 10:30 |
| lpapp | rburton: the patch should go into the meta-yocto repository and master branch? | 10:32 |
| lpapp | or master-next? | 10:32 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 10:33 | |
| rburton | lpapp: you just send the patch, don't worry about the workflow between that and it reaching master. | 10:33 |
| *** TuTizz <TuTizz!~TuTizz@46.18.96.158> has joined #yocto | 10:35 | |
| lpapp | rburton: to be honest, I have not used git send-email lately. | 10:39 |
| lpapp | and I do not have the sake to set up all the stuff for it to work. | 10:40 |
| rburton | its just a matter of telling it your smtp server | 10:40 |
| lpapp | rburton: well, it is a hassle to set up, especially with email aliases. | 10:41 |
| rburton | fine. | 10:42 |
| lpapp | 1) I use archlinux.us which is a gmail based service, but different domain | 10:44 |
| lpapp | 2) I use the lpapp@kde.org alias | 10:44 |
| lpapp | gluing it all together is effort. | 10:44 |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 10:45 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 10:50 | |
| lpapp | rburton: ok, ssmtp is set up. | 10:55 |
| *** ivali <ivali!~ivali@unaffiliated/ivali> has quit IRC | 10:59 | |
| *** jwessel <jwessel!~jwessel@128.224.250.2> has quit IRC | 10:59 | |
| *** erbo <erbo!~erik@host.62.65.125.245.bitcom.se> has quit IRC | 10:59 | |
| *** fray <fray!U2FsdGVkX1@gate.crashing.org> has quit IRC | 10:59 | |
| *** RP <RP!~richard@dan.rpsys.net> has quit IRC | 10:59 | |
| *** erbo <erbo!~erik@host.62.65.125.245.bitcom.se> has joined #yocto | 10:59 | |
| lpapp | which mailing list should I send the change to? | 10:59 |
| *** RP <RP!~richard@dan.rpsys.net> has joined #yocto | 10:59 | |
| *** jwessel <jwessel!~jwessel@128.224.250.2> has joined #yocto | 10:59 | |
| *** fray <fray!U2FsdGVkX1@63.228.1.57> has joined #yocto | 10:59 | |
| lpapp | yocto@yoctoproject.org ? | 11:00 |
| *** swex <swex!~swex@178.17.200.22> has joined #yocto | 11:02 | |
| rburton | lpapp: for meta-yocto, poky@. | 11:05 |
| *** swex__ <swex__!~swex@178.132.101.134> has quit IRC | 11:05 | |
| lpapp | rburton: already sent to yocto@ | 11:05 |
| *** zerus <zerus!~epetmab@90-224-44-236-no67.tbcn.telia.com> has joined #yocto | 11:06 | |
| lpapp | rburton: I guess I cannot depend on a yocto layer right now either. | 11:07 |
| lpapp | as it is not specified. | 11:07 |
| lpapp | or I can? | 11:08 |
| lpapp | I mean for my own bsp layer. | 11:08 |
| rburton | a bsp layer shouldnt depend on meta-yocto anyway | 11:08 |
| rburton | a BSP layer should be standalone from any distro layer, such as meta-yocto. | 11:08 |
| lpapp | it is a BSP _and_ distribution layer. | 11:08 |
| rburton | we recommend that you split them | 11:08 |
| rburton | your choice, of course. | 11:09 |
| lpapp | yeah, I appreciate the recommendation, but I will not for now. | 11:09 |
| lpapp | so can something depend on meta-yocto without the dedicated entries? | 11:09 |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 11:09 | |
| lpapp | is there a default "yocto" dependency by its name? | 11:09 |
| lpapp | by its file name, etc, that is. | 11:09 |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 11:10 | |
| *** ivali <ivali!~ivali@134.134.139.76> has joined #yocto | 11:11 | |
| *** ivali <ivali!~ivali@unaffiliated/ivali> has joined #yocto | 11:12 | |
| rburton | lpapp: only bblayers.conf | 11:12 |
| lpapp | so patches mentioned in the SRC_URI will be applied by default without an explicit intervention? | 11:12 |
| lpapp | rburton: what do you mean? | 11:13 |
| rburton | lpapp: the only places where layer filenames are is bblayers.conf | 11:13 |
| rburton | lpapp: and yes, a .patch file will be applied automatically unless you tell it otherwise | 11:13 |
| lpapp | rburton: do_patches is the way to tell it otherwise? | 11:14 |
| rburton | lpapp: no, see apply in http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-SRC_URI | 11:14 |
| lpapp | rburton: but how can I depend on meta-yocto in meta-foo then? | 11:14 |
| lpapp | LAYERDEPENDS_foo = "yocto" -> can I use this already? | 11:15 |
| rburton | lpapp: yes | 11:15 |
| rburton | you don't need the dependency from yocto->core to depend on yocto | 11:15 |
| lpapp | ok | 11:16 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 11:36 | |
| *** synthnassizer <synthnassizer!~quassel@143.233.242.130> has joined #yocto | 11:39 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 11:40 | |
| *** joeythesaint <joeythesaint!~jjm@128.224.252.2> has joined #yocto | 11:45 | |
| lpapp | rburton: shall I resubmit my change against poky@? | 11:47 |
| lpapp | rburton: also, for that matter, perhaps the oe-core layer should have versioning as well? | 11:55 |
| g0hl1n | Hello everybody, | 11:59 |
| g0hl1n | what's the best-practice way to change the splash screen? | 11:59 |
| lpapp | g0hl1n: I am not sure what the best practice is, but | 12:00 |
| lpapp | I put it into meta/recipes-core/psplash/ | 12:00 |
| lpapp | arguably, you could put it into your meta-$distro. | 12:01 |
| lpapp | g0hl1n: 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 IRC | 12:02 | |
| lpapp | probably you will need a minor .bbapend, but do not take me seriously. | 12:02 |
| g0hl1n | lpapp: 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 #yocto | 12:03 | |
| lpapp | g0hl1n: don't you yet have an own meta-$distro layer? | 12:03 |
| g0hl1n | lpapp: of course I have one. | 12:04 |
| g0hl1n | lpapp: but is the whole psplash folder of meta-core needed or would a bbappend be sufficient? | 12:05 |
| lpapp | g0hl1n: I would use a .bbappend then with SRC_URI extended. | 12:05 |
| lpapp | you do not modify the script, so I think .bbappend is ok. | 12:05 |
| lpapp | it is similar to when you create a custom bsp layer | 12:05 |
| lpapp | and you have your own kernel config with .bbappend. | 12:06 |
| lpapp | but honestly, I am not an expert. | 12:06 |
| lpapp | so you may want to hear others, too. | 12:06 |
| g0hl1n | lpapp: Thank you. | 12:06 |
| g0hl1n | lpapp: As long as it works it might be ok for me :) | 12:06 |
| lpapp | g0hl1n: I am in the same boat. | 12:07 |
| lpapp | I 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 IRC | 12:09 | |
| lpapp | so 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 #yocto | 12:09 | |
| *** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has joined #yocto | 12:09 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 12:10 | |
| *** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has quit IRC | 12:10 | |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto | 12:10 | |
| bluelightning | lpapp: yes | 12:11 |
| bluelightning | g0hl1n: have a look at what meta-yocto does, it uses a bbappend to change the splash screen | 12:12 |
| g0hl1n | bluelightning: thanks ! | 12:15 |
| bluelightning | g0hl1n: as a slight difference, you can point to a .png file in SRC_URI rather than a header and that will be converted automatically | 12:16 |
| lpapp | bluelightning: why do projects use header then? | 12:19 |
| lpapp | legacy reason or what? | 12:19 |
| lpapp | bluelightning: I do not find any explanation for do_patch | 12:19 |
| bluelightning | lpapp: legacy, plus you avoid having to build gdk-pixbuf-native | 12:19 |
| lpapp | and for any task, for that matter. | 12:19 |
| lpapp | that is actually a good reason why not to use png... | 12:20 |
| lpapp | not to slow the build down. | 12:20 |
| *** sameo <sameo!samuel@nat/intel/x-gwkyzfpykwjckqyv> has joined #yocto | 12:22 | |
| lpapp | bluelightning: the psplash image though should go into the meta-$distro, right? | 12:22 |
| bluelightning | lpapp: correct | 12:23 |
| lpapp | bluelightning: denzil does not use .bbappend for meta-yocto though when it comes to recipes-core/psplash. :/ | 12:23 |
| bluelightning | lpapp: er... ??? it does here | 12:25 |
| bluelightning | even the very first denzil release does | 12:25 |
| lpapp | bluelightning: sounds all kind of weird then. | 12:25 |
| bluelightning | I'd have to agree | 12:25 |
| lpapp | our guy patched that out | 12:26 |
| lpapp | he needs some punishment. :) | 12:26 |
| bluelightning | I see... | 12:26 |
| TuTizz | Hi 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 comment | 12:27 |
| lpapp | bluelightning: so with priority 6, my psplash will be preferred instead of the meta-yocto poky stuff? | 12:28 |
| bluelightning | lpapp: 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 it | 12:31 |
| bluelightning | lpapp: also, it determines the order in which bbappends will be applied if more than one layer applies one to a recipe | 12:31 |
| lpapp | yes, so the short is "yes" then. | 12:31 |
| bluelightning | lpapp: with priority 0 it would be applied, with priority 999 it would be applied; priority is not a factor | 12:32 |
| lpapp | bluelightning: it is | 12:32 |
| lpapp | bluelightning: because it means the poky psplash stuff is not picked up | 12:32 |
| lpapp | oh, really? | 12:33 |
| lpapp | then, I am totally lost | 12:33 |
| lpapp | I thought that is what priority is exactly for. | 12:33 |
| lpapp | to pick up the package (even if just bbappend) which has a higher priority. | 12:33 |
| bluelightning | see above for my explanation about exactly what the priority does | 12:33 |
| *** roric <roric!~roric@194-237-7-146.customer.telia.com> has quit IRC | 12:33 | |
| lpapp | I cannot follow that, sorry. | 12:33 |
| lpapp | you need to rephrase or elaborate more. | 12:33 |
| lpapp | you are claiming that priority does matter which package is picked up. | 12:34 |
| lpapp | then you are claiming, priority does not matter because my recipe will be picked up all the time. | 12:34 |
| bluelightning | lpapp: you have abc_1.23.bb in meta-firstlayer and abc_1.23.bb in meta-secondlayer | 12:34 |
| lpapp | that is contradictory to me. | 12:34 |
| bluelightning | lpapp: in that case the priority will choose which one gets built, assuming there is no PREFERRED_VERSION to override that | 12:35 |
| lpapp | yes | 12:35 |
| lpapp | meta/recipes-core/psplash/psplash_git.bb exists. | 12:35 |
| lpapp | and then there are bbappends in meta-firstlayer and meta-secondlayer | 12:36 |
| lpapp | I wanna get rid of the append for firstlayer | 12:36 |
| bluelightning | lpapp: 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.bbappend | 12:36 |
| lpapp | and apply stuff from my custom secondlayer | 12:36 |
| lpapp | how can I do that? | 12:36 |
| bluelightning | lpapp: both of the two bbappends will be applied, in the order dictated by the relative priorities of the second two layers | 12:36 |
| lpapp | sounds like a feature request then. | 12:37 |
| bluelightning | er, no... | 12:37 |
| lpapp | it is definitely a valid use case to allow me to skip a bbappend | 12:38 |
| lpapp | and apply mine | 12:38 |
| lpapp | and only mine. | 12:38 |
| bluelightning | if you want yours applied, see the second example | 12:38 |
| bluelightning | or rather, if you want yours applied last | 12:38 |
| *** eren <eren!~eren@unaffiliated/eren> has joined #yocto | 12:39 | |
| lpapp | no no | 12:39 |
| lpapp | I do not wanna get both applied | 12:39 |
| lpapp | I wanna get mine applied, and only that. | 12:39 |
| lpapp | I think it is a valid use case and hence feature. | 12:39 |
| lpapp | I do not wanna get both applied | 12:39 |
| lpapp | surely, it is not a problem for small changes. | 12:39 |
| lpapp | but for huge changes, it is an unnecessary overhead, that is. | 12:40 |
| lpapp | so as a workaround for now: the poky image is applied, and then mine, too? | 12:41 |
| lpapp | and mine will be the last if the layer containing it, has a higher priority than meta-yocto? | 12:41 |
| bluelightning | yes | 12:41 |
| ndec | you could 'mask' the offending recipe too, perhaps, no? | 12:42 |
| eren | when we create hdimage, or "iso", can it be directly "dd"ed into compact flash drive? | 12:42 |
| eren | if not, how can we bring together isolinux, kernel, rootfs so that the only needed command is "dd" to compact flash or usb? | 12:42 |
| lpapp | bluelightning: the problem is not when the second application can block the first | 12:42 |
| lpapp | by overriding it. | 12:42 |
| lpapp | bluelightning: the problem is that, when they are actually different changes. | 12:42 |
| lpapp | bluelightning: and you do not wanna take that. | 12:43 |
| bluelightning | ndec: 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 inappropriately | 12:43 |
| lpapp | bluelightning: then you will be screwed. | 12:43 |
| bluelightning | lpapp: that's not going to be the case in this instance | 12:43 |
| lpapp | bluelightning: not here, but I have places where it will be though. | 12:43 |
| lpapp | http://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@194.9.240.240> has joined #yocto | 12:44 | |
| lpapp | ok, semi-clear from the log. | 12:44 |
| bluelightning | eren: I'm not entirely sure, I suspect our iso's can't currently be used in that way | 12:45 |
| bluelightning | eren: hence why we have live images that can | 12:45 |
| bluelightning | eren: a lot of the deployment stuff is planned to be reworked very soon which should address these kinds of concerns | 12:46 |
| eren | bluelightning: 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/221 | 12:46 | |
| bluelightning | eren: yes for something you can dd to a USB stick | 12:47 |
| eren | otherwise, I need to manually install "grub", copy sysroot and kernel etc | 12:47 |
| lpapp | bluelightning: shsh, the guy put the custom image header into meta | 12:47 |
| lpapp | not even meta-yocto | 12:47 |
| lpapp | double punishment. :) | 12:47 |
| *** roinn <roinn!~roinn@194.9.240.240> has quit IRC | 12:47 | |
| bluelightning | eren: indeed | 12:47 |
| eren | bluelightning: ok, I have ALIX 3D3 board which is a regular x86-compatible device. I guess "live" image would be OK for it | 12:48 |
| *** roinn <roinn!~roinn@194.9.240.240> has joined #yocto | 12:48 | |
| lpapp | do people use recipes-core/images a lot to create custom images? | 12:48 |
| eren | the arch is i586, I even have a BSP for starting | 12:48 |
| bluelightning | eren: I would think so yes... occasionally there can be issues depending on what kind of BIOS the board has on it | 12:48 |
| lpapp | there are no fpga recipes around yet anywhere? | 12:49 |
| bluelightning | lpapp: as a basis, quite often I think | 12:49 |
| eren | okkie, I will try that, then | 12:49 |
| lpapp | for xilinx, altera, etc? | 12:49 |
| bluelightning | lpapp: xilinx provide their own layers for stuff, I think altera has something as well but I'm not sure of the details | 12:50 |
| lpapp | yeah, just found that on layer index. | 12:51 |
| *** JaMa <JaMa!~martin@ip-62-24-80-145.net.upcbroadband.cz> has quit IRC | 12:53 | |
| *** flynn378 <flynn378!80db310d@gateway/web/freenode/ip.128.219.49.13> has joined #yocto | 12:55 | |
| *** flynn378 <flynn378!80db310d@gateway/web/freenode/ip.128.219.49.13> has joined #yocto | 12:56 | |
| lpapp | bluelightning: what to do with ../../../meta-yocto/conf/foo-local.conf and ../../../meta-yocto/conf/site-foo.conf files we had? | 13:00 |
| bluelightning | lpapp: depends, what's in them that's not in the default unmodified local.conf? | 13:01 |
| lpapp | bluelightning: I do not see default in here: http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/conf | 13:05 |
| bluelightning | lpapp: try: http://cgit.openembedded.org/openembedded-core/tree/meta/conf | 13:06 |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-uwjfatdnkgfcybuj> has joined #yocto | 13:06 | |
| lpapp | bluelightning: I have not actually seen "meta" in here, http://cgit.openembedded.org/meta-openembedded/tree/ | 13:07 |
| lpapp | ah, it is oe-core | 13:07 |
| lpapp | right | 13:07 |
| bluelightning | TuTizz: sorry, which " " ? | 13:08 |
| lpapp | bluelightning: interesting, the poky release do not come with examples. | 13:09 |
| lpapp | but that is probably OK ... | 13:09 |
| bluelightning | lpapp: in poky the equivalents are under meta-yocto/conf/ | 13:09 |
| lpapp | true. | 13:10 |
| lpapp | our site.conf is equal to the sample. | 13:10 |
| lpapp | so is our local.conf to the sample (note, not extended). | 13:11 |
| lpapp | bluelightning: so just copy those samples over to meta-foo/conf/? | 13:12 |
| bluelightning | lpapp: no, you shouldn't do that | 13:12 |
| lpapp | bluelightning: then what? | 13:13 |
| bluelightning | lpapp: what are you trying to accomplish particularly if the files are the same as the sample ones? | 13:14 |
| TuTizz | bluelightning, 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 |
| bluelightning | TuTizz: I'm not sure if that's there deliberately | 13:16 |
| bluelightning | TuTizz: 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 it | 13:16 |
| TuTizz | bluelightning, ok, should I write something about it? | 13:17 |
| bluelightning | TuTizz: you can feel free to post a question to the mailing list | 13:17 |
| TuTizz | bluelightning, ok | 13:20 |
| *** davest <davest!Adium@nat/intel/x-ejgjdmrxdeeegxed> has joined #yocto | 13:20 | |
| lpapp | bluelightning: porting an existing code to a more modularized | 13:22 |
| lpapp | perhaps it had an intent | 13:22 |
| lpapp | which needs to be revisited later. | 13:22 |
| lpapp | bluelightning: I will just copy over for now. | 13:23 |
| *** acidfu <acidfu!~nib@unaffiliated/acidmen> has quit IRC | 13:25 | |
| *** JimNH2 <JimNH2!~jmchale@23-25-235-113-static.hfc.comcastbusiness.net> has joined #yocto | 13:25 | |
| lpapp | bluelightning: should I resubmit my yocto patch against poky@? | 13:26 |
| bluelightning | lpapp: it would be preferable yes | 13:27 |
| *** JimNH3 <JimNH3!~jmchale@23-25-235-113-static.hfc.comcastbusiness.net> has quit IRC | 13:29 | |
| lpapp | bluelightning: done | 13:31 |
| bluelightning | thx | 13:31 |
| lpapp | bluelightning: do these make any sense in the layer conf? http://paste.kde.org/~lpapp/p63f02b8d/ | 13:32 |
| silviof | eren: the meta-fsl-arm layer makes a sdcard image - you can look how they do it... | 13:32 |
| eren | silviof: okkie | 13:32 |
| bluelightning | lpapp: the setting of PATH and COREBASE sets off alarm bells | 13:34 |
| bluelightning | lpapp: if you're setting COREBASE and QEMUIMAGETESTS solely because that's what OE-Core's layer.conf does, don't do that | 13:35 |
| *** walters <walters!walters@nat/redhat/x-rcqaayzvoidkhzrg> has joined #yocto | 13:36 | |
| rburton | morning walters | 13:36 |
| walters | rburton: good morning! | 13:37 |
| eren | the moment that you cannot remember why you coded, add configuration in such a way | 13:37 |
| lpapp | bluelightning: I agree. | 13:37 |
| eren | now I should read the kernel article from the start, check out kernel metadata and play with it | 13:37 |
| lpapp | bluelightning: http://paste.kde.org/~lpapp/pb97a98de/ -> not sure if the first makes any sense | 13:40 |
| lpapp | I saw this somewhere. | 13:40 |
| lpapp | I mean it is already coded into the second line. | 13:40 |
| bluelightning | lpapp: the old convention was BBFILES := "${BBFILES} ..."; you should use BBFILES += "..." instead | 13:41 |
| *** ruben__ <ruben__!~ruben@217.8.50.14> has joined #yocto | 13:44 | |
| lpapp | bluelightning: yeah, so removing the first line | 13:45 |
| lpapp | and s/:=/+=/ on the second. | 13:45 |
| bluelightning | lpapp: and remove ${BBFILES} | 13:45 |
| ruben__ | hello, has anybody beaglebone black with yocto? | 13:45 |
| lpapp | bluelightning: yes | 13:45 |
| eren | is there a problem with git repository? | 13:45 |
| eren | it is really slow | 13:45 |
| lpapp | bluelightning: is it a common practice in third-party projects to check in downloaded files? | 13:46 |
| lpapp | it seems to me. | 13:46 |
| lpapp | it avoiding the downloading of lots of stuff. | 13:46 |
| eren | I'm in the university network, it has 20mbit of output | 13:46 |
| bluelightning | lpapp: not sure what you mean... ? | 13:46 |
| ndec | lpapp: not checked in per-say. but creating your local mirror, yes certainly a good practice. | 13:46 |
| lpapp | bluelightning: downloads folder in the build foler. | 13:47 |
| lpapp | folder* | 13:47 |
| ndec | e.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 #yocto | 13:47 | |
| eren | oh damn, there is a huge lag to level3 network :( | 13:47 |
| ndec | lpapp: for the 'build' folder, you should not do anything with it. what is probably good practice is to mirror the sstate folder. | 13:48 |
| ndec | though i have no idea what sstate was in denzil ;-) | 13:48 |
| rburton | lpapp: 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 |
| ndec | rburton: is there any standard tool to upade a sstate mirror at the end of a build? | 13:50 |
| ndec | or is it expected that the 'builder' has write access to sstate directly? | 13:50 |
| rburton | ndec: not afaik. one option it just to use a NAS and nfs/smb mounts. | 13:50 |
| lpapp | rburton: more work | 13:50 |
| ndec | rburton: sure. | 13:51 |
| rburton | lpapp: checking into a vcs server your entire downloads directory would be ... odd. you'd kill many systems for a start. | 13:51 |
| lpapp | rburton: not entirely sure what you mean. | 13:51 |
| ndec | lpapp: 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 |
| lpapp | ndec: no no | 13:52 |
| lpapp | ndec: I mentioned I do not wanna use the upstream git repository | 13:52 |
| rburton | i'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 |
| lpapp | let us not lose the important bits during the translation | 13:52 |
| lpapp | interpretation* | 13:52 |
| rburton | oh goodie "windows system support" have just called. | 13:53 |
| lpapp | rburton: not sure what you mean | 13:54 |
| lpapp | many 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 IRC | 13:55 | |
| rburton | fine, 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 |
| lpapp | it is not about who knows best. | 13:57 |
| lpapp | it is about that it works. | 13:57 |
| lpapp | it 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 IRC | 13:58 | |
| *** bluelightning_ <bluelightning_!~paul@83.217.123.106> has joined #yocto | 14:00 | |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 14:00 | |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-mqgkazthmbohiacr> has joined #yocto | 14:00 | |
| *** mihai <mihai!mihai@nat/intel/x-ikclvczxdjrydgyw> has quit IRC | 14:00 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 14:00 | |
| *** bluelightning_ is now known as bluelightning | 14:00 | |
| *** sameo <sameo!samuel@nat/intel/x-gwkyzfpykwjckqyv> has quit IRC | 14:01 | |
| *** mihai <mihai!~mihai@80.97.15.150> has joined #yocto | 14:01 | |
| lpapp | bluelightning: is it worth cleaning up the recipes? | 14:04 |
| lpapp | at several places, there are multiple versions, like u-boot. | 14:04 |
| lpapp | so how do the recipe writers update the checksums? Everyone manually invoking the tools, and copy pasting output, etc? | 14:05 |
| lpapp | and then fixing bugs due to copy paste and other silly issues? | 14:05 |
| bluelightning | lpapp: so with u-boot I don't know why we have multiple versions | 14:05 |
| lpapp | bluelightning: at least, I should not copy the old versions to my layer as well, I guess. | 14:06 |
| bluelightning | lpapp: 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 images | 14:07 |
| bluelightning | lpapp: no, you'd just have one version since that's likely all you would need | 14:08 |
| lpapp | bluelightning: ok, any reason why we do not have only a u-boot package rather than fw-utils, mkimage, etc? | 14:08 |
| bluelightning | lpapp: probably because the tools need to be built for the host whereas we want u-boot itself built for the target | 14:09 |
| lpapp | bluelightning: yeah, but there are three packages instead of two, even then. | 14:10 |
| bluelightning | like I said, I don't know why we have multiple versions of u-boot | 14:10 |
| lpapp | bluelightning: it is not versions. | 14:10 |
| lpapp | it is multiple packages for the same version. | 14:11 |
| lpapp | fw-utils, mkimage, and u-boot. | 14:11 |
| bluelightning | u-boot is the bootloader, u-boot-mkimage is for creating the uimage file, no idea what u-boot-fw-utils is | 14:12 |
| lpapp | yes, I know what they are. | 14:12 |
| lpapp | I just do not understand why they need three packages. | 14:12 |
| lpapp | anyway, how about the question above: | 14:13 |
| lpapp | so how do the recipe writers update the checksums? Everyone manually invoking the tools, and copy pasting output, etc? | 14:13 |
| lpapp | and then fixing bugs due to copy paste and other silly issues? | 14:13 |
| bluelightning | yes and in practice that's rarely a problem at least in my experience | 14:13 |
| lpapp | would not it be handy to just run a tool anyway? | 14:14 |
| lpapp | copy/paste errors not a problem in practice? | 14:14 |
| lpapp | well, look for programming forums all around. | 14:14 |
| rburton | lpapp: automatically updated checksums would invalidate the point, which is a human being verified them. | 14:15 |
| lpapp | rburton: I really do not know what you mean | 14:16 |
| lpapp | the checksum would come from the output of the tool | 14:16 |
| lpapp | exactly what you do _manually_ | 14:17 |
| rburton | by manually you mean "run bitbake" | 14:17 |
| rburton | feel free to write a tool if you want though | 14:18 |
| *** acidfu <acidfu!~nib@unaffiliated/acidmen> has joined #yocto | 14:18 | |
| lpapp | rburton: nope | 14:18 |
| lpapp | manually, I mean md5, etc commands | 14:18 |
| lpapp | which will provide you the crcs. | 14:18 |
| rburton | yeah 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 |
| lpapp | you still need to copy them inside the file. | 14:19 |
| lpapp | instead of a tool updating the file. | 14:19 |
| * rburton shrugs | 14:20 | |
| rburton | that's two lines of copy and paste. | 14:20 |
| lpapp | yes, exactly. | 14:20 |
| lpapp | instead of just using an option for bitbake. | 14:20 |
| *** acidfu <acidfu!~nib@unaffiliated/acidmen> has quit IRC | 14:22 | |
| lpapp | what 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 #yocto | 14:23 | |
| *** ruben__ <ruben__!~ruben@217.8.50.14> has quit IRC | 14:24 | |
| *** tonghuix <tonghuix!~tonghuix@114.245.222.35> has joined #yocto | 14:24 | |
| mario-goulart | lpapp: 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 #yocto | 14:26 | |
| lpapp | yeah, ok. | 14:26 |
| kergoth | s/_/-/ | 14:28 |
| lpapp | ERROR: Failed to obtain CodeSourcery toolchain version: Execution of '/usr/local/arm-2009q1/bin/INVALID-oe-linux-gcc -v' failed: command not found | 14:32 |
| lpapp | that INVALID-oe-linux stuff looks kinda weird, no/ | 14:33 |
| lpapp | ? | 14:33 |
| lpapp | TCMODE = "external-csl" | 14:33 |
| lpapp | EXTERNAL_TOOLCHAIN = "/usr/local/arm-2009q1" | 14:33 |
| lpapp | TARGET_PREFIX = "arm-none-linux-gnueabi-" | 14:33 |
| lpapp | I have this, and I have the toolchain installed right in there. | 14:34 |
| *** davest <davest!Adium@nat/intel/x-ejgjdmrxdeeegxed> has quit IRC | 14:38 | |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-mqgkazthmbohiacr> has quit IRC | 14:41 | |
| *** Garibaldi|work <Garibaldi|work!~andydalt@64.102.254.33> has joined #yocto | 14:46 | |
| *** walters <walters!walters@nat/redhat/x-rcqaayzvoidkhzrg> has quit IRC | 14:46 | |
| *** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has joined #yocto | 14:47 | |
| *** sameo <sameo!samuel@nat/intel/x-bvqszfjnhwoiinef> has joined #yocto | 14:49 | |
| *** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has quit IRC | 14:50 | |
| *** Song <Song!c0373629@gateway/web/freenode/ip.192.55.54.41> has joined #yocto | 14:51 | |
| *** Song is now known as Song_Liu | 14:51 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 14:52 | |
| *** laur <laur!~lau@192.198.151.43> has joined #yocto | 14:54 | |
| *** scottrif <scottrif!~scott-len@b482.ip17.netikka.fi> has joined #yocto | 14:56 | |
| *** belen <belen!~Adium@134.134.139.74> has quit IRC | 14:57 | |
| *** Corneliu <Corneliu!c0c6972b@gateway/web/freenode/ip.192.198.151.43> has joined #yocto | 14:58 | |
| lpapp | anyone got a clue about the error above? | 14:58 |
| *** belen <belen!Adium@nat/intel/x-gpylnnimqnxxrekm> has joined #yocto | 14:59 | |
| sgw_ | YTPM: Saul Here | 15:00 |
| pidge | YPTM: Beth is on the bridge | 15:00 |
| Corneliu | YPTM: Corneliu joined | 15:00 |
| scottrif | YPTM: Scott Rifenbark joined the call | 15:00 |
| bluelightning | YPTM: Paul Eggleton here | 15:00 |
| *** Ramana_ <Ramana_!7aa6729b@gateway/web/freenode/ip.122.166.114.155> has joined #yocto | 15:00 | |
| Song_Liu | YPTM: Welcome to the technical team meeting, please let me know who's on the bridge | 15:00 |
| belen | YPTM: Belen joined | 15:00 |
| jmpdelos | YPTM: polk joined | 15:00 |
| *** Guest91176 is now known as tomz | 15:00 | |
| lpapp | also, mkimage and fw-utils get the u-boot packages from the ftp site | 15:00 |
| lpapp | but u-boot does not ?! | 15:00 |
| tomz | YPTM: Tom Z here | 15:00 |
| laur | YPTM: LaurentiuP joined | 15:00 |
| nitink | YPTM: nitin is dialing the bridge | 15:00 |
| *** tomz is now known as Guest25188 | 15:00 | |
| sgw_ | Yocto Project Tech Meeting: | 15:01 |
| sgw_ | Dial-in number: 1.972.995.7777 | 15:01 |
| sgw_ | US Toll Free number: 1.877.561.6828 | 15:01 |
| sgw_ | Participant passcode: 42001078 | 15:01 |
| rburton | YPTM: ross here | 15:01 |
| *** jzhang-laptop <jzhang-laptop!~jzhang16@134.134.137.75> has joined #yocto | 15:02 | |
| jzhang-laptop | YPTM: jzhang on the call | 15:02 |
| sgw_ | Song_Liu: I think you should start posting the Dial info here in case people are on the ML yet | 15:02 |
| rburton | i think we should do the irc back-channel in another room so we don't swamp any existing discussions | 15:03 |
| Ramana_ | joined YPTM | 15:03 |
| kergoth | YPTM: Chris Larson here | 15:03 |
| Song_Liu | YPTM: Any opens? | 15:03 |
| Ramana_ | https://wiki.yoctoproject.org/wiki/Binary_configuration_support | 15:04 |
| Ramana_ | https://bugzilla.yoctoproject.org/show_bug.cgi?id=3252 | 15:04 |
| yocti | Bug 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 #yocto | 15:04 | |
| BSDCat | Matthew Weigel here | 15:04 |
| Song_Liu | https://wiki.yoctoproject.org/charts/combo.html | 15:06 |
| Song_Liu | https://bugzilla.yoctoproject.org/buglist.cgi?priority=High&priority=Medium%2B&priority=Medium&list_id=59356&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&columnlist=short_desc%2Ctarget_milestone%2Cbug_severity%2Cpriority%2Cassigned_to%2Cbug_status%2Cstatus_whiteboard&query_based_on=All%20med-above%20bugs&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ACCEPTED&bug_status=IN%20P | 15:07 |
| zeddii | YPTM: 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 #yocto | 15:19 | |
| mulhern | YPTM: mulhern here | 15:20 |
| *** slaine <slaine!~slaine@84.203.137.218> has quit IRC | 15:30 | |
| halstead | oops. YPTM: Michael was there. :) | 15:34 |
| *** belen <belen!Adium@nat/intel/x-gpylnnimqnxxrekm> has quit IRC | 15:35 | |
| *** scottrif <scottrif!~scott-len@b482.ip17.netikka.fi> has left #yocto | 15:36 | |
| lpapp | bluelightning: why do you think it is easier to backport patches with git? | 15:36 |
| lpapp | http://patchwork.openembedded.org/patch/31377/ | 15:36 |
| lpapp | trying to backport this one for instance. | 15:36 |
| lpapp | should I back port it to the poky repository, btw? | 15:37 |
| *** belen <belen!~Adium@134.134.139.74> has joined #yocto | 15:38 | |
| kergoth | heh :) | 15:40 |
| *** zenlinux_ <zenlinux_!~sgarman@24.20.145.95> has joined #yocto | 15:40 | |
| *** Corneliu <Corneliu!c0c6972b@gateway/web/freenode/ip.192.198.151.43> has quit IRC | 15:41 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 15:42 | |
| sgw_ | lpapp: what version of poky are you trying to patch? | 15:42 |
| lpapp | bluelightning: http://paste.kde.org/~lpapp/pe272b5bd/ | 15:43 |
| lpapp | cherry-pick did not quite work out. | 15:43 |
| *** jzhang-laptop <jzhang-laptop!~jzhang16@134.134.137.75> has quit IRC | 15:43 | |
| lpapp | sgw_: denzil | 15:44 |
| bluelightning | lpapp: not really surprising I guess... you'll just have to go through and resolve the conflicts | 15:44 |
| lpapp | bluelightning: thing is, I do not understand the conflict. | 15:44 |
| *** TuTizz <TuTizz!~TuTizz@46.18.96.158> has quit IRC | 15:45 | |
| lpapp | bluelightning: I guess it is somewhat due to the PR numbers. | 15:45 |
| lpapp | bluelightning: http://paste.kde.org/~lpapp/p66d616be/ | 15:47 |
| lpapp | bluelightning: once I solve it, is it welcome in upstream? | 15:48 |
| lpapp | or the denzil branch is frozen? | 15:48 |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 15:48 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 15:49 | |
| *** bluelightning_ is now known as bluelightning | 15:49 | |
| *** TuTizz <TuTizz!~TuTizz@46.18.96.158> has joined #yocto | 15:49 | |
| *** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto | 15:49 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 15:50 | |
| *** ivali <ivali!~ivali@unaffiliated/ivali> has quit IRC | 15:59 | |
| *** eballetbo <eballetbo!~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net> has quit IRC | 16:01 | |
| *** zeeblex1 <zeeblex1!apalalax@nat/intel/x-gakyprcwjynfsqte> has left #yocto | 16:03 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 16:03 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 16:06 | |
| *** elmi82 <elmi82!~timo@mail.bmw-carit.de> has quit IRC | 16:07 | |
| *** mckoan is now known as mckoan|away | 16:09 | |
| *** dlern <dlern!~dlerner@128.224.250.2> has joined #yocto | 16:11 | |
| lpapp | bluelightning: how do you solve conflicts in so many files? | 16:11 |
| lpapp | it is a royal pain in the ass. | 16:11 |
| bluelightning | lpapp: it's just what you have to deal with when backporting | 16:11 |
| lpapp | bluelightning: even git mergetool with vimdiff is super painful, and more importantly: overly error-prone. | 16:12 |
| lpapp | bluelightning: I spent half an hour with it | 16:14 |
| lpapp | and after the resolve, I got my content lost | 16:14 |
| lpapp | I am not sure I would like to really backport it to the repository, and maintain it. | 16:14 |
| lpapp | it is not really fun | 16:14 |
| bluelightning | it just takes practice | 16:14 |
| bluelightning | and yes, it's not fun | 16:14 |
| lpapp | well, you have not shared any practice yet. | 16:15 |
| bluelightning | there's no magic to it | 16:15 |
| lpapp | that is bad | 16:16 |
| lpapp | we should have a git tool for it | 16:16 |
| *** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC | 16:16 | |
| bluelightning | sometimes it's easier just to look at what the patch does and make the appropriate changes yourself | 16:16 |
| bluelightning | I'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 distro | 16:16 |
| lpapp | well, Intel should maintain it in the first place (tm). :) | 16:18 |
| bluelightning | we did try to warn you... | 16:18 |
| bluelightning | why? | 16:18 |
| lpapp | warn is highly productive | 16:19 |
| lpapp | I mean, I was aware of it of course. | 16:19 |
| lpapp | yet, someone has to do the work | 16:19 |
| lpapp | because Intel is a big company | 16:19 |
| lpapp | they could know one year support for a software is nothing. | 16:19 |
| lpapp | almost | 16:20 |
| bluelightning | if only it were that simple... | 16:20 |
| b1gtuna | good morning! Has anyone seen dhclient.service failing to start on boot? | 16:20 |
| lpapp | bluelightning: ? | 16:20 |
| b1gtuna | It's failing because the interface isn't up yet | 16:21 |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 16:21 | |
| bluelightning | lpapp: within Intel it's actually quite a small team working full time on the Yocto Project | 16:21 |
| bluelightning | lpapp: not to mention, we're not the only organisation involved | 16:21 |
| lpapp | bluelightning: small team means? | 16:22 |
| bluelightning | lpapp: 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 versions | 16:22 |
| lpapp | well, arch is a very popular distro. | 16:23 |
| bluelightning | it also changes more frequently than any other on our list which means it requires more support effort than any other on our list | 16:23 |
| lpapp | I would not say that | 16:23 |
| lpapp | I would claim the opposite personally. | 16:24 |
| lpapp | it getsw new software | 16:24 |
| lpapp | it gets bugfixes earlier | 16:24 |
| lpapp | rather than ancient distributionsd. | 16:24 |
| *** ErkiS <ErkiS!~erki@pro01.dcc.ttu.ee> has quit IRC | 16:24 | |
| bluelightning | bugfixes and new versions of base tools we rely on (automake, autoconf, libtool, texinfo, ...) that lead to breakages | 16:24 |
| lpapp | bluelightning: gd | 16:24 |
| lpapp | * Unmerged path meta/recipes-support/gnutls/gnutls_2.12.20.bb | 16:24 |
| lpapp | what to do here? | 16:24 |
| bluelightning | not sure, sorry | 16:26 |
| *** levi <levi!~user@c-24-10-225-212.hsd1.ut.comcast.net> has quit IRC | 16:26 | |
| * lpapp cries | 16:26 | |
| lpapp | bluelightning: I will drop the cherry-pick thingie | 16:26 |
| lpapp | it is a lot easier to write a patch from scratch | 16:27 |
| rburton | yeah, 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 #yocto | 16:27 | |
| *** levi <levi!~user@c-24-10-225-212.hsd1.ut.comcast.net> has joined #yocto | 16:28 | |
| lpapp | yeah, but I will not give credit then whatsoever. :) | 16:28 |
| lpapp | also, it is patching stdio.in.h which is a generated file? I do not follow. | 16:28 |
| lpapp | +=================================================================== | 16:29 |
| lpapp | +--- gettext-0.18.1.1.orig/gettext-runtime/gnulib-lib/stdio.in.h2010-05-17 12:56:12.000000000 -0700 | 16:29 |
| lpapp | ++++ gettext-0.18.1.1/gettext-runtime/gnulib-lib/stdio.in.h2012-07-02 22:42:21.292223316 -0700 | 16:29 |
| lpapp | why would anyone patch a generated file? | 16:29 |
| lpapp | oh, d'oh | 16:30 |
| lpapp | it has already been fixed in denzil | 16:30 |
| lpapp | it just has not been released | 16:30 |
| lpapp | sigh | 16:30 |
| lpapp | what is the point of fixing if it is not released?! | 16:30 |
| *** Guest98725 <Guest98725!~tbn@84.55.160.118> has quit IRC | 16:31 | |
| lpapp | probably time to take the latest version from git ... | 16:31 |
| rburton | lpapp: 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 |
| lpapp | rburton: you do realize there was no commit for about half a year? | 16:32 |
| rburton | lpapp: branching off the release branch is a sensible thing to do - you get fixes earlier and the chance of breakage is slim | 16:32 |
| rburton | lpapp: as a member of the community feel free to propose one final spin if there's numerous patches that are not in a release there | 16:32 |
| lpapp | I do not think it is "final" whatever it means. | 16:33 |
| rburton | or, just use the release branch. | 16:33 |
| lpapp | people do not choose software for a few months. | 16:33 |
| *** jzhang-laptop <jzhang-laptop!~jzhang16@134.134.137.73> has joined #yocto | 16:34 | |
| lpapp | although now that I got my layer testable, I think there is no reason not to try the latest poky versionm | 16:34 |
| lpapp | version* | 16:34 |
| lpapp | also, that has bugs for arch, too, unfortunately. | 16:34 |
| lpapp | I guess now that my layer got separated after 2-3 days work. | 16:35 |
| lpapp | I think it should be easy to update poky? | 16:35 |
| lpapp | btw, are you trying to push changes upstream? | 16:39 |
| *** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 16:40 | |
| *** cetola <cetola!~cetola@74-92-165-193-Oregon.hfc.comcastbusiness.net> has joined #yocto | 16:41 | |
| lpapp | WARNING: Failed to fetch URL http://www.zlib.net/zlib-1.2.7.tar.bz2, attempting MIRRORS if available | 16:43 |
| lpapp | that url looks broken. | 16:44 |
| lpapp | ok, so the poky releases have issue when upstream screws up the existing urls... | 16:47 |
| lpapp | that is good to know... | 16:47 |
| lpapp | is there a fallback solution provided by Yocto? | 16:48 |
| lpapp | like a mirror for the released stuff? | 16:48 |
| bluelightning | naturally | 16:48 |
| bluelightning | see the MIRRORS setting in meta-yocto/conf/distro/poky.conf | 16:49 |
| lpapp | naturally what? | 16:49 |
| lpapp | I have just double checked the downloads. | 16:49 |
| bluelightning | naturally we have a fallback | 16:49 |
| lpapp | and zlib is there. | 16:49 |
| lpapp | how about updating poky? | 16:49 |
| bluelightning | right | 16:49 |
| bluelightning | we do update it, regularly | 16:49 |
| lpapp | no no | 16:49 |
| lpapp | I mean, me updating from denzil to dylan | 16:49 |
| lpapp | should that be smooth? | 16:50 |
| bluelightning | lpapp: if you follow: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#migration | 16:50 |
| pidge | lpapp: yes. all sources that we utilize over the course of autobuilds are available, in perpetuity, via the autobuilder mirror. | 16:50 |
| lpapp | ok, how about my other question: | 16:52 |
| lpapp | btw, are you trying to push changes upstream? | 16:52 |
| *** sameo <sameo!samuel@nat/intel/x-bvqszfjnhwoiinef> has quit IRC | 16:54 | |
| lpapp | bluelightning: it is 1.14, not 1.13 though. | 16:55 |
| *** mihai <mihai!~mihai@80.97.15.150> has quit IRC | 16:56 | |
| lpapp | is there a patch update tool? | 16:57 |
| *** tonghuix <tonghuix!~tonghuix@114.245.222.35> has quit IRC | 17:01 | |
| *** mulhern <mulhern!~mulhern@24.128.153.12> has joined #yocto | 17:03 | |
| *** mulhern <mulhern!~mulhern@24.128.153.12> has quit IRC | 17:04 | |
| lpapp | bluelightning: http://paste.kde.org/~lpapp/pa772324b/ dylan build issue with gcc | 17:04 |
| lpapp | is that fixed in master? | 17:04 |
| bluelightning | frankly, I thought it was fixed in dylan | 17:05 |
| lpapp | bluelightning: ah, you are familiar with this issue? | 17:05 |
| bluelightning | I am yes, it came with the introduction of gcc 4.8 | 17:06 |
| * lpapp is not using gcc 4.8 | 17:06 | |
| lpapp | so it is not the typical 4.8 cannot build 4.7 issue | 17:06 |
| lpapp | gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) | 17:07 |
| lpapp | note, I do not use the arch toolchain. | 17:07 |
| lpapp | it should use the cross compilation arm gnueabi one from code sourcery. | 17:08 |
| bluelightning | lpapp: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dylan&id=950f2e453a2bd31764e99eb09154768e0c5049a4 | 17:10 |
| lpapp | bluelightning: yeah, I was just having that open | 17:10 |
| lpapp | Net147 sent it 3 weeks ago or so | 17:10 |
| lpapp | still, I do not build with 4.8 | 17:10 |
| lpapp | so I am not sure how it is relevant. | 17:10 |
| bluelightning | lpapp: your host compiler is gcc 4.8.x | 17:11 |
| bluelightning | lpapp: the fact that it's building gcc-cross-initial tells me that it's not using an external toolchain (correctly) | 17:11 |
| lpapp | bluelightning: as I said, it should not use the host compiler at all. | 17:11 |
| lpapp | I am building for arm. | 17:11 |
| lpapp | it should use the arm toolchain specified. | 17:11 |
| lpapp | right, so why is it not using the toolchain? | 17:11 |
| bluelightning | presumably, because it's not configured correctly | 17:12 |
| lpapp | means what exactly? | 17:12 |
| bluelightning | I can't personally help you configure it because I've never used the external CSL toolchain | 17:12 |
| lpapp | now this is where build/conf/local.conf is VERY annoying. | 17:13 |
| lpapp | I forgot to copy paste that from another build | 17:13 |
| lpapp | and now, I am getting it. | 17:13 |
| lpapp | can we reiterate ~/.yoctorc again please | 17:13 |
| lpapp | it is a pain in the ass without. | 17:13 |
| bluelightning | nope | 17:13 |
| lpapp | huh? | 17:14 |
| lpapp | I just wasted 1-2 hours | 17:14 |
| lpapp | due to it. | 17:14 |
| bluelightning | we've already explained why it can't work | 17:14 |
| bluelightning | and I'm not going to do so again | 17:14 |
| lpapp | it *can* work | 17:14 |
| lpapp | and no one actually had a rebruttal for my argument why it could not. | 17:14 |
| *** davest <davest!~Adium@134.134.137.75> has joined #yocto | 17:14 | |
| lpapp | or not something that a mortar can understand. | 17:14 |
| bluelightning | frankly 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 discussed | 17:15 |
| lpapp | Your 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 |
| lpapp | Matching the version numbers will remove this message. | 17:16 |
| lpapp | I did not have any old/new? | 17:16 |
| lpapp | it should have generated a new? | 17:16 |
| lpapp | I am clueless what is happening? | 17:16 |
| lpapp | how can something be conflicting which does not even exist? | 17:18 |
| lpapp | oh, I think the main problem is that bblayers.conf is not generated with my layer inside | 17:19 |
| lpapp | why is it not? | 17:19 |
| lpapp | how can I get it autogenerated like that? | 17:19 |
| lpapp | oh, the bblayers.conf stuff changed. | 17:20 |
| lpapp | to COREBASE | 17:20 |
| lpapp | what, it is not clear | 17:22 |
| lpapp | ERROR: 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-builds | 17:23 |
| lpapp | what do I need to replace ##COREBASE## with? | 17:24 |
| lpapp | Really, it is not written in the file. | 17:24 |
| bluelightning | that's a placeholder which the oe-init-build-env script automatically replaces | 17:27 |
| lpapp | http://pastebin.com/thS8WqYG | 17:27 |
| lpapp | it actually does not work | 17:27 |
| mario-goulart | lpapp: that ##COREBASE## string was supposed to be replaced by something meaninful when you run oe-init-build-env | 17:27 |
| lpapp | but then again: why is bblayers.conf not just generated right? | 17:27 |
| lpapp | mario-goulart: then shit happened I guess. | 17:28 |
| mario-goulart | Probably | 17:28 |
| lpapp | I remove that file generated | 17:28 |
| lpapp | and still getting the error pasted above. | 17:28 |
| lpapp | shouldn't it just generate the right thing? | 17:28 |
| lpapp | instead of generating some mixed stuff? | 17:28 |
| lpapp | bug in dylan? | 17:28 |
| *** Stygia <Stygia!~gmpsaifi@0904ds6-noe.0.fullrate.dk> has quit IRC | 17:28 | |
| lpapp | is it a known bug in dylan? | 17:29 |
| lpapp | How should I proceed? | 17:29 |
| *** zenlinux_ <zenlinux_!~sgarman@24.20.145.95> has quit IRC | 17:30 | |
| lpapp | hmpf: meld conf/bblayers.conf | 17:30 |
| lpapp | it should be $build/conf/bblayers.conf, no? | 17:30 |
| lpapp | the error reporting seems to be erroneous. | 17:30 |
| lpapp | it should tell me that, I do not have such a file. | 17:31 |
| lpapp | why is it not looking in the build folder by default? | 17:31 |
| lpapp | what I am doing is this in the dylan root: | 17:31 |
| lpapp | . oe-init-build-env my-builds | 17:31 |
| lpapp | bitbake core-image-minimal | 17:32 |
| lpapp | I would kinda expect that, it is the right way | 17:32 |
| mario-goulart | Are you running bitbake from the build dir? | 17:33 |
| *** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has quit IRC | 17:34 | |
| lpapp | mario-goulart: no | 17:34 |
| mario-goulart | Can you try that? | 17:34 |
| lpapp | it worked with denzil with that two-liner script | 17:35 |
| lpapp | without being in the build directory. | 17:35 |
| lpapp | yocto is mysterious at times. :) | 17:36 |
| lpapp | mario-goulart: btw, oe-init-build-env should take you into the build folder! | 17:37 |
| lpapp | so yes, of course I was running it there. | 17:37 |
| lpapp | and yes, trying it again, did not help. | 17:37 |
| lpapp | is it really meant to be this buggy even with the newest versions? :O | 17:37 |
| lpapp | any 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@128.224.250.2> has left #yocto | 17:45 | |
| lpapp | I am still interested in why bblayers.conf is not generated with my layer inside, automatically? | 17:46 |
| lpapp | how could I make that happen? | 17:46 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 17:49 | |
| lpapp | or 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 method | 17:52 |
| lpapp | sgw_: ok, that sounds even more complex than without solving the problem. | 17:52 |
| lpapp | so now, I would have two. :) | 17:53 |
| lpapp | in any case, is there a generator command? | 17:53 |
| lpapp | it is pretty silly to build with a wrong bblayers.conf | 17:53 |
| lpapp | so the generation should obviously happen in a different step | 17:53 |
| lpapp | so that I can edit (correct) it before the actual build. | 17:53 |
| lpapp | otherwise the layer support is not that particularly mature for third parties. | 17:54 |
| lpapp | or am I supposed to edit myself from the sample file? | 17:55 |
| *** lpapp <lpapp!~lpapp@212.44.19.228> has quit IRC | 17: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 personally | 17:59 |
| sgw_ | missed him | 17:59 |
| *** belen <belen!~Adium@134.134.139.74> has quit IRC | 18:04 | |
| *** mihai <mihai!~mihai@188.27.93.142> has joined #yocto | 18:04 | |
| *** b1gtuna <b1gtuna!~adam@s206-116-3-18.bc.hsia.telus.net> has quit IRC | 18:04 | |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC | 18:07 | |
| *** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has joined #yocto | 18:09 | |
| *** el_robin <el_robin!~el_robin@2a01:e0b:1:124:54be:d5e4:293e:5235> has quit IRC | 18:26 | |
| *** lpapp <lpapp!~lpapp@cpc11-cmbg15-2-0-cust30.5-4.cable.virginmedia.com> has joined #yocto | 18:28 | |
| lpapp | "You should also have about 100 gigabytes of free disk space for building images." | 18:30 |
| lpapp | a 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 #yocto | 18:33 | |
| *** b1gtuna <b1gtuna!~adam@206.116.3.18> has joined #yocto | 18:35 | |
| b1gtuna | udhcpc from busybox is conflicting with dhclient from NetworkManager. Anyone with this experience? | 18:36 |
| rburton | lpapp: 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 |
| rburton | for what its worth, my /data (solely yocto builds) is sitting at 766G used. | 18:49 |
| lpapp | rburton: how many? | 18:53 |
| rburton | how 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 |
| rburton | 100G 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 |
| lpapp | well, my partition table is not prepared for Yocto. | 18:56 |
| lpapp | so I guess I need to use rm_work. | 18:56 |
| lpapp | and it is probably a lesson learnt when I partition a new disk next time. | 18:57 |
| lpapp | that I should not be modest with 50-100 GB for the home. | 18:57 |
| rburton | i never set more than 20G for / unless i know i'll need it for something special, everything else is "mine" | 19:02 |
| rburton | and if/when you get a dedicated machine for yocto builds, put the build data on its own *disk* | 19:03 |
| rburton | not just partition | 19:03 |
| lpapp | I was saying home intentionally, not root. | 19:07 |
| lpapp | I do not have a dedicated machine, no. | 19:07 |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has quit IRC | 19:11 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 19:15 | |
| *** eren <eren!~eren@unaffiliated/eren> has quit IRC | 19:15 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 19:16 | |
| *** sakoman <sakoman!~steve@static-74-41-60-154.dsl1.pco.ca.frontiernet.net> has quit IRC | 19:19 | |
| *** dompe <dompe!0fc3c958@gateway/web/freenode/ip.15.195.201.88> has joined #yocto | 19:20 | |
| dompe | hi, I have a quick question about recipes: I'm creating a recipe libdbus-c++ | 19:21 |
| dompe | I need a nativesdk version as well | 19:21 |
| dompe | my recipe is called | 19:21 |
| dompe | libdbus-c++-1_0.9.0.bb | 19:21 |
| dompe | but 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 |
| dompe | however my nativesdk package gets named without the extra -0 | 19:22 |
| lpapp | can the yocto build system take MAKEFLAGS into account? | 19:22 |
| dompe | any idea why this happens? | 19:22 |
| lpapp | dompe: should be libdbus-c++_1_0.9.0.bb | 19:23 |
| lpapp | or you are creating a recipe for libdbus-c++-1 | 19:23 |
| dompe | lpapp I'm creating for libdbus-c++-1 | 19:24 |
| dompe | version is 0.9.0 | 19:24 |
| dompe | meaning the library is named libdbus-c++-1.so | 19:24 |
| lpapp | yes | 19:24 |
| dompe | my question is why the package gets the extra -0 | 19:25 |
| dompe | is this an expected behavior? | 19:25 |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has joined #yocto | 19:25 | |
| *** Song_Liu <Song_Liu!c0373629@gateway/web/freenode/ip.192.55.54.41> has quit IRC | 19:26 | |
| *** jzhang-laptop <jzhang-laptop!~jzhang16@134.134.137.73> has quit IRC | 19:31 | |
| *** sakoman <sakoman!~steve@static-74-41-60-154.dsl1.pco.ca.frontiernet.net> has joined #yocto | 19:34 | |
| kergoth | sometimes i get the feeling we need the ability to backfill packageconfig | 19:36 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 19:39 | |
| lpapp | ERROR: 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 |
| lpapp | TCMODE = "external-csl" | 19:40 |
| lpapp | EXTERNAL_TOOLCHAIN = "/usr" | 19:40 |
| lpapp | TARGET_PREFIX = "arm-none-linux-gnueabi-" | 19:40 |
| lpapp | I have this. | 19:40 |
| lpapp | it 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 IRC | 19:42 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 19:54 | |
| *** dlern <dlern!~dlerner@99-16-243-235.lightspeed.mrgvil.sbcglobal.net> has joined #yocto | 19:55 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 19:55 | |
| *** flihp <flihp!~flihp@216.57.91.130> has quit IRC | 19:57 | |
| *** flihp <flihp!~flihp@216.57.91.130> has joined #yocto | 19:57 | |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@autobuilder.yoctoproject.org> has quit IRC | 19:58 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 20:01 | |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@autobuilder.yoctoproject.org> has joined #yocto | 20:03 | |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@autobuilder.yoctoproject.org> has joined #yocto | 20:03 | |
| *** joeythesaint <joeythesaint!~jjm@128.224.252.2> has quit IRC | 20:03 | |
| *** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has quit IRC | 20:04 | |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@autobuilder.yoctoproject.org> has quit IRC | 20:05 | |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@autobuilder.yoctoproject.org> has joined #yocto | 20:05 | |
| pidge | folks. 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.15.195.201.88> has quit IRC | 20:08 | |
| *** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has quit IRC | 20:11 | |
| *** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has joined #yocto | 20:11 | |
| *** jzhang-laptop <jzhang-laptop!~jzhang16@134.134.137.73> has joined #yocto | 20:43 | |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has quit IRC | 20:43 | |
| *** dvhart <dvhart!dvhart@nat/intel/x-zzsimixjizlvtazk> has joined #yocto | 20:45 | |
| mulhern | I 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 IRC | 20:48 | |
| mulhern | But sometime in the future it might make sense to install the package itself. | 20:48 |
| mulhern | Things like that are in meta/recipes-devtools ? | 20:50 |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has joined #yocto | 20:56 | |
| *** bluelightning <bluelightning!~paul@cpc13-lewi17-2-0-cust74.2-4.cable.virginmedia.com> has joined #yocto | 21:05 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 21:05 | |
| sgw_ | mulhern: not really, looking at some native tool might be helpful | 21:05 |
| mulhern | sgw_: 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 |
| mulhern | Not bitbake, pulledpork. | 21:07 |
| lpapp | anyone having a clue for the cross-compilation? | 21:07 |
| mulhern | sgw_: 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 email | 21:10 |
| lpapp | everyone is doing native builds with yocto in here ? :) | 21:10 |
| mr_science | mmm... pulledpork | 21:10 |
| sgw_ | lpapp: possibly, I have not worked with external toolchain yet, other folks have done it though | 21:11 |
| mulhern | sgw_: 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 |
| mulhern | sgw_: OK. I can use quilt as a model. | 21:15 |
| lpapp | sgw_: 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 documentation | 21:23 |
| lpapp | sgw_: apparently, not. | 21:24 |
| *** jzhang-laptop <jzhang-laptop!~jzhang16@134.134.137.73> has left #yocto | 21:25 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 21:32 | |
| *** dlern <dlern!~dlerner@99-16-243-235.lightspeed.mrgvil.sbcglobal.net> has left #yocto | 21:37 | |
| *** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has quit IRC | 21:40 | |
| *** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has joined #yocto | 21:50 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 21:51 | |
| *** sameo <sameo!samuel@nat/intel/x-qsyfmyoziqmtdiqq> has joined #yocto | 21:51 | |
| *** Garibaldi|work <Garibaldi|work!~andydalt@64.102.254.33> has quit IRC | 22:04 | |
| ndec | very 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 |
| ndec | it's not an OE bug of couse. | 22:06 |
| ndec | course | 22:06 |
| bluelightning | ndec: ugh... | 22:06 |
| ndec | yep.. | 22:07 |
| mr_science | heh | 22:08 |
| ndec | the symptom is that ne_xxx.h files aren't found when compiling subversion .c files. | 22:08 |
| ndec | these files are in neon package | 22:08 |
| *** ant_home <ant_home!~andrea@host133-7-dynamic.20-79-r.retail.telecomitalia.it> has joined #yocto | 22:09 | |
| ndec | and it's subversion 1.7. so dylan and master are impacted. | 22:09 |
| mr_science | could always link upstream svn to a local git repo as a workaround... | 22:11 |
| ndec | you just need to 'not use -D or -I' in the folder name ;-) | 22:13 |
| mr_science | never said it was an optimal workaround... | 22:15 |
| *** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has quit IRC | 22:15 | |
| *** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has joined #yocto | 22:18 | |
| lpapp | sgw_: who is the author of the external stufF? | 22:26 |
| lpapp | stuff( | 22:26 |
| lpapp | * | 22:26 |
| lpapp | perhaps it is time to document it? | 22:26 |
| mr_science | it's typo day, just g0 with it... | 22:29 |
| lpapp | which mailing list to bring the topic up, on? | 22:30 |
| lpapp | presumably oe-core? | 22:30 |
| *** zerus <zerus!~epetmab@90-224-44-236-no67.tbcn.telia.com> has quit IRC | 22: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@206.116.3.18> has quit IRC | 22:34 | |
| lpapp | sgw_: as I wrote, that did not help. | 22:35 |
| lpapp | but 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 |
| lpapp | sgw_: I think it is good to boost a documentation process regardless. | 22:38 |
| lpapp | cross-compilation is probably the main power for Yocto | 22:38 |
| lpapp | at least in my book. | 22:38 |
| lpapp | for me that is the pillar why Yocto exists. :) | 22:39 |
| lpapp | it is very slow to build on embedded architecture. | 22:39 |
| lpapp | and for desktop, we have got many more powerful distribution that yocto has ever been able to generate. | 22:40 |
| lpapp | distributions* | 22:40 |
| *** agust <agust!~agust@p4FC460FC.dip0.t-ipconnect.de> has quit IRC | 22:40 | |
| *** b1gtuna <b1gtuna!~adam@206.116.3.18> has joined #yocto | 22:41 | |
| bluelightning | lpapp: it sounds like you think cross-compilation can't be done without an external toolchain, which isn't the case | 22:42 |
| *** BSDCat <BSDCat!unique@calvin.idempot.net> has left #yocto | 22:43 | |
| lpapp | sgw_: email sent. | 22:45 |
| lpapp | bluelightning: how do you internal for gnueabi ? Could you please englighten us? | 22:46 |
| lpapp | do* | 22:46 |
| bluelightning | lpapp: we can build a cross-compiler for anything that gcc supports, certainly including ARM gnueabi | 22:47 |
| lpapp | why would you bother? | 22:47 |
| lpapp | there is little to no point in it. | 22:47 |
| bluelightning | there's quite a lot of point in it | 22:47 |
| lpapp | not really, no. | 22:48 |
| bluelightning | really, yes | 22:48 |
| lpapp | and TI disagrees with you, too. | 22:48 |
| lpapp | alongside many other people. | 22:48 |
| lpapp | intel, etc | 22:48 |
| lpapp | simply there is no point in rebuiling a toolchain for a well proven distribution with dedicated packages. | 22:50 |
| lpapp | rebuilding* | 22:50 |
| lpapp | for the vast majority of the use casese. | 22:51 |
| lpapp | cases.* | 22:51 |
| bluelightning | well, if you're convinced I won't try to change your mind | 22:51 |
| lpapp | and even if there was, external has to be documented, no matter what. | 22:51 |
| lpapp | in fact, I have never seen anyone building a cross-compiler toolchain in my 10+ years. | 22:52 |
| lpapp | usually, it is coming from the vendor or the partner of the vendor in binary form to the developers. | 22:53 |
| lpapp | only gentoo was doing that as far as I can tell, but they rebuild everything after all. | 22:54 |
| lpapp | almost everything | 22:54 |
| lpapp | but I think even then, they had some convenience binary packages. | 22:54 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 23:03 | |
| *** dvhart <dvhart!dvhart@nat/intel/x-zzsimixjizlvtazk> has quit IRC | 23:05 | |
| *** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has quit IRC | 23:07 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 23:16 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 23:22 | |
| *** yzhao2_ <yzhao2_!~yzhao2@128.224.252.2> has joined #yocto | 23:31 | |
| *** yzhao2 <yzhao2!~yzhao2@128.224.252.2> has quit IRC | 23:34 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 23:39 | |
| *** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has quit IRC | 23:47 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!