**** BEGIN LOGGING AT Thu Jul 26 02:59:58 2012 Jul 26 08:40:38 heyho Jul 26 08:40:40 JaMa: ping Jul 26 08:42:34 pong Jul 26 08:57:28 JaMa: I pushed my worked related to the new libfsoframework library to the morphis/framework branch Jul 26 08:57:34 I want to merge it soon to master Jul 26 08:57:50 so if you want to start with OE related work for this you can use this as base Jul 26 08:58:20 and as I know some people are using AUTOREV here most things will break for them after merge this Jul 26 08:58:24 s/merge/merging/ Jul 26 08:58:26 morphis meant: and as I know some people are using AUTOREV here most things will break for them after merging this Jul 26 08:59:07 morphis: ah, right I was hoping to do that together with 0.12 release tarballs Jul 26 08:59:22 morphis: as now I would need different recipes for _git and tarball Jul 26 08:59:38 and switching branch would break AUTOREV upgrade path anyway Jul 26 09:00:30 we can lock SRCREV in fso-autorev to revision just before this merge if it's fine for you (and you plan 0.12 release soon) Jul 26 09:01:01 and we can prepare new set of recipes in branch (usable only with AUTOREV for now) Jul 26 09:01:54 yeah that sounds like a good solution Jul 26 09:03:48 ok, let me know when it's merged Jul 26 09:06:45 SHR: 03shr-devel 07buildhistory * r5c7402c858df 10/packages/om_gta04-oe-linux-gnueabi/linux-gta04/ (323 files in 323 dirs): packages: Build 201207260750 of shr 20120726 for machine om-gta04 on opmbuild Jul 26 09:19:27 JaMa: ok Jul 26 09:41:41 SHR: 03Martin.Jansa 07meta-smartphone * ra103b0b2bb82 10/ (2 files in 2 dirs): om-gta02, crespo: bump MACHINE_KERNEL_PR to rebuild with newer kernel.bbclass Jul 26 09:45:39 morphis: btw with next rebuild from scratch I'm thinking about enabling sstate checksums (as signature handler) which will cause a lot more rebuilds Jul 26 09:46:07 morphis: it's default in oe-core/poky/angstrom now and with automatic PR bumps it will be mandatory AFAIK Jul 26 09:52:23 SHR: 03Martin.Jansa 07meta-smartphone * r1d5010a38de3 10/meta-nokia/conf/machine/nokia900.conf: nokia900: bump MACHINE_KERNEL_PR to rebuils with newer kernel.bbclass Jul 26 09:57:38 SHR: 03Martin.Jansa 07meta-smartphone * r8d5f90c98513 10/meta-openmoko/recipes-kernel/linux/linux-openmoko.inc: linux-openmoko: fix postinst for kernel-image Jul 26 10:03:59 SHR: 03shr-devel 07buildhistory * rb498d1825013 10/images/om_gta04/eglibc/shr-image/ (5 files): images: Build 201207261107 of shr 20120726 for machine om-gta04 on opmbuild Jul 26 10:29:47 JaMa: ok Jul 26 11:15:09 freesmartphone.org: 03morphis 07morphis/framework * r79f61416e59c 10cornucopia/libfsoframework/ (16 files in 5 dirs): libfsoframework: integrate sources + tests from libfsotest Jul 26 11:24:01 freesmartphone.org: 03morphis 07morphis/framework * rf5e3f0b4a213 10cornucopia/ (187 files in 24 dirs): Drop standalone version of our libraries; they are all now part of libfsoframework Jul 26 11:24:02 freesmartphone.org: 03morphis 07morphis/framework * r8127fd84fd81 10cornucopia/scripts/list_components.sh: scripts: fix list of components as standalone libraries are gone now Jul 26 11:24:03 freesmartphone.org: 03morphis 07morphis/framework * r2285d85d69ad 10cornucopia/libfsoframework/configure.ac: Jul 26 11:24:03 freesmartphone.org: libfsoframework: bump ABI for all libraries to 3.0.0 Jul 26 11:24:03 freesmartphone.org: We are using the same ABI version for all our libraries for as this make things easier. Jul 26 11:24:03 freesmartphone.org: Maybe we will change that later. Jul 26 11:24:11 JaMa: I will merge the framework changes now Jul 26 11:26:31 ok Jul 26 11:26:51 just doing a quick compile for all components Jul 26 11:27:50 freesmartphone.org: 03morphis 07cornucopia * r3a4b437a38bc 10/Makefile: Update global makefile as some components have moved Jul 26 11:28:20 JaMa: merge is done now Jul 26 11:28:52 SHR: 03Martin.Jansa 07meta-smartphone * r998e065bb2c7 10/meta-fso/conf/distro/include/fso-autorev.inc: meta-fso: fso-autorev: lock FSO_CORNUCOPIA_SRCREV until recipes are updated to cope with new unified fsoframework tree Jul 26 11:29:16 JaMa: last SRCREV with old layout would be 2602366d8db95be55f3389bcfefaec6c96aa641a Jul 26 11:32:45 I'm building new kernels and efl right now.. so tonight or tomorrow I'll enable fso-autorev and start updating recipes in jansa/fso branch Jul 26 11:34:12 great Jul 26 11:34:14 GNUtoo: ping Jul 26 11:34:40 GNUtoo: AUTOREV is broken for all fso components! Jul 26 11:34:59 GNUtoo: and it's up to SHR to fix that and JaMa will do ^^ Jul 26 11:35:28 mrmoku: GNUtoo: what do you think about switching BB_SIGNATURE_HANDLER to OEBasicHash? Jul 26 11:35:42 morphis: no it's not :) it was locked already Jul 26 11:35:52 morphis: so not broken just not really tracking HEAD for now Jul 26 11:36:57 morphis, ok Jul 26 11:37:27 JaMa, what's that already? Jul 26 11:37:48 GNUtoo: ? Jul 26 11:37:57 mrmoku: GNUtoo: what do you think about switching BB_SIGNATURE_HANDLER to OEBasicHash? Jul 26 11:38:13 11:45:50 < JaMa> morphis: btw with next rebuild from scratch I'm thinking about enabling sstate checksums (as signature handler) which will cause a lot more rebuilds Jul 26 11:38:16 11:46:19 < JaMa> morphis: it's default in oe-core/poky/angstrom now and with automatic PR bumps it will be mandatory AFAIK Jul 26 11:38:26 ok Jul 26 11:38:41 I'll eat right now Jul 26 11:39:28 JaMa: great Jul 26 11:40:50 morphis: do you want to keep current packaging? Jul 26 11:41:16 morphis: so that it will build just once, but provide same target packages as before (e.g. fsobasics fsobasics-dev etc.)? Jul 26 11:44:34 yes, so we keep everything as it was before Jul 26 11:44:39 as in detail nothing as changed Jul 26 11:44:45 just the infrastructure Jul 26 11:45:03 and a system doesn't need all libraries Jul 26 11:45:17 on crespo for example we don't need libgsm0710mux Jul 26 11:50:54 ok, I've expected that Jul 26 11:51:04 easier for upgrade path too Jul 26 12:46:21 SHR: 03shr-devel 07buildhistory * r118645623f43 10/images/om_gta02/eglibc/shr-image/ (5 files): images: Build 201207261236 of shr 20120726 for machine om-gta02 on opmbuild Jul 26 12:46:22 SHR: 03shr-devel 07buildhistory * reebf0f1a0c8f 10/packages/ (430 files in 430 dirs): packages: Build 201207261236 of shr 20120726 for machine om-gta02 on opmbuild Jul 26 13:04:36 Hey Guys.. Anybody who has Pre2 and worked with usb tethering? Jul 26 13:05:41 JaMa: btw. is SHR really using fsonetworkd in any way? Jul 26 13:07:43 afaik no Jul 26 13:42:43 kPb_in, pre/pre+/pre2 are not maintained anymore Jul 26 13:43:16 JaMa, when will the sig+hash changes be pushed? Jul 26 13:44:25 GNUtoo: I haven't decided yet.. Jul 26 13:44:42 ok Jul 26 13:44:49 GNUtoo: would be nice to do one more release before that, but I don't know if we're in state for "formal" release Jul 26 13:44:59 ask morphis then Jul 26 13:45:06 GNUtoo: ok.. but anyone did usb tethering? whenever device goes in recovery mode.. my system cant find usb0 (i know its not shr/openmoko related) Jul 26 13:45:16 but it would be better now then after merging new efl and new fso Jul 26 13:45:34 morphis: what do you think about release? ^^ Jul 26 13:46:04 kPb_in, under SHR it was easy to tether, I don't know with webOS, there is a channel for webos: #webos-internals or something like that Jul 26 13:46:21 GNUtoo: and then when I'll rebuild on official buildhost I'll drop finally pre* and would like to switch BB_SIGNATURE_HANDLER as it will take a week again to rebuild it Jul 26 13:46:34 ok Jul 26 13:46:40 note that pre is already dropped in fso Jul 26 13:46:52 GNUtoo: so the system was able to detect usb0 even after the pre2 goes in recovery mode? Jul 26 13:47:00 but you don't use autorev tough Jul 26 13:47:21 GNUtoo: yes it's only populated sysroot I'm talking about Jul 26 13:47:53 JaMa: you mean a SHR release? Jul 26 13:47:54 and next SHR release is also called shr-2012.07 already :) Jul 26 13:47:57 morphis: yup Jul 26 13:48:16 are there any FSO related bugs which aren't closed in master yet? Jul 26 13:48:39 morphis: FSO bugs in SHR master, right? Jul 26 13:48:43 kPb_in, what's recovery mode? Jul 26 13:48:56 JaMa: yes Jul 26 13:49:16 morphis: #1494 Jul 26 13:49:40 GNUtoo: i do "usbmode enable" in pre2 using nova term.. then it reboots.. i hold volume up button.. its goes in recovery mode Jul 26 13:49:43 taken from http://www.shr-project.org/trac/wiki/StagingTests Jul 26 13:50:02 kPb_in, I don't know webos, sorry Jul 26 13:50:19 JaMa: as far as I know that one should be fixed Jul 26 13:50:21 I only got a palm pre with a broken touch Jul 26 13:50:28 and I only made it boot again Jul 26 13:50:35 JaMa: I did a lot work regarding the SMS support in fsogsmd Jul 26 13:50:37 morphis: even in 0.11*? Jul 26 13:50:41 not Jul 26 13:50:43 but then we droped it because it had a kernel too old for systemd Jul 26 13:50:44 s/not/no/ Jul 26 13:50:45 morphis meant: no Jul 26 13:50:52 but I know for sure that ssh over usb0 worked Jul 26 13:50:56 JaMa: I would propose the following Jul 26 13:50:58 morphis: then it's not fixed in SHR master yet Jul 26 13:50:59 that's all I know Jul 26 13:51:04 JaMa: ok Jul 26 13:51:08 I don't know the details Jul 26 13:51:14 and I don't have the palm pre with me Jul 26 13:51:15 JaMa: I do a rc-release of FSO Jul 26 13:51:25 you use this in SHR Jul 26 13:51:29 0.12*? Jul 26 13:51:33 we do another staging step Jul 26 13:51:42 and see if there are bugs left Jul 26 13:51:50 would be the best for both, SHR and FSO Jul 26 13:52:01 0.12-rc1 Jul 26 13:52:03 ok fine with me.. Jul 26 13:52:29 good then I will open a 0.12 branch in the cornucopia repository soon Jul 26 13:52:31 if you don't expect it to be "dangerous" :) Jul 26 13:52:41 :) Jul 26 13:53:27 there is still some work missing for a complete 0.12 like the correct ALSA scenario handling in fsodeviced Jul 26 13:53:38 but I think doing a rc1 release now should be worth Jul 26 13:53:53 I wanted to do release before that so that we can use it in staging for few months after first 0.12 release to test it properly.. but our releases are really just formality so I don't mind either way Jul 26 13:54:24 hm, ok Jul 26 13:55:03 by our I meant SHR releases :) yours are fine :) Jul 26 13:57:54 :) Jul 26 13:58:16 it would be great if SHR releases would be more than a only formal ones Jul 26 13:58:48 yes but for maintaining "stable" branch and stable builds we don't have devs/builders Jul 26 13:59:50 that was my biggest reason for doing just "tags" of staging builds without any maintenance branch behind it to keep it alive Jul 26 14:00:33 with builders you need real hardware? Jul 26 14:00:52 yup hardware and person running builds Jul 26 14:01:04 there is still the amethyst Jul 26 14:01:06 official builder is on limit with just shr-core builds Jul 26 14:01:11 amethyst.openembedded.net Jul 26 14:01:31 we can use it for SHR builds too Jul 26 14:01:48 we should ask mickeyl before but I think he will be fine with this Jul 26 14:01:56 yes but will such stable branch be better then tested staging test image? Jul 26 14:02:05 don't know Jul 26 14:02:16 with more devs probably yes Jul 26 14:02:17 just say with have some hardware available :) Jul 26 14:02:41 for sure Jul 26 14:02:53 but with only few of us there is already quite big gap between offical staging test images/fso-autorev/jansatest branches etc Jul 26 14:53:39 morphis: after BB_SIGNATURE_HANDLER switch it would be better to use ametyst too Jul 26 14:53:51 JaMa: are there any disadvantages with BB_SIGNATURE_HANDLER? Jul 26 14:53:55 JaMa: ok Jul 26 14:54:13 amethyst has Xeon cpu with four cores Jul 26 14:54:14 morphis: because on my desktop I'll be the first to build everything (before pushing it to shr branch) Jul 26 14:54:21 ok Jul 26 14:54:27 morphis: so I won't use SSTATE mirror for my builds Jul 26 14:54:40 and I think 4GB of ram Jul 26 14:54:52 and for my desktop to populate SSTATE mirror for SHR buildhost I don't have fast enough upload Jul 26 14:55:07 yeah, upload is a problem for this Jul 26 14:55:21 so I will ping mickey about SHR use of the amethyst and giving you access there Jul 26 14:55:47 and for SHR buildhost to populate it, it's too slow (most builders can pick those changes from shr branch before SHR buildhost builds them -> so again SSTATE mirror not populated in time) Jul 26 14:56:37 so for best SSTATE experience, I would suggest: Jul 26 14:56:44 1) /me building it without SSTATE Jul 26 14:56:51 2) /me pussing new shr branches Jul 26 14:57:22 3) ametyst building updated shr branches and populating SSTATE mirror for SHR buildhost Jul 26 14:58:01 4) SHR buildhost building official staging build with help of pre populated SSTATE mirror from ametyst and then providing own SSTATE mirror (available to everyone) Jul 26 14:58:17 pushing :))) Jul 26 15:00:44 SHR: 03shr-devel 07buildhistory * r1d7a08e2e078 10/images/nokia900/eglibc/shr-image/ (5 files): images: Build 201207261513 of shr 20120726 for machine nokia900 on opmbuild Jul 26 15:00:47 SHR: 03shr-devel 07buildhistory * re7844ec9b56e 10/packages/ (155 files in 155 dirs): packages: Build 201207261513 of shr 20120726 for machine nokia900 on opmbuild Jul 26 15:01:19 JaMa: sounds ok to me Jul 26 15:01:44 after that we don't need the amethyst anymore right? Jul 26 15:02:32 I would start build there after every shr branch update if possible Jul 26 15:02:41 ok Jul 26 15:02:48 that can we trigger with git hooks I think Jul 26 15:03:05 if we install for example jenkins on the amethyst Jul 26 15:03:06 but if you mean for upload bandwidth then no we can use it only for SHR buildhost (not make sstate mirror public from there) Jul 26 15:03:39 ok Jul 26 15:03:53 morphis: and to answer your disadvantages question Jul 26 15:04:04 we should describe this process somewhere later when it is set up Jul 26 15:04:04 it will force you to rebuild everything when gcc is changed Jul 26 15:04:12 hm Jul 26 15:04:29 are gcc changes often in oe-core? Jul 26 15:04:30 right now I was able to decide that gcc change is important (like 4.6 -> 4.7 upgrade) Jul 26 15:04:47 and rebuild from scratch only in such case Jul 26 15:04:59 now it tracks sstate checksums all way down in dependency tree Jul 26 15:05:24 so if something is changed all checksums above are invalidated and packages rebuilt Jul 26 15:05:58 Last time I've tried that it was changing *a lot* Jul 26 15:06:33 I was even proposing to improve bitbake to ignore changes which had no effect on output packages (which are stored in sstate mirror) Jul 26 15:07:08 because now when someone changes DESCRIPTION then sstate checksum is different and all packages depending on recipe with changed DESCRIPTION are rebuilt too :/ Jul 26 15:07:35 I plan to enable it again on my host for some time and see how bad it goes.. Jul 26 15:08:23 ok, sounds unfinished to me Jul 26 15:08:38 as DESCRIPTION change chould only rebuild the package and not its dependencies Jul 26 15:10:07 agreed Jul 26 15:10:52 what are oe-core developer say to this? Jul 26 15:11:03 is it unclear how to solve this? Jul 26 15:11:20 now it just calculates sstate hashes from metadata and almost any change is considered important Jul 26 15:11:38 I can find my replies on that thread Jul 26 15:11:56 but in short they have fast machines and don't do as many incremental builds as we do Jul 26 15:12:16 hm Jul 26 15:12:25 so they don't really care about this Jul 26 15:13:42 morphis: http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/10225 Jul 26 15:13:45 morphis: yes Jul 26 15:13:45 hm amethyst needs really some love Jul 26 15:19:28 morphis: and it will be worse.. with AUTOPR stuff (which will increment PR with sstate checksum change to "upgrade" it on taget device too) I assume that OEBasicHash will be manatory (unless you would maintain all current PR values yourself manually) Jul 26 15:19:35 ok, to proceed I will check the amethyst and talk with mickey about this so we can use it in the future Jul 26 15:19:46 currently it has a lot of old stuff on it's harddisk Jul 26 15:19:53 ok, thanks Jul 26 15:20:13 * JaMa gtg.. I need to buy new glasse Jul 26 15:20:14 s Jul 26 15:20:16 hm, AUTOPR sounds nice but if it requires sstate stuff it is bad for us Jul 26 15:20:27 JaMa: ok Jul 26 15:20:42 it's not so nice.. because a lot of rebuilds is work for builders Jul 26 15:21:17 and lot of upgrades (with same content, just PR changing) is work for target devices (opkg upgrade) and lot's of bandwith (over wifi/3g/usbnet) Jul 26 15:25:02 ah sister got stuct in subway so I have few more minutes ;) Jul 26 15:26:03 morphis: we can work around those regular updates by using only oe-core releases or also meta-oe releases Jul 26 15:26:23 morphis: that way we would "rebuild from scratch" only about twice a year Jul 26 15:27:18 but also get stuck with some issues for long time (until new release is out) and I don't think that previous releases were perfect already :/ Jul 26 17:33:23 SHR: 03shr-devel 07buildhistory * red9b85778047 10/images/crespo/eglibc/shr-image/ (5 files): images: Build 201207261735 of shr 20120726 for machine crespo on opmbuild Jul 26 17:33:33 SHR: 03shr-devel 07buildhistory * r3438f5e2d272 10/packages/crespo-oe-linux-gnueabi/ (35 files in 35 dirs): packages: Build 201207261735 of shr 20120726 for machine crespo on opmbuild Jul 26 19:55:50 hello, i have a question which does not belong in this channel ! but i know here are a lot of experts. so this is my question: Reading makefile `../../common/Subdirs.gmk' (search path) (no ~ expansion)... this is the last output of a windows build. make was called with -d but it does not bring me further how can i analyse this problem ? Jul 26 22:00:18 freesmartphone.org: 03Martin.Jansa 07cornucopia * r95d66b4c8f3f 10/libfsoframework/tests/fsoresource/Makefile.am: Jul 26 22:00:18 freesmartphone.org: libfsoframework: tests/fsoresource drop fsoframework-2.0 pkg from VALAFLAGS Jul 26 22:00:18 freesmartphone.org: * it's not in requested vapidir anyway Jul 26 22:00:18 freesmartphone.org: Signed-off-by: Martin Jansa Jul 26 22:16:39 freesmartphone.org: 03Martin.Jansa 07cornucopia * rfd7de9d4ad50 10/libfsoframework/tests/fsoresource/Makefile.am: Jul 26 22:16:39 freesmartphone.org: libfsoframework: tests/fsoresource actually revert previous commit and add fsoramework to vapidir Jul 26 22:16:39 freesmartphone.org: * it's needed from fsoresource-2.0.deps Jul 26 22:16:39 freesmartphone.org: Signed-off-by: Martin Jansa Jul 26 22:17:08 SHR: 03shr-devel 07buildhistory * r0714a39c2e29 10/images/crespo/eglibc/chroot-image/ (11 files): images: Build 201207270014 of shr 20120726 for machine crespo on opmbuild Jul 26 22:58:50 SHR: 03shr-devel 07buildhistory * re5ef91a64c45 10/images/crespo/eglibc/shr-image/installed-package-sizes.txt: images: Build 201207270018 of shr 20120726 for machine crespo on opmbuild **** ENDING LOGGING AT Fri Jul 27 02:59:58 2012