**** BEGIN LOGGING AT Tue Jul 23 02:59:59 2013
Jul 23 06:06:19 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 lpapp, I would say yes
Jul 23 06:42:04 and if custom patches are needed, I would need to "replicate" the packages in my layer?
Jul 23 06:46:02 it is not worth putting custom patches into the meta and meta-yocto layers at all?
Jul 23 07:11:57 good morning
Jul 23 07:17:35 "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 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 Crofton: https://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html
Jul 23 08:10:43 bluelightning: it is not worth putting custom patches into the meta and meta-yocto layers at all?
Jul 23 08:11:04 morning all
Jul 23 08:11:56 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 lpapp: we have the layer structure in part to avoid such difficulties
Jul 23 08:12:34 bluelightning: k, thanks.
Jul 23 08:12:53 what about the local and site configs? Should I have those in each layer?
Jul 23 08:13:30 lpapp: no, those shouldn't be in any layer
Jul 23 08:13:44 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 bluelightning: inside the build folder then?
Jul 23 08:14:28 lpapp: that's a little different... in that case you probably want to be maintaining a branch
Jul 23 08:14:33 lpapp: yes
Jul 23 08:16:09 bluelightning: maintaning a branch means?
Jul 23 08:16:36 lpapp: of poky
Jul 23 08:16:49 bluelightning: not sure I follow, mind elaborating?
Jul 23 08:17:09 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 bluelightning: I am not using branches
Jul 23 08:18:31 bluelightning: I am working independently from the poky repository.
Jul 23 08:18:50 bluelightning: I download the tarball, and I backport changes to that when packaging.
Jul 23 08:21:03 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 bluelightning: sorry?
Jul 23 08:22:25 have you seen other distributions packaging?
Jul 23 08:22:34 lpapp: packaging of... ?
Jul 23 08:22:37 they use the release, and then they have stabilization patches backported.
Jul 23 08:22:53 once they get a usable release, they will drop their patches.
Jul 23 08:23:07 but as far as I know, people do not care in Yocto to actually maintain a feature release.
Jul 23 08:23:13 which is sad, but that is how it is anyway.
Jul 23 08:23:38 lpapp: that's not correct, we maintain at least two stable releases back
Jul 23 08:24:09 bluelightning: why don't I see proper bugfix releases for the feature releases then?
Jul 23 08:24:26 also, "two" is a weak argument when they release cycle is 6 months.
Jul 23 08:24:31 the*
Jul 23 08:24:42 so basically, the software is taken care of, maximum up to a year.
Jul 23 08:25:02 and then end users are screwed with those releases.
Jul 23 08:25:27 anyway, do you plan to release a stable denzil any soon for arch?
Jul 23 08:25:57 lpapp: http://article.gmane.org/gmane.linux.embedded.yocto.general/14529/
Jul 23 08:26:05 lpapp: http://comments.gmane.org/gmane.linux.embedded.yocto.announce/47
Jul 23 08:26:36 bluelightning: dylan is far from denzil.
Jul 23 08:26:43 lpapp: I don't think we have any further denzil releases planned, no
Jul 23 08:26:56 or even danny.
Jul 23 08:27:09 bluelightning: then why would I bother with git?
Jul 23 08:27:28 if Yocto does not care to maintain and release it?
Jul 23 08:27:37 lpapp: maybe because it makes backporting and maintaining a patch series trivially easy?
Jul 23 08:27:43 in any case, even with a release, we would need a solution _now_.
Jul 23 08:27:52 and git works, now
Jul 23 08:27:53 no, it does not.
Jul 23 08:28:27 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 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 unnecessarily so since git does exist and works well for the job
Jul 23 08:29:05 not really, no.
Jul 23 08:29:27 Yocto is a project, foo is another.
Jul 23 08:29:29 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 actually, for debian, it is pretty simple to apply a patch locally.
Jul 23 08:30:21 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 only thing needed is copying that into the patches folder, and append it to the patch file, done.
Jul 23 08:31:11 bluelightning: why would it be hard?
Jul 23 08:31:23 debian, arch, etc packagers have been doing that for decades.
Jul 23 08:39:24 lpapp: OE/Yocto is *not* a distribution. It's not about upgrading a binary package on host
Jul 23 08:39:53 ant_work: yes, we all know.
Jul 23 08:40:09 then why do you insist comparing pears with apples?
Jul 23 08:40:27 no any clue what you are talking about.
Jul 23 08:41:00 bluelightning: also, just out of the curiosity, could I get omnipotence in the denzil branch?
Jul 23 08:41:21 i.e. unlimited commit rights, not allowing others to commit in, etc?
Jul 23 08:41:34 I do not think it would work anyway, so we need full control over our software.
Jul 23 08:41:42 lpapp: no, but you can send patches
Jul 23 08:41:54 and of course you have complete control over your own branches
Jul 23 08:42:02 what with git being a distributed VCS
Jul 23 08:42:17 bluelightning: you can see yourself it would not fit the business model for many, including me.
Jul 23 08:42:27 bluelightning: companies need full control over their software.
Jul 23 08:42:44 Hi, anyone can tell me how the rpm spec generated in yocto ?
Jul 23 08:42:56 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 lpapp: and, you can have that
Jul 23 08:43:04 to me, it would be a complication.
Jul 23 08:43:22 frank: sure, the code that does it is in meta/classes/package_rpm.bbclass
Jul 23 08:43:27 because we could not use the release tarball after all.
Jul 23 08:43:35 yet another complication step.
Jul 23 08:44:59 bluelightning: Thanks a lot ! I'll take a look at the file.
Jul 23 08:45:04 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 How can I make a global clean to poky?
Jul 23 08:45:21 bluelightning: except a few things:
Jul 23 08:45:26 1) I do not have git access right now
Jul 23 08:45:34 lpapp: you don't need git access
Jul 23 08:45:47 2) Monkey work only comes after a good decision which is hardly git.
Jul 23 08:46:23 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 it is usually a weak attempt to argue for doing monkey work instead of thinking and discussing the design.
Jul 23 08:46:34 ivali: that's quite a drastic measure though, usually that's not necessary
Jul 23 08:46:35 which is for long term and good.
Jul 23 08:48:23 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 recompiling now ..
Jul 23 08:49:13 bluelightning: any plans to actually support a software and maintain it for more than maximum a year.
Jul 23 08:49:23 You know, companies are a bit more interested in a product for more than a year ...
Jul 23 08:49:42 to me, this also differentiates ubuntu and co from Yocto.
Jul 23 08:49:44 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 They at least care about maintaining the software for a while.
Jul 23 08:50:03 so their software will be reliable in two years time, too.
Jul 23 08:50:07 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 rburton: Actually, Yocto is under a foundation.
Jul 23 08:50:24 it employs people for money.
Jul 23 08:50:40 bluelightning, thanks
Jul 23 08:50:43 Intel also sponsors developers working on it.
Jul 23 08:50:50 lpapp: yes. me.
Jul 23 08:50:55 note how you get lts for ubuntu, linux kernel, etc.
Jul 23 08:50:56 rburton: I know.
Jul 23 08:58:27 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 it would be a wonderful experience if that person ever start contribution/discussion on lkml.
Jul 23 09:00:09 ha
Jul 23 09:00:40 ndec: I'm told such a discussion did happen recently on LAKML
Jul 23 09:00:45 ;)
Jul 23 09:01:04 well, that was i think a more valuable discussion than ours...
Jul 23 09:01:18 I didn't read it myself
Jul 23 09:01:40 oh. lamkl... i thought you were referring to *the* lkml discussion from last week.
Jul 23 09:01:56 yeah, not the LKML one
Jul 23 09:21:24 how can I list the dependencies for my own layer?
Jul 23 09:21:31 I wonder how *.bbclass executed, they're mixed python and shell code, right ?
Jul 23 09:23:34 frank:
Jul 23 09:24:20 frank: bitbake can handle shell and python as well, yeah.
Jul 23 09:24:23 lpapp: bitbake-layers?
Jul 23 09:25:11 rburton: ?
Jul 23 09:25:45 lpapp: i'm recommending a tool that might do what you want
Jul 23 09:26:19 http://paste.kde.org/~lpapp/pd35d87b5/
Jul 23 09:26:26 can you recommend a tool which at least has a help output?
Jul 23 09:26:58 rburton: bitbake magic ? you mean insert python flag for python code sections as like ?
Jul 23 09:27:48 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 rburton: maybe python 3 issue.
Jul 23 09:28:52 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 frank: the python and shell fragments are extracted from the bb files and then executed.
Jul 23 09:35:08 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 sort of.
Jul 23 09:44:47 thanks, rburton
Jul 23 09:55:07 this bitbake-layers is pretty untalkative tool
Jul 23 09:55:12 bitbake-layers
Jul 23 09:55:13 The BBPATH variable is not set
Jul 23 09:55:20 what BBPATH, how, where, when?
Jul 23 09:58:08 lpapp: source oe-init-build-env before using bitbake-layers
Jul 23 09:58:16 mihai: that happened
Jul 23 09:58:17 lpapp: and set your default python to 2, instead of 3
Jul 23 09:58:20 of course.
Jul 23 09:58:26 as I could not use bitbake without sourcing anyway
Jul 23 09:58:42 in any case, is there a hidden option to make it more talkative and dump more useful outputs?
Jul 23 09:59:09 lpapp: what's listed in --help is all there is
Jul 23 09:59:28 so basically nothing.
Jul 23 09:59:32 sound ... :(
Jul 23 10:00:01 http://www.crashcourse.ca/wiki/index.php/BitBake_layers
Jul 23 10:00:02 hopefully these basic tools will improve in the future.
Jul 23 10:00:27 like 1) Having a help output in the first place 2) Command outputs resulting something productive. etc
Jul 23 10:00:34 lpapp: yes. patches welcome if you have a scratch to itch.
Jul 23 10:00:45 lpapp: rpjday the author is surely interested to hear your comments for improvements
Jul 23 10:01:01 lpapp: http://pastebin.com/BAuh8Kzk rburton: there is no help output for me, no.
Jul 23 10:01:47 ant_work: well, the first important fix would be to have a help output.
Jul 23 10:01:55 lpapp: that was probably fixed in the last year, remember denzil is from april 2012.
Jul 23 10:01:59 ant_work: perhaps the denzil bitbake-layers version is too old and hence buggy.
Jul 23 10:02:17 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 rburton: I am very surprised that help output was not the first feature implemented.
Jul 23 10:02:42 rburton: in fact, the cli parser module in python manages that for you by default.
Jul 23 10:04:16 denzil is probably useless to go for.
Jul 23 10:04:17 anyone can tell me why libnfsidmap0 was made an rpm package instead of libnfsidmap, after I run "bitbake libnfsidmap" ?
Jul 23 10:04:28 I wish we could easily update, but it is a pain with a hardware adaptation layer... :(
Jul 23 10:05:02 I wonder where the '0' comes from ?
Jul 23 10:05:24 frank: library version
Jul 23 10:06:02 frank: debian.bbclass does the renaming, if a package contains just a versioned library.
Jul 23 10:06:16 so any way to specify layer dependencies with denzil?
Jul 23 10:06:53 see, this is exactly what I meant by no care about a bit more than one year old software
Jul 23 10:06:56 even basic tools are broken.
Jul 23 10:07:15 lpapp: it produces help output perfectly fine here, I just tested it
Jul 23 10:07:23 (using denzil)
Jul 23 10:07:41 bluelightning: ok, but that does not make me work magically. :)
Jul 23 10:07:47 rburton: it makes sense. thanks !
Jul 23 10:08:13 so is there a way to do it manually without the smart, but non-working tool?
Jul 23 10:11:42 or denzil does not support custom layers then, I take it?
Jul 23 10:13:20 it does, oe-core always has supported layers.
Jul 23 10:13:50 if it did, it would work for mer.
Jul 23 10:13:51 me*
Jul 23 10:13:56 so tell me how to make the help output work then.
Jul 23 10:14:01 if it does, you will know.
Jul 23 10:14:35 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 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 if it is invoked incorrectly, it *should* tell it.
Jul 23 10:16:17 which means there is a bug either way.
Jul 23 10:16:36 so for me, it does not quite qualify as usable, and something that can handle a custom layer.
Jul 23 10:16:49 it's been an hour I am trying to get it work
Jul 23 10:16:51 no clue how, really.
Jul 23 10:17:06 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 bitbake-layers is just an introspection tool, you can still use layers without it.
Jul 23 10:18:03 how ?
Jul 23 10:18:26 well, you already are. oe-core is a layer. meta-yocto is a layer.
Jul 23 10:18:55 LAYERDEPENDS maybe.
Jul 23 10:19:12 I am explicitly not talking about oe-core, nor meta-yocto
Jul 23 10:19:17 I am actually talking about a custom layer.
Jul 23 10:20:02 that's just semantics, oe-core and meta-yocto are not special in any way.
Jul 23 10:20:10 they are.
Jul 23 10:20:16 1) oe-core: it has no dependencies
Jul 23 10:20:24 2) meta-yocto: it actually does not mention oe-core as dependency.
Jul 23 10:20:36 they are special to my case as I would like to specify dependency layers.
Jul 23 10:21:08 1) that's just a statement. 2) we should fix that.
Jul 23 10:22:53 LAYERDEPENDS_hob = "core" -> that seems to be a good example.
Jul 23 10:23:03 I might send a patch against meta-yocto to depend on core similarly.
Jul 23 10:23:47 sounds like a sensible thing to do indeed.
Jul 23 10:24:34 rburton: any idea why current weston doesn't recognize --disable-libunwind option?
Jul 23 10:25:22 "configure: WARNING: unrecognized options: --disable-android-compositor"
Jul 23 10:25:24 works for me
Jul 23 10:25:38 should remove that android option though )
Jul 23 10:26:14 1.0.6, right?
Jul 23 10:26:32 ah, 1.1.0
Jul 23 10:26:38 unwind is new in 1.1
Jul 23 10:28:12 ok, I'll backport it into 1.0.6 for dylan, because it autodetects libunwind
Jul 23 10:28:50 huh, i thought unwind itself was new in 1.1
Jul 23 10:28:52 rburton: sorry for noise (I thought I've seen it in dylan too)
Jul 23 10:29:18 ah so it is
Jul 23 10:29:26 rburton: http://pastebin.com/AUETam3i
Jul 23 10:29:46 the option to disable it is new
Jul 23 10:30:08 yeah, so i see
Jul 23 10:32:01 rburton: the patch should go into the meta-yocto repository and master branch?
Jul 23 10:32:46 or master-next?
Jul 23 10:33:58 lpapp: you just send the patch, don't worry about the workflow between that and it reaching master.
Jul 23 10:39:56 rburton: to be honest, I have not used git send-email lately.
Jul 23 10:40:03 and I do not have the sake to set up all the stuff for it to work.
Jul 23 10:40:16 its just a matter of telling it your smtp server
Jul 23 10:41:56 rburton: well, it is a hassle to set up, especially with email aliases.
Jul 23 10:42:32 fine.
Jul 23 10:44:37 1) I use archlinux.us which is a gmail based service, but different domain
Jul 23 10:44:42 2) I use the lpapp@kde.org alias
Jul 23 10:44:49 gluing it all together is effort.
Jul 23 10:55:29 rburton: ok, ssmtp is set up.
Jul 23 10:59:31 which mailing list should I send the change to?
Jul 23 11:00:00 yocto@yoctoproject.org ?
Jul 23 11:05:00 lpapp: for meta-yocto, poky@.
Jul 23 11:05:44 rburton: already sent to yocto@
Jul 23 11:07:54 rburton: I guess I cannot depend on a yocto layer right now either.
Jul 23 11:07:57 as it is not specified.
Jul 23 11:08:00 or I can?
Jul 23 11:08:07 I mean for my own bsp layer.
Jul 23 11:08:17 a bsp layer shouldnt depend on meta-yocto anyway
Jul 23 11:08:36 a BSP layer should be standalone from any distro layer, such as meta-yocto.
Jul 23 11:08:45 it is a BSP _and_ distribution layer.
Jul 23 11:08:54 we recommend that you split them
Jul 23 11:09:02 your choice, of course.
Jul 23 11:09:14 yeah, I appreciate the recommendation, but I will not for now.
Jul 23 11:09:28 so can something depend on meta-yocto without the dedicated entries?
Jul 23 11:09:35 is there a default "yocto" dependency by its name?
Jul 23 11:09:58 by its file name, etc, that is.
Jul 23 11:12:39 lpapp: only bblayers.conf
Jul 23 11:12:43 so patches mentioned in the SRC_URI will be applied by default without an explicit intervention?
Jul 23 11:13:00 rburton: what do you mean?
Jul 23 11:13:34 lpapp: the only places where layer filenames are is bblayers.conf
Jul 23 11:13:46 lpapp: and yes, a .patch file will be applied automatically unless you tell it otherwise
Jul 23 11:14:03 rburton: do_patches is the way to tell it otherwise?
Jul 23 11:14:49 lpapp: no, see apply in http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-SRC_URI
Jul 23 11:14:51