**** BEGIN LOGGING AT Thu Sep 13 03:00:00 2012
Sep 13 06:05:46 <vlrk1> it seems to be now oe is not supporting this http://icedtea.classpath.org/wiki/CrossCompileOEClassicTutorial
Sep 13 06:06:13 <vlrk1> it only supports http://icedtea.classpath.org/wiki/CrossCompileOECoreTutorial
Sep 13 06:06:43 <vlrk1> with the first link it stops me at Parsing receipes stage for 10 tp 12 hours with out even showing ETA
Sep 13 08:14:44 <silvio> morning all
Sep 13 08:51:06 <bluelightning> morning all
Sep 13 08:52:04 <silvio> bluelightning, hi
Sep 13 09:18:11 <afournier> is it possible to escape backslashes in a variable ?
Sep 13 09:24:56 <bluelightning> afournier: I don't think you need to - I don't believe it will be interpreted unless it appears at the end of a line with no terminating quote
Sep 13 09:25:13 <bluelightning> of course it will depend on where the value ends up being used
Sep 13 09:25:57 <bluelightning> if it is later passed to something that does interpret backslashes you'll need to do whatever is needed to handle that - usually preceding the backslash with another backslash
Sep 13 09:26:08 <bluelightning> afournier: where are you seeing a problem with using backslashes?
Sep 13 09:27:22 <afournier> i wanted to modify a line in a makefile
Sep 13 09:27:26 <afournier> using sed
Sep 13 09:27:35 <afournier> so i need to escape backslashes :p
Sep 13 09:27:41 <afournier> i can do a patch otherwise
Sep 13 09:27:47 <afournier> but i am lazy
Sep 13 09:28:56 <afournier> the Makefile says "MODS=/lib/modules/$(KVERS)" and i would like to prepend the sysroot to that variable
Sep 13 09:37:09 <vlrk1> if i see like xxx.bb is not cached while running bitbake -DDDDD openjdk-6
Sep 13 09:37:12 <vlrk1> what does it say..
Sep 13 09:37:55 <bluelightning> afournier: I'm not sure how backslashes are involved - surely something like this would work: sed -i 's/MODS=/MODS=${STAGING_DIR}/' Makefile
Sep 13 09:38:04 <bluelightning> er well
Sep 13 09:38:13 <afournier> sed won't like that :)
Sep 13 09:38:21 <bluelightning> sed -i 's!MODS=!MODS=${STAGING_DIR}!' Makefile
Sep 13 09:38:40 <afournier> your sed kungfu is great !
Sep 13 09:38:57 <bluelightning> almost any character can be used as a separator there
Sep 13 09:39:07 <afournier> i didn't know :p
Sep 13 09:39:27 <bluelightning> whatever character follows s is considered to be the separator
Sep 13 09:39:33 <afournier> i got it
Sep 13 09:39:38 <bluelightning> cool
Sep 13 09:39:43 <vlrk1> is org.openembedded.dev is stopped 
Sep 13 09:40:17 <bluelightning> vlrk1: it's not actively developed anymore no - OE-Core is where current development happens now
Sep 13 09:40:51 <vlrk1> but old things should be supported ..
Sep 13 09:41:16 <vlrk1> i have one old machine with openjdk-6 running
Sep 13 09:41:36 <vlrk1> but some how its not working now when i do bitbake openjdk-6 
Sep 13 09:41:46 <vlrk1> it stops in the Parsing Reciepes
Sep 13 09:41:47 <bluelightning> vlrk1: there's the 2011.3-maintenance branch of OE-Classic for those who still need it; but it only gets very minor bugfixes and those come from interested people in the community
Sep 13 09:42:10 <vlrk1> how can i get that ..
Sep 13 09:42:45 <vlrk1> i have every thing in my machine like all source downloaded on my previous occasion 
Sep 13 09:42:54 <bluelightning> if you have an OE-Classic git clone, just git checkout 2011.3-maintenance
Sep 13 09:43:07 <bluelightning> I have no idea if that will help in your situation though, no guarantees
Sep 13 09:43:11 <vlrk1> ok.. fine
Sep 13 09:43:14 <vlrk1> thx bluelightning
Sep 13 10:13:07 <pb_> hi all
Sep 13 10:14:26 <florian> hi pb_ 
Sep 13 10:15:17 <bluelightning> hi pb_, florian
Sep 13 10:15:43 <florian> hi bluelightning 
Sep 13 10:28:33 <heeen> how can I prevent bitbake from trying to do_fetch when I specify a local source tree in local.conf?
Sep 13 10:29:05 <bluelightning> heeen: you can set BB_NO_NETWORK = "1"
Sep 13 10:29:23 <bluelightning> but if you haven't properly provided the source for something it will error out
Sep 13 10:30:55 <heeen> can I change the default do_fetch implementation
Sep 13 10:31:06 <bluelightning> heeen: to do what?
Sep 13 10:31:16 <heeen> something like if exists LOCAL TREE return success
Sep 13 10:31:25 <bluelightning> the answer is, yes you can, but you probably don't need to
Sep 13 10:31:51 <heeen> it tries to pull huge packages over a very slow VPN when I already have git checkouts
Sep 13 10:32:08 <heeen> and the git fetch I do is much faster
Sep 13 10:32:27 <bluelightning> if you're actually building from a properly set up development tree for a particular piece of software you may want to look at externalsrc.bbclass
Sep 13 10:32:27 <heeen> which files would I have to touch for this
Sep 13 10:34:06 <heeen> could I also just override do_fetch for the two packages that I maintain myself?
Sep 13 10:34:13 <heeen> as in change their bb file
Sep 13 10:35:02 <bluelightning> I would recommend trying externalsrc first, that's what it's designed to handle; if that doesn't work for you we'd like to know about it so we can improve
Sep 13 10:38:43 <heeen> where should that file exist
Sep 13 10:39:25 <bluelightning> heeen: meta/classes
Sep 13 10:39:41 <bluelightning> it has some comments at the top on how to use it
Sep 13 10:39:41 <heeen> hm I don't have a meta dir
Sep 13 10:39:52 <bluelightning> ah so you are using OE-Classic
Sep 13 10:39:54 <bluelightning> ?
Sep 13 10:40:23 <heeen> hmm maybe
Sep 13 10:40:28 <heeen> I'm a oe newbie
Sep 13 10:40:39 <heeen> 1.8.11 FWIW
Sep 13 10:40:59 <bluelightning> ok, if you're starting with a new project I would suggest using OE-Core rather than OE-Classic
Sep 13 10:41:19 <bluelightning> http://www.openembedded.org/index.php/OpenEmbedded-Core
Sep 13 10:41:30 <heeen> the project exists it is just I only know how to build stuff, not how to change how oe works
Sep 13 10:43:12 <bluelightning> ok
Sep 13 10:43:31 <bluelightning> well if you want to stick with OE-Classic on the understanding that it is not really developed anymore, that's fine
Sep 13 10:43:36 <heeen> what is the difference between classic and core
Sep 13 10:43:48 <bluelightning> it's described at the link I posted above :)
Sep 13 10:43:56 <heeen> I have heard both terms being thrown around at work
Sep 13 10:44:21 <heeen> by the way, can you use oe to build native
Sep 13 10:45:01 <heeen> i.e. we have targets for arm and qemu, can we use it for a native build as well
Sep 13 10:45:08 <bluelightning> heeen: sure, in fact we always do that - we need to build certain native tools either because we need up-to-date versions or we need to apply patches
Sep 13 10:46:21 <bluelightning> heeen: hang on, do you mean native compilation tools to be run on the target?
Sep 13 10:46:36 <bluelightning> if so, we can build those as well
Sep 13 10:48:46 <heeen> I mean the thing you want to build, your software product, can you use oe not only for embedded targets but also the machine that oe runs on as a target
Sep 13 10:48:58 <heeen> so all configuration is kept in one place
Sep 13 10:49:25 <bluelightning> for the host machine? yes, that's what I was referring to in the first answer
Sep 13 10:49:43 <bluelightning> the first stage of any build is building tools to run on the host using the compiler from the host system
Sep 13 10:49:58 <heeen> say you build firefox mobile through oe, could you use the same configs with different paths etc, to build it for the machine you are building on, i.e. firefox proper
Sep 13 10:50:06 <bluelightning> yep
Sep 13 10:50:10 <heeen> ok cool
Sep 13 10:50:31 <bluelightning> these days it is often as simple as adding BBCLASSEXTEND = "native" to the recipe and then just bitbake recipename-native
Sep 13 10:51:33 <bluelightning> you won't get any packages produced though, the output just goes into the sysroot
Sep 13 10:51:48 <woglinde> hi
Sep 13 10:51:51 <bluelightning> hi woglinde
Sep 13 11:00:46 <erwin> hello
Sep 13 11:06:23 <woglinde> hi erwin
Sep 13 11:06:26 <woglinde> hi zecke
Sep 13 11:13:56 <Dim_> Hello - Can I change a variable in a bbclass-file? The variable is configured in a conf-file.
Sep 13 11:16:55 <zecke> woglinde: hi
Sep 13 11:18:22 <Dim_> My problem is, i have a variable "HPL = "some string some string" in a conf-file. In some recipies i inherit a bbclass. In this bbclass I change the variable like "hpl = d.getVar("HPL", True); hpl.replace(...); d.setVar("HPL", hpl);". And in a last recipe i use this variable, but she is not changed.
Sep 13 11:25:49 <zecke> Dim_: are you sure that your bbclass python code is executed
Sep 13 11:25:53 <zecke> JaMa|Off: ping?
Sep 13 11:25:59 <zecke> woglinde: did you try systemd recently?
Sep 13 11:26:07 <woglinde> zecke
Sep 13 11:26:08 <woglinde> no
Sep 13 11:26:09 <Dim_> zecke: yes - i have some "print" in my code - it is executed
Sep 13 11:26:26 <woglinde> zecke whats the problem?
Sep 13 11:26:36 <woglinde> I only had problems with uclibc and systemd
Sep 13 11:28:10 <zecke> woglinde: my issue is with 'udev' and how to build sysvinit and systemd images from the same build tree
Sep 13 11:28:28 <zecke> woglinde: I need to set systemd-udev as preferred provider to build, but then there is no sysvinit script installed
Sep 13 11:30:51 <woglinde> lol
Sep 13 11:30:53 <woglinde> http://www.toothycat.net/~hologram/Turing/
Sep 13 11:31:22 <woglinde> zecke hm I think there was some discussion about it on the ml
Sep 13 11:31:45 <woglinde> zecke wouldnt it be easier do simply convert all your stuff to systemd-confs?
Sep 13 11:31:52 <woglinde> s/do/to
Sep 13 11:31:54 <Dim_> zecke: I need  to call a update_data,?
Sep 13 11:37:14 <zecke> woglinde: well,i might have a tiny init.
Sep 13 11:40:34 <woglinde> zecke o.O
Sep 13 11:53:37 <woglinde> hi tartarus
Sep 13 11:54:23 <JaMa|Off> zecke: pong
Sep 13 11:54:30 <JaMa|Off> but I'm leaving soon
Sep 13 11:55:31 <woglinde> hi mickey
Sep 13 11:55:41 <zecke> JaMa|Off: i wondered about meta-systemd and allowing old sysvinit/other init systems in regard to udev. The last question by Simon Busch was not discussed to an end
Sep 13 12:03:14 <Dim_> same problem another approach: I have a task "python do_a () { hpl = d.getVar('HPL', True); hpl.replace(...); d.setVar('HPL', hpl); } ... this task is added with "addtask a after do_install before do_package". The task is executed. a second task "python do_b () { hpl = d.getVar('HPL', True); print "hpl: %s" % (hpl); }" is added with "addtask b after do_b before do_package". This task is executed too. But the second task prints my unchanged v
Sep 13 12:03:21 <Dim_> :-)
Sep 13 12:07:10 <Dim_> My Problem in code-form here: https://gist.github.com/3713910
Sep 13 12:11:10 <woglinde> dim do you need anonymous python function?
Sep 13 12:11:44 <woglinde> you could make a variable with python syntax
Sep 13 12:11:54 <woglinde> and call the variable in shell snippet
Sep 13 12:12:05 <woglinde> that should work
Sep 13 12:12:35 <Dim_> woglinde: this was my first approach, but it didnt work.
Sep 13 12:14:45 <Dim_> woglinde: this was my first example: https://gist.github.com/3713910
Sep 13 12:21:09 <woglinde> dim hm wahts d? you need to have bb.data
Sep 13 12:22:06 <bluelightning> woglinde: not with OE-Core
Sep 13 12:22:32 <bluelightning> woglinde: in fact using bb.data instead of d in that context is deprecated
Sep 13 12:22:40 <woglinde> bl hm whith which layers it works?
Sep 13 12:22:48 <woglinde> looks like my meta-java still works
Sep 13 12:23:21 <woglinde> okay anyway I will take nap
Sep 13 12:23:35 <bluelightning> woglinde: right, it's deprecated but will still work
Sep 13 12:30:59 <otavio_> Hi; we're seeing a weird error on bitbake: http://paste.debian.net/189677/
Sep 13 12:31:26 <otavio> it raises an exception in pickle
Sep 13 12:31:31 <otavio> any clue?
Sep 13 12:31:53 <otavio> it seems to be machine dependant and image dependant
Sep 13 12:32:22 <bluelightning> otavio: which version of bitbake are you using?
Sep 13 12:32:30 <Dim_> woglinde:  is "d" not the complete metadata of all my recipies and confs? What is the difference of "bb.data" and "d"?
Sep 13 12:32:30 <otavio> denzil
Sep 13 12:32:37 <otavio> bluelightning: denzil
Sep 13 12:33:27 <bluelightning> Dim_: d.getVar("SOMEVAR", True) and bb.data.getVar("SOMEVAR", d, True) are exactly equivalent, except the former is now preferred and the latter is deprecated
Sep 13 12:34:02 <bluelightning> otavio: can you pastebin the rest of the error output?
Sep 13 12:34:18 <bluelightning> otavio: I think I've seen this is as a follow-on from another error
Sep 13 12:34:56 <Dim_> bluelightning: thx, but why i cannot update my variables like in https://gist.github.com/3713910
Sep 13 12:35:15 <otavio> bluelightning: https://groups.google.com/d/topic/meta-fsl-arm/7W9bwxqslnk/discussion
Sep 13 12:36:50 <bluelightning> Dim_: I think you'll find the python replace function returns the modified value, it doesn't alter the string it's called upon (python strings are immutable IIRC)
Sep 13 12:37:03 <bluelightning> Dim_: so you need hpl = hpl.replace(...)
Sep 13 12:38:29 <bluelightning> otavio: hmm, maybe not the issue I was thinking of then...
Sep 13 12:38:59 <Dim_> bluelightning: yes - you are right, it was a copy'n'paste-failure from my chat-input. But the problem is still here. :-(
Sep 13 12:38:59 <otavio> bluelightning: the weird thing it happens in two machines
Sep 13 12:39:56 <afournier> how can someone select the kernel he wants using virtual/kernel ?
Sep 13 12:40:18 <bluelightning> Dim_: you can always bb.warn(hpl) in that python function to see if the value is being changed as you expect
Sep 13 12:40:37 <bluelightning> afournier: PREFERRED_PROVIDER_virtual/kernel
Sep 13 12:40:47 <bluelightning> afournier: in your local or distro configuration
Sep 13 12:40:54 <afournier> ok
Sep 13 12:40:58 <bluelightning> or machine configuration
Sep 13 12:41:44 <afournier> thanks
Sep 13 12:42:55 <Dim_> bluelightning: I have a print "hpl: %s" % (hpl) in my python-code - and yes the value is changed. but in my do_a function it will print the old content of hpl.
Sep 13 12:49:31 <bluelightning> Dim_: I just tried it here and it worked...
Sep 13 12:50:54 <denisATeukrea> hi,
Sep 13 12:51:11 <otavio> denisATeukrea: hi
Sep 13 12:51:26 <denisATeukrea> I want to do update-alternative to qtdemo because I think it's cleaner than other solutions
Sep 13 12:51:38 <denisATeukrea> so I tried to add that:
Sep 13 12:52:44 <denisATeukrea> ALTERNATIVE_PATH = "...", ALTERNATIVE_NAME = "..."  etc....
Sep 13 12:52:58 <denisATeukrea> however that adds it to qt-x11-free
Sep 13 12:52:58 <bluelightning> Dim_: which version of bitbake are you using?
Sep 13 12:53:01 <denisATeukrea> instead of qtdemo
Sep 13 12:53:04 <denisATeukrea> if I do that:
Sep 13 12:54:10 <Dim_> bluelightning:  i'm stuck on version 1.12.0. with a oe-classic 
Sep 13 12:54:31 <bluelightning> Dim_: ah ok; that might explain it
Sep 13 12:54:44 <Dim_> bluelightning: lol? 
Sep 13 12:54:45 <denisATeukrea> ALTERNATIVE_NAME_qt4-demos = "..."
Sep 13 12:54:55 <denisATeukrea> it complain that ALTERNATIVE_NAME is not defined
Sep 13 12:54:59 <Dim_> bluelightning: sorry why?
Sep 13 12:55:17 <denisATeukrea> because I inherit update-alternative
Sep 13 12:55:40 <denisATeukrea> I've a workarround tough
Sep 13 12:55:59 <denisATeukrea> like making a simlink to /etc/something for mini-x-session
Sep 13 12:56:01 <bluelightning> Dim_: well, I wouldn't necessarily say that is a known bug (to me at least) but it may explain why it works here and not for you
Sep 13 12:56:15 <denisATeukrea> but I would prefer the ua approach for x-window-manager...
Sep 13 12:56:44 <Dim_> bluelightning: ok - i will try another approach - thx for your help!
Sep 13 12:56:57 <bluelightning> Dim_: if you do export HPL and then use $HPL in the shell script does that work?
Sep 13 12:57:17 <afournier> i added this and it stills takes the 3.2
Sep 13 12:57:19 <afournier> PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
Sep 13 12:57:19 <afournier> PREFERRED_VERSION_linux-yocto = "2.6.37"
Sep 13 12:57:20 <Dim_> bluelightning: can i export in a python-script?
Sep 13 12:57:32 <bluelightning> Dim_: I mean export HPL on one line in the recipe
Sep 13 12:57:43 <bluelightning> that is legal syntax
Sep 13 12:57:55 <bluelightning> (i.e. outside of a function)
Sep 13 12:57:58 <Dim_> bluelightning: i will try it.
Sep 13 13:00:40 <afournier> ah it was in the cache...
Sep 13 13:00:47 <afournier> i think it will work now
Sep 13 13:01:01 <denisATeukrea> is there a more clever solution
Sep 13 13:01:02 <denisATeukrea> ?
Sep 13 13:01:07 <denisATeukrea> because I see that:
Sep 13 13:01:09 <denisATeukrea>         pkg = d.getVar('PN', True)
Sep 13 13:01:23 <denisATeukrea> in python populate_packages_prepend () { in update-alternatives.bbclass
Sep 13 13:01:47 <denisATeukrea> bitbake -e doesn't help much
Sep 13 13:02:04 <denisATeukrea> because if I inherit ua.bbclass it fails before producing the -e output
Sep 13 13:02:15 <denisATeukrea> if I add the override for ${PN}
Sep 13 13:02:17 <denisATeukrea> I mean that:
Sep 13 13:02:22 <denisATeukrea> ALTERNATIVE_NAME_qt4-demos
Sep 13 13:03:21 <afournier> NOTE: preferred version 2.6.37 of linux-yocto not available (for item virtual/kernel)
Sep 13 13:07:07 <afournier> yay it work with +git%
Sep 13 13:10:43 <xim> Hello, everybody =)
Sep 13 13:11:48 <xim> I'm writing a bitbake recipe for a daemon, and got it working smoothly. I would, however, like to have two versions of the package – with different config files.
Sep 13 13:11:56 <Dim_> bluelightning: nope - is still the old value
Sep 13 13:11:59 <denisATeukrea> I know setting PN is a verry bad idea.....
Sep 13 13:12:10 <denisATeukrea> like PN = "..."
Sep 13 13:13:25 <bluelightning> xim: you can just "require" recipe B (include its contents) from recipe A and then make the changes to SRC_URI and anything else afterwards in recipe A
Sep 13 13:13:42 <bluelightning> xim: or if you prefer you can put the common parts in an inc file and use require on the inc file from both
Sep 13 13:14:34 <bluelightning> Dim_: hmm; I suspect it is a bug in that old version then I'm afraid
Sep 13 13:14:52 <Dim_> bluelightning: ok - but thx for your help
Sep 13 13:15:05 <xim> bluelightning: Is there no way to simply use the normal package splitting for this? Not that making a new .bb is a lot of work, but... :)
Sep 13 13:15:20 <denisATeukrea> maybe it's the inherit that is problematic?
Sep 13 13:15:29 <denisATeukrea> I mean there is no inherit_foo
Sep 13 13:15:49 <denisATeukrea> maybe the cleanest way is a separate recipe
Sep 13 13:15:51 <denisATeukrea> ?
Sep 13 13:16:25 <bluelightning> xim: I don't think you can have a single recipe that has two packages that contain different versions of the same file, if that's what you're asking; unless you use the alternatives system to handle that of course
Sep 13 13:16:39 <bluelightning> xim: in fact that may be the answer
Sep 13 13:16:44 <xim> the alternatives system?
Sep 13 13:16:56 <Dim_> xim: you can put your configuration-file in a own package.
Sep 13 13:16:57 * xim googles
Sep 13 13:17:21 <denisATeukrea> update-alternative...
Sep 13 13:17:30 <xim> Dim_: Ah, and I also want a flag added to the compilation. Forgot that :)
Sep 13 13:19:17 <Dim_> xim: eg. you need a config-option - dependent on something and you adapt your two recipies for this situation
Sep 13 13:21:55 <bluelightning> xim: oh, well in that case you really do need a different recipe
Sep 13 13:23:50 <xim> Actually, I realize I could compile the extra module (a dlopen()-able plugin to the main daemon) always, and include that in the FILES_${PN}-foo = "..."
Sep 13 13:24:45 <bluelightning> right, that sounds reasonable
Sep 13 13:25:39 <xim> But that doesn't allow me to override the config files. The daemon uses a conf.d style config, but I need to override a whole config section (not just include the plugin itself) for the new package...
Sep 13 13:26:02 <xim> Compiling it twice feels a bit silly
Sep 13 13:26:22 <bluelightning> you could use a postinst to handle it
Sep 13 13:26:33 <bluelightning> does the software not support a configuration directory a la apache?
Sep 13 13:27:08 <xim> bluelightning: Yup, but I need one whole config file replaced
Sep 13 13:27:51 <xim> Hmmmm, maybe if the daemon itself supports a «If this plugin exitst» type directive...
Sep 13 13:28:10 <bluelightning> right, apache handles things that way
Sep 13 13:28:48 <xim> But that doesn't appear to be the case here, damn...
Sep 13 13:29:18 <xim> (Pardon my french)
Sep 13 13:35:45 <xim> Is there any good documentation on the FILES_${PN}-foo and friends?
Sep 13 13:37:53 <bluelightning> xim: there's the Yocto Project documentation - specifically the reference manual has documentation on almost all variables
Sep 13 13:38:14 <bluelightning> http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html
Sep 13 13:38:32 <bluelightning> http://www.yoctoproject.org/documentation
Sep 13 13:40:42 <xim> bluelightning: Thanks, I think I have a plan now, and thanks for the link as well!
Sep 13 13:40:50 <bluelightning> no worries
Sep 13 13:55:51 <woglinde> re
Sep 13 16:14:33 <hrw> does someone has recipes for 2012* ltp?
Sep 13 16:15:12 <hrw> ops, found
Sep 13 16:35:37 <silvio_> bb all
Sep 13 21:51:04 <cbrake> does bitbake now rebuild dependent recipes?
Sep 13 21:53:30 <kergoth> if A depends on B and B changes, A will rebuild, yes
Sep 13 21:53:45 <kergoth> that is, if you're using the default OEBasicHash signature handler
Sep 13 21:53:52 <kergoth> which results in the sstate checksums being part of the stamps
Sep 13 21:54:13 <kergoth> and sstate checksums cross task/recipe dependency boundaries
**** ENDING LOGGING AT Fri Sep 14 02:59:59 2012