**** BEGIN LOGGING AT Sat Jun 23 02:59:58 2012 Jun 23 09:51:11 hmm Jun 23 09:51:13 i have Jun 23 09:51:14 BB_GENERATE_MIRROR_TARBALLS = "True" Jun 23 09:51:45 but bitbake is always trying to download new stuff from git Jun 23 09:51:47 why ? Jun 23 09:52:10 bitbake -c fetchall succeeds Jun 23 09:52:25 then I remove all git, git2 directories from source dir Jun 23 09:52:31 (tarballs are there) Jun 23 09:52:51 and when I rerun -c fetchall git dirs are created :( Jun 23 16:06:53 m4t: did your glib-2.0/libiconv issues got solved ? Jun 23 16:07:05 nope Jun 23 16:07:19 i actually switched build environments to openwrt a week ago :| Jun 23 16:07:25 hmmm Jun 23 16:08:10 did you find more issues after using --with-libiconv=no Jun 23 16:10:02 m4t: I think we prolly have to dump proxy-libintl and use gettext in angstrom/uclibc Jun 23 16:10:09 like we do in OE-Core Jun 23 16:11:29 okay Jun 23 16:12:52 I am not sure if that will help so much hmm since the problem is glib -> libiconv -> pkgconfig -> glib Jun 23 16:12:58 circular dep Jun 23 16:13:10 yeah Jun 23 16:13:21 m4t: which image were you trying Jun 23 16:13:26 systemd-image Jun 23 16:13:30 modified systemd-image Jun 23 16:13:30 ok Jun 23 16:13:36 but just a few extra deps Jun 23 16:13:36 yeah thats fine Jun 23 16:13:44 so you need a console image kind of Jun 23 16:13:59 yep no video just ttys0 Jun 23 16:14:40 ok let me check the depchain Jun 23 16:14:40 im stuck with another issue unrelated atm, trying to get this 3.1 arch/arm/mach- to 3.2 Jun 23 16:14:55 ok Jun 23 16:14:59 what is it Jun 23 16:15:04 smp hang right after smp_init() Jun 23 16:15:28 its not a mainline arch, its an up-port someone did from propietary 2.6.31 sources to 3.1.10 Jun 23 16:15:41 i see Jun 23 16:15:50 lot have chnaged between those two vers Jun 23 16:16:06 the major changes i saw where boot_parms going to atag_offset Jun 23 16:16:43 and mach/memory.h requiring NEED_MACH_MEMORY_H in arm/Kconfig Jun 23 16:17:11 building without CONFIG_SMP results in a booting apparently stable kernel with just 1 core active Jun 23 16:17:44 oh this is mpcorw Jun 23 16:17:46 i added some #pragma message to check the macros in platsmp.c and everything was identical Jun 23 16:17:48 mpcore Jun 23 16:17:52 yeh its mpcore Jun 23 16:18:01 similar to mach-realview Jun 23 16:18:11 ok make sure the forward port is smp safe Jun 23 16:19:17 hmmm glib-2.0 depends on pkgconfig and pkgconfig depends on glib-2.0 Jun 23 16:19:23 thats a closed loop Jun 23 16:20:55 but thats same on OE-Core too Jun 23 16:21:04 so I wonder now how it works in OE-Core Jun 23 16:21:57 was it Jun 23 16:22:02 the angstrom inc Jun 23 16:22:10 that specifies USE_nls Jun 23 16:22:51 conf/distro/include/angstrom-uclibc.inc:USE_NLS_glib-2.0 = "yes" Jun 23 16:22:59 thats same in OE-Core Jun 23 16:23:02 oh Jun 23 16:23:04 you can not build glib without it Jun 23 16:23:50 what would be an example of something not smp safe? from 3.1 to 3.2? Jun 23 16:24:03 it works with 3.1 ? Jun 23 16:24:06 yeah Jun 23 16:24:14 oh i did not know that bit Jun 23 16:24:17 heh Jun 23 16:27:49 if you feel like wasting a few minutes: https://github.com/WarheadsSE/OX820-3.1-Linux/commits/master/arch/arm/mach-ox820 Jun 23 16:27:59 https://github.com/WarheadsSE/OX820-3.1-Linux/tree/master/arch/arm Jun 23 16:38:57 m4t: is this a new chip Jun 23 16:40:37 nope 3-4 years old i think Jun 23 16:41:15 its used in a few nas devices Jun 23 16:42:27 pogoplug, thecus, medion Jun 23 16:43:09 2x700mhz mpcorenovfp Jun 23 16:49:14 moin Jun 23 16:54:59 m4t: ok, ARM: 7196/1: errata: Remove SMP dependency for erratum 720789 ARM: 7197/1: errata: Remove SMP dependency for erratum 751472 Jun 23 16:55:12 see if those are causing your issue Jun 23 16:56:34 will do, thanks Jun 23 17:01:47 hmm it says only cortex-a9 are affected Jun 23 17:34:30 m4t: what kind of mpcore do you have ? Jun 23 17:34:36 is it 1176 Jun 23 17:34:45 hi khem Jun 23 17:34:51 khem i'm not sure Jun 23 17:34:54 i think so Jun 23 17:35:23 hmm Jun 23 17:37:05 i tried a bunch of things and started to add debug printks to init/main.c Jun 23 17:37:13 I might have fixed the iconv/glib-2.0 issue for good. Jun 23 17:37:16 lets see Jun 23 17:37:24 I have some patches brewing Jun 23 17:37:34 there are not many changes in the mach-* from 3.1 to 3.2 in others Jun 23 17:37:46 khem which iconv/glib-2.0? Jun 23 17:37:47 m4t: can you point me to diff of forward port ? Jun 23 17:37:55 glib removed the gettext stuff Jun 23 17:37:56 woglinde: with angstrom Jun 23 17:38:05 which included libiconv for uclibc Jun 23 17:38:06 we dont use gettext Jun 23 17:38:18 but glib-2.0 now needs libiconv Jun 23 17:38:25 yes Jun 23 17:38:30 khem yes i can Jun 23 17:38:43 and no-iconv patch I had in OE-Core was faulty so that needed to go Jun 23 17:38:58 and coreutils complains about libiconv beeing in /usr/lib Jun 23 17:39:05 so now I have added mini-iconv package which will provide small libiconv Jun 23 17:39:23 on the same line of proxy-libintl Jun 23 17:39:47 so now we can shunt both gettext and libiconv Jun 23 17:39:58 and I am hopeful that even NLS wont be needed Jun 23 17:40:04 to build glib-2.0 Jun 23 17:40:35 woglinde: england vs italy today :) Jun 23 17:41:01 yes Jun 23 17:41:13 one hour Jun 23 17:41:15 togo Jun 23 17:41:20 khem in fact there are no changes :| Jun 23 17:41:42 woglinde: yes I am waiting for it Jun 23 17:41:49 m4t: so the patch applied cleanly Jun 23 17:41:56 include export.h, remove a deprecated arg from oxnas_fixup (struct machine_desc *desc,) Jun 23 17:42:13 hmm then it could be an interaction issue Jun 23 17:42:15 the mach-ox820 did, its a new arch Jun 23 17:42:46 and NEED_MACH_MEMORY_H in Kconfig Jun 23 17:44:05 it hangs right before CPU1: Booted secondary processor Jun 23 17:44:23 i want to say it has to do with the PHYS_OFFSET being wrong, but how would that affect only SMP? Jun 23 17:48:23 good Jun 23 17:48:24 NOTE: package openjdk-7-jre-03b21-2.1.1-r1.0: task do_rm_work_all: Succeeded Jun 23 17:49:31 woglinde: did you see that mail about integrating gradle Jun 23 17:51:46 hm Jun 23 17:51:50 yes Jun 23 17:51:57 didnt I answer? Jun 23 17:52:04 I did nothing before with gradle Jun 23 17:52:10 maven does all things nice Jun 23 17:55:58 woglinde: so I wonder one thing Jun 23 17:56:18 woglinde: in a mixed env where you have bit of C and bit of java with gradle/maven Jun 23 17:56:18 hm? Jun 23 17:56:33 how can this retrofit using OE Jun 23 17:56:38 okay Jun 23 17:56:53 never set up a jni project yet with maven Jun 23 17:58:21 woglinde: thinking from system integration POV Jun 23 17:58:44 some bits are in java and some bits are in C ( kernel + glibc etc.) Jun 23 17:58:56 and now one needs to put a total system together Jun 23 17:59:12 and I am thinkin of OE being the vehicle here Jun 23 17:59:44 o.O Jun 23 18:00:02 you can do it with meta-java Jun 23 18:00:08 dont understand the problem Jun 23 18:00:16 ok Jun 23 18:00:54 there are I think two workflows Jun 23 18:00:59 its a workflow issue Jun 23 18:01:30 o.O Jun 23 18:04:45 hi florian Jun 23 18:08:39 woglinde: how do you deliver java to developers Jun 23 18:09:02 woglinde: iow people like to use eclipse and stuff Jun 23 18:11:20 hi all Jun 23 18:12:42 khem opkg install java Jun 23 18:12:44 ? Jun 23 18:12:56 cross development Jun 23 18:13:48 o.O? Jun 23 18:16:15 so here is the deal Jun 23 18:16:34 people want to use normal boxes for regular development Jun 23 18:28:50 sorry khem Jun 23 18:28:52 -> < khem> people want to use normal boxes for regular development Jun 23 18:28:58 that was the last I was seeing Jun 23 18:30:01 woglinde_: yes I mean they want to do dev work on desktops Jun 23 18:30:09 sort of cross dev env Jun 23 18:30:27 ok game beginning Jun 23 18:30:47 in 15 minutes Jun 23 20:37:58 khem ping Jun 23 20:38:10 khem we need this patch http://lists.uclibc.org/pipermail/uclibc/2012-April/046679.html Jun 23 20:38:13 for systemd Jun 23 20:38:23 or better systemd-journal lib Jun 23 21:26:06 woglinde: I know, but it needs some testing Jun 23 21:26:19 woglinde: I will queue it into OE-Core uclibc/git recipe Jun 23 21:26:32 so it can be tried out Jun 23 21:29:44 hm trying it here too Jun 23 21:30:47 ok Jun 23 21:31:27 There was a fish in India which was predicting Euro 2012 results correctly for past 7 games went wrong today :) Jun 23 21:31:35 predicted france to win Jun 23 21:31:58 spain is to good Jun 23 21:32:18 only germany can win against them Jun 23 21:32:30 we will see in the final Jun 23 21:32:40 yeah but Portugal is good too :) Jun 23 21:33:19 portugal will loose 1:0 against spain Jun 23 21:33:41 hmm Jun 23 21:34:44 like they did against us Jun 23 21:35:05 I think last two games they played were lot better Jun 23 21:35:20 so I think they pose a serious threat to spain **** ENDING LOGGING AT Sun Jun 24 02:59:58 2012