**** BEGIN LOGGING AT Tue Jul 23 02:59:59 2013
Jul 23 06:06:19 <lpapp> when having a bsp layer, it is better to use .bbappend if the kernel is not different, just having custom configuration?
Jul 23 06:24:58 <Crofton> lpapp, I would say yes
Jul 23 06:42:04 <lpapp> and if custom patches are needed, I would need to "replicate" the packages in my layer?
Jul 23 06:46:02 <lpapp> it is not worth putting custom patches into the meta and meta-yocto layers at all?
Jul 23 07:11:57 <mckoan> good morning
Jul 23 07:17:35 <lpapp> "However, the dependencies should also contain information regarding any other dependencies the BSP might have." -> where can I set that dependency?
Jul 23 07:58:42 <Crofton> lpapp, do you have a source of that line? I'm on holiday right now, so reponse time is pretty slow for me :)
Jul 23 08:07:53 <lpapp> Crofton: https://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html
Jul 23 08:10:43 <lpapp> bluelightning: it is not worth putting custom patches into the meta and meta-yocto layers at all?
Jul 23 08:11:04 <bluelightning> morning all
Jul 23 08:11:56 <bluelightning> lpapp: unless they're general changes you're planning to upstream, no - otherwise you'll have to rebase those changes when you upgrade
Jul 23 08:12:09 <bluelightning> lpapp: we have the layer structure in part to avoid such difficulties
Jul 23 08:12:34 <lpapp> bluelightning: k, thanks.
Jul 23 08:12:53 <lpapp> what about the local and site configs? Should I have those in each layer?
Jul 23 08:13:30 <bluelightning> lpapp: no, those shouldn't be in any layer
Jul 23 08:13:44 <lpapp> also, what about about patches backported from master to denzil to build on archlinux? Should they go into the existing layers or custom?
Jul 23 08:14:02 <lpapp> bluelightning: inside the build folder then?
Jul 23 08:14:28 <bluelightning> lpapp: that's a little different... in that case you probably want to be maintaining a branch
Jul 23 08:14:33 <bluelightning> lpapp: yes
Jul 23 08:16:09 <lpapp> bluelightning: maintaning a branch means?
Jul 23 08:16:36 <bluelightning> lpapp: of poky
Jul 23 08:16:49 <lpapp> bluelightning: not sure I follow, mind elaborating?
Jul 23 08:17:09 <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
Jul 23 08:18:21 <lpapp> bluelightning: I am not using branches
Jul 23 08:18:31 <lpapp> bluelightning: I am working independently from the poky repository.
Jul 23 08:18:50 <lpapp> bluelightning: I download the tarball, and I backport changes to that when packaging.
Jul 23 08:21:03 <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...
Jul 23 08:22:06 <lpapp> bluelightning: sorry?
Jul 23 08:22:25 <lpapp> have you seen other distributions packaging?
Jul 23 08:22:34 <bluelightning> lpapp: packaging of... ?
Jul 23 08:22:37 <lpapp> they use the release, and then they have stabilization patches backported.
Jul 23 08:22:53 <lpapp> once they get a usable release, they will drop their patches.
Jul 23 08:23:07 <lpapp> but as far as I know, people do not care in Yocto to actually maintain a feature release.
Jul 23 08:23:13 <lpapp> which is sad, but that is how it is anyway.
Jul 23 08:23:38 <bluelightning> lpapp: that's not correct, we maintain at least two stable releases back
Jul 23 08:24:09 <lpapp> bluelightning: why don't I see proper bugfix releases for the feature releases then?
Jul 23 08:24:26 <lpapp> also, "two" is a weak argument when they release cycle is 6 months.
Jul 23 08:24:31 <lpapp> the*
Jul 23 08:24:42 <lpapp> so basically, the software is taken care of, maximum up to a year.
Jul 23 08:25:02 <lpapp> and then end users are screwed with those releases.
Jul 23 08:25:27 <lpapp> anyway, do you plan to release a stable denzil any soon for arch?
Jul 23 08:25:57 <bluelightning> lpapp: http://article.gmane.org/gmane.linux.embedded.yocto.general/14529/
Jul 23 08:26:05 <bluelightning> lpapp: http://comments.gmane.org/gmane.linux.embedded.yocto.announce/47
Jul 23 08:26:36 <lpapp> bluelightning: dylan is far from denzil.
Jul 23 08:26:43 <bluelightning> lpapp: I don't think we have any further denzil releases planned, no
Jul 23 08:26:56 <lpapp> or even danny.
Jul 23 08:27:09 <lpapp> bluelightning: then why would I bother with git?
Jul 23 08:27:28 <lpapp> if Yocto does not care to maintain and release it?
Jul 23 08:27:37 <bluelightning> lpapp: maybe because it makes backporting and maintaining a patch series trivially easy?
Jul 23 08:27:43 <lpapp> in any case, even with a release, we would need a solution _now_.
Jul 23 08:27:52 <bluelightning> and git works, now
Jul 23 08:27:53 <lpapp> no, it does not.
Jul 23 08:28:27 <lpapp> what actually the packagers do out there at large, is what I wrote already: they use the release and then patches locally.
Jul 23 08:28:34 <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.
Jul 23 08:28:52 <bluelightning> unnecessarily so since git does exist and works well for the job
Jul 23 08:29:05 <lpapp> not really, no.
Jul 23 08:29:27 <lpapp> Yocto is a project, foo is another.
Jul 23 08:29: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
Jul 23 08:30:10 <lpapp> actually, for debian, it is pretty simple to apply a patch locally.
Jul 23 08:30:21 <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
Jul 23 08:30:23 <lpapp> only thing needed is copying that into the patches folder, and append it to the patch file, done.
Jul 23 08:31:11 <lpapp> bluelightning: why would it be hard?
Jul 23 08:31:23 <lpapp> debian, arch, etc packagers have been doing that for decades.
Jul 23 08:39:24 <ant_work> lpapp: OE/Yocto is *not* a distribution. It's not about upgrading a binary package on host
Jul 23 08:39:53 <lpapp> ant_work: yes, we all know.
Jul 23 08:40:09 <ant_work> then why do you insist comparing pears with apples?
Jul 23 08:40:27 <lpapp> no any clue what you are talking about.
Jul 23 08:41:00 <lpapp> bluelightning: also, just out of the curiosity, could I get omnipotence in the denzil branch?
Jul 23 08:41:21 <lpapp> i.e. unlimited commit rights, not allowing others to commit in, etc?
Jul 23 08:41:34 <lpapp> I do not think it would work anyway, so we need full control over our software.
Jul 23 08:41:42 <bluelightning> lpapp: no, but you can send patches
Jul 23 08:41:54 <rburton> and of course you have complete control over your own branches
Jul 23 08:42:02 <rburton> what with git being a distributed VCS
Jul 23 08:42:17 <lpapp> bluelightning: you can see yourself it would not fit the business model for many, including me.
Jul 23 08:42:27 <lpapp> bluelightning: companies need full control over their software.
Jul 23 08:42:44 <frank> Hi, anyone can tell me how the rpm spec generated in yocto ?
Jul 23 08:42:56 <lpapp> bluelightning: but that kinda is besides the point as I do not see how git would simplify anything after all.
Jul 23 08:42:56 <bluelightning> lpapp: and, you can have that
Jul 23 08:43:04 <lpapp> to me, it would be a complication.
Jul 23 08:43:22 <bluelightning> frank: sure, the code that does it is in meta/classes/package_rpm.bbclass
Jul 23 08:43:27 <lpapp> because we could not use the release tarball after all.
Jul 23 08:43:35 <lpapp> yet another complication step.
Jul 23 08:44:59 <frank> bluelightning: Thanks a lot ! I'll take a look at the file.
Jul 23 08:45:04 <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
Jul 23 08:45:05 <ivali> How can I make a global clean to poky?
Jul 23 08:45:21 <lpapp> bluelightning: except a few things:
Jul 23 08:45:26 <lpapp> 1) I do not have git access right now
Jul 23 08:45:34 <bluelightning> lpapp: you don't need git access
Jul 23 08:45:47 <lpapp> 2) Monkey work only comes after a good decision which is hardly git.
Jul 23 08:46:23 <bluelightning> ivali: depends... if you want to clear everything out completely just delete TMPDIR (tmp/ under your build directory by default) and sstate-cache
Jul 23 08:46:24 <lpapp> it is usually a weak attempt to argue for doing monkey work instead of thinking and discussing the design.
Jul 23 08:46:34 <bluelightning> ivali: that's quite a drastic measure though, usually that's not necessary
Jul 23 08:46:35 <lpapp> which is for long term and good.
Jul 23 08:48:23 <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
Jul 23 08:48:29 <ivali> recompiling now ..
Jul 23 08:49:13 <lpapp> bluelightning: any plans to actually support a software and maintain it for more than maximum a year.
Jul 23 08:49:23 <lpapp> You know, companies are a bit more interested in a product for more than a year ...
Jul 23 08:49:42 <lpapp> to me, this also differentiates ubuntu and co from Yocto.
Jul 23 08:49:44 <rburton> lpapp: yocto project isn't a company, there are many companies that offer commercial support for many years (up to 7, iirc)
Jul 23 08:49:53 <lpapp> They at least care about maintaining the software for a while.
Jul 23 08:50:03 <lpapp> so their software will be reliable in two years time, too.
Jul 23 08:50:07 <bluelightning> ivali: if you want to be completely sure of which file is being used you can do bitbake -e recipe | grep ^FILE=
Jul 23 08:50:17 <lpapp> rburton: Actually, Yocto is under a foundation.
Jul 23 08:50:24 <lpapp> it employs people for money.
Jul 23 08:50:40 <ivali> bluelightning, thanks
Jul 23 08:50:43 <lpapp> Intel also sponsors developers working on it.
Jul 23 08:50:50 <rburton> lpapp: yes. me.
Jul 23 08:50:55 <lpapp> note how you get lts for ubuntu, linux kernel, etc.
Jul 23 08:50:56 <lpapp> rburton: I know.
Jul 23 08:58:27 <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.
Jul 23 08:58:55 <ndec> it would be a wonderful experience if that person ever start contribution/discussion on lkml.
Jul 23 09:00:09 <rburton> ha
Jul 23 09:00:40 <bluelightning> ndec: I'm told such a discussion did happen recently on LAKML
Jul 23 09:00:45 <bluelightning> ;)
Jul 23 09:01:04 <ndec> well, that was i think a more valuable discussion than ours...
Jul 23 09:01:18 <bluelightning> I didn't read it myself
Jul 23 09:01:40 <ndec> oh. lamkl... i thought you were referring to *the* lkml discussion from last week.
Jul 23 09:01:56 <bluelightning> yeah, not the LKML one
Jul 23 09:21:24 <lpapp> how can I list the dependencies for my own layer?
Jul 23 09:21:31 <frank> I wonder how *.bbclass executed, they're mixed python and shell code, right ?
Jul 23 09:23:34 <rburton> frank: <insert bitbake magic>
Jul 23 09:24:20 <lpapp> frank: bitbake can handle shell and python as well, yeah.
Jul 23 09:24:23 <rburton> lpapp: bitbake-layers?
Jul 23 09:25:11 <lpapp> rburton: ?
Jul 23 09:25:45 <rburton> lpapp: i'm recommending a tool that might do what you want
Jul 23 09:26:19 <lpapp> http://paste.kde.org/~lpapp/pd35d87b5/
Jul 23 09:26:26 <lpapp> can you recommend a tool which at least has a help output?
Jul 23 09:26:58 <frank> rburton: bitbake magic ? you mean insert python flag for python code sections as like ?
Jul 23 09:27:48 <rburton> lpapp: ah, works for me.  must have been broken in denzil, sorry. probably just a bad import, the error is clear.
Jul 23 09:28:14 <lpapp> rburton: maybe python 3 issue.
Jul 23 09:28:52 <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.
Jul 23 09:28:53 <zibri> frank: the python and shell fragments are extracted from the bb files and then executed.
Jul 23 09:35:08 <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 ?
Jul 23 09:35:34 <rburton> sort of.
Jul 23 09:44:47 <frank> thanks, rburton
Jul 23 09:55:07 <lpapp> this bitbake-layers is pretty untalkative tool
Jul 23 09:55:12 <lpapp> bitbake-layers
Jul 23 09:55:13 <lpapp> The BBPATH variable is not set
Jul 23 09:55:20 <lpapp> what BBPATH, how, where, when?
Jul 23 09:58:08 <mihai> lpapp: source oe-init-build-env before using bitbake-layers
Jul 23 09:58:16 <lpapp> mihai: that happened
Jul 23 09:58:17 <mihai> lpapp: and set your default python to 2, instead of 3
Jul 23 09:58:20 <lpapp> of course.
Jul 23 09:58:26 <lpapp> as I could not use bitbake without sourcing anyway
Jul 23 09:58:42 <lpapp> in any case, is there a hidden option to make it more talkative and dump more useful outputs?
Jul 23 09:59:09 <mihai> lpapp: what's listed in --help is all there is
Jul 23 09:59:28 <lpapp> so basically nothing.
Jul 23 09:59:32 <lpapp> sound ... :(
Jul 23 10:00:01 <ant_work> http://www.crashcourse.ca/wiki/index.php/BitBake_layers
Jul 23 10:00:02 <lpapp> hopefully these basic tools will improve in the future.
Jul 23 10:00:27 <lpapp> like 1) Having a help output in the first place 2) Command outputs resulting something productive. etc
Jul 23 10:00:34 <rburton> lpapp: yes. patches welcome if you have a scratch to itch.
Jul 23 10:00:45 <ant_work> lpapp: rpjday the author is surely interested to hear your comments for improvements
Jul 23 10:01:01 <rburton> lpapp: http://pastebin.com/BAuh8Kzk <-- this is what i see when i run it, so there is "help output"
Jul 23 10:01:16 <lpapp> rburton: there is no help output for me, no.
Jul 23 10:01:47 <lpapp> ant_work: well, the first important fix would be to have a help output.
Jul 23 10:01:55 <rburton> lpapp: that was probably fixed in the last year, remember denzil is from april 2012.
Jul 23 10:01:59 <lpapp> ant_work: perhaps the denzil bitbake-layers version is too old and hence buggy.
Jul 23 10:02:17 <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)
Jul 23 10:02:30 <lpapp> rburton: I am very surprised that help output was not the first feature implemented.
Jul 23 10:02:42 <lpapp> rburton: in fact, the cli parser module in python manages that for you by default.
Jul 23 10:04:16 <lpapp> denzil is probably useless to go for.
Jul 23 10:04:17 <frank> anyone can tell me why libnfsidmap0 was made an rpm package instead of libnfsidmap, after I run "bitbake libnfsidmap" ?
Jul 23 10:04:28 <lpapp> I wish we could easily update, but it is a pain with a hardware adaptation layer... :(
Jul 23 10:05:02 <frank> I wonder where the '0' comes from ?
Jul 23 10:05:24 <rburton> frank: library version
Jul 23 10:06:02 <rburton> frank: debian.bbclass does the renaming, if a package contains just a versioned library.
Jul 23 10:06:16 <lpapp> so any way to specify layer dependencies with denzil?
Jul 23 10:06:53 <lpapp> see, this is exactly what I meant by no care about a bit more than one year old software
Jul 23 10:06:56 <lpapp> even basic tools are broken.
Jul 23 10:07:15 <bluelightning> lpapp: it produces help output perfectly fine here, I just tested it
Jul 23 10:07:23 <bluelightning> (using denzil)
Jul 23 10:07:41 <lpapp> bluelightning: ok, but that does not make me work magically. :)
Jul 23 10:07:47 <frank> rburton: it makes sense. thanks !
Jul 23 10:08:13 <lpapp> so is there a way to do it manually without the smart, but non-working tool?
Jul 23 10:11:42 <lpapp> or denzil does not support custom layers then, I take it?
Jul 23 10:13:20 <rburton> it does, oe-core always has supported layers.
Jul 23 10:13:50 <lpapp> if it did, it would work for mer.
Jul 23 10:13:51 <lpapp> me*
Jul 23 10:13:56 <lpapp> so tell me how to make the help output work then.
Jul 23 10:14:01 <lpapp> if it does, you will know.
Jul 23 10:14:35 <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.
Jul 23 10:15:25 <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.
Jul 23 10:16:08 <lpapp> if it is invoked incorrectly, it *should* tell it.
Jul 23 10:16:17 <lpapp> which means there is a bug either way.
Jul 23 10:16:36 <lpapp> so for me, it does not quite qualify as usable, and something that can handle a custom layer.
Jul 23 10:16:49 <lpapp> it's been an hour I am trying to get it work
Jul 23 10:16:51 <lpapp> no clue how, really.
Jul 23 10:17:06 <lpapp> reading upon some information on the internet how to do it manually if that is even possible with this buggy denzil.
Jul 23 10:17:39 <rburton> bitbake-layers is just an introspection tool, you can still use layers without it.
Jul 23 10:18:03 <lpapp> how ?
Jul 23 10:18:26 <rburton> well, you already are. oe-core is a layer. meta-yocto is a layer.
Jul 23 10:18:55 <lpapp> LAYERDEPENDS maybe.
Jul 23 10:19:12 <lpapp> I am explicitly not talking about oe-core, nor meta-yocto
Jul 23 10:19:17 <lpapp> I am actually talking about a custom layer.
Jul 23 10:20:02 <rburton> that's just semantics, oe-core and meta-yocto are not special in any way.
Jul 23 10:20:10 <lpapp> they are.
Jul 23 10:20:16 <lpapp> 1) oe-core: it has no dependencies
Jul 23 10:20:24 <lpapp> 2) meta-yocto: it actually does not mention oe-core as dependency.
Jul 23 10:20:36 <lpapp> they are special to my case as I would like to specify dependency layers.
Jul 23 10:21:08 <rburton> 1) that's just a statement.  2) we should fix that.
Jul 23 10:22:53 <lpapp> LAYERDEPENDS_hob = "core" -> that seems to be a good example.
Jul 23 10:23:03 <lpapp> I might send a patch against meta-yocto to depend on core similarly.
Jul 23 10:23:47 <rburton> sounds like a sensible thing to do indeed.
Jul 23 10:24:34 <JaMa> rburton: any idea why current weston doesn't recognize --disable-libunwind option?
Jul 23 10:25:22 <rburton> "configure: WARNING: unrecognized options: --disable-android-compositor"
Jul 23 10:25:24 <rburton> works for me
Jul 23 10:25:38 <rburton> should remove that android option though )
Jul 23 10:26:14 <JaMa> 1.0.6, right?
Jul 23 10:26:32 <rburton> ah, 1.1.0
Jul 23 10:26:38 <rburton> unwind is new in 1.1
Jul 23 10:28:12 <JaMa> ok, I'll backport it into 1.0.6 for dylan, because it autodetects libunwind
Jul 23 10:28:50 <rburton> huh, i thought unwind itself was new in 1.1
Jul 23 10:28:52 <JaMa> rburton: sorry for noise (I thought I've seen it in dylan too)
Jul 23 10:29:18 <rburton> ah so it is
Jul 23 10:29:26 <JaMa> rburton: http://pastebin.com/AUETam3i
Jul 23 10:29:46 <JaMa> the option to disable it is new
Jul 23 10:30:08 <rburton> yeah, so i see
Jul 23 10:32:01 <lpapp> rburton: the patch should go into the meta-yocto repository and master branch?
Jul 23 10:32:46 <lpapp> or master-next?
Jul 23 10:33:58 <rburton> lpapp: you just send the patch, don't worry about the workflow between that and it reaching master.
Jul 23 10:39:56 <lpapp> rburton: to be honest, I have not used git send-email lately.
Jul 23 10:40:03 <lpapp> and I do not have the sake to set up all the stuff for it to work.
Jul 23 10:40:16 <rburton> its just a matter of telling it your smtp server
Jul 23 10:41:56 <lpapp> rburton: well, it is a hassle to set up, especially with email aliases.
Jul 23 10:42:32 <rburton> fine.
Jul 23 10:44:37 <lpapp> 1) I use archlinux.us which is a gmail based service, but different domain
Jul 23 10:44:42 <lpapp> 2) I use the lpapp@kde.org alias
Jul 23 10:44:49 <lpapp> gluing it all together is effort.
Jul 23 10:55:29 <lpapp> rburton: ok, ssmtp is set up.
Jul 23 10:59:31 <lpapp> which mailing list should I send the change to?
Jul 23 11:00:00 <lpapp> yocto@yoctoproject.org ?
Jul 23 11:05:00 <rburton> lpapp: for meta-yocto, poky@.
Jul 23 11:05:44 <lpapp> rburton: already sent to yocto@
Jul 23 11:07:54 <lpapp> rburton: I guess I cannot depend on a yocto layer right now either.
Jul 23 11:07:57 <lpapp> as it is not specified.
Jul 23 11:08:00 <lpapp> or I can?
Jul 23 11:08:07 <lpapp> I mean for my own bsp layer.
Jul 23 11:08:17 <rburton> a bsp layer shouldnt depend on meta-yocto anyway
Jul 23 11:08:36 <rburton> a BSP layer should be standalone from any distro layer, such as meta-yocto.
Jul 23 11:08:45 <lpapp> it is a BSP _and_ distribution layer.
Jul 23 11:08:54 <rburton> we recommend that you split them
Jul 23 11:09:02 <rburton> your choice, of course.
Jul 23 11:09:14 <lpapp> yeah, I appreciate the recommendation, but I will not for now.
Jul 23 11:09:28 <lpapp> so can something depend on meta-yocto without the dedicated entries?
Jul 23 11:09:35 <lpapp> is there a default "yocto" dependency by its name?
Jul 23 11:09:58 <lpapp> by its file name, etc, that is.
Jul 23 11:12:39 <rburton> lpapp: only bblayers.conf
Jul 23 11:12:43 <lpapp> so patches mentioned in the SRC_URI will be applied by default without an explicit intervention?
Jul 23 11:13:00 <lpapp> rburton: what do you mean?
Jul 23 11:13:34 <rburton> lpapp: the only places where layer filenames are is bblayers.conf
Jul 23 11:13:46 <rburton> lpapp: and yes, a .patch file will be applied automatically unless you tell it otherwise
Jul 23 11:14:03 <lpapp> rburton: do_patches is the way to tell it otherwise?
Jul 23 11:14:49 <rburton> lpapp: no, see apply in http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-SRC_URI
Jul 23 11:14:51 <lpapp> rburton: but how can I depend on meta-yocto in meta-foo then?
Jul 23 11:15:12 <lpapp> LAYERDEPENDS_foo = "yocto" -> can I use this already?
Jul 23 11:15:15 <rburton> lpapp: yes
Jul 23 11:15:30 <rburton> you don't need the dependency from yocto->core to depend on yocto
Jul 23 11:16:01 <lpapp> ok
Jul 23 11:47:00 <lpapp> rburton: shall I resubmit my change against poky@?
Jul 23 11:55:24 <lpapp> rburton: also, for that matter, perhaps the oe-core layer should have versioning as well?
Jul 23 11:59:26 <g0hl1n> Hello everybody,
Jul 23 11:59:48 <g0hl1n> what's the best-practice way to change the splash screen?
Jul 23 12:00:29 <lpapp> g0hl1n: I am not sure what the best practice is, but
Jul 23 12:00:56 <lpapp> I put it into meta/recipes-core/psplash/
Jul 23 12:01:07 <lpapp> arguably, you could put it into your meta-$distro.
Jul 23 12:02: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.
Jul 23 12:02:21 <lpapp> probably you will need a minor .bbapend, but do not take me seriously.
Jul 23 12:02:50 <g0hl1n> lpapp: Thanks! ... but how can I put it into my meta directory? Copying the whole psplash?
Jul 23 12:03:37 <lpapp> g0hl1n: don't you yet have an own meta-$distro layer?
Jul 23 12:04:19 <g0hl1n> lpapp: of course I have one.
Jul 23 12:05:04 <g0hl1n> lpapp: but is the whole psplash folder of meta-core needed or would a bbappend be sufficient?
Jul 23 12:05:12 <lpapp> g0hl1n: I would use a .bbappend then with SRC_URI extended.
Jul 23 12:05:37 <lpapp> you do not modify the script, so I think .bbappend is ok.
Jul 23 12:05:52 <lpapp> it is similar to when you create a custom bsp layer
Jul 23 12:06:02 <lpapp> and you have your own kernel config with .bbappend.
Jul 23 12:06:07 <lpapp> but honestly, I am not an expert.
Jul 23 12:06:14 <lpapp> so you may want to hear others, too.
Jul 23 12:06:35 <g0hl1n> lpapp: Thank you.
Jul 23 12:06:47 <g0hl1n> lpapp: As long as it works it might be ok for me :)
Jul 23 12:07:35 <lpapp> g0hl1n: I am in the same boat.
Jul 23 12:07:53 <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.
Jul 23 12:09:11 <lpapp> so the patch order is the one they are mentioned in the SRC_URI?
Jul 23 12:11:49 <bluelightning> lpapp: yes
Jul 23 12:12:07 <bluelightning> g0hl1n: have a look at what meta-yocto does, it uses a bbappend to change the splash screen
Jul 23 12:15:06 <g0hl1n> bluelightning: thanks !
Jul 23 12:16:26 <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
Jul 23 12:19:01 <lpapp> bluelightning: why do projects use header then?
Jul 23 12:19:07 <lpapp> legacy reason or what?
Jul 23 12:19:25 <lpapp> bluelightning: I do not find any explanation for do_patch
Jul 23 12:19:25 <bluelightning> lpapp: legacy, plus you avoid having to build gdk-pixbuf-native
Jul 23 12:19:32 <lpapp> and for any task, for that matter.
Jul 23 12:20:07 <lpapp> that is actually a good reason why not to use png...
Jul 23 12:20:14 <lpapp> not to slow the build down.
Jul 23 12:22:56 <lpapp> bluelightning: the psplash image though should go into the meta-$distro, right?
Jul 23 12:23:17 <bluelightning> lpapp: correct
Jul 23 12:23:42 <lpapp> bluelightning: denzil does not use .bbappend for meta-yocto though when it comes to recipes-core/psplash. :/
Jul 23 12:25:24 <bluelightning> lpapp: er... ??? it does here
Jul 23 12:25:37 <bluelightning> even the very first denzil release does
Jul 23 12:25:46 <lpapp> bluelightning: sounds all kind of weird then.
Jul 23 12:25:54 <bluelightning> I'd have to agree
Jul 23 12:26:23 <lpapp> our guy patched that out
Jul 23 12:26:26 <lpapp> he needs some punishment. :)
Jul 23 12:26:55 <bluelightning> I see...
Jul 23 12:27:40 <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
Jul 23 12:28:42 <lpapp> bluelightning: so with priority 6, my psplash will be preferred instead of the meta-yocto poky stuff?
Jul 23 12:31:10 <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
Jul 23 12:31:31 <bluelightning> lpapp: also, it determines the order in which bbappends will be applied if more than one layer applies one to a recipe
Jul 23 12:31:57 <lpapp> yes, so the short is "yes" then.
Jul 23 12:32:32 <bluelightning> lpapp: with priority 0 it would be applied, with priority 999 it would be applied; priority is not a factor
Jul 23 12:32:44 <lpapp> bluelightning: it is
Jul 23 12:32:54 <lpapp> bluelightning: because it means the poky psplash stuff is not picked up
Jul 23 12:33:07 <lpapp> oh, really?
Jul 23 12:33:12 <lpapp> then, I am totally lost
Jul 23 12:33:22 <lpapp> I thought that is what priority is exactly for.
Jul 23 12:33:34 <lpapp> to pick up the package (even if just bbappend) which has a higher priority.
Jul 23 12:33:34 <bluelightning> see above for my explanation about exactly what the priority does
Jul 23 12:33:45 <lpapp> I cannot follow that, sorry.
Jul 23 12:33:49 <lpapp> you need to rephrase or elaborate more.
Jul 23 12:34:23 <lpapp> you are claiming that priority does matter which package is picked up.
Jul 23 12:34:37 <lpapp> then you are claiming, priority does not matter because my recipe will be picked up all the time.
Jul 23 12:34:40 <bluelightning> lpapp: you have abc_1.23.bb in meta-firstlayer and abc_1.23.bb in meta-secondlayer
Jul 23 12:34:42 <lpapp> that is contradictory to me.
Jul 23 12:35:10 <bluelightning> lpapp: in that case the priority will choose which one gets built, assuming there is no PREFERRED_VERSION to override that
Jul 23 12:35:20 <lpapp> yes
Jul 23 12:35:45 <lpapp> meta/recipes-core/psplash/psplash_git.bb exists.
Jul 23 12:36:00 <lpapp> and then there are bbappends in meta-firstlayer and meta-secondlayer
Jul 23 12:36:07 <lpapp> I wanna get rid of the append for firstlayer
Jul 23 12:36:11 <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
Jul 23 12:36:11 <lpapp> and apply stuff from my custom secondlayer
Jul 23 12:36:15 <lpapp> how can I do that?
Jul 23 12:36:51 <bluelightning> lpapp: both of the two bbappends will be applied, in the order dictated by the relative priorities of the second two layers
Jul 23 12:37:50 <lpapp> sounds like a feature request then.
Jul 23 12:37:57 <bluelightning> er, no...
Jul 23 12:38:01 <lpapp> it is definitely a valid use case to allow me to skip a bbappend
Jul 23 12:38:07 <lpapp> and apply mine
Jul 23 12:38:10 <lpapp> and only mine.
Jul 23 12:38:24 <bluelightning> if you want yours applied, see the second example
Jul 23 12:38:45 <bluelightning> or rather, if you want yours applied last
Jul 23 12:39:21 <lpapp> no no
Jul 23 12:39:26 <lpapp> I do not wanna get both applied
Jul 23 12:39:32 <lpapp> I wanna get mine applied, and only that.
Jul 23 12:39:46 <lpapp> I think it is a valid use case and hence feature.
Jul 23 12:39:50 <lpapp> I do not wanna get both applied
Jul 23 12:39:57 <lpapp> surely, it is not a problem for small changes.
Jul 23 12:40:07 <lpapp> but for huge changes, it is an unnecessary overhead, that is.
Jul 23 12:41:03 <lpapp> so as a workaround for now: the poky image is applied, and then mine, too?
Jul 23 12:41:16 <lpapp> and mine will be the last if the layer containing it, has a higher priority than meta-yocto?
Jul 23 12:41:39 <bluelightning> yes
Jul 23 12:42:07 <ndec> you could 'mask' the offending recipe too, perhaps, no?
Jul 23 12:42:17 <eren> when we create hdimage, or "iso", can it be directly "dd"ed into compact flash drive?
Jul 23 12:42:44 <eren> if not, how can we bring together isolinux, kernel, rootfs so that the only needed command is "dd" to compact flash or usb?
Jul 23 12:42:44 <lpapp> bluelightning: the problem is not when the second application can block the first
Jul 23 12:42:47 <lpapp> by overriding it.
Jul 23 12:42:57 <lpapp> bluelightning: the problem is that, when they are actually different changes.
Jul 23 12:43:02 <lpapp> bluelightning: and you do not wanna take that.
Jul 23 12:43:03 <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
Jul 23 12:43:07 <lpapp> bluelightning: then you will be screwed.
Jul 23 12:43:36 <bluelightning> lpapp: that's not going to be the case in this instance
Jul 23 12:43:52 <lpapp> bluelightning: not here, but I have places where it will be though.
Jul 23 12:44:07 <lpapp> http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/tree/meta-yocto/recipes-core/psplash/psplash_git.bbappend -> PRINC = "1" was eliminated, interesting.
Jul 23 12:44:52 <lpapp> ok, semi-clear from the log.
Jul 23 12:45:28 <bluelightning> eren: I'm not entirely sure, I suspect our iso's can't currently be used in that way
Jul 23 12:45:40 <bluelightning> eren: hence why we have live images that can
Jul 23 12:46:43 <bluelightning> eren: a lot of the deployment stuff is planned to be reworked very soon which should address these kinds of concerns
Jul 23 12:46:44 <eren> bluelightning: so, I should chose "live" for image type?
Jul 23 12:47:01 <bluelightning> eren: yes for something you can dd to a USB stick
Jul 23 12:47:17 <eren> otherwise, I need to manually install "grub", copy sysroot and kernel etc
Jul 23 12:47:19 <lpapp> bluelightning: shsh, the guy put the custom image header into meta
Jul 23 12:47:21 <lpapp> not even meta-yocto
Jul 23 12:47:24 <lpapp> double punishment. :)
Jul 23 12:47:44 <bluelightning> eren: indeed
Jul 23 12:48:09 <eren> bluelightning: ok, I have ALIX 3D3 board which is a regular x86-compatible device. I guess "live" image would be OK for it
Jul 23 12:48:31 <lpapp> do people use recipes-core/images a lot to create custom images?
Jul 23 12:48:33 <eren> the arch is i586, I even have a BSP for starting
Jul 23 12:48:43 <bluelightning> eren: I would think so yes... occasionally there can be issues depending on what kind of BIOS the board has on it
Jul 23 12:49:43 <lpapp> there are no fpga recipes around yet anywhere?
Jul 23 12:49:43 <bluelightning> lpapp: as a basis, quite often I think
Jul 23 12:49:44 <eren> okkie, I will try that, then
Jul 23 12:49:47 <lpapp> for xilinx, altera, etc?
Jul 23 12:50:23 <bluelightning> lpapp: xilinx provide their own layers for stuff, I think altera has something as well but I'm not sure of the details
Jul 23 12:51:59 <lpapp> yeah, just found that on layer index.
Jul 23 13:00:59 <lpapp> bluelightning: what to do with ../../../meta-yocto/conf/foo-local.conf and ../../../meta-yocto/conf/site-foo.conf files we had?
Jul 23 13:01:36 <bluelightning> lpapp: depends, what's in them that's not in the default unmodified local.conf?
Jul 23 13:05:07 <lpapp> bluelightning: I do not see default in here: http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/conf
Jul 23 13:06:18 <bluelightning> lpapp: try: http://cgit.openembedded.org/openembedded-core/tree/meta/conf
Jul 23 13:07:24 <lpapp> bluelightning: I have not actually seen "meta" in here, http://cgit.openembedded.org/meta-openembedded/tree/
Jul 23 13:07:54 <lpapp> ah, it is oe-core
Jul 23 13:07:55 <lpapp> right
Jul 23 13:08:25 <bluelightning> TuTizz: sorry, which " " ?
Jul 23 13:09:26 <lpapp> bluelightning: interesting, the poky release do not come with examples.
Jul 23 13:09:29 <lpapp> but that is probably OK ...
Jul 23 13:09:50 <bluelightning> lpapp: in poky the equivalents are under meta-yocto/conf/
Jul 23 13:10:35 <lpapp> true.
Jul 23 13:10:44 <lpapp> our site.conf is equal to the sample.
Jul 23 13:11:25 <lpapp> so is our local.conf to the sample (note, not extended).
Jul 23 13:12:23 <lpapp> bluelightning: so just copy those samples over to meta-foo/conf/?
Jul 23 13:12:58 <bluelightning> lpapp: no, you shouldn't do that
Jul 23 13:13:56 <lpapp> bluelightning: then what?
Jul 23 13:14:08 <bluelightning> lpapp: what are you trying to accomplish particularly if the files are the same as the sample ones?
Jul 23 13:15:31 <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"
Jul 23 13:16:09 <bluelightning> TuTizz: I'm not sure if that's there deliberately
Jul 23 13:16:37 <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
Jul 23 13:17:08 <TuTizz> bluelightning, ok, should I write something about it?
Jul 23 13:17:52 <bluelightning> TuTizz: you can feel free to post a question to the mailing list
Jul 23 13:20:32 <TuTizz> bluelightning, ok
Jul 23 13:22:21 <lpapp> bluelightning: porting an existing code to a more modularized
Jul 23 13:22:23 <lpapp> perhaps it had an intent
Jul 23 13:22:28 <lpapp> which needs to be revisited later.
Jul 23 13:23:31 <lpapp> bluelightning: I will just copy over for now.
Jul 23 13:26:50 <lpapp> bluelightning: should I resubmit my yocto patch against poky@?
Jul 23 13:27:28 <bluelightning> lpapp: it would be preferable yes
Jul 23 13:31:01 <lpapp> bluelightning: done
Jul 23 13:31:11 <bluelightning> thx
Jul 23 13:32:10 <lpapp> bluelightning: do these make any sense in the layer conf? http://paste.kde.org/~lpapp/p63f02b8d/
Jul 23 13:32:45 <silviof> eren: the meta-fsl-arm layer makes a sdcard image - you can look how they do it...
Jul 23 13:32:53 <eren> silviof: okkie
Jul 23 13:34:48 <bluelightning> lpapp: the setting of PATH and COREBASE sets off alarm bells
Jul 23 13:35:11 <bluelightning> lpapp: if you're setting COREBASE and QEMUIMAGETESTS solely because that's what OE-Core's layer.conf does, don't do that
Jul 23 13:36:28 <rburton> morning walters
Jul 23 13:37:00 <walters> rburton: good morning!
Jul 23 13:37:22 <eren> the moment that you cannot remember why you coded, add configuration in such a way
Jul 23 13:37:26 <lpapp> bluelightning: I agree.
Jul 23 13:37:48 <eren> now I should read the kernel article from the start, check out kernel metadata and play with it
Jul 23 13:40:22 <lpapp> bluelightning: http://paste.kde.org/~lpapp/pb97a98de/ -> not sure if the first makes any sense
Jul 23 13:40:25 <lpapp> I saw this somewhere.
Jul 23 13:40:29 <lpapp> I mean it is already coded into the second line.
Jul 23 13:41:20 <bluelightning> lpapp: the old convention was BBFILES := "${BBFILES} ..."; you should use BBFILES += "..." instead
Jul 23 13:45:11 <lpapp> bluelightning: yeah, so removing the first line
Jul 23 13:45:19 <lpapp> and s/:=/+=/ on the second.
Jul 23 13:45:31 <bluelightning> lpapp: and remove ${BBFILES}
Jul 23 13:45:31 <ruben__> hello, has anybody beaglebone black with yocto?
Jul 23 13:45:40 <lpapp> bluelightning: yes
Jul 23 13:45:53 <eren> is there a problem with git repository?
Jul 23 13:45:57 <eren> it is really slow
Jul 23 13:46:12 <lpapp> bluelightning: is it a common practice in third-party projects to check in downloaded files?
Jul 23 13:46:16 <lpapp> it seems to me.
Jul 23 13:46:22 <lpapp> it avoiding the downloading of lots of stuff.
Jul 23 13:46:28 <eren> I'm in the university network, it has 20mbit of output
Jul 23 13:46:44 <bluelightning> lpapp: not sure what you mean... ?
Jul 23 13:46:55 <ndec> lpapp: not checked in per-say. but creating your local mirror, yes certainly a good practice.
Jul 23 13:47:17 <lpapp> bluelightning: downloads folder in the build foler.
Jul 23 13:47:19 <lpapp> folder*
Jul 23 13:47:21 <ndec> e.g. we have our own at linaro, http://snapshots.linaro.org/openembedded/sources. which is 'close' to the builders.
Jul 23 13:47:50 <eren> oh damn, there is a huge lag to level3 network :(
Jul 23 13:48:00 <ndec> lpapp: for the 'build' folder, you should not do anything with it. what is probably good practice is to mirror the sstate folder.
Jul 23 13:48:17 <ndec> though i have no idea what sstate was in denzil ;-)
Jul 23 13:49:54 <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.
Jul 23 13:50:32 <ndec> rburton: is there any standard tool to upade a sstate mirror at the end of a build?
Jul 23 13:50:46 <ndec> or is it expected that the 'builder' has write access to sstate directly?
Jul 23 13:50:58 <rburton> ndec: not afaik.  one option it just to use a NAS and nfs/smb mounts.
Jul 23 13:50:59 <lpapp> rburton: more work
Jul 23 13:51:27 <ndec> rburton: sure.
Jul 23 13:51:37 <rburton> lpapp: checking into a vcs server your entire downloads directory would be ... odd.  you'd kill many systems for a start.
Jul 23 13:51:53 <lpapp> rburton: not entirely sure what you mean.
Jul 23 13:52:15 <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' ;-)
Jul 23 13:52:26 <lpapp> ndec: no no
Jul 23 13:52:36 <lpapp> ndec: I mentioned I do not wanna use the upstream git repository
Jul 23 13:52:38 <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.
Jul 23 13:52:45 <lpapp> let us not lose the important bits during the translation
Jul 23 13:52:51 <lpapp> interpretation*
Jul 23 13:53:12 <rburton> oh goodie "windows system support" have just called.
Jul 23 13:54:03 <lpapp> rburton: not sure what you mean
Jul 23 13:54:14 <lpapp> many people have been doing that for ages, and it just works (tm)
Jul 23 13:56:35 <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.
Jul 23 13:57:02 <lpapp> it is not about who knows best.
Jul 23 13:57:07 <lpapp> it is about that it works.
Jul 23 13:57:18 <lpapp> it is not best, but it is not worth the trouble either to do it urgently.
Jul 23 14:04:10 <lpapp> bluelightning: is it worth cleaning up the recipes?
Jul 23 14:04:18 <lpapp> at several places, there are multiple versions, like u-boot.
Jul 23 14:05:00 <lpapp> so how do the recipe writers update the checksums? Everyone manually invoking the tools, and copy pasting output, etc?
Jul 23 14:05:07 <lpapp> and then fixing bugs due to copy paste and other silly issues?
Jul 23 14:05:47 <bluelightning> lpapp: so with u-boot I don't know why we have multiple versions
Jul 23 14:06:11 <lpapp> bluelightning: at least,  I should not copy the old versions to my layer as well, I guess.
Jul 23 14:07:04 <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
Jul 23 14:08:19 <bluelightning> lpapp: no, you'd just have one version since that's likely all you would need
Jul 23 14:08:28 <lpapp> bluelightning: ok, any reason why we do not have only a u-boot package rather than fw-utils, mkimage, etc?
Jul 23 14:09:23 <bluelightning> lpapp: probably because the tools need to be built for the host whereas we want u-boot itself built for the target
Jul 23 14:10:11 <lpapp> bluelightning: yeah, but there are three packages instead of two, even then.
Jul 23 14:10:36 <bluelightning> like I said, I don't know why we have multiple versions of u-boot
Jul 23 14:10:58 <lpapp> bluelightning: it is not versions.
Jul 23 14:11:04 <lpapp> it is multiple packages for the same version.
Jul 23 14:11:19 <lpapp> fw-utils, mkimage, and u-boot.
Jul 23 14:12:01 <bluelightning> u-boot is the bootloader, u-boot-mkimage is for creating the uimage file, no idea what u-boot-fw-utils is
Jul 23 14:12:52 <lpapp> yes, I know what they are.
Jul 23 14:12:58 <lpapp> I just do not understand why they need three packages.
Jul 23 14:13:02 <lpapp> anyway, how about the question above:
Jul 23 14:13:12 <lpapp> so how do the recipe writers update the checksums? Everyone manually invoking the tools, and copy pasting output, etc?
Jul 23 14:13:15 <lpapp> and then fixing bugs due to copy paste and other silly issues?
Jul 23 14:13:47 <bluelightning> yes and in practice that's rarely a problem at least in my experience
Jul 23 14:14:11 <lpapp> would not it be handy to just run a tool anyway?
Jul 23 14:14:18 <lpapp> copy/paste errors not a problem in practice?
Jul 23 14:14:24 <lpapp> well, look for programming forums all around.
Jul 23 14:15:21 <rburton> lpapp: automatically updated checksums would invalidate the point, which is a human being verified them.
Jul 23 14:16:40 <lpapp> rburton: I really do not know what you mean
Jul 23 14:16:57 <lpapp> the checksum would come from the output of the tool
Jul 23 14:17:02 <lpapp> exactly what you do _manually_
Jul 23 14:17:43 <rburton> by manually you mean "run bitbake"
Jul 23 14:18:03 <rburton> feel free to write a tool if you want though
Jul 23 14:18:13 <lpapp> rburton: nope
Jul 23 14:18:21 <lpapp> manually, I mean md5, etc commands
Jul 23 14:18:26 <lpapp> which will provide you the crcs.
Jul 23 14:18:57 <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.
Jul 23 14:19:44 <lpapp> you still need to copy them inside the file.
Jul 23 14:19:50 <lpapp> instead of a tool updating the file.
Jul 23 14:20:18 * rburton shrugs
Jul 23 14:20:26 <rburton> that's two lines of copy and paste.
Jul 23 14:20:43 <lpapp> yes, exactly.
Jul 23 14:20:51 <lpapp> instead of just using an option for bitbake.
Jul 23 14:22:58 <lpapp> what is the difference between files/ and $PN_$PV/? The former is version agnostic, and the latter ones are changes for the $PV?
Jul 23 14:25:44 <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).
Jul 23 14:26:15 <lpapp> yeah, ok.
Jul 23 14:28:08 <kergoth> s/_/-/
Jul 23 14:32:59 <lpapp> ERROR: Failed to obtain CodeSourcery toolchain version: Execution of '/usr/local/arm-2009q1/bin/INVALID-oe-linux-gcc -v' failed: command not found
Jul 23 14:33:08 <lpapp> that INVALID-oe-linux stuff looks kinda weird, no/
Jul 23 14:33:08 <lpapp> ?
Jul 23 14:33:51 <lpapp> TCMODE = "external-csl"
Jul 23 14:33:51 <lpapp> EXTERNAL_TOOLCHAIN = "/usr/local/arm-2009q1"
Jul 23 14:33:52 <lpapp> TARGET_PREFIX = "arm-none-linux-gnueabi-"
Jul 23 14:34:00 <lpapp> I have this, and I have the toolchain installed right in there.
Jul 23 14:58:59 <lpapp> anyone got a clue about the error above?
Jul 23 15:00:05 <sgw_> YTPM: Saul Here
Jul 23 15:00:06 <pidge> YPTM: Beth is on the bridge
Jul 23 15:00:11 <Corneliu> YPTM: Corneliu joined
Jul 23 15:00:12 <scottrif> YPTM: Scott Rifenbark joined the call
Jul 23 15:00:13 <bluelightning> YPTM: Paul Eggleton here
Jul 23 15:00:16 <Song_Liu> YPTM: Welcome to the technical team meeting, please let me know who's on the bridge
Jul 23 15:00:17 <belen> YPTM: Belen joined
Jul 23 15:00:18 <jmpdelos> YPTM: polk joined
Jul 23 15:00:25 <lpapp> also, mkimage and fw-utils get the u-boot packages from the ftp site
Jul 23 15:00:29 <lpapp> but u-boot does not  ?!
Jul 23 15:00:35 <tomz> YPTM: Tom Z here
Jul 23 15:00:41 <laur> YPTM: LaurentiuP joined
Jul 23 15:00:41 <nitink> YPTM: nitin is dialing the bridge
Jul 23 15:01:24 <sgw_> Yocto Project Tech Meeting:
Jul 23 15:01:24 <sgw_> Dial-in number: 1.972.995.7777
Jul 23 15:01:24 <sgw_> US Toll Free number:    1.877.561.6828
Jul 23 15:01:28 <sgw_> Participant passcode:   42001078
Jul 23 15:01:43 <rburton> YPTM: ross here
Jul 23 15:02:09 <jzhang-laptop> YPTM: jzhang on the call
Jul 23 15:02:32 <sgw_> Song_Liu: I think you should start posting the Dial info here in case people are on the ML yet
Jul 23 15:03:02 <rburton> i think we should do the irc back-channel in another room so we don't swamp any existing discussions
Jul 23 15:03:11 <Ramana_> joined YPTM
Jul 23 15:03:19 <kergoth> YPTM: Chris Larson here
Jul 23 15:03:22 <Song_Liu> YPTM: Any opens?
Jul 23 15:04:24 <Ramana_> https://wiki.yoctoproject.org/wiki/Binary_configuration_support
Jul 23 15:04:40 <Ramana_> https://bugzilla.yoctoproject.org/show_bug.cgi?id=3252
Jul 23 15:04:41 <yocti> Bug 3252: enhancement, Low, 1.5 M3, venkatarg, IN PROGRESS DESIGN , Binary level package selection and configuration tool.
Jul 23 15:04:50 <BSDCat> Matthew Weigel here
Jul 23 15:06:49 <Song_Liu> https://wiki.yoctoproject.org/charts/combo.html
Jul 23 15:07:28 <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
Jul 23 15:08:52 <zeddii> YPTM: Bruce here.
Jul 23 15:12:41 <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.
Jul 23 15:20:05 <mulhern> YPTM: mulhern here
Jul 23 15:34:38 <halstead> oops. YPTM: Michael was there. :)
Jul 23 15:36:33 <lpapp> bluelightning: why do you think it is easier to backport patches with git?
Jul 23 15:36:38 <lpapp> http://patchwork.openembedded.org/patch/31377/
Jul 23 15:36:42 <lpapp> trying to backport this one for instance.
Jul 23 15:37:29 <lpapp> should I back port it to the poky repository, btw?
Jul 23 15:40:15 <kergoth> heh :)
Jul 23 15:42:40 <sgw_> lpapp: what version of poky are you trying to patch?
Jul 23 15:43:38 <lpapp> bluelightning: http://paste.kde.org/~lpapp/pe272b5bd/
Jul 23 15:43:43 <lpapp> cherry-pick did not quite work out.
Jul 23 15:44:07 <lpapp> sgw_: denzil
Jul 23 15:44:30 <bluelightning> lpapp: not really surprising I guess... you'll just have to go through and resolve the conflicts
Jul 23 15:44:45 <lpapp> bluelightning: thing is, I do not understand the conflict.
Jul 23 15:45:53 <lpapp> bluelightning: I guess it is somewhat due to the PR numbers.
Jul 23 15:47:58 <lpapp> bluelightning: http://paste.kde.org/~lpapp/p66d616be/
Jul 23 15:48:07 <lpapp> bluelightning: once I solve it, is it welcome in upstream?
Jul 23 15:48:10 <lpapp> or the denzil branch is frozen?
Jul 23 16:11:11 <lpapp> bluelightning: how do you solve conflicts in so many files?
Jul 23 16:11:17 <lpapp> it is a royal pain in the ass.
Jul 23 16:11:38 <bluelightning> lpapp: it's just what you have to deal with when backporting
Jul 23 16:12:01 <lpapp> bluelightning: even git mergetool with vimdiff is super painful, and more importantly: overly error-prone.
Jul 23 16:14:23 <lpapp> bluelightning: I spent half an hour with it
Jul 23 16:14:31 <lpapp> and after the resolve, I got my content lost
Jul 23 16:14:42 <lpapp> I am not sure I would like to really backport it to the repository, and maintain it.
Jul 23 16:14:45 <lpapp> it is not really fun
Jul 23 16:14:50 <bluelightning> it just takes practice
Jul 23 16:14:53 <bluelightning> and yes, it's not fun
Jul 23 16:15:33 <lpapp> well, you have not shared any practice yet.
Jul 23 16:15:45 <bluelightning> there's no magic to it
Jul 23 16:16:08 <lpapp> that is bad
Jul 23 16:16:11 <lpapp> we should have a git tool for it
Jul 23 16:16:42 <bluelightning> sometimes it's easier just to look at what the patch does and make the appropriate changes yourself
Jul 23 16:16:52 <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
Jul 23 16:18:33 <lpapp> well, Intel should maintain it in the first place (tm). :)
Jul 23 16:18:43 <bluelightning> we did try to warn you...
Jul 23 16:18:49 <bluelightning> why?
Jul 23 16:19:27 <lpapp> warn is highly productive
Jul 23 16:19:33 <lpapp> I mean, I was aware of it of course.
Jul 23 16:19:37 <lpapp> yet, someone has to do the work
Jul 23 16:19:49 <lpapp> because Intel is a big company
Jul 23 16:19:59 <lpapp> they could know one year support for a software is nothing.
Jul 23 16:20:01 <lpapp> almost
Jul 23 16:20:08 <bluelightning> if only it were that simple...
Jul 23 16:20:48 <b1gtuna> good morning! Has anyone seen dhclient.service failing to start on boot?
Jul 23 16:20:59 <lpapp> bluelightning: ?
Jul 23 16:21:00 <b1gtuna> It's failing because the interface isn't up yet
Jul 23 16:21:31 <bluelightning> lpapp: within Intel it's actually quite a small team working full time on the Yocto Project
Jul 23 16:21:43 <bluelightning> lpapp: not to mention, we're not the only organisation involved
Jul 23 16:22:08 <lpapp> bluelightning: small team means?
Jul 23 16:22:51 <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
Jul 23 16:23:08 <lpapp> well, arch is a very popular distro.
Jul 23 16:23:48 <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
Jul 23 16:23:59 <lpapp> I would not say that
Jul 23 16:24:08 <lpapp> I would claim the opposite personally.
Jul 23 16:24:08 <lpapp> it getsw new software
Jul 23 16:24:12 <lpapp> it gets bugfixes earlier
Jul 23 16:24:16 <lpapp> rather than ancient distributionsd.
Jul 23 16:24:42 <bluelightning> bugfixes and new versions of base tools we rely on (automake, autoconf, libtool, texinfo, ...) that lead to breakages
Jul 23 16:24:53 <lpapp> bluelightning: gd
Jul 23 16:24:54 <lpapp> * Unmerged path meta/recipes-support/gnutls/gnutls_2.12.20.bb
Jul 23 16:24:56 <lpapp> what to do here?
Jul 23 16:26:05 <bluelightning> not sure, sorry
Jul 23 16:26:19 * lpapp cries
Jul 23 16:26:57 <lpapp> bluelightning: I will drop the cherry-pick thingie
Jul 23 16:27:02 <lpapp> it is a lot easier to write a patch from scratch
Jul 23 16:27:37 <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.
Jul 23 16:28:10 <lpapp> yeah, but I will not give credit then whatsoever. :)
Jul 23 16:28:53 <lpapp> also, it is patching stdio.in.h which is a generated file? I do not follow.
Jul 23 16:29:11 <lpapp> +===================================================================
Jul 23 16:29:11 <lpapp> +--- gettext-0.18.1.1.orig/gettext-runtime/gnulib-lib/stdio.in.h	2010-05-17 12:56:12.000000000 -0700
Jul 23 16:29:14 <lpapp> ++++ gettext-0.18.1.1/gettext-runtime/gnulib-lib/stdio.in.h	2012-07-02 22:42:21.292223316 -0700
Jul 23 16:29:18 <lpapp> why would anyone patch a generated file?
Jul 23 16:30:36 <lpapp> oh, d'oh
Jul 23 16:30:42 <lpapp> it has already been fixed in denzil
Jul 23 16:30:48 <lpapp> it just has not been released
Jul 23 16:30:49 <lpapp> sigh
Jul 23 16:30:58 <lpapp> what is the point of fixing if it is not released?!
Jul 23 16:31:47 <lpapp> probably time to take the latest version from git ...
Jul 23 16:31:48 <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.
Jul 23 16:32:15 <lpapp> rburton: you do realize there was no commit for about half a year?
Jul 23 16:32:19 <rburton> lpapp: branching off the release branch is a sensible thing to do - you get fixes earlier and the chance of breakage is slim
Jul 23 16:32:48 <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
Jul 23 16:33:08 <lpapp> I do not think it is "final" whatever it means.
Jul 23 16:33:10 <rburton> or, just use the release branch.
Jul 23 16:33:14 <lpapp> people do not choose software for a few months.
Jul 23 16:34:18 <lpapp> although now that I got my layer testable, I think there is no reason not to try the latest poky versionm
Jul 23 16:34:21 <lpapp> version*
Jul 23 16:34:26 <lpapp> also, that has bugs for arch, too, unfortunately.
Jul 23 16:35:09 <lpapp> I guess now that my layer got separated after 2-3 days work.
Jul 23 16:35:16 <lpapp> I think it should be easy to update poky?
Jul 23 16:39:04 <lpapp> btw, are you trying to push changes upstream?
Jul 23 16:43:57 <lpapp> WARNING: Failed to fetch URL http://www.zlib.net/zlib-1.2.7.tar.bz2, attempting MIRRORS if available
Jul 23 16:44:00 <lpapp> that url looks broken.
Jul 23 16:47:47 <lpapp> ok, so the poky releases have issue when upstream screws up the existing urls...
Jul 23 16:47:53 <lpapp> that is good to know...
Jul 23 16:48:01 <lpapp> is there a fallback solution provided by Yocto?
Jul 23 16:48:08 <lpapp> like a mirror for the released stuff?
Jul 23 16:48:28 <bluelightning> naturally
Jul 23 16:49:18 <bluelightning> see the MIRRORS setting in meta-yocto/conf/distro/poky.conf
Jul 23 16:49:20 <lpapp> naturally what?
Jul 23 16:49:27 <lpapp> I have just double checked the downloads.
Jul 23 16:49:28 <bluelightning> naturally we have a fallback
Jul 23 16:49:30 <lpapp> and zlib is there.
Jul 23 16:49:35 <lpapp> how about updating poky?
Jul 23 16:49:37 <bluelightning> right
Jul 23 16:49:44 <bluelightning> we do update it, regularly
Jul 23 16:49:52 <lpapp> no no
Jul 23 16:49:58 <lpapp> I mean, me updating from denzil to dylan
Jul 23 16:50:01 <lpapp> should that be smooth?
Jul 23 16:50:33 <bluelightning> lpapp: if you follow: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#migration
Jul 23 16:50:42 <pidge> lpapp: yes. all sources that we utilize over the course of autobuilds are available, in perpetuity, via the autobuilder mirror.
Jul 23 16:52:38 <lpapp> ok, how about my other question:
Jul 23 16:52:49 <lpapp> btw, are you trying to push changes upstream?
Jul 23 16:55:14 <lpapp> bluelightning: it is 1.14, not 1.13 though.
Jul 23 16:57:21 <lpapp> is there a patch update tool?
Jul 23 17:04:18 <lpapp> bluelightning: http://paste.kde.org/~lpapp/pa772324b/ dylan build issue with gcc
Jul 23 17:04:20 <lpapp> is that fixed in master?
Jul 23 17:05:07 <bluelightning> frankly, I thought it was fixed in dylan
Jul 23 17:05:48 <lpapp> bluelightning: ah, you are familiar with this issue?
Jul 23 17:06:06 <bluelightning> I am yes, it came with the introduction of gcc 4.8
Jul 23 17:06:31 * lpapp is not using gcc 4.8
Jul 23 17:06:41 <lpapp> so it is not the typical 4.8 cannot build 4.7 issue
Jul 23 17:07:01 <lpapp> gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203)
Jul 23 17:07:56 <lpapp> note, I do not use the arch toolchain.
Jul 23 17:08:11 <lpapp> it should use the cross compilation arm gnueabi one from code sourcery.
Jul 23 17:10:14 <bluelightning> lpapp: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dylan&id=950f2e453a2bd31764e99eb09154768e0c5049a4
Jul 23 17:10:35 <lpapp> bluelightning: yeah, I was just having that open
Jul 23 17:10:43 <lpapp> Net147 sent it 3 weeks ago or so
Jul 23 17:10:48 <lpapp> still, I do not build with 4.8
Jul 23 17:10:52 <lpapp> so I am not sure how it is relevant.
Jul 23 17:11:16 <bluelightning> lpapp: your host compiler is gcc 4.8.x
Jul 23 17:11:27 <bluelightning> lpapp: the fact that it's building gcc-cross-initial tells me that it's not using an external toolchain (correctly)
Jul 23 17:11:30 <lpapp> bluelightning: as I said, it should not use the host compiler at all.
Jul 23 17:11:33 <lpapp> I am building for arm.
Jul 23 17:11:38 <lpapp> it should use the arm toolchain specified.
Jul 23 17:11:53 <lpapp> right, so why is it not using the toolchain?
Jul 23 17:12:10 <bluelightning> presumably, because it's not configured correctly
Jul 23 17:12:24 <lpapp> means what exactly?
Jul 23 17:12:28 <bluelightning> I can't personally help you configure it because I've never used the external CSL toolchain
Jul 23 17:13:01 <lpapp> now this is where build/conf/local.conf is VERY annoying.
Jul 23 17:13:08 <lpapp> I forgot to copy paste that from another build
Jul 23 17:13:11 <lpapp> and now, I am getting it.
Jul 23 17:13:24 <lpapp> can we reiterate ~/.yoctorc again please
Jul 23 17:13:29 <lpapp> it is a pain in the ass without.
Jul 23 17:13:29 <bluelightning> nope
Jul 23 17:14:01 <lpapp> huh?
Jul 23 17:14:04 <lpapp> I just wasted 1-2 hours
Jul 23 17:14:08 <lpapp> due to it.
Jul 23 17:14:19 <bluelightning> we've already explained why it can't work
Jul 23 17:14:26 <bluelightning> and I'm not going to do so again
Jul 23 17:14:40 <lpapp> it *can* work
Jul 23 17:14:51 <lpapp> and no one actually had a rebruttal for my argument why it could not.
Jul 23 17:14:59 <lpapp> or not something that a mortar can understand.
Jul 23 17:15:26 <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
Jul 23 17:15:57 <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.
Jul 23 17:16:01 <lpapp> Matching the version numbers will remove this message.
Jul 23 17:16:10 <lpapp> I did not have any old/new?
Jul 23 17:16:14 <lpapp> it should have generated a new?
Jul 23 17:16:18 <lpapp> I am clueless what is happening?
Jul 23 17:18:14 <lpapp> how can something be conflicting which does not even exist?
Jul 23 17:19:04 <lpapp> oh, I think the main problem is that bblayers.conf is not generated with my layer inside
Jul 23 17:19:10 <lpapp> why is it not?
Jul 23 17:19:12 <lpapp> how can I get it autogenerated like that?
Jul 23 17:20:44 <lpapp> oh, the bblayers.conf stuff changed.
Jul 23 17:20:55 <lpapp> to COREBASE
Jul 23 17:22:43 <lpapp> what, it is not clear
Jul 23 17:23:59 <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
Jul 23 17:24:08 <lpapp> what do I need to replace ##COREBASE## with?
Jul 23 17:24:13 <lpapp> Really, it is not written in the file.
Jul 23 17:27:10 <bluelightning> that's a placeholder which the oe-init-build-env script automatically replaces
Jul 23 17:27:21 <lpapp> http://pastebin.com/thS8WqYG
Jul 23 17:27:32 <lpapp> it actually does not work
Jul 23 17:27:37 <mario-goulart> lpapp: that ##COREBASE## string was supposed to be replaced by something meaninful when you run oe-init-build-env
Jul 23 17:27:48 <lpapp> but then again: why is bblayers.conf not just generated right?
Jul 23 17:28:08 <lpapp> mario-goulart: then shit happened I guess.
Jul 23 17:28:16 <mario-goulart> Probably
Jul 23 17:28:26 <lpapp> I remove that file generated
Jul 23 17:28:30 <lpapp> and still getting the error pasted above.
Jul 23 17:28:36 <lpapp> shouldn't it just generate the right thing?
Jul 23 17:28:41 <lpapp> instead of generating some mixed stuff?
Jul 23 17:28:50 <lpapp> bug in dylan?
Jul 23 17:29:42 <lpapp> is it a known bug in dylan?
Jul 23 17:29:47 <lpapp> How should I proceed?
Jul 23 17:30:43 <lpapp> hmpf: meld conf/bblayers.conf
Jul 23 17:30:50 <lpapp> it should be $build/conf/bblayers.conf, no?
Jul 23 17:30:59 <lpapp> the error reporting seems to be erroneous.
Jul 23 17:31:10 <lpapp> it should tell me that, I do not have such a file.
Jul 23 17:31:27 <lpapp> why is it not looking in the build folder by default?
Jul 23 17:31:50 <lpapp> what I am doing is this in the dylan root:
Jul 23 17:31:55 <lpapp> . oe-init-build-env my-builds
Jul 23 17:32:00 <lpapp> bitbake core-image-minimal
Jul 23 17:32:11 <lpapp> I would kinda expect that, it is the right way
Jul 23 17:33:49 <mario-goulart> Are you running bitbake from the build dir?
Jul 23 17:34:32 <lpapp> mario-goulart: no
Jul 23 17:34:56 <mario-goulart> Can you try that?
Jul 23 17:35:18 <lpapp> it worked with denzil with that two-liner script
Jul 23 17:35:23 <lpapp> without being in the build directory.
Jul 23 17:36:32 <lpapp> yocto is mysterious at times. :)
Jul 23 17:37:08 <lpapp> mario-goulart: btw, oe-init-build-env should take you into the build folder!
Jul 23 17:37:20 <lpapp> so yes, of course I was running it there.
Jul 23 17:37:34 <lpapp> and yes, trying it again, did not help.
Jul 23 17:37:47 <lpapp> is it really meant to be this buggy even with the newest versions? :O
Jul 23 17:39:31 <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?
Jul 23 17:46:30 <lpapp> I am still interested in why bblayers.conf is not generated with my layer inside, automatically?
Jul 23 17:46:37 <lpapp> how could I make that happen?
Jul 23 17:49:47 <lpapp> or at the very least, how can I only execute a generation procedure without building with the obviously bblayers.conf content.
Jul 23 17:52:21 <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
Jul 23 17:52:57 <lpapp> sgw_: ok, that sounds even more complex than without solving the problem.
Jul 23 17:53:09 <lpapp> so now, I would have two. :)
Jul 23 17:53:16 <lpapp> in any case, is there a generator command?
Jul 23 17:53:31 <lpapp> it is pretty silly to build with a wrong bblayers.conf
Jul 23 17:53:37 <lpapp> so the generation should obviously happen in a different step
Jul 23 17:53:46 <lpapp> so that I can edit (correct) it before the actual build.
Jul 23 17:54:03 <lpapp> otherwise the layer support is not that particularly mature for third parties.
Jul 23 17:55:14 <lpapp> or am I supposed to edit myself from the sample file?
Jul 23 17:59:32 <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
Jul 23 17:59:37 <sgw_> missed him
Jul 23 18:30:39 <lpapp> "You should also have about 100 gigabytes of free disk space for building images."
Jul 23 18:31:03 <lpapp> a full (not core, minimal, basic, base, etc) build takes up that much space?
Jul 23 18:36:07 <b1gtuna> udhcpc from busybox is conflicting with dhclient from NetworkManager. Anyone with this experience?
Jul 23 18:49:24 <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.
Jul 23 18:49:56 <rburton> for what its worth, my /data (solely yocto builds) is sitting at 766G used.
Jul 23 18:53:05 <lpapp> rburton: how many?
Jul 23 18:53:50 <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 :)
Jul 23 18:54:26 <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.
Jul 23 18:56:48 <lpapp> well, my partition table is not prepared for Yocto.
Jul 23 18:56:55 <lpapp> so I guess I need to use rm_work.
Jul 23 18:57:15 <lpapp> and it is probably a lesson learnt when I partition a new disk next time.
Jul 23 18:57:23 <lpapp> that I should not be modest with 50-100 GB for the home.
Jul 23 19:02:42 <rburton> i never set more than 20G for / unless i know i'll need it for something special, everything else is "mine"
Jul 23 19:03:10 <rburton> and if/when you get a dedicated machine for yocto builds, put the build data on its own *disk*
Jul 23 19:03:14 <rburton> not just partition
Jul 23 19:07:36 <lpapp> I was saying home intentionally, not root.
Jul 23 19:07:43 <lpapp> I do not have a dedicated machine, no.
Jul 23 19:21:07 <dompe> hi, I have a quick question about recipes: I'm creating a recipe libdbus-c++
Jul 23 19:21:18 <dompe> I need a nativesdk version as well
Jul 23 19:21:39 <dompe> my recipe is called
Jul 23 19:21:48 <dompe> libdbus-c++-1_0.9.0.bb
Jul 23 19:22:17 <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)
Jul 23 19:22:31 <dompe> however my nativesdk package gets named without the extra -0
Jul 23 19:22:31 <lpapp> can the yocto build system take MAKEFLAGS into account?
Jul 23 19:22:37 <dompe> any idea why this happens?
Jul 23 19:23:22 <lpapp> dompe: should be libdbus-c++_1_0.9.0.bb
Jul 23 19:23:42 <lpapp> or you are creating a recipe for libdbus-c++-1
Jul 23 19:24:05 <dompe> lpapp I'm creating for libdbus-c++-1
Jul 23 19:24:08 <dompe> version is 0.9.0
Jul 23 19:24:26 <dompe> meaning the library is named libdbus-c++-1.so
Jul 23 19:24:38 <lpapp> yes
Jul 23 19:25:18 <dompe> my question is why the package gets the extra -0
Jul 23 19:25:24 <dompe> is this an expected behavior?
Jul 23 19:36:56 <kergoth> sometimes i get the feeling we need the ability to backfill packageconfig
Jul 23 19:40:41 <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?
Jul 23 19:40:55 <lpapp> TCMODE = "external-csl"
Jul 23 19:40:55 <lpapp> EXTERNAL_TOOLCHAIN = "/usr"
Jul 23 19:40:55 <lpapp> TARGET_PREFIX = "arm-none-linux-gnueabi-"
Jul 23 19:40:58 <lpapp> I have this.
Jul 23 19:41:10 <lpapp> it should look for /usr/bin/arm-none-linux-gnueabi-gcc, no?
Jul 23 20:07:19 <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.
Jul 23 20:46:08 <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?
Jul 23 20:48:57 <mulhern> But sometime in the future it might make sense to install the package itself.
Jul 23 20:50:22 <mulhern> Things like that are in meta/recipes-devtools ?
Jul 23 21:05:04 <sgw_> mulhern: not really, looking at some native tool might be helpful
Jul 23 21:07:08 <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).
Jul 23 21:07:18 <mulhern> Not bitbake, pulledpork.
Jul 23 21:07:20 <lpapp> anyone having a clue for the cross-compilation?
Jul 23 21:08:11 <mulhern> sgw_: Btw, did you see my email about Sourcefire acquisition by Cisco?
Jul 23 21:09:52 <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?
Jul 23 21:10:07 <sgw_> mulhern: yes I saw your email
Jul 23 21:10:28 <lpapp> everyone is doing native builds with yocto in here ? :)
Jul 23 21:10:55 <mr_science> mmm...  pulledpork
Jul 23 21:11:20 <sgw_> lpapp: possibly, I have not worked with external toolchain yet, other folks have done it though
Jul 23 21:13:25 <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.
Jul 23 21:14:18 <sgw_> mulhern: you mean the target recipe. right?  Go ahead and write the target recipe now also then.
Jul 23 21:15:08 <mulhern> sgw_: OK. I can use quilt as a model.
Jul 23 21:18:18 <lpapp> sgw_: the problem is that, I do not even find proper documentation about it.
Jul 23 21:23:46 <sgw_> lpapp: is the example for external-sourcery not enough for you to by?
Jul 23 21:23:59 <sgw_> I know it's not full documentation
Jul 23 21:24:42 <lpapp> sgw_: apparently, not.
Jul 23 22:05:43 <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'`"
Jul 23 22:06:05 <ndec> it's not an OE bug of couse.
Jul 23 22:06:08 <ndec> course
Jul 23 22:06:51 <bluelightning> ndec: ugh...
Jul 23 22:07:04 <ndec> yep..
Jul 23 22:08:33 <mr_science> heh
Jul 23 22:08:40 <ndec> the symptom is that ne_xxx.h files aren't found when compiling subversion .c files.
Jul 23 22:08:51 <ndec> these files are in neon package
Jul 23 22:09:59 <ndec> and it's subversion 1.7. so dylan and master are impacted.
Jul 23 22:11:07 <mr_science> could always link upstream svn to a local git repo as a workaround...
Jul 23 22:13:47 <ndec> you just need to 'not use -D or -I' in the folder name ;-)
Jul 23 22:15:00 <mr_science> never said it was an optimal workaround...
Jul 23 22:26:46 <lpapp> sgw_: who is the author of the external stufF?
Jul 23 22:26:49 <lpapp> stuff(
Jul 23 22:26:51 <lpapp> *
Jul 23 22:26:55 <lpapp> perhaps it is time to document it?
Jul 23 22:29:30 <mr_science> it's typo day, just g0 with it...
Jul 23 22:30:28 <lpapp> which mailing list to bring the topic up, on?
Jul 23 22:30:35 <lpapp> presumably oe-core?
Jul 23 22:33:26 <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.
Jul 23 22:33:46 <sgw_> lpapp: as has been pointed out there is some material from ELC or Linuxcon that might help also.
Jul 23 22:35:08 <lpapp> sgw_: as I wrote, that did not help.
Jul 23 22:35:15 <lpapp> but feel free to suggest any fix based on that.
Jul 23 22:37:25 <sgw_> lpapp: I have seen it on the yocto@ mailing list in the past, you can check the archives maybe something there will help.
Jul 23 22:38:32 <lpapp> sgw_: I think it is good to boost a documentation process regardless.
Jul 23 22:38:49 <lpapp> cross-compilation is probably the main power for Yocto
Jul 23 22:38:54 <lpapp> at least in my book.
Jul 23 22:39:23 <lpapp> for me that is the pillar why Yocto exists. :)
Jul 23 22:39:55 <lpapp> it is very slow to build on embedded architecture.
Jul 23 22:40:08 <lpapp> and for desktop, we have got many more powerful distribution that yocto has ever been able to generate.
Jul 23 22:40:14 <lpapp> distributions*
Jul 23 22:42:00 <bluelightning> lpapp: it sounds like you think cross-compilation can't be done without an external toolchain, which isn't the case
Jul 23 22:45:32 <lpapp> sgw_: email sent.
Jul 23 22:46:17 <lpapp> bluelightning: how do you internal for gnueabi ? Could you please englighten us?
Jul 23 22:46:26 <lpapp> do*
Jul 23 22:47:02 <bluelightning> lpapp: we can build a cross-compiler for anything that gcc supports, certainly including ARM gnueabi
Jul 23 22:47:24 <lpapp> why would you bother?
Jul 23 22:47:32 <lpapp> there is little to no point in it.
Jul 23 22:47:56 <bluelightning> there's quite a lot of point in it
Jul 23 22:48:06 <lpapp> not really, no.
Jul 23 22:48:12 <bluelightning> really, yes
Jul 23 22:48:14 <lpapp> and TI disagrees with you, too.
Jul 23 22:48:21 <lpapp> alongside many other people.
Jul 23 22:48:36 <lpapp> intel, etc
Jul 23 22:50:51 <lpapp> simply there is no point in rebuiling a toolchain for a well proven distribution with dedicated packages.
Jul 23 22:50:57 <lpapp> rebuilding*
Jul 23 22:51:13 <lpapp> for the vast majority of the use casese.
Jul 23 22:51:15 <lpapp> cases.*
Jul 23 22:51:29 <bluelightning> well, if you're convinced I won't try to change your mind
Jul 23 22:51:37 <lpapp> and even if there was, external has to be documented, no matter what.
Jul 23 22:52:50 <lpapp> in fact, I have never seen anyone building a cross-compiler toolchain in my 10+ years.
Jul 23 22:53:15 <lpapp> usually, it is coming from the vendor or the partner of the vendor in binary form to the developers.
Jul 23 22:54:09 <lpapp> only gentoo was doing that as far as I can tell, but they rebuild everything after all.
Jul 23 22:54:15 <lpapp> almost everything
Jul 23 22:54:27 <lpapp> but I think even then, they had some convenience binary packages.
Jul 24 01:44:51 <mulhern> What provides all those perl-module-* packages?
Jul 24 02:51:36 <frank> Anyone can tell me the difference between PACKAGE_INSTALL and IMAGE_INSTALL ?
**** ENDING LOGGING AT Wed Jul 24 02:59:59 2013