**** BEGIN LOGGING AT Thu Mar 04 02:59:58 2010 Mar 04 05:05:51 morning Mar 04 05:08:14 omfg, moinmoin Mar 04 05:10:09 hehe Mar 04 05:10:14 early bird bla bla Mar 04 05:10:16 ;) Mar 04 05:10:21 mickey|ICE: no more train number? Mar 04 05:10:38 hmm, let me check Mar 04 05:10:51 we're so used to it Mar 04 05:11:09 true Mar 04 05:11:18 here we are Mar 04 05:11:31 mickey's private little nickname microblogging ;-P Mar 04 05:11:35 hehe Mar 04 05:11:38 i don't twitter Mar 04 05:11:41 i change nicknames Mar 04 05:11:42 :D Mar 04 05:13:13 hmm, 1sec Mar 04 05:13:28 EDGE? Mar 04 05:17:48 better Mar 04 05:17:49 Wifi Mar 04 05:18:02 one of the rare tracks where you have in-train-wifi Mar 04 05:20:30 are you already awake or still? Mar 04 05:53:01 freesmartphone.org: 03mickey 07cornucopia * rba80789eb00d 10/libfsotransport/fsotransport/commandqueue.vala: libfsotransport: add open() and close() to CommandQueue interface Mar 04 05:56:33 freesmartphone.org: 03mickey 07cornucopia * rf466840a9166 10/fsogsmd/src/ (7 files in 5 dirs): fsogsmd: refactor Channel into Channel interface and AtChannel implementation Mar 04 06:00:33 asm ("mult %2,%3" \ : "=l" (lo), "=h" (hi) \ : "%r" ((x) >> 12), "r" ((y) >> 16)) Mar 04 06:00:52 the above asm statement has error w.r.t ARM processor Mar 04 06:01:09 i'm using gcc 4.4.2 Mar 04 06:01:37 i see the changes w.r.t "h" constraint regarding MIPS arch Mar 04 06:01:58 but not with ARM arch... Mar 04 06:02:21 any help is appriciated. Mar 04 06:03:25 http://gcc.gnu.org/gcc-4.4/ Mar 04 06:08:29 moin Mar 04 06:30:30 freesmartphone.org: 03mickey 07cornucopia * r0e2ed2c28f06 10/fsogsmd/src/plugins/modem_qualcomm_palm/ (Makefile.am mediators.vala plugin.vala): fsogsmd: qualcomm_palm: start with own set of mediators Mar 04 06:45:29 mickey|ICE672: already. Even earlier than you Mar 04 06:46:18 in-train WiFi, woohooo o.O Mar 04 06:51:10 freesmartphone.org: 03mickey 07cornucopia * r46adfd11e659 10/fsogsmd/src/plugins/modem_qualcomm_palm/ (mediators.vala plugin.vala): fsogsmd: qualcomm_palm: make it compile at least Mar 04 06:53:52 good point :) Mar 04 07:12:40 sicu, shr-settings is doing it wrong :P overlapping: I know. Mar 04 07:42:21 ~uptime Mar 04 07:42:55 ~nuke apt Mar 04 07:42:56 * apt prepares 100 missle silos, and targets them at apt ... B☢☢M! Mar 04 07:57:21 to make sure clients don't die trying to upload requests to a non-existing layer and stuff. Mar 04 07:57:24 oops Mar 04 07:57:40 I really should learn that irssi has multiple windows :) Mar 04 08:00:24 8) Mar 04 08:01:06 hehe Mar 04 08:14:25 heh, I started rebuild on buildhost and my host.. at home I have half of shr-lite-image and buildhost NOTE: Running task 318 of 984 + 5 segfaults :/ Mar 04 08:14:38 TAsn: ok, good to know that you know Mar 04 08:14:48 JaMa: :/ Mar 04 08:15:25 TAsn: seems i managed to file a bug late last night anyways, so now you won't forget ;p Mar 04 08:15:27 * JaMa stopped rebuild on buildhost Mar 04 08:16:29 JaMa: what's the specs on your own host? Mar 04 08:16:55 phenom,4G ram,raid0 for workdir Mar 04 08:17:36 but the BIG problem are those segfaults only on shr buildhost :/ Mar 04 08:18:38 do you have full access to buildhost, or depending on help from bearstech to get it sorted? Mar 04 08:21:32 only normal account, but bearstech guys are helpfull and trying to solve it.. but it just takes probably more time and pity that it happen just after rebuild from scratch started :/ Mar 04 08:22:08 yeh :/ Mar 04 08:22:31 it's almost a week without usable image and 80% of build was finished the first day I started it.. remaining 20% is useless :/ Mar 04 08:28:34 JaMa: well, 0301 lite image is perfectly usable ... as long as one does your libopkg0 fix ;p Mar 04 08:31:34 sicu: as long as you don't need utf8 characters in sms and don't use few additional apps from feeds which are still not finished Mar 04 08:32:18 but running the build now just makes about 8 segfault and then successfully build package-index only Mar 04 08:33:09 JaMa: that sucks... :-( Mar 04 08:34:27 spaetz: yeah Mar 04 08:34:41 ~lart iffy buildhost Mar 04 08:34:42 * apt overclocks iffy buildhost until iffy buildhost burns out Mar 04 08:38:11 hehe, that sounds about what happened Mar 04 08:38:16 smart apt Mar 04 08:56:12 I wonder if the opensuse build service can be used. Mar 04 08:56:17 It says in http://en.opensuse.org/Build_Service#For_embedded_Developers Mar 04 08:56:36 # Build your software for other processor platforms. Mar 04 08:56:37 # The OBS version supporting cross-development with qemu emulator is released in the normal OBS Code. Also, arm support has been activated in the public OBS. The use of the local build feature via osc/build is also fully supported. For a technical information read the Cross Development Concept and Example. For QEMU use, up to ARMv7 EABI and VFPv3 is in a usable state. Three classes exist in the scheduler for arm: armv4l, armv5el and armv7el. Mar 04 08:59:57 spaetz, i already thought about using it to build fso package for arm Mar 04 09:00:10 MER is using it for it's builds Mar 04 09:00:31 the cross-compile example creates a .deb file Mar 04 09:00:52 is armv4l very different from armv4t? Mar 04 09:01:18 armv4l is armv4t(arv4tl) without thump support Mar 04 09:01:23 l - means little endian Mar 04 09:01:29 t - thumb Mar 04 09:01:31 thanks Mar 04 09:01:45 ahh, but we compile without thumb support anyway, IIRC Mar 04 09:01:53 so that could actually work out. Mar 04 09:03:36 spaetz: with thumb Mar 04 09:03:44 ahh, ok Mar 04 09:03:47 thanks Mar 04 09:04:00 spaetz: seen my commit about shr-launcher SRCREV? Mar 04 09:04:29 spaetz: you want that to testing branch too Mar 04 09:04:50 no, must have missed it. hold on Mar 04 09:05:22 tthis thread? Launcher Release svn r89 Mar 04 09:05:34 spaetz: no here qwery Mar 04 09:05:38 no, that was a very old one. Mar 04 09:05:41 ok Mar 04 09:08:25 Weiss: btw, also your gdrm2.6.32 branch misses the Enable FIFO stage patch (unless it's not needed with drm) Mar 04 09:12:06 ok, will cherrypick e6e884c834ec5b5152f237708bbc91e2feaebfb4 into shr-testing. thanks Mar 04 09:14:30 Mirv: it's in there.. rolled into the first "Introduce Glamo KMS driver" commit: glamo_crtc_mode_set_base() in glamo-display.c Mar 04 09:16:17 addr_high = ((addr >> 16) & 0x7f) | 0x4000; Mar 04 09:16:19 sneaked in there :) Mar 04 09:20:46 Weiss: sneaky indeed! :) Mar 04 09:20:53 hmm maybe we need python-2.6 on shr buildhost.. Mar 04 09:21:20 there is 2.5 and that could be the difference why it's segfaulting there and works ok everywhere else Mar 04 09:21:44 Mirv: for some reason (possibly an artifact rather than a real effect), the accelerator goes slightly faster in 2.6.32 as well.. 113fps on the fullscreen VGA fill test rather than 99 Mar 04 09:22:07 Mirv: probably down to the latency of fencing in the kernel Mar 04 09:22:34 Weiss: right. what about that bug reporting thing, can bugs be reported in openmoko trac or what would be the preferred solution? I could put that EXA crash somewhere. Mar 04 09:23:47 hmm Mar 04 09:23:59 maybe I could set up a bugzilla or something for my own projects Mar 04 09:24:48 reporting straight to me (possibly by email) is best for actually getting stuff fixed, but it'd be good to allow other people to comment Mar 04 09:25:43 maybe indeed it would be good Mar 04 09:28:18 Mirv: does that crash happen under the same circumstances but without KMS? Mar 04 09:30:08 Weiss: well with 2.6.29 without KMS it surely does not happen, I use literki as my default keyboard Mar 04 09:30:34 do I need something like minicom for my debug board? Mar 04 09:30:38 definitely the same version of everything else? (Xorg etc?) Mar 04 09:30:55 Serdar: I use "gtkterm", but "screen" can also work (to get the serial console) Mar 04 09:31:38 Mac. I guess I will have problems to find gtkterm for mac. Mar 04 09:31:55 Weiss: I only change kernel + modules + xf86-video-glamo when changing to 2.6.32 gdrm. Mar 04 09:32:28 Mirv: hmmm.. you shouldn't have to change xf86-video-glamo (it's really two drivers pretending to be one) Mar 04 09:32:40 well, to be more exact, I ln -s a new kernel to uImage.bin, copy new glamo_drv.so and reboot Mar 04 09:33:29 Serdar: maybe..but any terminal emulator should work Mar 04 09:33:31 Weiss: that's actually true, I didn't use to do that. Mar 04 09:34:29 Weiss: I now copied my "KMS driver" (ie. just a newer compilation) and restarted X under 2.6.29. does not crash. Mar 04 09:34:46 2.6.29+KMS, or not? Mar 04 09:36:32 no KMS, "KMS driver" just meant I compiled it with KMS support, unlike the Debian's packaged driver which has it disabled Mar 04 09:37:27 what about 2.6.29+KMS or 2.6.32 (no KMS) kernels? Mar 04 09:37:56 hmm Mar 04 09:37:57 I can test Mar 04 09:38:10 I guess these driver for debug board do not work with mac Mar 04 09:38:12 (I'm trying to be certain that it happens with the DDX running in KMS mode but not in fbdev mode, independent of kernel) Mar 04 09:38:20 I find the debug board Mar 04 09:38:29 Serdar: which drivers? Mar 04 09:38:33 but there is no dev/ttyUSBx Mar 04 09:38:46 ftdi stuff Mar 04 09:38:47 possibly it's called something else on Mac? Mar 04 09:39:12 can't compile ftdi_eeprom etc. Mar 04 09:39:15 maybe Mar 04 09:39:30 the FTDI stuff is for running GDB on the kernel. the ttyUSB0 stuff is for getting the serial console. the latter should be a question of plugging it in and finding which /dev node corresponds to the new TTY device. the former (GDB) is a little more tricky Mar 04 09:39:31 but nobody knows and I can't ask FIC anymore :/ Mar 04 09:40:21 Serdar: no need to ask FIC for anything? Mar 04 09:40:44 Serdar, you can ask mickey when he returns Mar 04 09:41:04 is he useing mac? Mar 04 09:41:13 Serdar: also, why insist on using proprietary software to debug openmoko? sounds somewhat backwards Mar 04 09:42:11 lindi-, I can get the source of ftdi but if you got another solution... Mar 04 09:42:22 Serdar: you should probably be looking up how USB serial devices work on OSX right about now.. rather than specifically the OM debug board Mar 04 09:43:48 USB CDC/ACM is the only standard, right? it is just not being used by ftdi stuff Mar 04 10:04:32 hehe.. the latest Intel drivers are now experiencing WSoDs.. Mar 04 10:05:49 heh Mar 04 10:06:45 seeing WSOD on big LCD during night could be a bit more painfull than on small neo :) Mar 04 10:07:29 yeah Mar 04 10:07:54 * Weiss needs to trace these GPIO lines to the LCM to ensure WSoD can't come back Mar 04 10:16:30 ok, I have "borrowed" a server for shr-testing compilation. Should be quicker than my poor laptop. Mar 04 10:17:54 spaetz, afaik you should have a nearby PS3 cluster Mar 04 10:21:34 Yes, I really should :) Mar 04 10:21:52 I'll try to convince my boss Mar 04 10:22:48 do you we can borrow it to break motorolas 128 Bit RSA key on the milestone? Mar 04 10:24:22 shit is that fast... /me stops compilation on the laptop Mar 04 10:32:03 spaetz: :) Mar 04 10:32:20 no time left for a winter hybernation? Mar 04 10:32:43 spaetz: btw maybe you would like to cherry-pick linux-libc-headers too Mar 04 10:32:56 spaetz: as upgrading those sometimes broke whole workdir Mar 04 10:33:18 Weiss: 2.6.32 without KMS (om-gta02-2.6.32) does not crash Mar 04 10:33:45 can I merge a specific file from one branch to another? Mar 04 10:34:18 spaetz: just preferred version 68364e28d64d54ef0cfd9241e6c6a391ad477245 Mar 04 10:34:27 cool Mar 04 10:34:44 or maybe whole shr/unstable :) Mar 04 10:35:14 does it compile work/ATM? Mar 04 10:35:24 I'll just merge in wall of shr-u and try. Mar 04 10:36:44 spaetz: except that old mesa-dri issue yes Mar 04 10:37:42 merged in. started a recompile from scratch Mar 04 10:38:07 and live memtest is running on shr buildhost.. so don't use it now :) Mar 04 10:38:15 nah, I won^ Mar 04 10:38:18 won' t Mar 04 10:38:21 arrg Mar 04 10:39:15 Weiss: by the way, gtkperf under KMS is now within 10% of non-KMS Mar 04 10:39:26 ie. they perform roughly the same Mar 04 10:39:37 in that test suite Mar 04 10:42:31 although it looks like 2.6.32 is performing ca. 30% worse than 2.6.29 Mar 04 10:42:56 was KMS not supposed to give graphics a speed boost as well? Mar 04 10:43:14 spaetz: well it's not automatic but certainly there is potential Mar 04 10:43:15 oo..cool. I noticed GTK is WAY slower on Xorg (xf86-video-glamo KMS or non-KMS, possibly fbdev is faster..) than on Kdrive.. was never quite able to figure out why Mar 04 10:43:50 that's anyway quite an improvement compared to my October results when KMS was 2x slower than non-KMS Mar 04 10:44:07 dunno why gtk perf is somewhat lower with 2.6.32, though Mar 04 10:44:37 heh, and I still have the funny problem that I cannot open my fbpanel menu in the lower left kernel when using KMS :) that's weird. Mar 04 10:44:38 KMS doesn't boost speed, but DRM allows niceness like allowing the CPU to relax while the GPU works. in practice, see this for why DRM might make things go faster: http://lists.shr-project.org/pipermail/shr-devel/2009-December/001702.html Mar 04 10:44:56 s/kernel/corner/ Mar 04 10:44:57 Mirv meant: heh, and I still have the funny problem that I cannot open my fbpanel menu in the lower left corner when using KMS :) that's weird. Mar 04 10:45:13 hmm.. possibly related to the crash Mar 04 10:45:23 EXA bugs are a pain :( Mar 04 10:45:39 maybe, the literki would pop up when dragging from the lower right corner Mar 04 10:46:18 heyho Mar 04 10:53:28 Mirv: maybe you could try telling x11perf to test a composite operation of some kind? Mar 04 10:55:12 Mirv: I hate the sentence "there is potential". It usually means things get worse and messy for quite a long time :-) Mar 04 10:56:31 the basic point of DRM/KMS is as follows: Mar 04 10:57:14 X.org's acceleration model (EXA) is a lousy match for things like text rendering and GTK, because all the commands get turned into tiny little rectangle operations which can't be meaningfully accelerated Mar 04 10:57:50 but with DRM we have the ability to have many programs all sending their own acceleration commands to the GPU, bypassing all of that mess Mar 04 10:58:12 k Mar 04 10:59:07 the other option would be to add some kind of clairvoyance to EXA.. so it knows what's going to happen in the future when it allocates a buffer or something Mar 04 11:01:20 EXA was really designed to accelerate compositing window managers, not things like GTK Mar 04 11:03:21 it's an architectural screwup which affects all graphics on Xorg, it's just that in most cases the hardware (GPU *and* CPU) is fast enough that you don't notice. we just feel it really badly Mar 04 11:04:18 hehe, well *fast enough* doesn't apply to our setup Mar 04 11:04:28 exactly Mar 04 11:04:59 if things were targetted at the hardware from a high level, then I'm pretty sure we wouldn't even notice the slow Glamo bus Mar 04 11:05:17 * spaetz nods Mar 04 11:05:22 if you want to see how much of a difference this kind of thing can make, compare using TangoGPS on Xglamo to the same on X.org Mar 04 11:24:21 freesmartphone.org: 03morphis 07msmcomm * r7982d9fbf643 10/msmcommd/ (include/msmcomm/internal.h src/msmcommd.c src/relay.c): msmcommd: use a user specific network addr for the relay port Mar 04 11:34:14 mickey|palmSprin: Hi :) can you please ask someone who should be able to do that to update an expired certificate at docs.openmoko.org Mar 04 11:34:52 roh: ? Mar 04 12:14:47 libnl fails to complie Mar 04 12:17:44 Heinervdm: yeah, it failed here too. But the pkg-fso team seems to have managed package it. (and I also managed to compile it, but not cross-compile it) Mar 04 12:18:13 leviathan: do you have solve the problem with libnl? i'm having same problem now Mar 04 12:18:40 Deubeuliou: i'm having that error: http://www.mail-archive.com/shr-devel@lists.shr-project.org/msg01622.html Mar 04 12:19:08 mmmh Mar 04 12:19:16 But others build it correct today with OE: http://tinderbox.openembedded.net/packages/?name=libnl&page=1 Mar 04 12:19:26 I think I had it too, once, but the day after, I couldn't reproduce it anymore Mar 04 12:19:59 I had another one, regarding the members of a struct taht have been changed Mar 04 12:20:05 i think the is a depencie missing Mar 04 12:20:15 I'm not sure Mar 04 12:20:40 iirc, these functions are defined in a locally-built library Mar 04 12:20:43 (and header) Mar 04 12:21:47 perhaps it's some conflict with libnl2 Mar 04 12:22:34 ah, sorry, libnl1 ? Mar 04 12:22:39 didn't notice Mar 04 12:23:03 The problem is, that we use both, libnl1 and libnl2 Mar 04 12:23:21 libnl1 is used in many project, but libnl2 is used in FSO Mar 04 12:24:58 yes, removing libnl2 helped... Mar 04 12:28:33 ok, mesa-dri failed to build... Mar 04 12:28:36 now building gcc Mar 04 12:40:40 freesmartphone.org: 03morphis 07msmcomm * r3409a4a846fa 10/libmsmcomm/ (src/message.c vapi/msmcomm-1.0.vapi): libmsmcomm: we don't need the context when creating a message Mar 04 12:43:19 freesmartphone.org: 03morphis 07msmcomm * r602495e048f4 10/libmsmcomm/vapi/msmcomm-1.0.vapi: libmsmcomm: remove Context from all command messages in vapi Mar 04 12:47:09 freesmartphone.org: 03mickey 07msmcomm * r51318479bd2f 10/libmsmcomm/src/msmcomm.h: libmsmcomm: sync w/ context removal Mar 04 12:56:58 FYI: 13:47:47 < lukhas> JaMa: memtester unconclusive, we'll have to do a "real" memtest86+ this afternoon (CET) Mar 04 13:00:18 freesmartphone.org: 03morphis 07msmcomm * r2e65b3c3eecf 10/libmsmcomm/src/event_system.c: libmsmcomm: complete comment so it don't comment code we need :) Mar 04 13:01:41 freesmartphone.org: 03mickey 07cornucopia * r07cb7bb7376f 10/fsogsmd/src/ (7 files in 2 dirs): fsogsmd: qualcomm_palm: start with own commandqueue, channel, and mediators Mar 04 13:04:01 freesmartphone.org: 03mickey 07msmcomm * rf38864f32fa0 10/libmsmcomm/vapi/msmcomm-1.0.vapi: vapi: fix typos Mar 04 13:12:33 freesmartphone.org: 03mickey 07cornucopia * re2582b8e65e9 10/fsogsmd/ (4 files in 3 dirs): fsogsmd: create configuration for palm pre Mar 04 13:18:12 13:57:06 < JaMa> lukhas: ok, unconclusive with errors or without? Mar 04 13:18:18 14:17:39 < lukhas> JaMa: with errors, but we can't rule out a Xen/memtester interaction Mar 04 13:24:43 ERROR: Task 491 (/home/shr/shr-testing/openembedded/recipes/ffalarms/ffalarms_git.bb, do_compile) faile Mar 04 13:24:58 mmh Mar 04 13:25:23 spaetz: error about next() ? Mar 04 13:26:06 Didn't I push that SRCREV bump? :/ Mar 04 13:28:08 no clue, I am just retrying so I can get the log easily. Mar 04 13:28:37 hmm no.. mmt I'll try even newer revision and push it with mesa-dri patch Mar 04 13:28:51 spaetz: you can replace 2 next() calls with get_next() Mar 04 13:28:52 ffalarms.vala:1157.9-1157.27: error: Too many arguments, method `Eina.Iterator.next' does not take 1 arguments while (iter.next(ref item)) Mar 04 13:29:04 spaetz: as written in my e-mail on ML Mar 04 13:32:23 JaMa: ffalarms is fixed in git Mar 04 13:32:29 according to his reply Mar 04 13:32:30 spaetz: I know :) Mar 04 13:32:42 so we just need to bump versions. should I do that? Mar 04 13:32:44 spaetz: that's why I had newer revision in my patch queue Mar 04 13:33:00 spaetz: but today I noticed that there is even more commits.. Mar 04 13:33:23 so instead of pushing that bump only for efl compatibility I'm trying newest first Mar 04 13:39:34 JaMa: I am compiling the latest ffalarms now. If it compiles I'll push the bump out Mar 04 13:39:58 freesmartphone.org: 03mickey 07cornucopia * r0cd1f165f105 10/libfsobasics/fsobasics/utilities.vala: libfsobasics: strip spaces from /proc/cpuinfo Mar 04 13:41:25 compiles. I'll push it Mar 04 13:41:31 spaetz: ok.. here it will take a bit longer NOTE: Running task 3401 of 4209 Mar 04 13:43:23 NOTE: Running task 7227 of 7231 Mar 04 13:43:26 :) Mar 04 13:43:40 spaetz: but you had to build gcc, I had not :P Mar 04 13:44:24 :) Mar 04 13:46:35 shr-lite done Mar 04 13:46:46 congratz Mar 04 13:46:51 now compiling full. Mar 04 13:47:02 flashing it now... Mar 04 13:47:28 alabd: http://heinervdm.dyndns.info/shr/armv4t/bluez4_4.61-r5.0.4_armv4t.ipk but i could only compile for shr-u not for shr-t, so you probably have to force installation Mar 04 13:48:44 Heinervdm: btw: what happen with your ca-cert.bb? still waiting for reaction on oe-devel? Mar 04 13:49:03 JaMa: ah, yes Mar 04 13:49:19 Heinervdm: please push it :) Mar 04 13:49:28 JaMa: no reaction till now, so i think i can commit it Mar 04 13:49:50 * Heinervdm searches the patch ;) Mar 04 13:50:35 http://patchwork.openembedded.org/patch/1630/ Mar 04 13:51:08 and please also add it to some task*.bb or maybe RRECOMMENS for ventura? Mar 04 13:52:26 RRECOMMENDS for ventura souds ok Mar 04 13:52:28 spaetz: lol.. I fixed mesa-dri for not pulling gcc, and now while building that ffalarms it's pulled by something else anyways ;) Mar 04 13:52:49 :) Mar 04 13:53:06 OE and the Lord have mysterious ways Mar 04 13:55:19 If anyone needs a shr-testing candidate image: http://82.130.119.36/images Mar 04 13:55:25 I am flashing this moment Mar 04 14:00:25 spaetz: edje pulls gcc :) mystery resolved :) Mar 04 14:00:36 Heinervdm: thanks a lot will try Mar 04 14:05:14 JaMa: ahh right, it needs the preprocessor Mar 04 14:06:57 edjcc Mar 04 14:07:14 edje-utils needs gcc Mar 04 14:07:35 and without that one can't change background in illume Mar 04 14:08:06 well it needs cpp Mar 04 14:08:16 as such cpp can be split off from gcc as its own package aand binary Mar 04 14:08:21 but the packages oyu use dont do that Mar 04 14:08:30 stand-alone cpp';s exist out there too Mar 04 14:08:42 but edje_cc requires a cpp to put .edc firles ftrhu for macro handling etc. Mar 04 14:08:50 err edc files thru Mar 04 14:09:20 hmm, so it would be interesting for us, to move cpp to a seperate package Mar 04 14:09:29 correct Mar 04 14:09:38 many desktop distros have done this due to tools doing this Mar 04 14:09:47 raster: o/ Mar 04 14:09:48 xrdb (x resrources) uses cpp too Mar 04 14:09:55 there are other such config files/tools that use it Mar 04 14:09:59 so its nothing new Mar 04 14:10:21 i just followed in the same footsteps - since there is a precedent for it being needed for a simple x login anyway Mar 04 14:10:28 may as well re-use Mar 04 14:10:43 I have some libgsm0710mux logs with failed registrations. It looks like the timeout happens just before the response Mar 04 14:11:15 well cpp is a nice-to-have all days Mar 04 14:11:44 its handy Mar 04 14:11:47 Heinervdm: AFAIK cpp is separate.. Mar 04 14:11:51 its a well known and defined macro processotr Mar 04 14:11:54 Heinervdm: and it's only in RDEPENDS Mar 04 14:12:01 Heinervdm: for edje-utils.. Mar 04 14:12:03 handles all the important bits #ifdef, #define constants, macros etc. Mar 04 14:12:18 and people actually know how to use it Mar 04 14:12:22 unlike.. let's say.. m4 Mar 04 14:12:23 :) Mar 04 14:12:24 JaMa: and why is gcc pulled? Mar 04 14:12:32 Heinervdm: pulled to build queue Mar 04 14:12:41 Heinervdm: to build cpp for runtime :) Mar 04 14:13:09 JaMa: but only for host, not for image? Mar 04 14:13:22 yup.. Mar 04 14:14:25 Heinervdm: libGLU from mesa-dri needed -lstdc++ to build successfully, but seems like lstdc++ from cross is enough.. Mar 04 14:14:44 ah Mar 04 14:14:45 * DocScrutinizer remembers good ole times when he used a macroprocessor to teach pascal "use " statements. (there was no modula yet) Mar 04 14:14:46 Heinervdm: so I was glad that there is no need to build gcc for target for -lite image Mar 04 14:15:14 JaMa: right. It takes long enough as it is :) Mar 04 14:15:17 Heinervdm: and then I started ffalarms build and was surprised that it's used anyways (and always was - for good reason in edje) Mar 04 14:15:50 efreet_xml.c:16:24: error: Ecore_File.h: No such file or directory Mar 04 14:16:14 * JaMa now trying to finish -lite build @ home, before shr buildhost goes down :) Mar 04 14:16:31 Heinervdm: which rev? Mar 04 14:16:45 JaMa: 46510 Mar 04 14:17:05 YAY, I can press dialog buttons! Mar 04 14:17:13 but i can also be my corrupt stagging, i had to rebuild a lot of packages today Mar 04 14:17:24 sqlite, libusb, libnl, ... Mar 04 14:17:44 Heinervdm: linux-libc-headers upgraded already? Mar 04 14:18:02 Heinervdm: last 3 times we bumped it .. bitbake removed whole /usr/include in staging.. Mar 04 14:18:06 JaMa: possible Mar 04 14:18:12 Heinervdm: so I guess you're suffering this now :/ Mar 04 14:18:45 ok, then i will just remove tmp Mar 04 14:18:54 freesmartphone.org: 03mickey 07cornucopia * rbe3f4cc92e72 10/fsogsmd/src/ (lib/modem.vala plugins/dbus_service/plugin.vala): fsogsmd: map modem_type = "qualcomm_palm" to appropriate class Mar 04 14:18:55 for my tests that's enough Mar 04 14:18:57 sorry :/ Mar 04 14:20:45 how can i set cache dir? Mar 04 14:20:52 CACHE = in local.conf? Mar 04 14:23:25 mmh, requesting channel from abyss and then hanging there... Mar 04 14:23:47 abyss still saying starting up... Mar 04 14:24:40 mmh, and no abyss process Mar 04 14:26:37 abyss hangs forever here: 2000-01-13T07:24:53.389247Z [DEBUG] fso-abyss : AllocChannel requested for name ogsmd.call, requested channel 1 Mar 04 14:27:43 raster, could you give me commit access to help mickey|palmSprin with eflvala? Mar 04 14:27:48 mickey|ICE672: are there known fso-abyss issues at the moment? Mar 04 14:28:50 spaetz, laggy connection? Mar 04 14:29:23 me or fso-abyss? :) Mar 04 14:30:06 you Mar 04 14:30:24 mickey left the train about 4h ago ;) Mar 04 14:30:28 I don't think so. why? Mar 04 14:30:32 ohh :) Mar 04 14:30:58 interesting irssi knows about 4 different mickey nicks for tab-completion Mar 04 14:31:58 Heinervdm: yes Mar 04 14:32:15 thx Mar 04 14:32:57 that has been there forever, right? Mar 04 14:32:58 2000.01.13 07:30:16.358 ogsmd.modems.ti_calypso INFO Requesting new channel from 'fso-abyss' Mar 04 14:33:01 2000.01.13 07:30:21.436 ogsmd.modems.abstract.channel WARNING UNHANDLED INTERMEDIATE: OK Mar 04 14:34:31 that's harmless Mar 04 14:34:36 if it only occurs once Mar 04 14:34:40 (for every channel) Mar 04 14:35:37 yes, but I still don't seem to get a channel or something. Mar 04 14:35:41 It never registers Mar 04 14:35:52 and that remains the last log entry in frameworkd Mar 04 14:36:19 resource gsm gets disabled after a while Mar 04 14:36:45 and fso-abyss stops running Mar 04 14:37:00 (it's not in the process list anymore) Mar 04 14:37:58 This is the only output in fso-abyss.log in DEBUG level: http://paste.in.ua/406/ Mar 04 14:38:29 spaetz: try to install fso-abyss-config Mar 04 14:38:41 if it's missing from image Mar 04 14:39:16 I do have a fso-abyss.conf though. Let me check Mar 04 14:40:20 ah right.. you have the one provided from fsogsmd IIRC Mar 04 14:41:09 fso-abyss-config - 1:0.9.1+gitr0+b13b3b31975d5c921326d38a528627cff53b8bb9-r0.4 Mar 04 14:41:16 this was installed in the image by default Mar 04 14:47:48 uhh, SIM PIN dialog after a reboot.... Mar 04 14:48:28 hihi Mar 04 14:58:09 phoneui-messages seems to segfault - is this known or do you want debugging info Mar 04 15:05:59 freesmartphone.org: 03morphis 07msmcomm * r9c6bd546ea16 10/libmsmcomm/ (src/group_call_event.c src/msmcomm.h vapi/msmcomm-1.0.vapi): libmsmcomm: add some get-methods for call_status_event Mar 04 15:05:59 freesmartphone.org: 03morphis 07msmcomm * r4bfd2e931568 10/libmsmcomm/vapi/msmcomm-1.0.vapi: Merge branch 'master' of git.freesmartphone.org:msmcomm Mar 04 15:11:44 freesmartphone.org: 03mickey 07cornucopia * r069e6e790be5 10/fsogsmd/ (3 files in 2 dirs): fsogsmd: start integrating libmsmcomm; send reset command on opening the channel Mar 04 15:21:45 i get a WARNING: Symbol not found: /usr/lib/phoneui/modules/shr.so: undefined symbol: phoneui_backend_phone_log_show Mar 04 15:21:55 and phoneui-messages crashes Mar 04 15:22:25 no further output available although i already use DEBUG loglevel ;( Mar 04 15:23:07 JaMa: shr-t looks good. Fresh flash worked now. I am now upgrading from an existing shr-t to the new shr-t Mar 04 15:23:26 spaetz: great Mar 04 15:23:38 the second error i can find in the logs is WARNING: Erorr opening /usr/share/libphone-ui-shr/config: No such file or directory [btw. you should fix the typo]+ Mar 04 15:23:51 spaetz: hopefully they will replace that RAM and then I'll build exactly the same shr-u as is shr-t now :) Mar 04 15:24:04 :) Mar 04 15:24:07 bumbl: second is harmless for sure Mar 04 15:24:21 bumbl: it's looking for theme config and default theme doesn't need one Mar 04 15:24:23 ok Mar 04 15:24:28 I just forgot copying over the tmp/cache to my build host first Mar 04 15:24:35 bumbl: no idea about first Mar 04 15:24:41 so some packages have lower revision numbers now ... Mar 04 15:24:46 in this test build Mar 04 15:25:12 it seems to have to do with some sms i got because when empty it starts properly Mar 04 15:25:15 spaetz: yeah.. that hard to upgrade :/ Mar 04 15:25:38 * JaMa going home.. bye Mar 04 15:25:42 bye Mar 04 15:25:57 git.shr-project is dead again Mar 04 15:25:57 bumbl: ohh, that probably is my fault :/ Mar 04 15:26:01 reboot? Mar 04 15:26:27 no Mar 04 15:26:35 bumbl's symbol not found segfault :( Mar 04 15:28:41 mrmoku: is there a fix on the way? ;) Mar 04 15:30:03 bumbl: problem is that symbol is in the contacts branch of libphone-ui-shr Mar 04 15:30:12 and I'm not sure we want to merge that yet Mar 04 15:30:29 I fix it anyway Mar 04 15:30:41 but if buildhost and git are down it will take some time :/ Mar 04 15:30:55 freesmartphone.org: 03mickey 07specs * rbd8a5d1cf461 10/ (3 files in 3 dirs): Mar 04 15:30:55 freesmartphone.org: org.freesmartphone.GSM: rename DebugAtCommand back to DebugCommand; we're not Mar 04 15:30:55 freesmartphone.org: only supporting AT here, but rather the language that the respective channel Mar 04 15:30:55 freesmartphone.org: speaks. Add DebugPing. Mar 04 15:31:05 Heinervdm: ping Mar 04 15:31:20 I got these errors on upgrading with conflicting files: http://paste.in.ua/408/ Mar 04 15:31:40