**** BEGIN LOGGING AT Fri Nov 30 02:59:58 2012 Nov 30 08:23:08 I found the bitbake fetch hang. somewhere it tries to open downloads/cfg.lock and if that fails, it just busy-loops trying again Nov 30 08:23:55 I saw it with strace -p, haven't found the offending code yet Nov 30 08:44:13 good morning Nov 30 09:19:36 morning all Nov 30 09:19:42 good morning Nov 30 09:23:57 morning Nov 30 09:27:14 hi hrw Nov 30 09:54:41 morning hrw, florian, all Nov 30 09:54:47 hi bluelightning Nov 30 09:56:58 hi bluelightning Nov 30 09:57:04 hi florian , hi bluelightning Nov 30 09:57:10 hi silvio Nov 30 09:57:14 hi silvio Nov 30 11:00:49 If i take an image.bb from another layer, it is possible remove only some packages with an imabe.bbappend from my layer? Nov 30 11:06:13 silvio: honestly I don't think it's worth doing for image recipes - much easier to just copy and rename it and then you can make whatever customisations you need Nov 30 11:07:25 (since image recipes usually don't have much in them beyond determining what packages should be installed) Nov 30 11:28:04 bluelightning, ok, thanks, this is still valid? http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Nov 30 11:56:53 silvio from a quick glance yes Nov 30 13:14:31 I'm working on a C++ OE based project that will require dbus. I noticed that libdbus-c++ was removed from oe-core early last year and the log comment said it was broken and there was a better option anyway in OE. What is everyone else using for dbus when writing C++ apps? Nov 30 13:15:45 svolpe are you using glib? Nov 30 13:15:59 you could use the glibmm dbus bindings Nov 30 13:16:46 woglinde: I have messed a little with using dbus-glib but its a bit of a pain to get it in a nice OO format. I can do it but I thought there might be a better solution out there. Nov 30 13:16:57 no Nov 30 13:17:05 dbus-glib is gone Nov 30 13:17:15 glib has it now included Nov 30 13:17:19 anf so glibmm Nov 30 13:17:50 woglinde: ok so the recommendation is glibmm and it is OO which I had missed in your first post about it. Nov 30 13:19:02 svolpe: I currently use glib for my dbus needs Nov 30 13:19:14 woglinde: and it looks like glibmm is thread safe. This is important as I'm adding it to an existing monolithic app with its own main loop so the glib main loop is problematic for my design. Nov 30 13:19:55 jackmitchell fine but svople is dooing oo with c++ Nov 30 13:19:56 svolpe: I also use my own main loop with a glib loop running aside it for managing the dbus connections Nov 30 13:20:20 svolpe yes more than one mainloop is some pain but Nov 30 13:20:29 I struggled in python with it a bit Nov 30 13:20:32 jackmitchell: what is the clean way to run the 2 main loops with glib. Nov 30 13:20:41 woglinde: I wish this was a python project ;-) Nov 30 13:21:07 yes python-dbus is nice to use Nov 30 13:21:48 woglinde: I had a complete prototype of my dbus design working in python in probably under 1 hour, I've been working on the same C++ implementation for a little over 5 hours now. Nov 30 13:22:13 svolpe: I create a new thread which runs the dbus init stuff and then ends up with a glib loop Nov 30 13:22:36 svolpe hm why you cannt use python? Nov 30 13:22:45 hm okay till later Nov 30 13:22:52 baby needs some new diapapers Nov 30 13:23:41 woglinde: just because its a legacy code base and would take for ever to rewrite. Nov 30 13:24:25 jackmitchell: ok so glib main loop is thread safe, that was what I was not sure of, I was going to do some searching on it today. Nov 30 13:25:07 svolpe: haha, well, I wouldn't take my word for it - all the glib stuff is in one thread and one thread only Nov 30 13:28:38 the qt dbus implementation is nice and easy to use (but requires qt) Nov 30 13:29:53 jackmitchell: FYI, after a quick search http://developer.gnome.org/glib/2.31/glib-Threads.html it looks like GLIB is thread safe since version 2.8.0 Nov 30 13:33:26 svolpe: good to know, thanks! Nov 30 13:40:35 svolpe hm okay so the source code is not opensource Nov 30 13:40:51 would have been cool to see the final stuff Nov 30 13:41:06 I did not find much application which uses glibmm at all Nov 30 13:41:12 and non of them used dbus Nov 30 13:42:57 Hello everbody. Sometimes bitbake -c clean software, bitbake software doesn't recompile the package.... I think it's just copying a created package so I guess I should delete a file to trigger recompiling... Any help ? Nov 30 13:44:22 vadmeste: bitbake -c cleansstate software Nov 30 13:46:04 vadmeste yes sstate is much faster than ccache Nov 30 13:49:28 okay thanks.. I have another question... Modifying a source file in work directory then bitbake -c compile software won't rebuild my binary.. is that normal ? Nov 30 13:51:54 vadmeste do you mean recipe or the real source code? Nov 30 13:51:57 woglinde: this really depends on the use case; sstate on a single host does not make a big difference (I almost never use '-c clean' but '-c cleansstate') while ccache is a real win. Although the 10% hits on build-from-scratch images are eaten by ccache overhead, you get nearly 100% hits when working on a package Nov 30 13:52:13 woglinde: I mean C code :) Nov 30 13:52:21 vadmeste: with current OE-Core you can use -C compile and it will also repackage and deploy everything as well Nov 30 13:52:44 or rather, with current bitbake Nov 30 13:56:37 bluelightning: it works, thanks ^^ Nov 30 13:58:17 this is still valid? http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Nov 30 13:58:28 woglinde: yeah there seems to be no examples out there of glibmm. Normally if I struggle through something like this I extract the solution from the non opensource portion and share it as I don't want others struggleing like I did ;-) Nov 30 13:59:30 svolpe okay because I found hands free bluetooth daemon which is 4 years old and using some noih stuff for dbus Nov 30 13:59:50 silvio as I said, yes Nov 30 14:05:53 ensc|w: do you use ccache with oe? Nov 30 14:10:55 silvio_: I can confirm yes it is still valid Nov 30 14:11:51 silvio_: note for new recipes there's not much description needed though Nov 30 14:12:25 silvio_: if migrating an OE-Classic recipe you should explain what you changed when migrating it though Nov 30 14:26:31 bluelightning, ok thanks, I thinks the only things that may create trouble are licences :) Nov 30 14:26:42 silvio_: why? Nov 30 14:26:46 bluelightning, the feh recipe is pratically unmodified Nov 30 14:27:56 bluelightning, because I have not clear the licence of giblib, and I don t know conseguence of if I publish it with wrong licence Nov 30 14:28:19 silvio_: as I said the other day just use LICENSE = "giblib" since it is not a standard license Nov 30 14:28:25 that is our convention Nov 30 14:28:52 that will produce a warning but that is OK Nov 30 14:29:38 bluelightning, ok, is only to guarantee myself Nov 30 14:30:07 but warning break the QA system of poky? Nov 30 14:30:18 not that particular warning no, it's just a warning Nov 30 14:30:22 but warning break the QA system of poky/oe core? Nov 30 14:58:21 jackmitchell: yes; I am using ccache Nov 30 14:58:36 ensc|w: is it easy to setup? Nov 30 15:00:27 basically, it is trivial to set it up. but you must remove the 'export CCACHE_DISABLE ??=' line from meta/conf/bitbake.conf Nov 30 15:02:33 you should set $CCACHE_DIR to .../tmp/cache/ccache too (using system ccache dir does not make much sense) Nov 30 15:03:16 avoid using the ccache.bbclass; a PN dependent CCACHE_DIR does not make sense Nov 30 15:04:40 ensc|w: Ok, I may have a crack at it one of these days thanks Nov 30 15:04:44 ensc|w: why would you need to remove that from bitbake.conf? it's ??= so you should be able to just set it in local.conf Nov 30 15:05:49 bluelightning: http://patches.openembedded.org/patch/32787/ Nov 30 15:07:09 I see Nov 30 15:07:21 thanks Nov 30 15:47:37 i don't understand the concept of volatiles... Nov 30 15:49:54 afournier1: the way I see volatiles is that it is memory which is nice to use if available but you don't necessarily need it, as the value can be recalculated if needs be Nov 30 15:50:34 i was thinking about the volatiles in initscritps Nov 30 15:50:56 the debian-volatile thing Nov 30 15:51:27 afournier1: hah, no worries - I think that explanation was utter trollop anyway Nov 30 15:51:38 :) Nov 30 15:51:43 afournier1: I was getting confused with something else! Nov 30 15:52:02 me too indeed Nov 30 15:52:22 there is the C/ASM volatile stuff, the populate volatile scripts, and the debian-volatile packages Nov 30 15:52:35 my question was about the populate-volatile.sh Nov 30 15:52:58 or /etc/default/volatiles Nov 30 15:54:13 if i understood, its purpose is to make directories and change attributes of those directories if its not done already, in order to prepare the environment for some daemons Nov 30 15:54:41 but it would be easier to add those directories and attribs in the packages directly no ? Nov 30 15:57:19 afournier1 this voilatile is for tmpfs directories Nov 30 15:57:42 afournier1 if you have /var/tmp or /var/pid on tmpfs Nov 30 15:57:46 brb Nov 30 15:57:52 argh, wrong channel, lol Nov 30 15:58:02 you need something to maybee create necessary directories within Nov 30 15:58:13 thats it about Nov 30 15:58:14 woglinde: then it should be in oe default fstab Nov 30 15:58:19 ????? Nov 30 15:58:27 fstab is for mounting Nov 30 15:58:37 ie mounting tmpfs Nov 30 15:58:42 not for creating dirs in tmpfs mounted dirs Nov 30 15:59:22 i mean why oe provides the populate-volatile.sh scripts if /var/volatile is not in the fstab and if the script doesn't even check /var/volatile is mounted as tmpfs Nov 30 16:00:00 than something is going wrong Nov 30 16:00:18 it's just a bit messy Nov 30 16:00:19 and yes some packages in oe-core still has problems with voilatile Nov 30 16:00:44 i think this feature should be taken away from the init scripts recipe Nov 30 16:00:52 maybee I should let bluelighting compile systemd image form angstrom to see the failures Nov 30 16:01:17 afournier1 and which mechanism than should create it? Nov 30 16:01:37 not all software is so clever to make the necessary dirs to be run themself Nov 30 16:02:06 lets say dbus needs /var/run/foo1 and /var/pid/foo2 and /var/log/moo4 Nov 30 16:02:36 you now can put in every init system before dbus is started Nov 30 16:02:49 or have one global mechanism to create the dirs Nov 30 16:04:37 then dbus should rdepend on volatile and define its volatiles Nov 30 16:05:59 afournier1 than send patches if you think something is wrong Nov 30 16:06:02 i know some daemons are not clever enought to prepare their env _then_ change their uid, and do the stuff they have to do, but it's a bit messy to provide volatiles as default, if /var/volatile is not mounted as default Nov 30 16:06:54 i think it's wrong working on X, QT, and systemd, when littles things like this does not work :/ Nov 30 16:07:17 afournier1 than do not work on x, at and systemd Nov 30 17:32:58 moin Nov 30 17:38:31 yes Nov 30 18:42:38 so what does the recipe DEPEND do besides pull the deps into the sysroot Nov 30 18:42:43 anything? Nov 30 19:22:40 pb_: ping Nov 30 19:23:46 otavio: have you had a chance to checkout the qt5? Nov 30 19:53:49 re Nov 30 20:01:58 hi blindman Nov 30 20:02:39 hm looks like I need to write some openwrt Makefiles Nov 30 20:12:46 florian: hi :) Nov 30 22:33:07 hi khem__ Nov 30 22:58:50 is there a bugtracker for filing bugs about meta-oe? Nov 30 22:59:11 or does one just submit patches to the openembedded-devel ML? Nov 30 23:03:44 zenlinux: pls use the ML nowadays Nov 30 23:03:58 ant_home, gotcha, thanks Nov 30 23:04:14 bugzilla died for lack of care :/ **** ENDING LOGGING AT Sat Dec 01 02:59:58 2012