**** BEGIN LOGGING AT Wed Nov 30 02:59:57 2011 Nov 30 04:06:53 freesmartphone.org: 03morphis 07cornucopia * r7cda76c3fc80 10/fsodeviced/src/Makefile.am: Nov 30 04:06:53 freesmartphone.org: fsodeviced: remove wrong line from makefile Nov 30 04:06:53 freesmartphone.org: Signed-off-by: Simon Busch Nov 30 04:19:54 freesmartphone.org: 03morphis 07cornucopia * re06d6ddd053e 10/fsodeviced/configure.ac: Nov 30 04:19:54 freesmartphone.org: fsodeviced: remove old makefile from configure.ac Nov 30 04:19:54 freesmartphone.org: Signed-off-by: Simon Busch Nov 30 04:33:17 SHR: 03morphis 07meta-smartphone * r089260f5221f 10/meta-fso/recipes-freesmartphone/freesmartphone/cornucopia.inc: meta-fso: cornucopia: bump SRCREV Nov 30 06:50:12 JaMa: pong Nov 30 06:50:15 GNUtoo: pong Nov 30 06:51:11 zub: no worries... I somehow dropped the idea of an natural e gadget Nov 30 06:51:18 I need it to work without e too Nov 30 06:51:48 would be nice to be able to write gadgets in vala anyway though Nov 30 07:07:30 mrmoku: and I meanwhile resolved the build issues, so maybe one day I build e-wm :) Nov 30 07:07:54 the root of the evil: libtool's .la files :-/ Nov 30 07:11:04 mrmoku: fixed already.. moin :) Nov 30 07:21:03 JaMa|Off: ok :) Nov 30 07:21:30 zub: ok Nov 30 07:26:08 JaMa|Off: how big is the diff between pure oe-core and our shr contrib branch? Nov 30 07:28:19 now better ~ 10 patches Nov 30 07:28:34 with about 8 already in pull request Nov 30 07:28:44 similar for meta-oe Nov 30 07:28:57 JaMa|Off: ok, great Nov 30 07:44:09 yesterday I got elsa partially working... the problem for me was xserver-nodm-init available in Xsession.. Nov 30 07:44:23 so it was trying to start 2nd Xorg while elsa had one already started Nov 30 07:45:26 ok Nov 30 07:48:29 JaMa|Off: for me fsousaged and fsogsmd plain segfault for gta04 now Nov 30 07:48:39 JaMa|Off: and I wonder how rebuilding should be done after a vala bump Nov 30 07:48:44 today's revision? Nov 30 07:48:53 ahh, todays I did not try yet Nov 30 07:48:59 was there some fix? Nov 30 07:49:03 * mrmoku checks Nov 30 07:49:04 morphis bumped cornucopia.. so we get rebuild for free Nov 30 07:49:36 * mrmoku is on autorev Nov 30 07:49:44 * JaMa|Off has small script (originaly written to compare vapi files during build) to rebuild cornucopia stuff Nov 30 07:49:53 so I get a bump for free too as the rev changed Nov 30 07:49:54 but it's a bit dusty now with vapis quite safe Nov 30 07:50:27 it might be something outside of cornucpia repo too Nov 30 07:50:37 like the lib or the vala-bindings Nov 30 07:54:38 ahh some elm API changes were just reverted for greater good layter :/ Nov 30 07:55:07 so with next EFL bump we need to revert our adaptations too :/ Nov 30 07:55:24 or wait for elm-1 :) Nov 30 07:59:54 gah Nov 30 08:01:18 I m configuring D-Link DWA-125 for ARM.... when I insert a USB dongle.... I m getting .... " " Nov 30 08:01:53 but still when I run "iwlist scan" .....I m getting " No scan result" Nov 30 08:02:24 can anyone help why it is not configuring.... Nov 30 08:05:06 snkt: dunno if this is the right channel? Nov 30 08:27:43 SHR: 03Martin.Jansa 07meta-smartphone * r64cfb6aab287 10/meta-shr/recipes-shr/3rdparty/ffalarms_git.bb: ffalarms: bump SRCREV Nov 30 08:34:25 mrmoku: do you have shr-splash.service somewhere? I'm going to push task-shr-systemd pulling all needed services Nov 30 08:35:09 JaMa|Off: I was playing with some other splash instead... Nov 30 08:35:10 moment Nov 30 08:36:04 ah ok.. so I'll skip shr-splash for now Nov 30 08:36:58 JaMa|Off: ahh... dietsplash was it Nov 30 12:06:00 SHR: 03Martin.Jansa 07shr-chroot * r3ec7161fd75e 10/ (1048 files in 44 dirs): system upgrade Nov 30 13:28:38 ping mrmoku Nov 30 13:30:15 pong GNUtoo Nov 30 13:31:16 mrmoku, we should do something like an emergency crisis meeting trough irc or mail Nov 30 13:31:57 basically I can't cope anymore, I'm about to leave Nov 30 13:32:11 first telephony got broken Nov 30 13:32:16 then backlight got broken Nov 30 13:32:20 I read what you wrote... Nov 30 13:32:24 and telephony couldn't be repaired anymore Nov 30 13:32:54 so the big question is: will I be able to continue until december FSOSHRCON Nov 30 13:33:00 personally I don't think I can Nov 30 13:33:11 there is one thing I really don't understand... Nov 30 13:33:24 why don't you keep a working installation as fallback? Nov 30 13:33:40 basically I've my music on microsd Nov 30 13:33:46 and my installation on flash Nov 30 13:33:49 I agree very much that the current situation is not satisfying Nov 30 13:33:57 shr-unstable is dead Nov 30 13:34:00 shr-core is broken Nov 30 13:34:04 that's bad Nov 30 13:34:07 indeed Nov 30 13:34:14 but Nov 30 13:34:17 shr-core is *currently* broken Nov 30 13:34:29 even if shr-unstable would not be dead and working Nov 30 13:34:30 I mean shr-unstable could broke too Nov 30 13:34:45 what I can't cope with is newer breakages Nov 30 13:34:51 so we must find a way to prevent that Nov 30 13:35:07 so I think that some preliminary discussion to FSOSHRCON are necessary Nov 30 13:35:30 the way to prevent that is to switch shr-unstable to be oe-core based too Nov 30 13:35:41 ? Nov 30 13:35:42 and keep that working Nov 30 13:35:51 I don't understand Nov 30 13:35:54 we *need* something that *can* break Nov 30 13:36:00 really? Nov 30 13:36:05 right now our problem is we only have one thing Nov 30 13:36:11 ah ok Nov 30 13:36:14 branches then Nov 30 13:36:20 how do you develop in a team without a common branch which can break? Nov 30 13:36:22 like jama/testing Nov 30 13:36:26 yes Nov 30 13:36:40 jama/testing is even more on the extreme side Nov 30 13:36:52 what about something like jekins+gerrit? Nov 30 13:36:59 ? Nov 30 13:37:09 it's tools for reviewing Nov 30 13:37:11 I know neither Nov 30 13:37:16 * mrmoku googles Nov 30 13:37:17 do we have the manpower to use that? Nov 30 13:37:28 we need a build machine tough Nov 30 13:37:34 a powerfull one Nov 30 13:37:42 ahh... the thing nschlee is using? Nov 30 13:37:49 yes but with gerrit Nov 30 13:37:59 yes Nov 30 13:38:00 basically you push some stuff Nov 30 13:38:05 and it get automatically tested Nov 30 13:38:07 nschle has jenkins and I have account Nov 30 13:38:13 and await for maintainer to ack your patch Nov 30 13:38:15 but that's "build" testing Nov 30 13:38:18 yes Nov 30 13:38:22 we need runtime too Nov 30 13:38:24 nobody will find broken telephony and backlight with that Nov 30 13:38:29 indeed Nov 30 13:38:43 so we need runtime tests? Nov 30 13:38:46 I agree with that having shr-core as only daily phone is *crazy* Nov 30 13:38:47 like unit testing? Nov 30 13:39:01 what are my options? Nov 30 13:39:04 1 partition on uSD with last known version of shr-core or even shr-unstable would be much better Nov 30 13:39:23 nobody says you have to keep only 1 partition with all your music :) Nov 30 13:39:29 basically maybe something like that: Nov 30 13:39:38 one microsd for testing purpose Nov 30 13:39:40 * JaMa|Off has 3 partitions exactly because of this and I'm not even using it as phone.. Nov 30 13:39:47 and the real daily install on NAND Nov 30 13:40:16 problem is that we have shr-t which *should* be stable and usable Nov 30 13:40:26 but nobody is maintaining it Nov 30 13:40:27 or debian? Nov 30 13:40:37 debian seems to have some SHR stuff Nov 30 13:40:39 like fso2 Nov 30 13:40:43 and shr-illume stuff Nov 30 13:40:58 the stuff is one year old tough Nov 30 13:41:12 we have shr-u which *could* be maintaned at least to be usable.. but there are reports that last image is broken and nobody stepped up to fix it and maintain it Nov 30 13:41:25 ok Nov 30 13:41:36 so what should we do for shr-core? Nov 30 13:41:42 if we "branch" shr-core to something more stable (with less ongoing development) then we'll lack testers for shr-core or nobody will maintain it Nov 30 13:41:50 indeed Nov 30 13:42:03 hmm Nov 30 13:42:13 what if we test before building on buildhost? Nov 30 13:42:23 like we build at home Nov 30 13:42:41 does somebody here work on shr/fso integration in debian? Nov 30 13:42:44 I think we don't have enough manpower to maintain more then 1 "mostly used" and 1 "experimental" Nov 30 13:42:50 and then if it's ok we build without autorev(like it's currently done) on the feeds building machine Nov 30 13:43:22 JaMa|Off, I think we should maintain only 1 thing, but the thing could have 2 tags Nov 30 13:43:24 and best scenario would be IMHO to keep "mostly used" now from shr-core and "experimental" in tests/shr-core Nov 30 13:43:28 like a tested tag Nov 30 13:44:00 also we need someone to work on unit testing Nov 30 13:44:00 but we need someone to runtime test those changes in tests/shr-core before I can call sync_core to move it to "mostly used" Nov 30 13:44:12 yes Nov 30 13:44:25 that could be done no? Nov 30 13:44:27 I do a lot of build test before even pushing it to shr branches Nov 30 13:44:36 ok Nov 30 13:44:51 for bigger changes I do also limited runtime tests before pushing to shr branches Nov 30 13:44:58 what about using even more branches? Nov 30 13:45:07 the way JaMa|Off and me use jansa/tests Nov 30 13:45:10 but after that I only do build test on shr buildhost Nov 30 13:45:25 and opkg upgrade test from buildhost feeds Nov 30 13:45:50 no way for me to runtime test it *again* from different feed Nov 30 13:46:25 ok Nov 30 13:46:36 mrmoku: imho more "feeds" should be enough Nov 30 13:46:55 mrmoku: as more branches will cause more fractions of manpower Nov 30 13:47:19 ok Nov 30 13:47:51 let's keep one main branch Nov 30 13:48:10 but could we tag working stuff? Nov 30 13:48:42 so the only thing we change right now is having a second feed that get's synced only when the experimental one is known working? Nov 30 13:49:00 yes that would be a good idea Nov 30 13:49:07 + tags in git Nov 30 13:49:46 mrmoku: yes, second feed or tests/shr-core as we have already Nov 30 13:50:22 mrmoku: only disadvantage is that we cannot "partially" sync Nov 30 13:50:28 JaMa|Off: so only change is to call sync_core only when tests/shr-core is working then Nov 30 13:50:31 yeah Nov 30 13:50:37 that was always the damn thing Nov 30 13:50:54 but better then incompatible feeds from different branches.. Nov 30 13:50:59 you can't just push an important fix when something else is not working Nov 30 13:51:06 and we shouldn't keep tests/shr-core for long.. Nov 30 13:51:28 but if we have enough people testing tests/shr-core we shouldn't miss important bug :) Nov 30 13:51:57 yes we could tell people that we want more stability(PR campaign) and ask for their help Nov 30 13:52:01 I suggest a "stabelize day" to concentrate on bugs to get a working image. Nov 30 13:52:02 I can test personally Nov 30 13:52:13 ok Nov 30 13:52:17 all we need is people like GNUtoo using 2 partitions one from tests/shr-core second from shr-core and some channel to report working tests/shr-core versions and when I get 10 votes for sync I'll sync to shr-core Nov 30 13:52:35 I'll try to use a microsd for testing only Nov 30 13:53:01 only problem is how to provide multiple feeds :/ Nov 30 13:53:06 JaMa|Off: that has one big problem though... until you get those 10 votes you would not be allowed to build anything Nov 30 13:53:09 because tests/shr-core maybe won't be enough Nov 30 13:53:32 yes.. that's problem with tests/shr-core Nov 30 13:53:51 if we do something like shr-core-staging-NN (NN week number) Nov 30 13:53:55 I think the most important is if telephony is working or not Nov 30 13:54:04 then testers have to update /etc/opkg/*feed.conf every week Nov 30 13:54:17 what phones support telephony right now? Nov 30 13:54:21 om-gta02? Nov 30 13:54:24 yes definitely Nov 30 13:54:33 palm pre? no idea Nov 30 13:54:35 JaMa|Off: we could have tests/shr-core as link to the last weekly one Nov 30 13:54:57 mrmoku: and also that we have to "close" the feed before users start testing Nov 30 13:55:10 close? Nov 30 13:55:30 mrmoku: so probably make sync_core sync to shr-core-staging-NN till end of week and then start new week while users are allowed to test previous week Nov 30 13:55:55 mrmoku: I mean that after everybuild I have to sync_core somewhere Nov 30 13:56:27 ok Nov 30 13:56:44 and somewhere needs to be different with every sync (lot of space) or stash it to same dir for whole week and then move to new dir Nov 30 13:57:17 a weekly quick test if telephony works and the thing boots sould be doable for me too Nov 30 13:57:46 and is week short enough to get fixes to main feed? Nov 30 13:57:55 it would be with enough testers.. but.. Nov 30 13:58:12 hmmm so pratically speaking I would use the shr-feeds daily Nov 30 13:58:16 and test what I build? Nov 30 13:58:19 of course after sync to main feed we can drop older weekly feeds Nov 30 13:58:56 and drop unsynced weeklys after some two or three weeks Nov 30 13:59:04 practically speaking it would be week old feed Nov 30 13:59:54 ok Nov 30 14:00:02 so I would use one week old feed, nice Nov 30 14:00:08 maybe I'll start with new feed for every sync and then we'll change it to weekly feeds? Nov 30 14:00:11 and build lastest stuff locally and test that Nov 30 14:00:13 GNUtoo: the problem with 'test what you build' is that it is not what will be synced Nov 30 14:00:16 as it's a lot easier :) Nov 30 14:00:31 mrmoku, ? Nov 30 14:00:38 * JaMa|Off is finishing a big upgrade on buildhost :) Nov 30 14:00:55 let's name it -staging-001 :) Nov 30 14:00:59 GNUtoo: your home-built stuff might be different to what shr-staging feed has Nov 30 14:01:00 or someone with better name? Nov 30 14:01:18 mrmoku, yes but why exactly? Nov 30 14:01:23 and then sync to shr-ripe :P Nov 30 14:01:42 because at home you'll get always latest not week old Nov 30 14:01:54 and to be clear this is only about runtime testing Nov 30 14:01:59 yes Nov 30 14:02:06 but I tought about doing that: Nov 30 14:02:18 build errors etc are fixed/tested only on shr branch Nov 30 14:02:18 I build lastest with autorev shr+fso Nov 30 14:02:20 I test that Nov 30 14:02:23 I tag that Nov 30 14:02:34 you can't tag that Nov 30 14:02:36 (autorev) Nov 30 14:03:18 then I bump srcrev in FSO_AUTOREV etc... instead and tag the meta-* repos Nov 30 14:04:05 a) test Nov 30 14:04:17 b) bump srcrevs to what you tested if it worked Nov 30 14:04:18 c) tag Nov 30 14:04:24 yes Nov 30 14:04:25 that Nov 30 14:04:55 since shr buildhost doesn't use autorev....it can work Nov 30 14:05:45 mrmoku: I'll add 2 scripts to buildhost (.bashrc) 1) shr_core_staging_new which will prepare new staging dir, update shr-core-staging to previous one and set where sync_core is syncing 2) shr_core_staging_sync NN which moves NN staging dir to main shr-core feeds Nov 30 14:06:00 we're using autorev ie for shr-autorev.inc.. Nov 30 14:06:05 I didn't understand well the staging stuff Nov 30 14:06:21 does it get sync automatically every week? Nov 30 14:06:25 no Nov 30 14:06:34 only if enough testers tested and proved it working Nov 30 14:06:35 so it require testing right? Nov 30 14:06:41 ok nice Nov 30 14:06:42 yup Nov 30 14:06:53 mrmoku: and the script should create info file with built revisions in staging dir.. instead of tagging all oe repos.. Nov 30 14:07:02 JaMa|Off: very good Nov 30 14:07:49 next we need wiki page with links to staging dirs and allowing users to vote for tested staging dirs.. Nov 30 14:07:54 don't forget to dokument that and post on website for newbies (like me). Nov 30 14:07:57 or something better then wiki Nov 30 14:08:16 dunno if lots of tags are welcome in oe repos anyway... Nov 30 14:09:04 GNUtoo: manual creation of "staging" feeds will be probably better as I know if there is something which needs separate testing when calling "make update" on buildhost Nov 30 14:09:45 ok Nov 30 14:09:49 and I can separate changes like staging after efl bump, staging after fso bump.. Nov 30 14:10:09 right that would be good to separate changes Nov 30 14:11:13 now I have to finish something at dayjob, but I hope to create scripts and first staging dir tonight.. I'll send info about it to list too (I hope) Nov 30 14:11:23 ok nice!!! Nov 30 14:11:28 thanks a lot!!! Nov 30 14:11:37 someone with wiki skills is welcome to prepare some wiki for it.. Nov 30 14:12:41 by the way, is shr using something like yocto stable or oe bleeding edge? Nov 30 14:13:52 ok I've wiki skills Nov 30 14:14:01 give me some minutes Nov 30 14:14:10 (be back in some minutes) Nov 30 14:14:12 karl882: something in between :) Nov 30 14:14:43 ok Nov 30 14:15:06 mrmoku: isn't it newer then bleeding edge? :) Nov 30 14:15:17 as core we have a shr branch in the oe-core-contrib repo Nov 30 14:15:48 JaMa|Off: dunno if master of contrib would make us bleed even more ;) Nov 30 14:17:41 sometimes yes Nov 30 14:17:50 but usually we have newer stuff :) Nov 30 14:18:02 ie to keep master from bleeding.. :) Nov 30 14:18:15 mrmoku: shr-core-staging or just shr-latest? Nov 30 14:18:49 and shr-latest link to shr-core-NNN Nov 30 14:19:21 or shr-core-staging/latest link to shr-core-staging/001 Nov 30 14:20:45 later if this works good we should develop something more effective like "partial" feeds and users only adding newer and newer feeds to /etc/opkg Nov 30 14:20:58 so we don't need to keep always whole feed Nov 30 14:22:38 JaMa|Off: shr-core-staging is fine for me Nov 30 14:24:22 hmm problem with revision info is that I do rebase shr often.. so not very reproducible.. :/ Nov 30 14:25:19 hmmm Nov 30 14:26:08 JaMa|Off: keep a branch before rebasing? Nov 30 14:26:45 JaMa|Off: I mean... let the staging script create a branch too Nov 30 14:26:57 hmm Nov 30 14:27:00 does not work Nov 30 14:30:31 is previous than rebase info keep in reflog? Nov 30 14:51:13 good morning people Nov 30 14:55:04 GNUtoo: reflog yes Nov 30 14:55:29 GNUtoo: but locally you maybe never had the revisions from info file.. Nov 30 15:26:55 GNUtoo: ok, rebuilding all cornucopia, vala-dbus-bindings, libfso-glib and fso-specs did fix fsouasaged and fsogsmd segfaults Nov 30 15:27:12 and on gta04 fsogsmd can open the modem Nov 30 15:27:40 maybe I should trigger a gta02 build now... wanted to see systemd in action on gta02 anyway :) Nov 30 15:28:42 be carefull without networking and elsa.. Nov 30 15:29:05 ohh Nov 30 15:29:08 right you are Nov 30 15:29:14 should fix ssh first .P Nov 30 15:29:27 * mrmoku got used to the nice serial console on gta04 :) Nov 30 15:30:29 * JaMa|Off didn't touch daywork today, but staging scripts are almost ready for review :) Nov 30 15:31:12 hehe :) Nov 30 15:33:42 ok Nov 30 15:34:01 JaMa|Off: the problem with ssh is that the keys don't get generated Nov 30 15:34:02 Also=sshdgenkeys.service Nov 30 15:34:07 is what sshd.socket has Nov 30 15:34:25 which should cause it to be installed together with sshd.socket Nov 30 15:34:37 and that one is the SYSTEMD_SERVICE Nov 30 15:34:40 and get's installed Nov 30 15:34:45 but the genkeys not Nov 30 15:34:47 hmm Nov 30 15:35:12 * mrmoku wonders if maybe OE does the linking itself and disrespects 'Also' Nov 30 15:35:15 there is also a backlight issue Nov 30 15:35:24 is there some SHR script to look after? Nov 30 15:35:30 s/script/config file/ Nov 30 15:35:31 GNUtoo meant: is there some SHR config file to look after? Nov 30 15:35:38 for backlight? Nov 30 15:35:41 yes Nov 30 15:35:43 let me reflash Nov 30 15:35:52 there's phonefsod.conf which has diming config Nov 30 15:36:08 the backlight as on at boot time and then goes off? Nov 30 15:36:14 s/as/is/ Nov 30 15:36:15 mrmoku meant: the backlight is on at boot time and then goes off? Nov 30 15:36:19 yes Nov 30 15:36:24 but never comes up again Nov 30 15:36:33 ok Nov 30 15:36:44 what does fsodeviced.log say let me reflash first Nov 30 15:36:57 it should have some idle state logging.. Nov 30 15:36:58 yeah, ok Nov 30 15:51:01 someone please review this .... Nov 30 15:51:10 SHR: 03Martin.Jansa 07shr-chroot * r8e202f6e934a 10/OE/ (7 files in 2 dirs): bashrc update and staging scripts to allow multiple testing feeds Nov 30 15:51:34 I don't use shr-chroot sorry Nov 30 15:51:46 JaMa|Off: ok, has to wait a bit for my build though Nov 30 15:52:10 mrmoku: sure, np Nov 30 15:53:43 mrmoku: ah found issue already.. `cat /OE/shr-core/.staging_dir` cannot be in .bashrc :) Nov 30 15:53:46 what should I do on the wiki exactly? Nov 30 15:57:10 bbiab Nov 30 15:59:10 SHR: 03Martin.Jansa 07shr-chroot * re29b90a97e64 10/OE/ (.bashrc bin/sync_core.sh): bashrc: move sync_core to separate script as cat CURRENT_STAGING_FILE won't work from .bashrc Nov 30 16:01:10 with my last image it seem that backlight comes back right after beeing off Nov 30 16:01:37 basically: Nov 30 16:01:44 backlight on in boot Nov 30 16:02:04 backlight off just before shr-wizard Nov 30 16:02:11 then I pass the wizard Nov 30 16:02:18 then backlight off right after the wizard Nov 30 16:02:22 and backlight on again Nov 30 16:02:34 s/shr-wizard/illume-wizard/ Nov 30 16:03:39 SHR: 03Martin.Jansa 07shr-chroot * r3ed571adc43f 10/OE/bin/shr_sync.sh: shr_sync.sh: check that IMG_FILE exists before calling md5sum (it can be ie '*/*.bin') Nov 30 16:03:45 GNUtoo: here is first staging feed http://build.shr-project.org/shr-core-staging/ Nov 30 16:03:51 ok Nov 30 16:03:57 then let's fix the telephony Nov 30 16:04:21 JaMa|Off, I didn't understand what staging means, is it the stable or unstable feed? Nov 30 16:04:26 latest points to not really latest (highest number) but one smaller Nov 30 16:04:44 GNUtoo: it's "testing" feed Nov 30 16:04:49 ok nice Nov 30 16:04:52 so it's the most stable one Nov 30 16:05:17 stored there for testers and when it's confirmed as working it's moved from "staging" area to public feed (shr-core) Nov 30 16:05:28 no most stable will be shr-core Nov 30 16:05:37 and that's where /etc/opkg/ files are pointing Nov 30 16:06:04 ok Nov 30 16:06:17 so tester should change /etc/opkg/*-feed.conf to point to shr-core-staging/latest instead of shr-core/ Nov 30 16:06:54 then download shr-core-staging/latest/info.end and begin testing Nov 30 16:10:12 which will look like this http://build.shr-project.org/shr-core-staging/001/info.begin Nov 30 16:12:09 ok Nov 30 16:22:26 * JaMa|Off gtg.. Nov 30 16:23:01 SHR: 03Martin.Jansa 07shr-chroot * r59073ea8be2b 10/OE/bin/ (5 files): shr scripts: refactor common settings to shr_core_header and add make update wrapper to keep updates also in info files Nov 30 16:26:00 I cannot work without the devshell Nov 30 16:26:11 I'm spending a lot of time trying to oe_runconf Nov 30 16:26:20 and it doesn't want to runconf and ask for distclean Nov 30 16:26:58 of course distclean fails Nov 30 16:26:59 make: *** No rule to make target `distclean'. Stop. Nov 30 16:27:08 and autogen.sh on host fails: Nov 30 16:27:13 configure: error: Vala 0.12.1 not found. Nov 30 16:31:52 freesmartphone.org: 03angelo 07settings-rework * r82bdaaaad09d 10aurora/aurora-daemon/src/applications/app-settings/ (7 files in 4 dirs): aurora-daemon: rework delegates Nov 30 16:31:53 freesmartphone.org: 03angelo 07settings-rework * ref6a3f0f456f 10aurora/aurora-daemon/src/applications/app-settings/ (4 files in 4 dirs): aurora-daemon: add sliderField to delegates Nov 30 16:31:55 freesmartphone.org: 03angelo 07settings-rework * r180ae7933b93 10aurora/aurora-daemon/src/applications/app-settings/ (8 files in 4 dirs): aurora-daemon: start returning values by delegates Nov 30 16:32:46 help! Nov 30 16:32:55 I cannot work without that devshell Nov 30 16:33:03 how do you work without it? Nov 30 16:33:10 I mean do you push without testing? Nov 30 16:33:24 how to cross compile a particular version? Nov 30 16:33:29 like a particular hash? Nov 30 16:33:36 ok I'll use oe Nov 30 16:33:42 but GRRRRR Nov 30 16:46:34 ah sorry I had packages un-upgraded, so maybe the backlight problem is still there Nov 30 16:47:09 GNUtoo: local builds is what I do Nov 30 16:48:25 GNUtoo: INHERIT_append_pn-fsodeviced = "srctree gitpkgv" Nov 30 16:48:25 SRCREV_pn-fsodeviced = "${GITSHA}" Nov 30 16:48:25 S_pn-fsodeviced = "/OE/source/cornucopia/${PN}" Nov 30 16:48:34 into the local.conf Nov 30 16:48:42 ok Nov 30 16:48:50 and make S_pn point to your checkout of the project Nov 30 16:48:57 heyho Nov 30 16:49:02 yo morphis Nov 30 16:49:07 GNUtoo: I got your lines last night Nov 30 16:49:13 and I found the cause for the bug Nov 30 16:49:27 which one? Nov 30 16:49:29 I will fix it in the next minutes Nov 30 16:49:32 we have lots of bugs :P Nov 30 16:49:40 that lowlevel_openmoko does not work Nov 30 16:49:44 ahh great Nov 30 16:49:55 it's about call-by-value/call-by-reference Nov 30 16:50:04 structs are per se call-by-value in C# Nov 30 16:50:08 and in vala too Nov 30 16:50:11 ok Nov 30 16:50:16 but it wasn't implemented correctly Nov 30 16:50:22 I was about to compare .c files Nov 30 16:50:24 so it was no problem until 0.14.0 Nov 30 16:50:24 and that changed with latest vala? Nov 30 16:50:28 ok Nov 30 16:50:30 yes Nov 30 16:50:41 I know how to fix but I need to talk to the vala guys Nov 30 16:50:52 good Nov 30 16:50:53 as this introduces a lot of maybe-bugs in our code Nov 30 16:50:55 thanks a lot Nov 30 16:51:00 as it does something like this: Nov 30 16:51:05 I'll opkg upgrade to see if the backlight breaks again Nov 30 16:51:08 struct termios t; Nov 30 16:51:12 struct termios t2; Nov 30 16:51:15 t2 = t; Nov 30 16:51:20 tcgetattr(&t2); Nov 30 16:51:25 and then it works with t Nov 30 16:51:32 ouch Nov 30 16:52:25 yes Nov 30 16:52:38 it is how dealing with structs work in modern languages Nov 30 16:52:42 it's the same of C# Nov 30 16:52:55 you need something like this tcgetattr(ref termios t); Nov 30 16:53:03 and then call it with tcgetattr(ref t); Nov 30 16:53:15 GNUtoo: and I wrote to broonie Nov 30 16:53:18 yes indeed because theses t are not pointers to structs Nov 30 16:53:21 morphis, yes I saw Nov 30 16:53:22 yes Nov 30 16:53:30 but I am unsure how we have to deal with this Nov 30 16:53:40 it means we need to write our bindings more careful in the future Nov 30 16:53:58 I know currently about two structures which causes problems Nov 30 16:54:04 struct termios and struct fd_set Nov 30 16:57:07 hey ho morphis! Nov 30 16:57:24 yes the backlight issue came back Nov 30 16:58:13 angelox|laptop: heyho Nov 30 16:58:15 GNUtoo: backlight? Nov 30 17:02:44 morphis: i'll have more time to code aurora after next week,since my vacation will start,is it ok if i code less/don't code until there? Nov 30 17:03:03 angelox|laptop: yes it's your choice :) Nov 30 17:03:15 angelox|laptop: I think we can't release next month anyway Nov 30 17:03:20 it's too much work left Nov 30 17:03:46 JaMa|Off: | cmake: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Nov 30 17:03:49 :) Nov 30 17:03:53 anyway... dinner first Nov 30 17:03:54 morphis: i see :\ Nov 30 17:04:07 morphis: maybe in january.. Nov 30 17:05:44 ls Nov 30 17:05:45 ops Nov 30 17:05:46 sorry Nov 30 17:05:48 ;) Nov 30 17:06:18 mrmoku: you need touch? :) Nov 30 17:06:19 angelox|laptop: I hope so Nov 30 17:06:54 mrmoku: I have few more ideas for staging.. ping me after dinner Nov 30 17:11:17 *burp* first work day tomorrow: a day off (at work) ;-P Nov 30 17:11:57 starting a job with a holiday, nice :-D Nov 30 17:16:38 GNUtoo: the bug is fixed now, fsogsmd is working on my om-gta02 again Nov 30 17:17:20 GNUtoo: I will cleanup and then push the relevant parts Nov 30 17:17:26 ok nice Nov 30 17:17:28 thanks a lot Nov 30 17:17:30 now backlight Nov 30 17:17:35 I was preparing the wiki Nov 30 17:22:43 would something like that be ok: http://www.shr-project.org/trac/wiki/Stabilizing Nov 30 17:25:17 to track working/non-working versions? Nov 30 17:26:26 GNUtoo: what I need is table with testing feeds numbers from info files and testers to mark them as tested or adding links to bugreports which needs to be closed before sync Nov 30 17:27:03 GNUtoo: endusers "testers" usually don't know exact revisions which were used when they did opkg upgrade Nov 30 17:27:13 GNUtoo: but you can keep this too if you find it usefull too Nov 30 17:28:48 one for builder and one for end user then Nov 30 17:29:08 freesmartphone.org: 03morphis 07cornucopia * r24e3fa10feea 10/libfsotransport/fsotransport/basetransport.vala: Nov 30 17:29:08 freesmartphone.org: libfsotransport: adjust for changes to posix vala binding which needs reference parameters now Nov 30 17:29:08 freesmartphone.org: This fixes bug #658 Nov 30 17:29:08 freesmartphone.org: Signed-off-by: Simon Busch Nov 30 17:29:13 that's exactly what I realized when I was away from keyboard 2s ago Nov 30 17:30:44 morphis, we decided something for SHR when you were offline Nov 30 17:30:52 GNUtoo: what? Nov 30 17:30:59 SHR: 03morphis 07meta-smartphone * rfffd4c9ecf02 10/meta-fso/recipes-devtools/vala/ (vala_0.14.0.6-68e8.bb vala_0.14.1.7-3673f.bb): meta-fso: vala: update to version 0.14.1.7-3673f Nov 30 17:31:09 SHR: 03morphis 07meta-smartphone * r519c4b8d7bcb 10/meta-fso/recipes-freesmartphone/freesmartphone/cornucopia.inc: meta-fso: cornucopia: bump SRCREV Nov 30 17:31:10 basically we will have a staging area that users will test, and once it's confirmed working we sync with main feeds Nov 30 17:31:31 GNUtoo: very good idea Nov 30 17:31:38 I thought about something similar already Nov 30 17:31:51 ok Nov 30 17:32:47 but I like the idea Nov 30 17:33:09 GNUtoo: can you check if the lowlevel_openmoko bug is fixed for you too? Nov 30 17:34:21 ok Nov 30 17:34:28 I'll build right now Nov 30 17:34:40 JaMa: touch is always good :) Nov 30 17:34:55 JaMa: dinner finished... it's my turn to bring the little one to bed though Nov 30 17:35:13 * mrmoku still needs some time Nov 30 17:36:20 btw is there some git pull --force ? Nov 30 17:36:35 because I often get conflicts Nov 30 17:38:38 mrmoku: I'm halfway finished with "make changelog" :) Nov 30 17:38:42 I meant better than git pull -f Nov 30 17:42:09 GNUtoo: git pull --rebase Nov 30 17:45:51 mickeyl: ping Nov 30 17:48:38 morphis: btw,why can't i see e.g. checkboxes,sliders ? Nov 30 17:48:59 angelox|laptop: what do mean with "can't see"? Nov 30 17:49:06 are they not visible when you use them? Nov 30 17:49:12 yes,exactly Nov 30 17:49:43 hm Nov 30 17:50:09 angelox|laptop: take a look here: http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qml-checkbox.html Nov 30 17:50:56 i'm not sure if it is the syntax Nov 30 17:51:03 i get sth like: DEBUG: Checking for file /opt/fso/usr/share/aurora/themes/default/qtg_graf_checkbox_disabled_unselected.svg ... Nov 30 17:51:04 file:///usr/lib/qt/imports/Aurora/Components/CheckBox.qml:132:5: QML Image: Failed to get image from provider: image://theme/qtg_graf_checkbox_disabled_unselected Nov 30 17:51:11 but the file is there Nov 30 17:51:52 hm Nov 30 17:52:16 can you show me the full output? Nov 30 17:53:01 sure,just one minute Nov 30 17:55:01 http://pastebin.com/s2LK3QKQ Nov 30 17:55:14 morphis: ^ Nov 30 17:56:13 freesmartphone.org: 03morphis 07cornucopia * r25e38610c9c8 10/fsousaged/src/plugins/lowlevel_android/plugin.vala: Nov 30 17:56:13 freesmartphone.org: fsousaged: lowlevel_android: adjust for changes to posix.vapi in latest vala version Nov 30 17:56:13 freesmartphone.org: Signed-off-by: Simon Busch Nov 30 17:59:03 angelox|laptop: for me it looks like this: http://pastebin.com/ikp6V2b8 Nov 30 17:59:15 can you try to merge recent changes of master branch in your branch? Nov 30 17:59:42 i'm running aurora from master Nov 30 18:02:22 i'll try recompile all stuff again Nov 30 18:03:49 you specified a different datadir with configure? Nov 30 18:04:52 yes,i did Nov 30 18:05:22 my config was: ./configure --prefix=/opt/fso/usr --sysconfdir=/opt/fso/etc --datarootdir=/opt/fso/usr/share --datadir=/opt/fso/usr/share --enable-debug Nov 30 18:05:55 hm Nov 30 18:06:06 can you show me a "ls /opt/fso/usr/share" Nov 30 18:06:25 [angelo@mlinux aurora-daemon]$ ls /opt/fso/usr/share/ Nov 30 18:06:25 aclocal aurora devhelp freesmartphone fsodatad man pkgconfig vala Nov 30 18:06:25 [angelo@mlinux aurora-daemon]$ Nov 30 18:06:54 and a ls /opt/fso/usr/share/aurora Nov 30 18:06:59 but maybe better Nov 30 18:07:05 a find /opt/fso/usr/share/aurora Nov 30 18:07:47 morphis: http://pastebin.com/EZUYrWBE Nov 30 18:08:39 all the *.svg files should be in /opt/fso/usr/share/aurora/themes/default/widgets Nov 30 18:08:50 there is something wrong with you configure line Nov 30 18:09:22 ah no,that was an test i did,i just copied from that to ../ Nov 30 18:09:40 no Nov 30 18:09:49 they should be in widgets Nov 30 18:09:58 remove your /opt/fso/usr/share/aurora Nov 30 18:10:00 and install again Nov 30 18:10:04 ok Nov 30 18:11:39 * angelox|laptop is just making whole stuff again from master :D Nov 30 18:18:13 freesmartphone.org: 03morphis 07cornucopia * rd888ccf64d7d 10/fsousaged/src/plugins/lowlevel_kernel26_staysalive/plugin.vala: Nov 30 18:18:13 freesmartphone.org: fsousaged: lowlevel_kernel26_staysalive: adjust for changes to posix.vapi in latest vala versio Nov 30 18:18:13 freesmartphone.org: Signed-off-by: Simon Busch Nov 30 18:18:49 morphis: still not working Nov 30 18:24:00 angelox|laptop: hm Nov 30 18:24:31 should i try to install in /usr/local? Nov 30 18:24:37 the images are now in /opt/fso/usr/share/aurora/themes/default/widgets and not in /opt/fso/usr/share/aurora/themes/default/ ? Nov 30 18:24:40 you can Nov 30 18:25:28 yes,they are Nov 30 18:37:35 morphis, ok thanks Nov 30 18:38:39 now does somebody has an idea for the backlight? Nov 30 18:38:43 should I try that: Nov 30 18:38:58 reflash and try to upgrade each package individually Nov 30 18:39:45 morphis: tried in /usr/local; no effect Nov 30 18:41:36 JaMa: ok, done Nov 30 18:41:37 * angelox|laptop will try to compile in some other where Nov 30 18:41:46 2011-11-27T21:17:31.691130Z [INFO] libfsotransport <0710:4>: URC: [ "AT-Command Interpreter ready" ] Nov 30 18:41:46 2011-11-27T21:17:32.882107Z [INFO] fsogsmd : received signal -11, exiting. Nov 30 18:41:57 so it's fixed but we have another problem Nov 30 18:42:11 I'll reflash to see Nov 30 18:44:10 http://www.pastie.org/2945354 Nov 30 18:44:15 morphis, ^^^ Nov 30 18:45:18 2011-11-27T21:18:15.436742Z [ERROR] DBusServiceResource : Could not register GSM with ousaged: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus); trying to enable the resource unconditionally Nov 30 18:45:24 GNUtoo: that looks like the problem I had Nov 30 18:46:12 did you rebuild all related stuff outside of cornucopia too? Nov 30 18:46:28 like the binding-tool and after that fso-specs? Nov 30 18:47:07 no Nov 30 18:47:11 I just did: Nov 30 18:47:15 bitbake -k shr-lite-image Nov 30 18:47:26 should I cleansstate and build in a particular order? Nov 30 18:48:08 what should I do for the segfault? gdb+gdbserver? Nov 30 18:48:17 or should I look into the backlight Nov 30 18:48:36 mrmoku: I'm was trying to write usable changelog from rebased git repo in Makefile.. but seems too difficult so I'm moving it from Makefile to extra bash script Nov 30 18:49:32 GNUtoo: bb -c cleansstate vala-dbus-binding-tool vala-dbus-binding-tool-native libfso-glib Nov 30 18:49:57 GNUtoo: + fso-specs Nov 30 18:50:20 ok Nov 30 18:50:30 and whole cornucopia needs rebuilding Nov 30 18:50:52 if you're on autorev and did not build after the commit from 19:14 then that should happen automatically Nov 30 18:51:06 yes but I jsut built Nov 30 18:51:08 JaMa: yeah... Makefile is hitting limits fast Nov 30 18:51:29 GNUtoo: ok, then you probably should cleansstate those too Nov 30 18:52:22 thoses beeing cornucopia? Nov 30 18:52:39 ok I'll try to generate cornucopia clean from the autorev filr Nov 30 18:52:42 *file Nov 30 18:52:55 GNUtoo: yeah, cornucopia Nov 30 18:56:44 hmmm bad idea that doesn't output fsogsmd for instance Nov 30 18:56:50 let me try something else Nov 30 18:57:51 JaMa: trying to understand your scripts :) Nov 30 18:57:58 I do cleansstate -b in meta-freesmartphone/freesmartphone/*.bb Nov 30 18:58:27 GNUtoo: missing a recipes-fso Nov 30 18:59:03 ok Nov 30 18:59:05 we should write a bb_rebuild_dependers Nov 30 19:01:00 JaMa: ln -sf ${OLD} ${STAGING_DIR}/latest Nov 30 19:01:09 shouldn't that be ${NEW} instead? Nov 30 19:01:29 mrmoku, where is that recipe-fso? Nov 30 19:02:33 GNUtoo: meta-freesmartphone/meta-fso/recipes-freesmartphone/*.bb Nov 30 19:02:47 err Nov 30 19:02:52 GNUtoo: meta-freesmartphone/meta-fso/recipes-freesmartphone/freesmartphone/*.bb Nov 30 19:03:08 meta-smartphone Nov 30 19:03:13 and that's what I did Nov 30 19:03:35 ah ok I spelled it badly Nov 30 19:03:36 sorry Nov 30 19:04:02 ( for x in $(ls ../repos/meta-smartphone/meta-fso/recipes-freesmartphone/freesmartphone/*.bb) ; do bitbake -c cleansstate -b $x; done ) Nov 30 19:04:44 :) Nov 30 19:06:48 mrmoku: no OLD is right Nov 30 19:07:14 mrmoku: because by this script you're releasing OLD for testers and creating new NEW for builds Nov 30 19:07:36 mrmoku: so the latest is "latest-1" Nov 30 19:08:03 JaMa: yeah, getting closer to understanding :) Nov 30 19:10:47 JaMa: without trying... looks good to me Nov 30 19:12:10 ok thanks, next will be make changelog :) Nov 30 19:12:34 and I also have to rename info files to info.NN so we can sync them all to public feeds Nov 30 19:13:00 but that I'll do after writing changelog to them during make update Nov 30 19:13:37 JaMa: regarding sshd and systemd... systemd.class is using systemctl to enable the services Nov 30 19:13:48 so I don't understand why it does not work Nov 30 19:14:00 if not systemctl does not work correctly when given a --root Nov 30 19:15:03 mrmoku: http://paste.debian.net/147610/ Nov 30 19:15:25 it does not work only on first boot? Nov 30 19:15:41 very nice :) Nov 30 19:15:45 and if you do systemctl enable opensshd.service after first boot it works? Nov 30 19:16:00 no, it does not work until I manually start that service once Nov 30 19:16:39 root@om-gta04:/etc/opkg# systemctl enable sshdgenkeys.service Nov 30 19:16:39 ln -s '/lib/systemd/system/sshdgenkeys.service' '/etc/systemd/system/multi-user.target.wants/sshdgenkeys.service' Nov 30 19:16:59 I'm not even sure we want that as a service... Nov 30 19:17:16 shouldn't sshdgenkeys.service be WantedBy=opensshd.service? Nov 30 19:17:33 not by multi-user.target Nov 30 19:17:43 no Nov 30 19:17:56 sshd.socket that is Nov 30 19:18:20 and sshd is WantedBy=sockets.target Nov 30 19:19:07 hmm... I took those from my arch systemd services... maybe I should check if there's something upstream already Nov 30 19:19:22 | No package 'dbus-1' found Nov 30 19:19:23 hmmm Nov 30 19:19:32 gconf-native-3.2.3-r2: Nov 30 19:19:53 gah... cvs Nov 30 19:21:18 hmm... does not look like Nov 30 19:21:34 JaMa: there is sshd.service and sshd.socket on my laptop Nov 30 19:21:42 you can choose which one fits better Nov 30 19:21:52 for embedded use it's socket for sure Nov 30 19:22:06 for high access ssh servers it's the service Nov 30 19:22:29 both need the keys to be generated Nov 30 19:24:12 brb Nov 30 19:27:05 GNUtoo: with which configuration does that happen? Nov 30 19:28:41 GNUtoo: if you want to discard old commits, instead of pull, do fetch and reset Nov 30 19:29:21 morphis, I just cleaned cornucopia and it happens with that Nov 30 19:29:47 hm Nov 30 19:29:48 mrmoku: did you check actual ssh upstream (not likely ever to see Linuxy stuff such as systemd units), or the portable variant?... Nov 30 19:30:07 GNUtoo: what does "cleaned cornucopia" mean in detail? Nov 30 19:30:11 GNUtoo: rebuild with OE? Nov 30 19:30:22 no Nov 30 19:30:29 for x in $(ls ../repos/meta-smartphone/meta-fso/recipes-freesmartphone/freesmartphone/*.bb) ; do bitbake -c cleansstate -b $x; done Nov 30 19:32:36 mrmoku: isn't the same problem in dropbear? Nov 30 19:32:50 mrmoku: dropbear works here somehow and I've seen keys generation in log too Nov 30 19:33:54 GNUtoo: ok Nov 30 19:34:05 SRCREV bump should be the same Nov 30 19:34:17 but my new image will be ready in some minutes Nov 30 19:34:41 mrmoku, any idea for the dbus problem? Nov 30 19:34:55 mrmoku: ah it's not blacklisted.. so probably it was from sysvinit script.. Nov 30 19:36:35 how can I know which provides the dbus-1.pc ? Nov 30 19:36:42 *which recipe Nov 30 19:36:49 maybe dbus? Nov 30 19:37:20 I'll cleansstate dbus + rebuild it Nov 30 19:38:13 antrik: I just checked the latest snapshot tarball of the portable variant Nov 30 19:38:17 nothing systemd in there Nov 30 19:39:18 should be in sysroots/x86_64-linux/usr/lib/pkgconfig/ but there is only dbus-glib-1.pc there Nov 30 19:39:25 JaMa: yeah, sysvinit script Nov 30 19:40:39 hmmm not in dbus Nov 30 19:41:23 JaMa, any idea of what I should build to get dbus-1.pc? Nov 30 19:42:09 I'll look on target Nov 30 19:44:08 GNUtoo: dbus-native if you need it in x86_64 Nov 30 19:44:15 ah right Nov 30 19:44:16 sorry Nov 30 19:44:56 GNUtoo: dbus? Nov 30 19:45:09 GNUtoo: maybe dbus-native if you need it for gconf-native Nov 30 19:45:10 I guess I need the native version Nov 30 19:45:38 strange I was changing gconf-native yesterday and there was dbus-native in DEPENDS Nov 30 19:45:56 GNUtoo: btw do you have the wiki page for me? I'm almost ready to announce it.. Nov 30 19:46:16 yes I must finish it Nov 30 19:46:35 http://www.shr-project.org/trac/wiki/Stabilizing Nov 30 19:46:38 it's a template rather Nov 30 19:46:40 than a page Nov 30 19:46:44 I'll complete it Nov 30 19:47:14 SHR: 03Martin.Jansa 07shr-makefile * rc89fe7a65f66 10/Makefile: Makefile: show changelog if enabled, by default it's disabled Nov 30 19:47:28 but this one is for builders I need the one for testers Nov 30 19:48:09 and it could be sort of template, just the link for e-mail announcement that there will be the table to mark successfull tests Nov 30 19:51:35 better now? Nov 30 19:55:37 it's compiling now, thanks Nov 30 19:56:01 GNUtoo: I am flashing my image now ... Nov 30 19:56:31 GNUtoo: broonie is available ... Nov 30 19:56:54 SHR: 03Martin.Jansa 07shr-chroot * ra018f8d95ecd 10/OE/bin/ (3 files): staging scripts: rename info files to info.NNN, add script for printing changelog on rebased repos Nov 30 19:57:20 GNUtoo: I would like to split it to 2 pages Nov 30 19:57:38 GNUtoo: as it has different audience and both can get a lot of updates from different users.. Nov 30 19:57:52 nschle85: QA on the run today :) Nov 30 19:58:28 JaMa: pardon ? Nov 30 19:59:02 nschle85: we were talking about QA and testing in general today a lot Nov 30 19:59:08 http://www.shr-project.org/trac/wiki/Stabilizing Nov 30 20:00:00 JaMa: i was giving up to talk about that :-) Nov 30 20:01:22 GNUtoo: everything is working fine here Nov 30 20:01:33 including backlight? Nov 30 20:01:43 reboot and look if backlight still works Nov 30 20:05:17 morphis, did you ask something in #alsa-soc? Nov 30 20:07:29 GNUtoo: I ping'ed only broonie Nov 30 20:07:41 GNUtoo: without restart backlight works Nov 30 20:07:55 ok Nov 30 20:09:05 JaMa: Removing package openssh-sshd-systemd from root... Nov 30 20:09:05 Failed to issue method call: No such file or directory Nov 30 20:09:09 JaMa: ok, that is a beginning. There is another fact which disappointed me last time: developers are pushing code which break builds. this is a problem if you want to stay near on development but the image does not compile. Nov 30 20:10:25 JaMa: writing code which contains is not good but that i can understand, but pushing code which will break the build i cannot accept. Nov 30 20:10:45 ... contains bugs .. Nov 30 20:11:15 nschle85: unfortunatelly that can always happen Nov 30 20:11:56 sorry for being negative again, but I don't think this new concept will work better than shr-u + shr-t did Nov 30 20:12:04 one examle: using a newer compiler and not compiling the image ? Nov 30 20:12:27 people don't want to stay with old versions, because many things do not work; but switching to a newer version, *other* things do not work... Nov 30 20:12:39 nschle85, what we came up is not against build failures, but against telephony not working for people using shr supported phones daily Nov 30 20:12:42 antrik: agree Nov 30 20:13:00 antrik: did you actually read what we discussed? Nov 30 20:13:16 not propagating version that introduce known regressions will just mean the shr-core will become ancient, just like shr-t did Nov 30 20:13:19 mrmoku: yes Nov 30 20:13:44 and propagating it when that breaks basic stuff like telephony is better? Nov 30 20:14:40 mrmoku: it doesn't matter, if the only choice is between old broken versions and new broken versions... Nov 30 20:14:40 mrmoku: do you have an overview which features are already working on which phone ? Nov 30 20:14:43 this is not about different branches which diverge... this is just trying to make sure that images people can download from our public feed have a good chance to do soomething usefull Nov 30 20:15:05 antrik: there's broken... and there's *very* broken :) Nov 30 20:15:25 indeed no telephony is kind of blocker Nov 30 20:15:25 and it's not old Nov 30 20:15:39 nschle85: IIRC GNUtoo did a nice wiki page for that Nov 30 20:15:45 well, yes, there are different levels of broken... but that doesn't really matter if neither is really usable Nov 30 20:16:12 mrmoku: and who is tracking that ? Nov 30 20:16:34 antrik, it matters: between not beeing able to listen music and not beeing able to place a phone call, which one do you prefer if you use your phone daily? Nov 30 20:16:55 nschle85: the community :-) Nov 30 20:17:11 I think if you cannot listen some music for one day it'll be bad but not as bad as not beeing able to make a phone call Nov 30 20:17:27 GNUtoo: I'm not using the phone for music. but from what I've seen over the past year, I don't think there was *any* version during that time that was really working even for the basic phone stuff Nov 30 20:17:50 antrik, shr-core worked for me until it broke recently Nov 30 20:17:55 GNUtoo: maybe those who care about phone calls should only update music player regularly and update the telephony packages only when they have a day or two to test them and are prepared to downgrade them if they fail in basic tests. this is what I do Nov 30 20:17:55 tough I had issues with my microsd Nov 30 20:18:13 lindi-, I had 3 days to test Nov 30 20:18:22 and in 3 days we weren't able to fix the bug Nov 30 20:18:25 GNUtoo: I do the same for kernel and Xorg and other critical packages that make me afraid Nov 30 20:18:31 ok Nov 30 20:18:32 GNUtoo: well then you can downgrade? Nov 30 20:18:34 JaMa: Configuring openssh-sshd-systemd. Nov 30 20:18:34 ln -s '/lib/systemd/system/sshd.socket' '/etc/systemd/system/sockets.target.wants/sshd.socket' Nov 30 20:18:37 ln -s '/lib/systemd/system/sshdgenkeys.service' '/etc/systemd/system/multi-user.target.wants/sshdgenkeys.service' Nov 30 20:18:40 when manually installing all ist fine Nov 30 20:18:43 it's difficult to downgrade Nov 30 20:18:48 GNUtoo: not in debian :) Nov 30 20:18:53 ah ok nice Nov 30 20:19:02 lindi-, I failed to find a microsd for debian btw Nov 30 20:19:10 GNUtoo: failed? Nov 30 20:19:15 maybe you should make it easier to downgrade with opkg too Nov 30 20:19:25 yes all the one that I tried didn't work with the install script Nov 30 20:19:45 the bottom line is that a better process for testing and propagating new versions won't make the system more usable. only a changed mindeset of the developers can do that Nov 30 20:19:48 maybe I should go buy a new microsd but I fear it would be the same Nov 30 20:20:04 GNUtoo: they work with something else but don't work with install.sh? Nov 30 20:20:23 no idea Nov 30 20:20:31 GNUtoo: I thought you said it only worked with some nokia phone Nov 30 20:20:33 at least they work in my computer Nov 30 20:20:37 right now the stance goes like, "oh, there is some shiny new thing that works only with recent efl/vala/whatever, let's push some random trunk revision and see what breaks!" Nov 30 20:20:45 yes it works in all my other devices Nov 30 20:20:52 GNUtoo: yeah, so saying that it doesn't work with install.sh kind of gives me the wrong impression Nov 30 20:20:56 I've tried one of 4GB, one of 2GB Nov 30 20:21:09 basically it errors at some point Nov 30 20:21:15 GNUtoo: it's clearly not install.sh's fault if the hardware/kernel fails :) Nov 30 20:21:20 yes indeed Nov 30 20:21:37 but I've no idea on how to get this install.sh working Nov 30 20:21:46 not sure what to say, I have three cards that work Nov 30 20:21:46 I've tried different values for sd_max_clk Nov 30 20:22:04 lindi-: better even, drop opkg alltogether ;-) Nov 30 20:22:04 and only one of those requires tweaking sd_max_clk Nov 30 20:22:07 I've cards that work but they are at a capacity that is too low Nov 30 20:22:13 I don't mind buying a new card Nov 30 20:22:16 but it should work Nov 30 20:22:26 GNUtoo: what do you expect me to do? ;) Nov 30 20:22:32 GNUtoo: I can't manufacture SD cards :P Nov 30 20:22:36 I never understood why people think it's a good idea to use an inferior packaging system on a machine that's perfectly powerful enough to use something proper like .deb Nov 30 20:22:36 I know Nov 30 20:22:53 I just wondered about the values I should try, or about tricks Nov 30 20:23:22 GNUtoo: BTW, does your 32 MB card work with 2.6.34? Nov 30 20:23:43 32G, I would have to test Nov 30 20:23:56 it works with 2.6.39+sd_max_clock of 1M Nov 30 20:24:10 but after some times it errors -16 Nov 30 20:24:21 like if I scan the card for music Nov 30 20:25:27 JaMa: is it possible to activate the "inherit rm_work" in norman-schleicher build server again because the hard disk space is approximating 0 , and should i delete the old gta02 oe dev build is it really dead ? Nov 30 20:27:04 flashing.... Nov 30 20:27:50 btw what's the best distro to bootstrap debian Nov 30 20:27:51 ? Nov 30 20:28:05 basically I'd like to show debian on the freerunner to some people Nov 30 20:28:10 and to try it myself Nov 30 20:28:33 maybe I could repartitionate the 32G Nov 30 20:29:46 nschle85: yes in conf/local.conf Nov 30 20:30:18 JaMa: yes i know where but should i do it really or can i run in problems ? Nov 30 20:31:01 GNUtoo: have you ever tried http://build.hackable1.org/ ? Nov 30 20:31:39 GNUtoo: i tried it 1-2 years ago, and it worked Nov 30 20:31:43 ok Nov 30 20:31:53 and you can flash it Nov 30 20:32:23 but be carefully with updated from the official debian repositories Nov 30 20:34:16 GNUtoo: no idea, I don't really reinstall Nov 30 20:34:24 GNUtoo: but be warned, debian is "very stable" so its mostly outdated if it comes out Nov 30 20:34:38 nschle85: comes out? install.sh installs unstable Nov 30 20:34:57 debian sid ? Nov 30 20:35:01 nschle85: yes Nov 30 20:35:05 ok Nov 30 20:35:10 it always has installed unstable Nov 30 20:35:24 hackable1 is different project though Nov 30 20:35:40 hackable1 is based on squeeze Nov 30 20:36:30 ok Nov 30 20:38:23 I eared that the fso+shr software was like one year old Nov 30 20:38:28 *heard Nov 30 20:39:10 GNUtoo: in hackable1? Nov 30 20:39:20 in debian Nov 30 20:39:29 but I don't know if it's true or not Nov 30 20:39:35 I personally use ogsmd from 2009 or so :) Nov 30 20:39:41 ok Nov 30 20:39:43 since I don't want to break my telephony :) Nov 30 20:39:48 ok lol Nov 30 20:39:55 everything else is pretty much from debian unstable except for ogsmd Nov 30 20:40:01 ok Nov 30 20:40:23 I just don't see the point of being on the bleeding edge of python->vala transitions and all that in the case of telephony stuff Nov 30 20:41:59 speed? Nov 30 20:49:07 GNUtoo: speed of what? Nov 30 20:49:22 my conversations won't be any faster :) Nov 30 20:50:08 the phone may be faster Nov 30 20:50:16 like memory usage + speed Nov 30 20:50:27 because it slow down the rest Nov 30 20:50:33 like other applications Nov 30 20:50:38 nschle85: it's causing problems for multimachine builds (not sharing sstate), so won't harm your setup (with every machine in separate workspace etc..) Nov 30 20:50:58 GNUtoo: well possibly but you have to choose your priorities Nov 30 20:51:05 GNUtoo: it's totally fast enough Nov 30 20:51:19 * JaMa still writting long announcement.. hopefully someone will be here to at least read it once :) Nov 30 20:51:30 ok Nov 30 20:51:36 * lindi- is still playing with gnuradio :) Nov 30 20:51:47 nice about gnuradio Nov 30 20:51:47 JaMa: ok, different problem at home: nschle85@dual-wohnzimmer:~/build-core-shr$ make update make: Entering directory `/home/nschle85/build-core-shr' /bin/sh: -c: line 3: syntax error: unexpected end of file make: *** [update] Error 1 Nov 30 20:51:52 I think I managed to create an FM radio receiver that can receive two channels at the same time Nov 30 20:52:03 mostly as learning experiment Nov 30 20:52:11 ok Nov 30 20:52:19 can you try openBTS as an experiment? Nov 30 20:52:28 GNUtoo: I don't have a license Nov 30 20:52:37 JaMa: ups same problem on build host :-) Nov 30 20:52:42 ah bad idea you need a GSM test license Nov 30 20:52:49 ok Nov 30 20:54:22 GNUtoo: also that'd be so insanely complex that I wouldn't actually learn much :) Nov 30 20:55:34 ok Nov 30 20:55:38 lindi-: don't you run into memory problems with the old python stuff? I regularily experienced application crashes back then... with a complete SHR GUI though Nov 30 20:55:47 antrik: well I only run ogsmd Nov 30 20:55:52 antrik: not the whole frameworkd Nov 30 20:56:01 morphis, mrmoku shr_elm_softkey fails for me: Nov 30 20:56:13 again :/ Nov 30 20:56:24 nschle85: sorry I'll fix it in minute Nov 30 20:56:28 that time it's easy: Nov 30 20:56:29 shr_elm_softkey: symbol lookup error: shr_elm_softkey: undefined symbol: elm_table_homogenous_set Nov 30 20:56:37 I rebuild? Nov 30 20:56:53 oh at least Nov 30 20:56:54 JaMa: can you shortly explain what is wrong i cannot analyze, line 3 is empty Nov 30 20:57:12 GNUtoo: yes it will probably fail and then update it to use elm_table_homogeneous_set Nov 30 20:57:15 JaMa: its only for teaching me :-) Nov 30 20:57:25 ok Nov 30 20:57:38 nschle85: it's not line 3 of Makefile but of some inner script Nov 30 20:57:48 | basetransport.vala:505.45-505.55: error: Argument 2: Cannot pass ref argument to non-reference parameter Nov 30 20:57:51 | if ( res < 0 || Posix.FD_ISSET( fd, ref readfds ) == 0 ) Nov 30 20:57:52 morphis: ^^^ Nov 30 20:58:45 or does that need the 0.14.1 update now ;) Nov 30 21:01:15 mrmoku: yes Nov 30 21:01:26 mrmoku: and latest version of cornucopia Nov 30 21:02:47 morphis: I'm autoreved... updating vala and doing the rebuild boogie again :) Nov 30 21:03:51 JaMa: GNUtoo: mrmoku: now i know how to avoid pushing non compiling code (for most cases) Nov 30 21:04:43 1. rebase to master / shr branch. commit locally Nov 30 21:04:51 2. build shr image Nov 30 21:05:01 3. if it builds push Nov 30 21:13:32 sounds good Nov 30 21:14:07 GNUtoo: is it practicable ? Nov 30 21:14:08 nschle85: what do you think I _always_ do before pushing to shr branch? Nov 30 21:14:40 yes but it won't fix everything Nov 30 21:14:52 but as we talked before many build issues are not even reproducible ie in shr-chroot Nov 30 21:15:09 or with wrong combination of concurrent upgrades and high -j Nov 30 21:15:29 so point 2 that shr-image build is very weak Nov 30 21:16:16 and on the other side I have to push it to be able to do the same shr-image build at least on other machine (SHR buildhost) and now also on your jenkins Nov 30 21:17:13 so when I'm finished with one git push I have it built on 3 machines or I'm already working on some fix for issues which happened only on 3rd build (ie your host) Nov 30 21:18:11 JaMa: so is it practicable to have an extra build test branch ? which can be build on several build hosts ? Nov 30 21:18:21 mrmoku: GNUtoo nschle85: please review and comment http://dpaste.com/663998/ Nov 30 21:19:05 I've to push the fix and I'll look Nov 30 21:19:46 nschle85: it's the same as last time we talked about it.. and read today's log because I think it's simmilar problem (only not for runtime but for build time issues) Nov 30 21:21:20 SHR: 03GNUtoo 07shr-e-gadgets * rfa5f68c50ba1 10/src/softkey_quickpanel/main.c: softkey_quickpanel: Adapt to newer enlightenment API(homogenous -> homogeneous ) to fix compilation Nov 30 21:23:20 JaMa, btw is it allowed to bump srcrev of a recipe without bumping PR Nov 30 21:23:26 if it has SRCPV for instance? Nov 30 21:23:36 because I saw a lot of theses recipes in meta-smartphone Nov 30 21:23:40 GNUtoo: yes Nov 30 21:23:41 and the count is local Nov 30 21:23:45 ok Nov 30 21:24:02 JaMa: very nice :) Nov 30 21:24:04 so I guess angstrom now shares the cache files Nov 30 21:24:36 GNUtoo: no Angstrom is not using BB_LOCALCOUNT_OVERRIDE.. Nov 30 21:24:51 GNUtoo: so they have constant LOCALCOUNT.. Nov 30 21:25:49 JaMa: if (initgroups(pwd->pw_name, pwd->pw_gid) != 0) fails for elsa Nov 30 21:25:54 that's why it does not work for me Nov 30 21:28:00 SHR: 03Martin.Jansa 07shr-makefile * r783ad80d8404 10/Makefile: Makefile: fix missing ; Nov 30 21:28:05 mrmoku: your root has only root group? Nov 30 21:28:11 nschle85: ^^ Nov 30 21:28:26 nice Nov 30 21:28:31 I've read it and it's nice Nov 30 21:28:34 indeed Nov 30 21:29:17 http://build.shr-project.org/shr-core-staging/latest/info has new changelog :) Nov 30 21:29:53 mrmoku, GNUtoo: so should I send it today or wait until we have closed feed an also public feeds working fine? Nov 30 21:30:05 hmmm Nov 30 21:30:08 JaMa: good work Nov 30 21:30:08 I don't know Nov 30 21:30:28 mrmoku, GNUtoo: I vote to wait so we can give example how at least us 4 filled the table on wiki and moved it to public feed after testing Nov 30 21:30:28 give me some minutes to finish the working state Nov 30 21:30:30 JaMa: thank you for update, locally it works, ill fix build host later Nov 30 21:30:38 yes good point Nov 30 21:31:06 It would make my overcomplicated description a bit shorter :) Nov 30 21:31:12 hehe :) Nov 30 21:31:28 and we should move at much information from this mail to that wiki page as well Nov 30 21:31:55 GNUtoo: I'm counting on your wiki powers here.. :) Nov 30 21:32:14 ok Nov 30 21:32:27 i did not finsh reading/understanding Nov 30 21:33:57 mrmoku: just note for buildhost.. sync_core alias is now sync_core.sh script and instead of make update please always call wrapper shr_core_update.sh, which fills the info files with changelog.. Nov 30 21:36:14 SHR: 03GNUtoo 07meta-smartphone * r83975e612eb7 10/meta-shr/recipes-shr/shr/shr-e-gadgets_git.bb: meta-shr: shr-e-gadgets: fix building with newer EFL (homogenous -> homogeneous API change) Nov 30 21:37:02 * JaMa starting build and --> dinner Nov 30 21:37:25 ok Nov 30 21:37:34 I hope I'll have the time to test before going to bed Nov 30 21:37:47 JaMa: ok Nov 30 21:37:51 JaMa: and have a nice dinner Nov 30 21:38:30 JaMa: bon apetito Nov 30 21:38:41 buon apetito Nov 30 21:38:54 | basetransport.vala:504.39-504.49: error: Argument 2: Cannot pass ref argument to non-reference parameter Nov 30 21:38:57 | int res = Posix.select( fd+1, ref readfds, ref writefds, ref exceptfds, t ); Nov 30 21:39:00 | still fails for me Nov 30 21:39:09 and morphis is gone ;) Nov 30 21:39:23 hmmm Nov 30 21:39:27 guess vala-native needs bumping too Nov 30 21:39:32 GNUtoo: does it build for you? Nov 30 21:39:37 it did build Nov 30 21:39:41 ok Nov 30 21:39:41 not sure if it still builds Nov 30 21:39:51 SHR: 03Martin.Jansa 07shr-makefile * rc52c5276f523 10/Makefile: fix changelog-shr-unstable and changelog-shr-testing Nov 30 21:40:38 * mrmoku off to bed Nov 30 21:40:53 I will not be able to test before tomorrow afternoon... but that I will do and fill the wiki Nov 30 21:41:05 ok Nov 30 21:41:11 JaMa: and I will start local-building elsa and trying to fix it too Nov 30 21:41:28 gnight all Nov 30 21:41:33 good night Nov 30 21:41:34 and... today was a good day :) Nov 30 21:41:46 mrmoku: thank you for the book Nov 30 21:41:54 which helps me sleeping Nov 30 21:41:58 :-) Nov 30 21:42:06 manage to build a software radio that can listen to two FM broadcasts at the same time: http://www.metsahovi.fi/howto/usrp/simple-examples/uhd_wbfm_receive_dual/ :-) Nov 30 21:42:55 nice Nov 30 21:42:55 probably very simple stuff if you are familiar with software radio but it took me two days to struggle through all these filter definitions to finally find the simplest solution Nov 30 21:43:07 ok Nov 30 21:43:34 I read a lot about GNU/Radio and the USRP and OpenBTS Nov 30 21:43:42 but I've no real experience with it Nov 30 21:44:41 SHR: 03Martin.Jansa 07shr-makefile * r60f4f6de1836 10/Makefile: fix changelog-shr-unstable and changelog-shr-testing Nov 30 21:45:55 crofton is maintaining it in OE and he was showing it on ELCE, nice stuff Nov 30 21:53:01 yes I saw an E version at fosdem too Nov 30 21:53:09 I think crofton was showing it too Nov 30 21:55:58 nschle85: did you already started the build? Nov 30 21:56:19 yes locally Nov 30 21:56:21 nschle85: I can push a lot of changes from oe-core if you want to test it oevr night Nov 30 21:56:47 test==build only ? Nov 30 21:57:41 yes.. I plan this batch to be in 002 :) Nov 30 21:58:07 yes push it i ll start a clean build on build host Nov 30 21:58:22 ok, few mins Nov 30 21:58:33 JaMa: dont hurry Nov 30 22:00:41 JaMa: i do not understand line 56-58, how should it work in real ? Nov 30 22:01:34 I don't understand what you don't understand on it :) Nov 30 22:02:24 ..will contain a directory for each major feature we want to test... Nov 30 22:02:37 how is that done ? Nov 30 22:05:10 now it was by rsync to shr-core/ dir Nov 30 22:05:28 now it is rsync to shr-core-staging/NNN dir Nov 30 22:05:48 and only after enough votes another rsync moves shr-core-staging/NNN to shr-core/ Nov 30 22:06:06 see shr-chroot repo for those scripts Nov 30 22:06:34 JaMa: i know but how do you sync by workpackage ? shr/oe development is not workpackage oriented, its time lined Nov 30 22:07:12 so you cannot test a upgraded feature you can only test chnages from a-b in time Nov 30 22:08:19 what's workpackage? Nov 30 22:08:54 its a changeset to solve a specific task Nov 30 22:09:28 normally done on developer branches Nov 30 22:09:44 if I'm still talking here after 17 minutes, kick me.. there will be rice burning in my kitchen :) Nov 30 22:09:56 nschle85: the point is there is only one branch Nov 30 22:10:09 and all we're testing are binary ipk feeds Nov 30 22:10:28 and images if they are built for that NNN Nov 30 22:11:20 ik now so you cannot test only major features, potentually all can be broken in meantime Nov 30 22:11:35 ? Nov 30 22:11:59 you cannot test 005 and skip testing 00[1234] if that's what you mean Nov 30 22:12:56 it's about granularity how often we'll close the feed for now rsync, it will be after some feature is built for all machines or after some time (ie week) Nov 30 22:13:41 JaMa: the problem is that you have to take all changes which are made until rotation Nov 30 22:13:54 code is not frozen to solve one problem Nov 30 22:14:14 no, the problem will be always fixed only in latest Nov 30 22:14:36 what we're trying to fix here is that feed with problem wont get to "stable" feed Nov 30 22:14:58 so it will rotate as long as we don't have version with enough users voting for it Nov 30 22:15:18 but this should be shorter periods than what we have with shr-u and shr-t Nov 30 22:15:43 and which code is integrated ? all or only code fixing a specific problem ? Nov 30 22:16:04 ? Nov 30 22:16:08 SHR: 03lukpank 07shr-settings * r1b5f5ecd84f5 10/shr-settings: fix maximization of modules' windows Nov 30 22:16:37 nschle85: read the log from today please Nov 30 22:19:10 JaMa: i did but did not help , so i do not understand which code will be integrated where. in worst case youll never have a voted version true ? Nov 30 22:20:41 nschle85: yeah, that's more or less what I have been saying as well Nov 30 22:23:00 so do i understand the tactic: identifying some builds, testing them and if one is ok is "released" ? Nov 30 22:23:33 yes Nov 30 22:24:40 antrik: but the period should be shorter and we won't be maintaining 3 sets of branches to keep 3 levels of broken stuff as you say.. Nov 30 22:25:03 * JaMa off to kitchen Nov 30 22:25:26 SHR: 03mok 07meta-smartphone * r56ddee8197f9 10/meta-openmoko/recipes-graphics/xorg-xserver/xserver-xf86-config/om-gta04/xorg.conf: xserver-xf86-config: fix touchscreen input device for om-gta04 Nov 30 22:25:26 SHR: 03lukpank 07meta-smartphone * r0cd1ab19a8cf 10/meta-shr/recipes-shr/3rdparty/ffalarms_git.bb: falarms_git.bb: bump SRCREV for switch to gdbus Nov 30 22:26:41 JaMa: ok so bugs, leading to breaking features can be found earlier ? Nov 30 22:28:48 hmm another new vala issue Nov 30 22:28:49 | plugin.vala:86.31-86.37: error: Argument 2: Cannot pass value to reference or output parameter Nov 30 22:28:52 | Posix.FD_SET( fd, readfds ); Nov 30 22:28:56 fsousaged this time Nov 30 22:29:06 JaMa: its not new :-) Nov 30 22:31:04 JaMa: i have it too Nov 30 22:31:33 JaMa: just to be clear: I don't mean to say that this new approach is a bad thing in itself. my point is rather that unless other things change as well, it probably won't do much good... Nov 30 22:34:23 antrik: how i jama understand: this is not meant to get a stable code but to get a decision point to update the image for end users Nov 30 22:34:51 antrik: I hope that this way it will be easier for people to test new stuff and with more testers we can improve it Nov 30 22:34:52 antrik: in worst case the image is everytime broken Nov 30 22:35:10 antrik: you're right that without testers voting for some builds we don't get anywhere Nov 30 22:35:38 antrik: but at least we can say that they had the option to test it easily before it hit the normal feed Nov 30 22:36:44 JaMa: antrik: next is to work out a procedure to prevent broken code but its a different problem Nov 30 22:37:41 you mean when image does not build on some combination of host&workspace? Nov 30 22:38:04 JaMa: yes Nov 30 22:39:13 example: the current problem seems not to be a problem of host/workspace ! Nov 30 22:39:21 because you and me have it Nov 30 22:39:34 that is much lower priority imho.. if something doesn't build (not only shr-image but whole task-shr-feed) then it doesn't move to staging feed Nov 30 22:39:39 so users are "save" Nov 30 22:39:47 and we should care about users.. Nov 30 22:39:58 JaMa: i am now speaking in developers view :-) Nov 30 22:40:28 broken builds are wasting time Nov 30 22:41:01 and what, so it doesn't build with latest greates vala morphis needed.. you can revert back to revision before this vala was added or better help morphis to solve those issues Nov 30 22:42:05 so why is morphis adding new vala in public ? git does not support branches ? Nov 30 22:42:14 but if we don't allow morphis to push it to meta-smartphone repo until he build every possible combination then morphis won't work on new features and we'll be wasting time of one of most valuable FSO dev Nov 30 22:43:24 nschle85: morphis asked me and I said that he can push it to meta-smartphone/master if it works for him Nov 30 22:43:32 nschle85: and it worked in 99% Nov 30 22:44:03 and because of remainging 1% which was discovered after he pushed it, he had to upgrade it again Nov 30 22:44:15 ok it works for him but not for the rest here ! Nov 30 22:44:25 unfortunately the even newer version was worse here Nov 30 22:45:13 hi guys Nov 30 22:45:14 nschle85: that's just what happends on _development_ branch Nov 30 22:45:47 JaMa: at work we also have a development branch and it never happened Nov 30 22:45:57 yeh is that a vala issue , a gdbus issue or fso at autorev using one of previous item with wrong version ? Nov 30 22:46:01 | main.vala:102.22-102.37: error: dynamic methods are not supported for `DBus.Object?' Nov 30 22:46:02 | uint reply = bus.request_name("org.freesmartphone.ousaged", (uint) 0); Nov 30 22:47:00 an then I should remove fso autorev ? Nov 30 22:47:13 nschle85: in corporation you can keep your changes until you do all needed tests in development branch, you can even have whole departments testing those changes before it goes to normal branch Nov 30 22:47:15 s/?/./ Nov 30 22:47:16 GarthPS meant: an then I should remove fso autorev . Nov 30 22:47:29 nschle85: but we're <10 ppl here Nov 30 22:47:52 JaMa: no, we do not test,we only compile before merging indo dev Nov 30 22:48:05 nschle85: and it looks like 8 from us are able to revert rollback if something goes wrong :) Nov 30 22:48:27 nschle85: I bet that new vala compiled fine for morphis before he pushed Nov 30 22:48:56 nschle85: just because he had already whole latest fso already built (except that failing 1%) he didn't get the new issue Nov 30 22:49:32 JaMa: ok, thats an argument Nov 30 22:49:33 nschle85: and you and me and GarthPS have it only because we got vala upgrade and then FSO upgrade Nov 30 22:49:49 JaMa: you are right Nov 30 22:50:42 he was probably also quite confident with new vala when he saw that it fixed the 1% he was trying to fix by upgrading vala Nov 30 22:50:58 but do you remember: [21:08:48] one examle: using a newer compiler and not compiling the image ? Nov 30 22:51:23 yes I do local rebuild from scratch after "bigger" compiler changes Nov 30 22:51:48 but if someone just changes packaging and bump PR I'm not going to wait 50 hours before all images are built again Nov 30 22:51:50 JaMa: ok so it is a morphis commit that currently break fso ? Nov 30 22:51:53 JaMa: i would like to stop the discussion here. Nov 30 22:52:05 fso building f course Nov 30 22:52:07 GarthPS: read backlog, but newer vala seems to be the cause Nov 30 22:52:27 nschle85: fine with me.. Nov 30 22:52:58 JaMa: If that helps me I am having my isue with completely fresh tmp/ rep. Nov 30 22:53:26 JaMa: ill wipe out workspace on build host for shr-core-n900 Nov 30 22:55:43 GarthPS: you can revert vala upgrade patch, but it's fixing opening modem iirc.. Nov 30 22:56:12 GarthPS: http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=fffd4c9ecf02f8c41bd39ce932132440b8df7812 Nov 30 22:57:02 nschle85: ok.. I probably wont push oe-core-contrib/shr today, there is a lot of changes and I have to update glamo patch for newer libdrm from oe-core too Nov 30 22:57:29 JaMa: ok you can plress play button when you like :-) Nov 30 22:58:10 it will take whole night to build it here.. so maybe tomorrow.. Nov 30 22:58:32 you can also start a test build on build server :-) Nov 30 22:58:50 but at the moment the image does not build Nov 30 22:59:33 nschle85: not before I push it to shr branches.. :) Nov 30 22:59:35 but a build there would also take 12 hours Nov 30 23:00:12 ok workspace is still cleaning ... Nov 30 23:01:18 sofar only fsousaged failed here Nov 30 23:02:09 JaMa: so ill go to bed ... at 06.00 the night is over Nov 30 23:03:24 JaMa: i have another question, can you bring please some szech krones to FSOSHRCON ? ill exchange into euros if you would do that Nov 30 23:04:56 ok thx Nov 30 23:05:37 nschle85: yes, just remind me later and decide how much you want Nov 30 23:05:49 ok thank you Nov 30 23:06:39 JaMa: its not so much only for paying parink and the tax for the highway Nov 30 23:06:43 parking Nov 30 23:06:56 thank you bye Nov 30 23:07:01 bye Nov 30 23:07:29 good night nschle85! Nov 30 23:07:43 thank you , good night Nov 30 23:11:51 JaMa: well, my point is that more testing won't help if the result it yields is that version 23 fixes issue A but introduces issue B; version 24 fixes issue B but introduces issue C; and so on... Nov 30 23:12:41 antrik: I see Nov 30 23:13:28 also, many issues are not immediately obvious even with testing; so even now and then a lucky version *does* get into the validated feed, there is no guarantee that it works better (or as well) as the previous one Nov 30 23:13:56 antrik: but at least we'll know about A B C and will be able to fix at least this in next version (with issue D) Nov 30 23:14:55 antrik: with people using very old shr-t or shr-u we probably wont even try to fix their A/B/C because it was probably already fixed somehere on way to shr-core and nobody from devs is using shr-t or shr-u Nov 30 23:15:08 so what I'm really saying is that better testing doesn't help the fundamental issue that SHR/FSO is of *constantly* bad quality; and testing preventing the worst breakages entering the main feed is not really helpful, if the main feed is not actually usable anyways... Nov 30 23:15:36 why do you hate SHR/FSO so much? :) Nov 30 23:15:51 if I hated it, I wouldn't be here :-) Nov 30 23:16:04 that was my 2nd question.. Nov 30 23:16:09 antrik: why you're here? :) Nov 30 23:17:13 I just hate the wasted effort... this project is promising on many scores, and it's a shame that it's not getting anywhere Nov 30 23:19:35 at least shr-t/shr-u wont be wasting effort anymore and this staging is almost for free Nov 30 23:19:49 I used SHR for several weeks about two years ago, and in spite of a number of shortcomings, it was quite usable actually. I'd love to see it to get back into such a state, and improve from there... but that's just not happening. over the past two years, the number of regressions has been larger than the number of improvements :-( Nov 30 23:22:31 JaMa: BTW, note that while this channel is mostly used that way, it's actually *not* an SHR or FSO channel -- I would have perfectly valid reasons to be here even if I wasn't interested in either of these projects :-) Nov 30 23:23:53 and I'm glad you're here.. Nov 30 23:28:03 to be more specific, in spite of some quibbles here and there, I quite like the general approach of FSO and the SHR UI. what I don't like is the OE-based packaging, and the constant reliance on unstable (i.e. broken) upstream versions (most notably of EFL and Vala) Nov 30 23:28:24 (with QtMoko it's pretty exactly the opposite...) Nov 30 23:28:50 if I wasn't such a lazy bum, I'd start a Debian-based SHR variant :-) Nov 30 23:28:51 antrik: btw .deb and .rpm are also supported by OE, just one configuration swith.. Nov 30 23:29:03 switch Nov 30 23:29:19 yeah, someone mentioned that already... but that doesn't help unless someone actually flips the switch ;-) Nov 30 23:29:36 the package format probably does not help that much Nov 30 23:30:12 but the format of the packages is only part of the problem. I don't like the general approach how things are built/integrated in OE -- it's good for real embedded devices, but not for modern smartphones, which are pretty much general-purpose computers, and need a general-purpose operating system Nov 30 23:31:05 I see people struggling with OE more than with actual development here... Nov 30 23:31:46 lindi-: well, it would help *somewhat*, as opkg is quite limited in itself... but it's indeed just part of the problem Nov 30 23:37:07 mrmoku: looks like I have same issue with elsa and group http://paste.debian.net/147634/ Nov 30 23:38:25 * JaMa is not struggling with OE, but you're right it has steep learning curve and not all people want to go there Nov 30 23:48:11 freesmartphone.org: 03angelo 07settings-rework * r0e422ce3252a 10aurora/aurora-daemon/src/applications/app-settings/ (9 files in 4 dirs): aurora-daemon: settings-app: clean-up of delegates Nov 30 23:48:11 freesmartphone.org: 03angelo 07settings-rework * r84e29272c735 10aurora/aurora-daemon/src/applications/app-settings/ (7 files in 4 dirs): aurora-daemon: rework delegates Nov 30 23:48:12 freesmartphone.org: 03angelo 07settings-rework * r86f6a3b81978 10aurora/aurora-daemon/src/applications/app-settings/ (4 files in 4 dirs): aurora-daemon: add sliderField to delegates Nov 30 23:48:12 freesmartphone.org: 03angelo 07settings-rework * rc8975640c687 10aurora/aurora-daemon/src/applications/app-settings/ (8 files in 4 dirs): aurora-daemon: start returning values by delegates Nov 30 23:51:20 good night guys Nov 30 23:58:17 * JaMa completely forgot 2L beer in my bag... ahh Dec 01 00:17:09 SHR: 03Martin.Jansa 07meta-smartphone * r89dc88b4d4cb 10/meta-fso/recipes-freesmartphone/freesmartphone/cornucopia.inc: cornucopia: bump SRCREV a bit more Dec 01 02:09:02 This might be old-news, but I found the n900 meego kernel patches. http://build.meego.com/package/files?expand=0&package=kernel-adaptation-n900&project=Trunk%3ATesting **** ENDING LOGGING AT Thu Dec 01 02:59:58 2011