**** BEGIN LOGGING AT Tue Aug 13 03:00:00 2013 Aug 13 09:54:51 what are the protocols for overiding a machine in someone elses layer? Aug 13 09:55:51 xora hm why no rename the machine Aug 13 09:56:24 woglinde: I could if that is the done thing Aug 13 09:57:22 preferable Id like to just kill two lines of its machine.conf from Angstrom Aug 13 10:18:13 morning all Aug 13 10:19:15 hi pb Aug 13 10:44:21 XorA, are the two lines in the machine wrong? Aug 13 10:45:16 morning XorA, pb_, woglinde, Crofton|work Aug 13 10:46:09 Crofton|work: I think technically yes Aug 13 10:46:51 you could bother the machone maintainer Aug 13 10:47:15 Crofton|work: BTW is there a way to stop Angstrom systemd stuff redoing DHCP on nfsroot? Aug 13 10:47:26 dunno Aug 13 10:47:42 I haven't run into that Aug 13 10:47:51 but I suspect it is a generaly systemd config issue Aug 13 10:48:45 hi bluelightning Aug 13 10:49:13 Crofton|work: or where the hell is network config stored these days :-D Aug 13 10:50:03 * Crofton|work blames systemd Aug 13 10:50:12 which may not be accurate :) Aug 13 10:54:24 git grep helps Aug 13 11:53:29 XorA: I patched connman to disable ip/route setup while keeping dhcp alive (which fetches dns and ntp server information) Aug 13 11:53:58 dunno, whehter it is worth to send it upstream... https://www.cvg.de/people/ensc/0001-added-noipconfig-option.patch Aug 13 12:52:39 SRC_URI_append += " \ Aug 13 12:52:46 the += is redundant, right? Aug 13 12:54:45 you don't know if there was a previous SRC_URI_append Aug 13 12:55:00 no I do not Aug 13 12:55:17 so it's not redundant, it's for preserving it Aug 13 12:55:22 k Aug 13 12:55:33 Crofton|work: it's redundant Aug 13 12:55:43 heh Aug 13 12:55:48 Crofton|work: only difference is that it also adds space Aug 13 12:56:03 yeah, I wa thinking the space would be the difference :) Aug 13 12:56:21 so drop + and add leading space, or keep + Aug 13 12:56:37 drop + add leading space if there isn't Aug 13 12:56:53 'append +=' is misleading don't use it Aug 13 12:57:01 k Aug 13 13:11:29 Crofton|work: I am seeing a high correlation between sports you do and cheating scandals, when I do see the caving scandal? Aug 13 13:11:56 rofl Aug 13 13:12:14 American team admit using pig grease for caving?? Aug 13 13:12:30 alcohol Aug 13 13:23:17 Stygia: hey... how is the perl recipe collection coming along? Aug 13 13:24:25 bluelightning, Quite fine actually. Aug 13 13:24:34 I just came back from vacation. Pardon for the long silence. Aug 13 13:24:39 np Aug 13 13:24:44 hope you enjoyed the break :) Aug 13 13:24:45 We/I actually stopped working on that for now, since it "just works". Aug 13 13:24:47 I did. :) Aug 13 13:24:59 We actually got our RTSP server (video streamer) to work, too, so now there's a recipe for that too. :P Aug 13 13:25:23 not sure if you saw but a patch has been send out to create a "meta-perl" layer within the meta-openembedded repository Aug 13 13:25:49 http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg32236.html Aug 13 13:26:16 only two recipes in it to begin with but hopefully that can be expanded ;) Aug 13 13:38:19 Huh. Aug 13 13:38:22 Yes, that we can absolutely do. Aug 13 13:38:50 bluelightning, You already send me something about how to contribute. Aug 13 13:38:54 I'll have a look once I'm off today. :) Aug 13 13:39:01 that would be awesome :) Aug 13 13:39:06 And it was MIT you had your code under, right? Aug 13 13:39:14 Because I don't like xGLP-type licenses much. Aug 13 13:39:19 that's what we tend to use for metadata yes Aug 13 13:40:19 I'm not sure but I suspect we'll end up moving the perl support recipes from meta-security to that new layer when it gets created as well Aug 13 15:06:47 * Crofton|work hates telecons Aug 13 15:07:19 does anyone know debian / dpkg or apt-get? I'm trying to figure out an analog for BAD_RECOMMENDATIONS, but so far I've not found anything Aug 13 15:16:22 fray: would that be 'dpkg hold'? Aug 13 15:19:37 hold doesn't prevent recommends from being installed.. :( Aug 13 15:19:49 hat is what I started with... Aug 13 15:20:00 and unlike dpkg you can't set 'deinstall hold'.. Aug 13 15:20:14 'er.. I mean unlike ipkg Aug 13 15:20:43 hold appears to prevent upgrades of packages, but not installs.. :/ Aug 13 15:23:35 fray: pinning to -1 priority is a suggestion I see Aug 13 15:23:46 that prevents the package from being installed at all.. Aug 13 15:23:55 fray: you can pin exact versions Aug 13 15:24:05 the ipkg BAD_RECOMMENDATION behavior is that if it's required you get it.. if it's recommended you don't Aug 13 15:24:25 that always was a nasty hack though :-) Aug 13 15:24:46 good example is installing core-image-basic.. if you BAD_RECOMMEDNATION acl and update-rc.d -- you should get acl, but not update-rc.d Aug 13 15:59:13 I have to admit to being a bit disorganised, but I assume there's a TSC / workgroup meeting starting here in a minute or two... ? Aug 13 16:00:23 khem: RP: ^ Aug 13 16:02:01 or, maybe not... Aug 13 16:03:07 bluelightning: I'm not sure I would know :/ Aug 13 16:03:13 * RP is still getting up to speed Aug 13 16:10:44 are there topics that we would like to bring forth for discussing ? Aug 13 16:14:24 #startmeeting Aug 13 16:18:48 anyone have any suggestions for TSC / working group discussion topics? Aug 13 16:19:10 Jefro1: not sure if you need to repeat that given Crofton's bot joined after you said it ;) Aug 13 16:21:21 bluelightning good point - although there doesn't seem to be much to record! Aug 13 16:21:24 #startmeeting Aug 13 16:21:24 Meeting started Tue Aug 13 16:21:24 2013 UTC. The chair is Jefro1. Information about MeetBot at http://wiki.debian.org/MeetBot. Aug 13 16:21:24 Useful Commands: #action #agreed #help #info #idea #link #topic. Aug 13 16:21:46 Jefro1: do we have a proposed agenda? Aug 13 16:22:15 bluelightning there are some topics to discuss, but thought we would find out first if anyone had open issues Aug 13 16:22:29 right, fair enough Aug 13 16:22:43 For those following along at home - this is a public OE Technical Steering Committee meeting Aug 13 16:23:07 If you have a technical issue you need the committee to discuss, please let us know so we can make sure to agendize it Aug 13 16:31:47 one thing to note perhaps - I sent out an RFC to the yocto list on automated testing on real hardware Aug 13 16:32:12 https://lists.yoctoproject.org/pipermail/yocto/2013-August/017716.html Aug 13 16:32:13 when did you send that? Aug 13 16:32:17 duh Aug 13 16:32:18 just today :) Aug 13 16:32:55 if anyone is currently doing automated testing or has an interest in doing so it would be great if you could respond to the thread on the list Aug 13 16:36:49 I'm still getting up to speed with things so I don't have much to discuss... Aug 13 16:37:23 and Aug 13 16:37:36 I dont have any new topics Aug 13 16:37:50 besides I am working on systemd upgrade to 206 Aug 13 16:42:53 Topic: janitor items Aug 13 16:43:04 Topic: eglibc Aug 13 16:43:49 eglibc 2.18 was released yesterday Aug 13 16:44:05 jefro #topic :) Aug 13 16:44:05 we have pending patches for kconfig support Aug 13 16:44:28 those patches should go into 2.19 glibc Aug 13 16:44:40 oops :) thanks Crofton|work Aug 13 16:44:43 any help in testing them out would be appreaciated Aug 13 16:44:47 I was just throwing out ideas Aug 13 16:51:18 khem: nice! :) Aug 13 16:54:39 Another thing I observed was users playing with kernel fragment manipulation infra Aug 13 16:54:51 need some documentation if thats not there Aug 13 16:55:05 now we use the same framework for busybox and uclibc Aug 13 16:55:08 I have fielded a few questions about config fragments also, both in the kernel and busybox Aug 13 16:55:12 soon for eglibc too Aug 13 16:55:32 OK cool. Aug 13 16:56:27 another issue that I am getting to is from https://bugzilla.yoctoproject.org/show_bug.cgi?id=4854 Aug 13 16:56:49 this issue seems to have surfaced with qemu 1.5 Aug 13 16:57:18 however I also saw that the default tune we use for qemuppc is ppc603 Aug 13 16:57:26 but machine we emulate in qemu is mac99 Aug 13 16:57:38 and not spec ( spec is 603e core based) Aug 13 16:57:51 mac99 has FPU differences Aug 13 16:58:26 earlier we used spec and sometime last year switched to using mac99 but default tune remained same Aug 13 16:59:27 if someone can dig down the right machine/defaut-tune match would be awesome Aug 13 17:03:39 #stopmeeting Aug 13 17:03:46 #endmeeting Aug 13 17:03:47 Meeting ended Tue Aug 13 17:03:46 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Aug 13 17:03:47 Minutes: oe/2013/oe.2013-08-13-16.21.html Aug 13 17:03:47 Minutes (text): oe/2013/oe.2013-08-13-16.21.txt Aug 13 17:03:47 Log: oe/2013/oe.2013-08-13-16.21.log.html Aug 13 17:04:10 Jefro1: thanks! Aug 13 17:07:54 thanks Jefro1 Aug 13 17:10:26 khem did you get my email about uclibc? Aug 13 17:11:51 woglinde: I did Aug 13 17:12:03 woglinde: however, for me uclibc builds ok Aug 13 17:12:04 okay Aug 13 17:12:25 khem you did not commit merge_config.sh Aug 13 17:12:30 I checked the commits Aug 13 17:12:46 so it might build for you Aug 13 17:12:50 but not for others Aug 13 17:13:18 woglinde: hmmm Aug 13 17:13:21 let me see once again Aug 13 17:15:46 woglinde: that should come from kernel tooling Aug 13 17:16:12 it shoudl be staged in your native sysroot Aug 13 17:16:19 okay Aug 13 17:16:29 will check that Aug 13 17:16:34 did not know where it comes from Aug 13 17:17:44 we now use same fragment mechanism like kernel and busybox Aug 13 17:17:50 for uclibc too Aug 13 17:17:57 yes sounds sane Aug 13 17:18:45 +DEPENDS += "kern-tools-native" Aug 13 17:18:46 +inherit cml1 Aug 13 17:19:06 these should take care of staging this script Aug 13 18:17:13 okay, what do i need to define a virtual? Aug 13 18:17:39 anything more than PROVIDES = "virtual/foo" in the right recipes? Aug 13 18:24:10 mr_science no Aug 13 18:26:18 well, it still builds both jpeg libs Aug 13 18:27:00 if libjpeg-turbo satisfies all the depends, then it shouldn't need jpeg8b, no? Aug 13 18:27:44 mr_science uhm thats solved Aug 13 18:27:55 use libjpeg-turbo as PREFFERED_PROIVIDER Aug 13 18:28:20 doesn't seem to work in -oeclassic... Aug 13 18:28:29 *oe-classic even Aug 13 18:29:05 conf/distro/include/angstrom-core-tweaks.inc:PREFERRED_PROVIDER_jpeg = "libjpeg-turbo" Aug 13 18:29:08 conf/distro/include/angstrom-core-tweaks.inc:PREFERRED_PROVIDER_jpeg-native = "libjpeg-turbo-native" Aug 13 18:29:11 ieehks Aug 13 18:29:14 nobody uses classic Aug 13 18:29:49 still on our original TI (classic) arago fork Aug 13 18:30:07 ieehks Aug 13 18:30:11 old kernel Aug 13 18:30:27 i really need to spend some time adding back our machine support to yocto/oe-core Aug 13 18:30:30 old u-boot Aug 13 18:30:35 still x-loader Aug 13 18:30:55 yup, using TI's omap3 and u-boot forks also Aug 13 18:31:12 khem I am trying now a clean build Aug 13 18:31:19 even TI is not using that any more :) Aug 13 18:31:30 then i get to migrate a bunch of TI recipes into meta-ti... Aug 13 18:31:43 hm meta-ti is old too Aug 13 18:31:47 * woglinde runs Aug 13 18:31:49 yeah, except we bought a dm816X Aug 13 18:31:50 mr_science: everything that is supported is already in meta-ti Aug 13 18:32:04 woglinde: ? Aug 13 18:32:12 denix: you mean omx, syslink, et al Aug 13 18:32:18 ? Aug 13 18:32:32 maybe the job is smaller than i thought... Aug 13 18:32:39 mr_science: no, that's just not supported Aug 13 18:33:43 so does the current meta-ti layer have any of the versions released under the PS stuff for 8168? Aug 13 18:33:52 *PSP even Aug 13 18:34:20 guess i need to check, since i don't have that stuff memorized... Aug 13 18:34:47 denix no update for mesa in master in meta-ti Aug 13 18:34:58 woglinde: what is your problem? I'm tired of the FUD you are spreading! Aug 13 18:35:34 denix I have meta-ti in my layers Aug 13 18:35:38 lastest master Aug 13 18:35:43 and do not works Aug 13 18:35:45 woglinde: http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=3f3f05eea39d0f13bc140747984e202e9288b2fe Aug 13 18:35:51 because mesa is overriden Aug 13 18:35:52 hm Aug 13 18:35:56 woglinde: http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=8fc6ff04ff82daa70b8bf9a92873db2010efa3fe Aug 13 18:36:23 oe-core should stop updating mesa so often... Aug 13 18:36:26 iehks okay Aug 13 18:36:33 wrong checkout still Aug 13 18:36:40 * mr_science votes for an international oe-kegger Aug 13 18:37:30 denix sorry Aug 13 18:40:02 okay, so back to my original question... will a conf/distro/include/angstrom-loca-preferred-providers.inc work in oe-classic? Aug 13 18:40:06 woglinde: I have multiple repos besides meta-ti supporting danny, dylan and master. currently I'm busy with dylan-based release and may not notice breakage in master right away. usually it gets resolved in couple days. you are welcome to send patches if you need it sooner Aug 13 18:40:46 all i see in now are *preferred-versions.inc files Aug 13 18:41:04 denix hm any plans to support newer u-boot and go away from x-loader for beagleboard? Aug 13 18:42:28 woglinde: SPL/MLO - http://git.yoctoproject.org/cgit/cgit.http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-bsp/u-boot/u-boot-beagleboard_2011.09.bbcgi/meta-ti/tree/recipes-bsp/u-boot/u-boot-beagleboard_2011.09.bb Aug 13 18:46:32 woglinde: here's a newer u-boot for beagleboard - http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-bsp/u-boot/u-boot-am37x_2012.04.01.bb Aug 13 18:47:00 woglinde: 2013.xx should work as well, just not tested completely, hence not a default Aug 13 18:47:49 woglinde: are you sure you are using the right meta-ti? I hope you are not stuck on koen's ancient fork... he's not updating it! Aug 13 18:48:11 denix I was Aug 13 18:48:15 I updated now Aug 13 18:48:23 thats why I said sorry Aug 13 18:48:28 koen should delete it Aug 13 18:48:32 heh Aug 13 18:49:06 it's a nice way of discrediting a project! Aug 13 18:51:28 hm uclibc still not works for me out of the box Aug 13 18:54:44 hm ah problem found Aug 13 18:54:55 khem still there? Aug 13 18:55:02 DEPENDS line is overwritten Aug 13 18:55:14 in uclibc-inital Aug 13 18:55:44 and uclibc too Aug 13 19:18:04 well, that was dumb... Aug 13 19:18:55 after messing with all that jpeg provider stuff, it turns out nobody even used libjpeg-turbo since andreas left... Aug 13 19:19:31 grep shows only jpeglib.h in our source trees... **** ENDING LOGGING AT Wed Aug 14 02:59:59 2013