**** BEGIN LOGGING AT Fri Dec 09 02:59:58 2011
Dec 09 09:56:40 <bluelightning> morning all
Dec 09 10:24:11 <otavio> morning
Dec 09 10:25:41 <d4ny> morning
Dec 09 10:40:58 <RP__> morning all
Dec 09 10:54:19 <otavio> :-)
Dec 09 11:14:52 <d4ny> Hi All, how would I setup yocto to spit out -src packages ?
Dec 09 11:16:18 <d4ny> Been looking around the source, but I cant find any references on how to do it.
Dec 09 11:20:24 <d4ny> sourcepkg.class seems to be the answer :)
Dec 09 18:37:43 <incandescant> otavio: ping?
Dec 09 18:38:15 <otavio> incandescant: pong
Dec 09 18:38:16 <incandescant> otavio: had you intended to submit ntp to oe-core? connman now DEPENDS it but we don't have it in oe-core
Dec 09 18:38:49 <otavio> incandescant: Ouch ...
Dec 09 18:39:06 <otavio> incandescant: it built here as I have meta-oe enabled
Dec 09 18:39:23 <incandescant> otavio: yeah, I just realised that - sorry I did not catch that sooner
Dec 09 18:39:37 * incandescant guessed he should only Ack patches he has built
Dec 09 18:39:38 <otavio> incandescant: I didn't catch it too
Dec 09 18:39:54 <otavio> incandescant: in fact I built, but did it on my tree
Dec 09 18:39:59 <otavio> incandescant: and my tree has meta-oe
Dec 09 18:40:21 <dvhart> http://bugzilla.yoctoproject.org/show_bug.cgi?id=1817
Dec 09 18:40:29 <otavio> RP__: should I add ntp or send a patch to remove ntp from depends?
Dec 09 18:41:04 <otavio> dvhart: thanks ;-)
Dec 09 18:41:05 <RP__> sgw: any opinion?
Dec 09 18:41:25 <otavio> I prefer to provide ntp
Dec 09 18:41:29 <RP__> otavio: I suspect add it
Dec 09 18:41:34 <otavio> OK
Dec 09 18:41:41 <otavio> will cook a patch for it
Dec 09 18:42:57 <dvhart> what does connman use ntp for?
Dec 09 18:43:06 <dvhart> how is it affected if it isn't there?
Dec 09 18:43:25 <otavio> dvhart: it has a pluging for it
Dec 09 18:43:37 <dvhart> seems to me connman should rely on the system time, and it should be up to the distro if the system time is maintained via ntp
Dec 09 18:44:04 <otavio> dvhart: http://www.mail-archive.com/connman@connman.net/msg06788.html
Dec 09 18:44:26 <sgw> RP__, otavio: catching up and reading
Dec 09 18:45:42 <dvhart> otavio, that doesn't really help explain WHY for me
Dec 09 18:46:08 <dvhart> could be perfectly valid mind you, I was just asking b/c I didn't know
Dec 09 18:46:29 <otavio> dvhart: personally I don't use ntp plugin
Dec 09 18:46:41 <sgw> otavio: so it's untested?
Dec 09 18:46:50 <otavio> dvhart: but as it is modular, I think it is better to have it
Dec 09 18:46:56 <otavio> sgw: the ntp plugin yes
Dec 09 18:47:15 <sgw> I think it might be better to disable that functionality for now instead of adding a new depends.
Dec 09 18:47:28 <RP__> otavio: If nobody is using it I'm not sure we should have it
Dec 09 18:47:36 <RP__> we can easily add it if someone actually uses it
Dec 09 18:47:42 <sgw> RP__: right
Dec 09 18:47:44 <otavio> RP__: for me it is OK to drop for now
Dec 09 18:48:24 <otavio> RP__: cooking a patch for it then
Dec 09 18:48:47 <sgw> otavio: I think we kind of rushed this, otherwise I might have caught this.
Dec 09 18:49:16 <otavio> sgw: yes; it is holding my product building and I asked RP__ to get it in.
Dec 09 18:49:20 <otavio> sgw: my fault
Dec 09 18:55:42 <otavio> sgw: dvhart: incandescant: RP__: https://github.com/OSSystems/oe-core/commit/35343ba859919a927e5373ac7f39526dad301ca5
Dec 09 18:55:45 <otavio> done
Dec 09 18:56:31 <dvhart> IRC-Acked-By: dvhart
Dec 09 18:56:50 <dvhart> typo in your commit log
Dec 09 18:56:53 <otavio> RP__: want me to send to ml?
Dec 09 18:56:56 <dvhart> s/know/known/
Dec 09 18:56:59 <otavio> dvhart: really? where
Dec 09 18:57:00 <otavio> grr
Dec 09 18:57:04 <otavio> I am not native
Dec 09 18:57:05 <RP__> otavio: please
Dec 09 18:57:05 <otavio> hold
Dec 09 18:57:22 <sgw> otavio: RP: seems right to me
Dec 09 18:57:46 <dvhart> otavio, it's cool, that's what the review process is for :)
Dec 09 18:57:55 * dvhart is native and still introduces all kinds of typos....
Dec 09 18:58:45 <otavio> dvhart: do you close the bug once it is merged?
Dec 09 18:58:58 <otavio> RP__: sent
Dec 09 18:59:16 <dvhart> otavio, no, we add the commit link to git.yoctoproject.org and mark it as FIXED
Dec 09 18:59:41 <otavio> dvhart: you do it, or I do it?
Dec 09 19:00:22 <dvhart> otavio, you should move to fixed
Dec 09 19:00:34 <dvhart> as the reported I will mark resolved after I confirm it works for me
Dec 09 19:00:36 <incandescant> once merged
Dec 09 19:00:46 <dvhart> gah, see - reported/reporter
Dec 09 19:01:26 <incandescant> i.e. dev submits fix -> fix merged -> dev marks bug as fixed with link to git -> reporter verifies and marks bug appropriately
Dec 09 19:01:49 <otavio> so I mark as resolved/fixed?
Dec 09 19:02:16 <incandescant> yes, once it's been merged
Dec 09 19:02:56 <incandescant> I think this is documented somewhere, let me try and find it
Dec 09 19:03:44 <incandescant> https://wiki.yoctoproject.org/wiki/Bugzilla_Configuration_and_Bug_Tracking
Dec 09 19:03:45 <incandescant> ta da!
Dec 09 19:03:52 <incandescant> that's a lot of words, though
Dec 09 19:04:36 <dvhart> incandescant, who's high maintenance now?
Dec 09 19:04:38 <dvhart> ;)
Dec 09 19:07:16 <incandescant> I'm not demanding it be read, I'm just pointing out its existence
Dec 09 19:07:55 <khem> sgw: other day you were asking for eglibc patches
Dec 09 19:08:13 <khem> sgw: they all are documented well in header and reflects the current status
Dec 09 19:08:22 <khem> nothing has changed in there
Dec 09 19:10:59 <sgw> khem: what about the uclibc patches, since you work with those also, I thought I mentioned them also?
Dec 09 19:11:20 <khem> uclibc ones I will take care of them one day
Dec 09 19:11:28 <khem> and push them upstream
Dec 09 19:11:35 <sgw> khem: thanks
Dec 09 19:13:33 <khem> there are about 400 patches I am holding on for uclibc
Dec 09 19:13:45 <khem> there is one pesky bug thats lurking somehwere
Dec 09 19:18:56 <zenlinux> There's got to be a better way of doing this.... I'm moving some, but not all, of various recipe libraries from libdir to base_libdir (e.g, e2fsprogs)...
Dec 09 19:19:30 <zenlinux> I can mv the libxyz.so.* files into base_libdir easily enough, but do I really need to re-create the .so symlink (which should stay in libdir)?
Dec 09 19:19:51 <zenlinux> or is there a helper function to relocate libraries like this?
Dec 09 19:20:32 <zenlinux> The issue I'm running into is not knowing what the soname extension is when relinking the .so file
Dec 09 19:20:36 <otavio> zenlinux: look at meta-micro
Dec 09 19:20:47 <otavio> zenlinux: you can do it using prefix and exec_prefix
Dec 09 19:20:59 <zenlinux> otavio, looking...
Dec 09 19:22:11 <zenlinux> otavio, where is the meta-micro layer hosted? I'm not seeing it on the oe git repo
Dec 09 19:23:24 <otavio> zenlinux: openembedded git iirc
Dec 09 19:23:41 <otavio> dvhart: Is it possible for you to test a patch for connman build?
Dec 09 19:23:43 <zenlinux> ah, found it
Dec 09 19:23:55 <otavio> dvhart: here it builds but maybe I know how to fix it
Dec 09 19:25:32 <dvhart> otavio, sure
Dec 09 19:25:42 <zenlinux> otavio, could you give me a more specific example? btw I'm not relocating *all* the libraries of e2fsprogs to base_libdir, just some of them known to be linked by binaries in base_bindir/base_sbindir
Dec 09 19:25:44 <RP__> otavio: zenlinux is trying something a little different
Dec 09 19:26:10 <RP__> zenlinux: I'm not sure meta-micro would help. A function for this kind of thing could be useful
Dec 09 19:27:07 <otavio> zenlinux: so no. This is not what I thought you were doing
Dec 09 19:27:17 <zenlinux> otavio, ok
Dec 09 19:34:39 <otavio> dvhart: https://github.com/OSSystems/oe-core/commit/695e24c9e389207412e0d39446f4ea1d95355ac2
Dec 09 19:36:32 <otavio> dvhart: I know the comment is not right, i fix it after you confirm it builds
Dec 09 19:38:48 <dvhart> hrm... can I download this as a patch directly from github.... not finding such a link
Dec 09 19:40:37 <dvhart> otavio, building
Dec 09 19:41:56 <otavio> dvhart: about dosfstools
Dec 09 19:42:05 <otavio> dvhart: gplv3 are 3.0.x releases
Dec 09 19:42:27 <otavio> dvhart: what i did was to forward-port patches to 2.11 and remove 2.10
Dec 09 19:42:41 <otavio> dvhart: and drop native specific recipe
Dec 09 19:45:23 <dvhart> ok, so 2.11 includes the llseek patch and retains GPLV2 ?
Dec 09 19:45:58 <otavio> dvhart: yes
Dec 09 19:48:39 <otavio> dvhart: has connman built for you now?
Dec 09 19:50:15 <dvhart> no, still seems to fail in the same way
Dec 09 19:53:45 <otavio> dvhart: https://github.com/OSSystems/oe-core/commit/835abb07c6bdc2d5c9e1c3e906819630c6dff023
Dec 09 19:53:53 <otavio> dvhart: I added line 54
Dec 09 19:54:55 <dvhart> building
Dec 09 19:57:34 <dvhart> that builds
Dec 09 19:57:45 <dvhart> but what are we losing from this?
Dec 09 20:02:54 <otavio> dvhart: this was in meta-oe and since it built fine here I removed
Dec 09 20:03:04 <otavio> dvhart: it is a test that is not built
Dec 09 20:03:11 <otavio> dvhart: seems safe for now
Dec 09 20:03:21 <otavio> dvhart: i will finish the patch and send
Dec 09 20:06:21 <otavio> dvhart: sent to ml
Dec 09 22:20:25 <dvhart> zeddii, ping
Dec 09 22:20:29 <dvhart> zeddii, $ cat ../../features/rt/rt.scc
Dec 09 22:20:29 <dvhart> patch rt-apply-patch-3.0.10-rt27.patch.patch
Dec 09 22:20:46 <dvhart> the file only has one .patch prefix - this is bad right?
Dec 09 23:57:26 <RP__> dvhart: I should pull otavio's patch?
Dec 09 23:58:03 <incandescant> RP__: I can confirm that without it I can't build, and with it I can
Dec 09 23:58:35 <dvhart> RP__, it builds and solves the immediate problem
Dec 09 23:58:46 <dvhart> RP__, but it feels like a hack
Dec 09 23:58:58 <RP__> ok, I'll add it on the grounds it makes things better rather than worse...
Dec 09 23:58:58 <dvhart> RP__, I don't know what the repercussions might be
Dec 09 23:59:06 * dvhart nods
**** ENDING LOGGING AT Sat Dec 10 02:59:56 2011