**** BEGIN LOGGING AT Sun Nov 15 02:59:56 2009 Nov 15 03:15:10 mturquette, I know sakoman has been working on gnome stuff in his spare time and koen has been pushing stuff occasionally Nov 15 03:18:34 mturquette: look at angstrom-task-gnome.bb Nov 15 03:18:50 koen based it on my gnome image Nov 15 04:18:23 re Nov 15 09:53:21 hmm Nov 15 09:53:26 ~lart ltrace Nov 15 09:53:27 * ibot hauls ltrace up by the scruff of the neck and spanks him until he waddles Nov 15 09:55:45 aha Nov 15 09:55:46 oe_runmake install ${EXTRA_OEMAKE} ARCH=${LTRACE_ARCH} INSTALL=${STAGING_BINDIR_NATIVE}/install DESTDIR=${D} Nov 15 09:55:58 that's wrong Nov 15 09:56:04 or missing a dependency to coreutils-native Nov 15 10:08:58 03Michael 'Mickey' Lauer  07org.openembedded.dev * r7df40b3378 10openembedded.git/recipes/ltrace/ (ltrace_0.4.bb ltrace_0.5.3.bb): ltrace: fix wrong path to coreutils-native and add actual dependency Nov 15 10:28:51 Hi, I've made a new machine configuration and corresponding kernel for the Samsung Omnia (SGH-i900). How do I go about merging it? Nov 15 10:29:00 File a bug report under OE Metadata? Nov 15 10:29:54 while i personally would appreciate a bug report, there's a majority in favour of sending patches to the list Nov 15 10:30:31 I can do either, though I guess a bug report will help with information retrieval, if it's ever needed by anyone. Nov 15 10:30:46 Does a tarred directory tree do? Nov 15 10:31:01 individual patches would be better Nov 15 10:31:08 OK Nov 15 10:31:08 if it's a tree, you might rather open a bug Nov 15 10:31:27 how's the state of GNU/Linux on the omnia? Nov 15 10:31:36 last i heard was that you have problems deciphering the modem language Nov 15 10:31:41 is that fixed? Nov 15 10:31:48 It's a conf/machine/sgh-i900.conf file and a linux-sgh-i900_2.6.29.bb file with a folder containing firmware images Nov 15 10:32:01 GSM works, but no sound Nov 15 10:32:13 Actually, ALSA works too but it's a bit of a mess Nov 15 10:32:26 ya, sound is always non-straightforward Nov 15 10:32:45 how's routing controlled on the omnia? Nov 15 10:33:21 You'd have to ask the kernel developers on Andromnia for that, I'm not sure about the specifics Nov 15 10:33:40 It's basically implemented in the kernel and exposed as a library. Nov 15 10:33:41 "Andromnia"??? Nov 15 10:33:43 oh fsck Nov 15 10:33:47 heh Nov 15 10:33:51 let me guess what they're trying to do... Nov 15 10:33:53 *sigh* Nov 15 10:34:09 They're the only ones actively working on a kernel, so it's all good in any case. Nov 15 10:34:19 I'm more interested in OpenMoko Nov 15 10:36:34 I'll make it into a tarred directory tree then, since it also contains binary data (the firmware images). Nov 15 10:36:49 righto Nov 15 10:46:40 Thanks for your help, mikeyl. Nov 15 10:47:05 * * OE Bug 5335 has been created by ThoughtMonster(AT)gmail.com Nov 15 10:47:07 * * Initial support for the Samsung Omnia (SGH-i900) Nov 15 10:47:09 * * http://bugs.openembedded.org/show_bug.cgi?id=5335 Nov 15 10:51:53 Hi guys. I am trying to build Ångström following http://www.angstrom-distribution.org/building-ångström. Nov 15 10:52:07 But do_configure of gmp-native fails for me. Nov 15 10:52:36 checking size of mp_limb_t... 4 configure: error: Oops, mp_limb_t is 32 bits, but the assembler code in this configuration expects 64 bits. You appear to have set $CFLAGS, perhaps you also need to tell GMP the intended ABI, see "ABI and ISA" in the manual. FATAL: oe_runconf failed Nov 15 10:53:23 This seems to be related to openembedded and I think it is related to that I am using a 64-bit Linux kernel but a 32-bit user space. Nov 15 10:56:51 I asked this yesterday an #angstrom and was told to post to the mailing list. I tried to do so, but my last attempt was rejected with »The message's content type was not explicitly allowed«. Nov 15 10:57:24 I am subscribing to openembedded-devel now and hope that it will work there, now that I know what the cause of the problem could be. Nov 15 10:57:54 Unfortunately I do not know how to solve it besides booting with a 32-bit Linux. Nov 15 11:03:11 mickeyl: good morning Nov 15 11:03:50 morning pb__ Nov 15 11:04:56 PaulePanter: i don't think anyone else is doing that, perhaps the system experts know a solution for that Nov 15 11:06:35 mickeyl: Are they on this channel? Nov 15 11:06:59 while some may, it's better to use the mailing list Nov 15 11:07:12 I am trying to build gmp normally now to see if it is a gmp upstream problem. Nov 15 11:07:46 But this requires automake-1.8 or a ylwrap script. So I am not done yet Nov 15 11:07:48 . Nov 15 11:09:33 Found the script. https://fedorahosted.org/xmlto/export/50/ylwrap Nov 15 11:11:54 Ok. Configuring http://gmplib.org:8000/gmp/ works without any errors. Nov 15 11:13:07 There is no ./configure in the repository (.bootstrap creates it) so I do not know what to compare. Nov 15 11:13:26 I am still waiting for the confirmation of the mailing list. Nov 15 11:14:53 Does anyone know if there is a OE Git branch including GMP 4.3? Nov 15 11:15:26 Or which OE Git branch includes the recent packages? Nov 15 11:15:41 origin/org.openembedded.dev? Nov 15 11:23:50 PaulePanter, i've bumped gmp and mpfr and others. Let me try to find a place where i can put them for you Nov 15 11:26:21 mmm is mplayer broken? when I compiled a static version of it I got : Nov 15 11:26:26 vo_x11.c:(.text+0xd8): undefined reference to `XPutImage' etc... Nov 15 11:27:15 but it doesn't complain about the missings .h Nov 15 11:29:52 PaulePanter, priv msg. I'll rm it in 30 minutes Nov 15 11:35:18 blindvt: I got it. Thank you. Nov 15 11:36:15 ah ok it's linking Nov 15 11:36:33 blindvt: So I just create a new branch based on stable2009 and mv your files over it? Nov 15 11:37:37 PaulePanter, yes. If you're super-cautious, you only put the new files in it (i simply tared the whole dirs out of lazyness) Nov 15 11:56:21 Now I have a »NOTE: Missing checksum«. Nov 15 11:56:25 NOTE: Missing checksum Nov 15 11:56:25 ERROR: gmp-native-4.3.1: ftp://ftp.gnu.org/gnu/gmp/gmp-4.3.1.tar.bz2 has no entry in conf/checksums.ini, not checking URI Nov 15 11:56:28 ERROR: Error in executing: /srv/filme/oe/openembedded/recipes/gmp/gmp-native_4.3.1.bb Nov 15 11:56:31 ERROR: Exception: Message:1 Nov 15 11:56:33 ERROR: Printing the environment of the function Nov 15 11:56:36 ERROR: Error in executing: /srv/filme/oe/openembedded/recipes/gmp/gmp-native_4.3.1.bb Nov 15 11:56:39 ERROR: Exception: Message:1 Nov 15 11:56:41 ERROR: Printing the environment of the function Nov 15 11:56:55 ERROR: Build of /srv/filme/oe/openembedded/recipes/gmp/gmp-native_4.3.1.bb do_fetch failed Nov 15 12:02:33 I will follow http://wiki.openembedded.net/index.php/Checksums in an instant. Nov 15 12:03:04 PaulePanter, there's a readme entry on how you can cat the new checksums to the ini and how to run a python-script to sort them Nov 15 12:03:09 PaulePanter, exactly Nov 15 12:04:11 (it's not exactly convenient that you have to do that manually imho; Perhaps it will change in the checksums.ini overhaul, didn't look) Nov 15 12:14:04 good morning Nov 15 12:14:45 hi Nov 15 12:14:51 florian: I should bother you again about wiki :) Nov 15 12:49:39 OK, a question of etiquette. Nov 15 12:50:32 I build a kernel for the Samsung Omnia which expects the firmware files gspi8686.bin and gspi8686_hlp.bin to be in the "firmware" folder at build-time. Nov 15 12:50:47 They are statically linked inside the kernel. Nov 15 12:52:11 I see nothing against that in the licence disclaimer, so I believe it's legal. Nov 15 12:52:48 Normally, I have the raw firmware files and I just add them to SRC_URI and then move them in the proper directory with configure_prepend Nov 15 12:53:14 But a package for these firmware files exists under the name marvell-gspi-fw Nov 15 12:53:44 Question: Is it right to DEPEND on this and copy the files from STAGING_LIB_DIR or whatever into the work directory? Nov 15 12:53:58 Or will I get flamed? Nov 15 12:58:09 blindvt: NOTE: Task failed: Error: /openembedded/recipes/gmp/gmp-4.3.1/configure.patch not found. Nov 15 12:58:30 blindvt: It is also not in your archive you sent me. Nov 15 12:58:40 blindvt: Is this needed? Nov 15 13:28:04 mmm might be related to the static thing Nov 15 13:34:36 because mplayer builds but not my static version Nov 15 14:46:08 B_Lizzard: I'm not sure that you can link arbitrary binary blobs into the kernel without making the resulting kernel impossible to distribute. But, yes, if you want to do that, copying them out of staging is legitimate. Nov 15 14:46:43 Is it a licencing issue? Nov 15 14:47:13 Yes. Nov 15 14:47:27 :/ Nov 15 14:49:47 Even when they're included with CONFIG_EXTRA_FIRMWARE? Nov 15 14:49:55 Isn't that a bit retarded? Nov 15 14:50:19 Considering that CONFIG_EXTRA_FIRMWARE exists for such purposes. Nov 15 14:50:35 Anyways, thanks a lot, pb__ Nov 15 14:51:56 I'll just distribute them along with the kernel, then. Nov 15 14:54:47 Ok I still do not know what to do with the error from 1:58 p. m. Nov 15 14:54:54 CEt Nov 15 14:54:58 CET Nov 15 14:55:16 Therefore I set up a virtual machine which is using all 32-bit. Nov 15 14:56:06 This failed with ERROR: function do_stage failed. Nov 15 14:56:44 It has to do with coreutils-native. Nov 15 14:57:44 Damn and I must be stupid. It is because 2 GB space is not enough to build Ångström. Sorry for bothering. Nov 15 14:58:07 Just to not. /dev/vda1 5,9G 4,5G 1,1G 81% / Nov 15 14:59:07 … after the error. Trying to run bitbake gives you »sqlite3.OperationalError: unable to open database file«. Nov 15 14:59:37 This message might some of you remember. At least according to Google some asked this already. Nov 15 14:59:53 So next time one further point to look at. Nov 15 16:11:31 Just for reference for the Web log. The problem in 15:59 CET was, that I did not have any free inodes anymore (`df -i`). Nov 15 16:17:20 `bitbake base-image` gives me now an error trying to compile /armv7a-angstrom-linux-gnueabi/binutils-cross-2.18.50.0.7-r6/binutils-2.18.50.0.7/binutils/readelf.c. Nov 15 16:17:34 /srv/filme/oe/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/binutils-cross-2.18.50.0.7-r6/binutils-2.18.50.0.7/binutils/readelf.c:4111: error: duplicate case value Nov 15 16:17:37 /srv/filme/oe/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/binutils-cross-2.18.50.0.7-r6/binutils-2.18.50.0.7/binutils/readelf.c:4110: error: previously used here Nov 15 16:19:04 I did not see this before. Does anyone have an idea? Nov 15 16:42:04 * * OE Bug 5336 has been RESOLVED (INVALID) by thommycheck(AT)gmx.de Nov 15 16:42:06 * * Can't flash the colli anymore Nov 15 16:42:08 * * http://bugs.openembedded.net/show_bug.cgi?id=5336 Nov 15 18:51:11 morning kergoth Nov 15 18:53:04 ibot, change 6775 chf to gbp Nov 15 18:53:10 i got some error trying that Nov 15 18:53:14 doh Nov 15 18:53:20 * pb__ stabs ibot Nov 15 19:02:52 03Martin Jansa  07org.openembedded.dev * rf3a637b546 10openembedded.git/recipes/shr/ (19 files in 2 dirs): Nov 15 19:02:52 shr themes: new recipes from shr/merge Nov 15 19:02:52 Signed-off-by: Klaus Kurzmann Nov 15 19:02:53 03Martin Jansa  07org.openembedded.dev * r588e21b7a6 10openembedded.git/recipes/shr/ (26 files): Nov 15 19:02:53 shr recipes: switch SRCREV->SRCPV, without PE bump Nov 15 19:02:56 * as shr recipes weren't complete in oe.dev before, so if there was Nov 15 19:02:58 someone already building those before, please rebuild them Nov 15 19:03:00 Signed-off-by: Klaus Kurzmann Nov 15 19:03:02 03Martin Jansa  07org.openembedded.dev * rf18414059f 10openembedded.git/recipes/shr/ (12 files): Nov 15 19:03:05 shr phone applications: new recipes Nov 15 19:03:07 Signed-off-by: Klaus Kurzmann Nov 15 19:03:09 03Martin Jansa  07org.openembedded.dev * raf10e8c2d1 10openembedded.git/recipes/shr/initscripts-shr_git.bb: Nov 15 19:03:12 initscripts-shr_git.bb: renamed to recipes/shr/initscripts-shr_0.0.1.bb, because its not git recipe Nov 15 19:03:14 Signed-off-by: Klaus Kurzmann Nov 15 19:03:16 03Martin Jansa  07org.openembedded.dev * r52b9d26f27 10openembedded.git/recipes/shr/ (13 files): Nov 15 19:03:19 illume-keyboards: add more keyboard definitions from shr/merge Nov 15 19:03:27 Signed-off-by: Klaus Kurzmann Nov 15 19:03:29 03Martin Jansa  07org.openembedded.dev * r0c8459574b 10openembedded.git/recipes/openmoko-panel-plugins/ (9 files): Nov 15 19:03:32 openmoko-panel-plugins: change svn${SVNREV} to svnr${SRCPV} Nov 15 19:03:34 * Only formal change Nov 15 19:03:36 * Should be safe as version svnr[1234567890]* > svn[1234567890]* Nov 15 19:03:38 * Only those bb are using SVNREV from openmoko2.class where its set to "r${SRCREV}" Nov 15 19:03:40 Signed-off-by: Martin Jansa Nov 15 19:03:42 Signed-off-by: Klaus Kurzmann Nov 15 19:13:14 re Nov 15 19:50:26 03Martin Jansa  07org.openembedded.dev * r6187540bc3 10openembedded.git/recipes/efl1/ (12 files): Nov 15 19:50:26 illume keyboards: switch from SRCREV to SRCPV Nov 15 19:50:26 Signed-off-by: Klaus Kurzmann Nov 15 19:50:37 03Martin Jansa  07org.openembedded.dev * r87b9249a50 10openembedded.git/recipes/shr/ (13 files): Nov 15 19:50:37 Revert "illume-keyboards: add more keyboard definitions from shr/merge" Nov 15 19:50:37 This reverts commit 52b9d26f27203c9df18fa4f4855cb006af800c0b. Nov 15 19:50:37 Signed-off-by: Klaus Kurzmann Nov 15 20:16:00 Hello everyone ... I am trying to build openembedded image and getting following error immediately after doing bitbake x11-image Nov 15 20:16:12 NOTE: Handling BitBake files: - (7517/7517) [100 %] Nov 15 20:16:22 NOTE: Parsing finished. 7150 cached, 68 parsed, 298 skipped, 0 masked. Nov 15 20:16:32 ERROR: Parsing errors found, exiting... Nov 15 20:16:35 what is the error? Nov 15 20:17:15 it says its a parsing error and exit the build process Nov 15 20:18:04 http://pastebin.com/m45e677f2 Nov 15 20:18:46 classes/girepository.bbclass Nov 15 20:19:01 look in the recipe it mentions and fix the typo? Nov 15 20:19:48 more a problem, I do not see anything in classes that looks like that Nov 15 20:20:53 what branch are you using? Nov 15 20:21:01 I do not see any of those in .dev Nov 15 20:21:01 it says nothing about .... where an error is Nov 15 20:21:18 line 3? Nov 15 20:21:19 org.openembedded.dev Nov 15 20:21:55 yeah thats it ... parsing error .. but no more information Nov 15 20:24:24 yeah i checked classes and couldnot find anything like classes/girepository.bbclass Nov 15 20:27:04 yeah Nov 15 20:27:12 these files are not in dev Nov 15 20:27:23 wait Nov 15 20:27:33 came in recent update Nov 15 20:27:50 oh ok .... so what should i do to resolve this error Nov 15 20:28:38 looks like someone commited some stuff without the needed class Nov 15 20:28:53 need to send something to the list Nov 15 20:29:01 let me see if I can do it quickly Nov 15 20:29:06 ok Nov 15 20:32:58 I emailed dev, hopefully someone that know what is intended and can commit a fix quickly Nov 15 20:33:39 Crofton: I know.. will fix in a minute.. Nov 15 20:33:41 ok thanks .. i will try again after sometime Nov 15 20:33:46 yeah Nov 15 20:33:50 sorry about that Nov 15 20:34:01 mrmoku: can you add classes/girepository.bbclass to oe.dev? Nov 15 20:34:12 JaMa, thanks, I can't see a quick fix, looks like a typo to me :) Nov 15 20:34:39 Crofton|work: there is classes/girepository.bbclass in shr/merge.. probably mrmoku will know why and if its still needed.. Nov 15 20:34:43 JaMa: moment Nov 15 20:35:45 girepository was added by ptitjes Nov 15 20:36:37 it might be it is not necessary anymore... Nov 15 20:36:40 I was expecting gitrepository :) Nov 15 20:36:41 mickey|bbl: should know Nov 15 20:37:00 Crofton|work: If it fixes parsing I can just add it Nov 15 20:37:19 maybe try removing it and see if the recipe builds Nov 15 20:37:45 JaMa: can you try that for oe.dev? Nov 15 20:37:45 girepository is just three-liner Nov 15 20:37:49 +FILES_${PN} += "${datadir}/gir-1.0/*.gir" Nov 15 20:37:50 +FILES_${PN}-dev += "${datadir}/gir-1.0/*.gir" Nov 15 20:37:52 +FILES_${PN} += "${libdir}/girepository-1.0/*.typelib" Nov 15 20:38:11 all: /ignore CIA-2 as there will will be big flood in few mins.. (merge) Nov 15 20:38:19 mrmoku: sure.. just after push.. Nov 15 20:38:26 even two-liner, as -dev part is commented out :P Nov 15 20:39:51 someone fixed CIA not to send merge commits? :) Nov 15 20:39:57 JaMa: it is just used in libmodulo... Nov 15 20:40:00 or maybe its busy parsing.. Nov 15 20:40:09 JaMa: we should just remove it from there for now Nov 15 20:40:19 and ask mickey|bbl if it is still needed Nov 15 20:40:32 IIRC it is not needed anymore... might be wrong though Nov 15 20:42:43 mrmoku: whole libmodulo recipe? Nov 15 20:42:49 mrmoku: or just that inherit? Nov 15 20:44:39 JaMa: just that inherit Nov 15 20:44:50 ok checking now.. Nov 15 20:52:51 03Martin Jansa  07org.openembedded.dev * r6824a82653 10openembedded.git/recipes/openmoko-panel-plugins/ (9 files): Nov 15 20:52:51 openmoko-panel-plugins: change svn${SVNREV} to svnr${SRCPV} Nov 15 20:52:51 * Only formal change Nov 15 20:52:51 * Should be safe as version svnr[1234567890]* > svn[1234567890]* Nov 15 20:52:51 Signed-off-by: Martin Jansa Nov 15 20:53:03 03Martin Jansa  07org.openembedded.dev * rc010062f3c 10openembedded.git/: Merge branch 'org.openembedded.dev' of git.openembedded.org:openembedded into org.openembedded.dev Nov 15 20:53:04 03Martin Jansa  07org.openembedded.dev * r29d6bcd858 10openembedded.git/recipes/shr/libmodulo_git.bb: libmodulo: remove girepository inherit Nov 15 20:53:26 amitshah: now it should be ok again Nov 15 20:53:33 amitshah: sorry for that Nov 15 20:54:03 thanks for the update ... i will try again and will update community if it works Nov 15 20:54:06 thanks Nov 15 20:54:57 JaMa: thanks for the commit, just wondering what girepository was ;) Nov 15 20:55:24 DJWillis: http://cgit.openembedded.net/cgit.cgi/openembedded/tree/classes/girepository.bbclass?h=shr/merge Nov 15 20:55:45 ahhh, it's only in shr, looking now, thanks. Nov 15 20:56:23 DJWillis, Crofton|work: btw: what's your opinion about SRCREV->SRCPV migration? as I sent to oe-devel ML and now its in martin_jansa/srcpv branch? Nov 15 20:58:06 JaMa: personally, I am all for it as it would give more consistency but as I am not an OE dev I did not feel it was my place to comment. Not sure about the PE bump for GIT but I can't see another way. Nov 15 21:02:59 yeah it fixed and working fine Nov 15 21:03:40 I haven't read enough to have a good opinion Nov 15 21:05:20 ok fair enough, thanks Nov 15 21:05:40 thanks for fixinf dev Nov 15 21:06:14 sorry for breaking it.. :/ Nov 15 21:31:49 hi, I saw some smartbook with an IMX51 that has an AMD Z160 / Z430 GPU...is there a free software driver for the GPU? Nov 15 21:32:41 mwester: what can we do with our twins tmpdir? e-bay one :=) ? Nov 15 21:33:21 hehe! Nov 15 21:33:53 seems nobody else had/noticed... Nov 15 21:34:18 find / -name 'opkg' -exec rm -rf {}; Nov 15 21:34:21 or something like that Nov 15 21:59:44 mwester: btw, rebuilding tcl-native: Nov 15 21:59:46 cp: cannot stat `/oe/build/tmp/work/i686-linux/tcl-native-8.4.19-r3/image/*': No such file or directory Nov 15 22:00:29 is not fatal, pb was hinting is an issue of legacy-staging-code perhaps Nov 15 22:00:55 I don't think anything I build uses tcl-native -- is it just that recipe? Nov 15 22:01:08 eh..you missed th esqlite3 story... Nov 15 22:01:34 yes, I did -- I think I was lost in python-wont-build-land. Nov 15 22:01:49 eh..that was just the failure before Nov 15 22:01:54 :) Nov 15 22:02:21 NOTE: Legacy staging mode for /oe/org.openembedded.dev/recipes/tcltk/tcl-native_8.4.19.bb Nov 15 22:03:18 RP will take care :) Nov 15 22:06:36 ant__: ? Nov 15 22:09:34 RP is the master. He'll fix everything :) Nov 15 22:09:52 :) Nov 15 22:10:05 RP: about tcl-native again Nov 15 22:10:05 mwester: I wish :/ Nov 15 22:10:18 the build finishes Nov 15 22:10:37 ant__: ah, but it prints something ons tderr Nov 15 22:10:49 pb was thinking here some bits of the old staging code could overlap Nov 15 22:11:25 he explained better...mom Nov 15 22:12:09 ant__: I don't think its that... Nov 15 22:12:16 * RP has scrollback Nov 15 22:12:26 yea Nov 15 22:12:33 I cut the logs :/ Nov 15 22:13:13 *** glibc detected *** opkg-cl: realloc(): invalid next size: 0x00000000018cb880 *** Nov 15 22:13:18 I love opkg .... Nov 15 22:13:45 Crofton|work: see if it sneaked in a second tmpdir under your oetree... Nov 15 22:14:17 andrea@mizar /oe/build/tmp/oe/build/tmp $ ls Nov 15 22:14:17 cross staging Nov 15 22:15:19 opkg just sucks. Nov 15 22:15:22 see where is opkg status :( Nov 15 22:15:24 andrea@mizar /oe/build/tmp/oe/build/tmp/cross/armv5te/lib/opkg $ ls Nov 15 22:15:24 info status Nov 15 22:16:10 it's a lesson that sometimes the technical costs of a political battle are too high to bear. Nov 15 22:16:36 mwester: political battle? Nov 15 22:16:39 I still think we could/should have found a way to fix up ipkg rather than take on opkg. Nov 15 22:17:07 mwester: Has ipkg moved forwards at all since then? Nov 15 22:17:25 what's the major difference with ipkg/opkg? i thought it was just bug fixes+curl Nov 15 22:18:00 probably not. but then the only thing that has moved forward with opkg is that we understand more and more bugs -- there has been no concerted development community that has undertaken the effort to gut and repair opkg. Nov 15 22:18:32 A few individuals (I included) have undertaken some work on opkg, but all have given up (to date anyway) at some point. Nov 15 22:18:47 mwester, i suggest you take a quick look at the changes i've been making... http://code.google.com/p/opkg/source/list Nov 15 22:18:49 mwester: Be thankful some bugs have been fixed in opkg Nov 15 22:19:01 RP, I'm thankful for that. Nov 15 22:19:28 But the unanimous conclusion of those who have investigated opkg is that huge parts of it need rewriting, and that hasn't (yet) happened. Nov 15 22:19:46 there seems to be a lot of bitching about opkg and many patches around the place. but lots of the patches dont get sent back to the list or the bugtracker Nov 15 22:20:10 mwester: I'm one of those people who have concluded that :/ Nov 15 22:20:16 The patches don't solve the problem. They are placing bandaids on a limb that's been through a meat grinder. Nov 15 22:20:35 yes, but at least it exposes areas that need work. Nov 15 22:20:45 They keep the patient alive for a while longer, but the fundamental issues remain. Nov 15 22:21:18 We need to find someone to lead a team to rewrite the core broken-ness. (I have not the skills, so I certainly cannot do it) Nov 15 22:21:31 the fundamental issues i've seen are: too many allocations that aren't checked for failure, too much memory abuse in general Nov 15 22:22:07 all allocations should now be checked, ensuring graceful failure instead of random shit.... Nov 15 22:22:15 Architectural problems abound; there is no discernably consistent architecture to the core. Nov 15 22:22:51 i agree. but the barrier to entry is just too high for most because of the shittyness of the code Nov 15 22:23:20 For example, I'm struck that parts of it use the highly-optimized libbbb from busybox, while other parts use high-level/high-cost interfaces such as "fork()" and system(). Nov 15 22:24:00 really the only bit from busybox is the decompression routines Nov 15 22:24:05 Alas, a rewrite is a huge project -- and there has to be something that can be saved from opkg. I wish I knew what/how to do it! Nov 15 22:24:15 Yep. Nov 15 22:24:20 mwester: The fact is nobody seems to have the time to fix the core of it :( Nov 15 22:24:34 mwester: Where I have the skills or not, I don't have the time :( Nov 15 22:25:00 you have to understand the core in order to redo it. Understanding that mess is time consuming Nov 15 22:25:51 enough talk. Back to hacking! Nov 15 22:25:52 I tried to convince my boss a year ago to let me use opkg as a case study/learning exercise for a commercial software code analysis tool. He said no, but that would have been a great way to get some tools and time on the project. Nov 15 22:26:22 opkg is now 99% valgrind clean.... Nov 15 22:27:19 mwester: yes, we need to come up with something creative like that Nov 15 22:29:44 RP: anyway, I fear the issue now is not in opkg itself but in some OE change Nov 15 22:30:21 it is in a nested path.. somewhere missing an absolute path Nov 15 22:31:44 Yeah, back to the original problem -- it looks as if there is a path provided or computed, where the leading / is missing or stripped -- that would convert the full path to a relative one and cause this symptom. Nov 15 22:31:50 ant__: those staging messages due to opkg? Nov 15 22:32:10 no, the fact I have two /cross/armv5te/lib Nov 15 22:32:47 in the right one is gcc Nov 15 22:33:15 in the wrong one ~ipkg and /opkg Nov 15 22:33:42 same for the native Nov 15 22:34:05 in staging/i686-linux/usr/lib Nov 15 22:34:40 parhaps is Angstrom-only problem? Nov 15 22:35:16 SlugOS also sees it, which is not angstrom. Nov 15 22:36:08 ok, some recent change, then Nov 15 22:37:52 hmm, this looks like something the recent changes probably broke Nov 15 22:38:35 ok, I'm in front of a computer with some cpu power now :) Nov 15 22:38:52 we can only imagine...hal? Nov 15 22:39:02 is the pkg crash? Nov 15 22:39:05 er opkg Nov 15 22:39:36 could be a consequence of misplaced files Nov 15 22:39:42 ant__: My new lightweight laptop ate 50% of its battery in 15 mins due to poky abuse :/ Nov 15 22:40:08 ah, I was dreaming about unreleased multicore cpu's Nov 15 22:41:49 "poky abuse" -- sounds bad ;) :D Nov 15 22:43:33 ok, these strange package paths are something nasty Nov 15 22:45:32 definitely Nov 15 22:49:32 ant__: It won't break the build, just means staging has 3 different status files Nov 15 22:50:48 seems all the natives are in the nested dir Nov 15 22:51:04 I mean the staging-* control + lists Nov 15 22:51:56 ant__: cross, nativesdk, sdk, native and target would all end up in different places Nov 15 22:52:34 RP: I see unfortunately the arch in the staging- is still broken... Nov 15 22:53:29 for the others Nov 15 22:53:59 ant__: Yes, undoubtedly Nov 15 22:54:14 ant__: I gave that some thought and I kind of remember why I did it Nov 15 22:55:02 ant__: We have recipes with things like cross scripts in which install into the native staging area Nov 15 22:56:14 ant__: The correct thing to do is to move them Nov 15 22:56:34 I think I've now seen the commit Nov 15 22:57:33 anyway...no doubt that you know why you did it ;) Nov 15 22:57:43 go ahead! Nov 15 22:59:23 ant__: which commit? Nov 15 22:59:53 hm..mom Nov 15 23:00:15 (I'm battling with klcc atm...) Nov 15 23:00:42 hmm . . . my gnome image seems quite broken after the recent staging changes :-( Nov 15 23:01:17 sakoman: build or runtime? Nov 15 23:01:41 I finally got the build to complete this am, the runtime is broken Nov 15 23:01:54 first boot went *very* fast Nov 15 23:02:41 sakoman: Hopefully its nothing too serious :/ Nov 15 23:02:45 looking at the log it seems that lots of "Configuring packagename" lines are missing! Nov 15 23:03:01 sakoman: so the postinstalls failed? Nov 15 23:03:10 seems so at first glance Nov 15 23:03:28 RP: http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=ab35aa34f3de37365d46692555c8a2ec3667da56 Nov 15 23:03:51 RP: normaly took 15 minutes or so for first boot, ths time maybe 2 or 3! Nov 15 23:04:15 and it is broken :-( Nov 15 23:04:35 03Richard Purdie  07org.openembedded.dev * rd365dd3de4 10openembedded.git/classes/packaged-staging.bbclass: Nov 15 23:04:35 packaged-staging.bbclass: Fix references to libdir which should be libdir_native to remove multiple status files Nov 15 23:04:35 Signed-off-by: Richard Purdie Nov 15 23:05:08 ant__, mwester: That should fix the mutliple opkg status files problem Nov 15 23:05:53 thx, will test-build overnight Nov 15 23:09:35 sakoman: 15 minutes for a fist boot sounds like a crazy amount of time Nov 15 23:09:42 sakoman: Whats your normal boottime? Nov 15 23:10:06 RP: subsequent boots are quite a bit less! Nov 15 23:10:12 seconds not minutes Nov 15 23:10:41 sakoman: pleased to hear it! Nov 15 23:10:58 RP: the beagle demo image first boot is also quite slow Nov 15 23:11:01 sakoman: if you've a previous image you could compare the /etc directory with that might be very useful Nov 15 23:11:24 RP: that's what I am doing now :-) Nov 15 23:12:34 * mwester renames tmpdir, and kicks off a SlugOS build on the quad-core. :) Nov 15 23:13:10 need to drive quad core sales somehow... :) Nov 15 23:13:40 I've long thought that the OE team should get commissions from both Intel and from Seagate. Nov 15 23:13:42 :D Nov 15 23:13:48 RP: sadly I don't have the raw image from previous builds, just a tgz of the image after first boot :-( Nov 15 23:14:19 perhaps on another machine . . . Nov 15 23:14:23 mwester: In a way now... :) Nov 15 23:14:30 sakoman: :/ Nov 15 23:14:49 sakoman: I'm building an image here to see if I can spot anything obvious Nov 15 23:15:28 RP: do you recall which init runs the postinst routines on first boot? Nov 15 23:16:29 S at level 99 iirc? Nov 15 23:16:42 sakoman: but it changes in OE :/ Nov 15 23:17:58 I guess I should try to boot an image built with the new staging layout, too... Nov 15 23:18:07 ah, perhaps S98configure Nov 15 23:18:21 sakoman: yes, thats it Nov 15 23:18:39 sakoman: I was close :) Nov 15 23:18:58 hmm . . . so that does an opkg-cl configure Nov 15 23:19:19 guess I better go research that. new territory! Nov 15 23:26:23 looking at this after an afternoon visiting local wineries is probably not a good idea :-) Nov 15 23:27:15 sakoman: It can help in the right circumstances :) Nov 15 23:27:23 :-) Nov 15 23:29:23 'nite Nov 15 23:30:56 RP: I think I may redo a bootable SD card and change the command to opkg-cl -V 3 configure prior to first boot to see if that yields any clues Nov 15 23:33:05 it seems that metacity and gnome-session are both broken and also suspiciously those two packages are missing from the "Configuring ..." list on first boot Nov 15 23:41:37 sakoman: broken in what way? Nov 15 23:45:57 RP: with metacity I get an error message saying: Application 'metacity.desktop' failed to register before timeout Nov 15 23:46:39 for gnome-session and gdm I get some error messages about unset gconf keys Nov 15 23:47:01 sakoman: right, that points to postinst problems Nov 15 23:47:09 yup Nov 15 23:47:31 sakoman: My test image do_rootfs log worries me a little :/ Nov 15 23:47:47 oh oh! Nov 15 23:48:06 sakoman: Just warnings about not being able to open /var/lib/opkg :/ Nov 15 23:48:17 sakoman: not fatal on its own, I don't think but I'm not sure Nov 15 23:48:50 RP: /var/lib/opk is empty in my image Nov 15 23:49:10 sakoman: Thats fine. It doesn't exist in mine :/ Nov 15 23:49:13 hmm . . . empty in my old working image too Nov 15 23:49:49 sakoman: you weren't able to diff /etc ? Nov 15 23:49:52 What's the incantation to make OE preserve my rootfs dir in the tmpdir? Nov 15 23:50:50 RP: the old image is just a tarball of a working image post first boot Nov 15 23:51:14 but a diff might be interesting Nov 15 23:51:15 mwester: IMAGE_KEEPROOTFS Nov 15 23:51:20 thanks :) Nov 15 23:51:25 mwester: I just editted image.bbclass as its faster for me :/ Nov 15 23:51:41 sakoman: Yes, could still show something up Nov 15 23:51:55 sakoman: also maybe the /usr/lib/opkg directory Nov 15 23:52:09 sakoman: The postinst scripts are under there Nov 15 23:53:16 RP: I'm doing a first boot with verbose debugging on the opkg-cl command Nov 15 23:55:34 RP's changes fixed the funny directory structures here... thanks RP! Nov 15 23:56:52 mwester: I think that bug must have been around for a while :/ Nov 16 00:00:19 RP: ah metacity postinst in woring image is 701 bytes, 212 in new non-working image Nov 16 00:00:34 hi Nov 16 00:00:45 sakoman: Can you pastebin it please? Nov 16 00:00:47 hi hrw Nov 16 00:00:55 yup! Nov 16 00:01:31 mwester: I bought Samsung HDD this time instead of seagate - it was cheaper per TB Nov 16 00:02:20 03Mike Westerhof  07org.openembedded.dev * r1e7e232522 10openembedded.git/conf/distro/include/slugos.inc: SlugOS: slugos.inc - set preferred provider for util-linux to util-linux-ng. Nov 16 00:02:39 RP: http://pastebin.com/m4d94cf17 Nov 16 00:03:14 sakoman: thanks, let me poke around Nov 16 00:03:40 RP: good luck! thanks :-) Nov 16 00:03:54 sakoman: looks like something to do with gconf.bbclass Nov 16 00:04:12 yes Nov 16 00:04:49 I seem to recall having to tweak that a bit to get the ordering of things right when a recipe had a postinst Nov 16 00:06:15 sakoman: I've spotted one broken class so far :/ Nov 16 00:06:25 sakoman: but not the cause of this Nov 16 00:07:08 sakoman: ah, I know why this has happened. Its my changes too : Nov 16 00:07:09 :/ Nov 16 00:07:34 Too many places making assumptions about the packages core :/ Nov 16 00:07:42 Always happy to help find bugs! Nov 16 00:13:14 03Richard Purdie  07org.openembedded.dev * r6b591e5079 10openembedded.git/classes/gconf.bbclass: Nov 16 00:13:14 gconf: Remove hardcoded PKGDEST directory assumption Nov 16 00:13:14 Signed-off-by: Richard Purdie Nov 16 00:13:19 sakoman: These two commits should fix that particular problem Nov 16 00:13:20 03Richard Purdie  07org.openembedded.dev * r97da69ac08 10openembedded.git/classes/gtk-icon-cache.bbclass: Nov 16 00:13:20 gtk-icon-cache.bbclass: Remove hardcoded PKGDEST directory assumption Nov 16 00:13:20 Signed-off-by: Richard Purdie Nov 16 00:13:38 sakoman: ANything using those classes needs to be rebuilt though :/ Nov 16 00:13:55 RP: thanks! I'll fire up a new clean build Nov 16 00:14:13 (yet another quad core user here) Nov 16 00:14:24 Should be done after dinner :-) Nov 16 00:14:33 sakoman: I'd wait 5 minutes - there are more to fix Nov 16 00:14:35 heh.. I started new fresh build on friday... not finished yet and new 'lets rebuild' needs to be done Nov 16 00:14:39 ;D Nov 16 00:15:00 sakoman: intel should really send us some mainboard+core quad i7+ram combos Nov 16 00:15:11 RP: OK, I'll wait a bit Nov 16 00:15:20 ;) Nov 16 00:15:31 hrw: I'd be happy to accept a couple for testing :-) Nov 16 00:15:53 They would double as a heat source. Nov 16 00:15:55 hahah ;D Nov 16 00:15:57 efficient. Nov 16 00:16:03 ok, just one more, coming now Nov 16 00:16:17 sakoman: my q6600 starts to generate more heat each time Nov 16 00:16:39 * mwester loves his q6600 - rock-solid. Nov 16 00:16:50 03Richard Purdie  07org.openembedded.dev * r01f6b4999d 10openembedded.git/classes/mime.bbclass: Nov 16 00:16:50 mime.bbclass: Remove hardcoded PKGDEST directory assumption Nov 16 00:16:50 Signed-off-by: Richard Purdie Nov 16 00:17:01 My 8 core i7 is heating a house atm :/ Nov 16 00:17:04 mwester: my is stable now too - after dropping box cooler and putting some monster on it Nov 16 00:17:07 8-core? Nov 16 00:17:10 ooooo! Nov 16 00:17:18 RP: xeon? Nov 16 00:17:25 mwester: dual quad core Nov 16 00:17:56 Yikes - I think I saw one of those MB once, an extra digit in the price tag!~ Nov 16 00:18:55 ERROR: Task do_rm_work_all does not exist for target console-image Nov 16 00:18:57 hrw: Coe i7 Nov 16 00:18:57 ARGH Nov 16 00:19:01 Core i7 Nov 16 00:19:15 hrw: I guess not if you have an @intel.com in your email address Nov 16 00:19:24 :D Nov 16 00:19:53 RP: dual quadcore means two cpus. and iirc only Xeon family works that way Nov 16 00:19:54 That machine was bought from Dell, nothing special Nov 16 00:20:21 sakoman: I had such one for some time. in middle of having it I lost a way to be able to use it Nov 16 00:20:30 Sorry, its not dual, its an 8 way single chip Nov 16 00:20:41 RP: quadcore+HT? Nov 16 00:20:56 hrw: yes, it will be Nov 16 00:21:18 blummin fast which is mainly what I was interested in :) Nov 16 00:21:35 I have buildbot on one dual quadcore xeon machine. works nice Nov 16 00:21:56 RP: yes, i7 is nicely made. Nov 16 00:22:18 It requires memory in groups of three, right? Nov 16 00:22:44 mwester: or two - depends on version iirc Nov 16 00:22:59 mwester: Pass, I plugged it in and used it as should be evident from my lack of knowledge above :/ Nov 16 00:23:03 mwester: s1156<>s1366 thing iirc Nov 16 00:23:50 sakoman: let me know how the new image works out. Hopefully it was just this... Nov 16 00:24:34 I have a feeling that will do it. The image seems to be ok with console command line access, it is just the gnome stuff that is broken. Nov 16 00:25:00 * RP hopes so Nov 16 00:25:28 RP: I'll drop you a note confirming it in a few hours :-) (hows that for positive thinking!) Nov 16 00:26:49 if that image works, then the changes ought to be in good shape. gnome image is a monster! Nov 16 00:27:23 (but actually works surprising well on OMAP3!) Nov 16 00:31:59 sakoman: thanks for the angstrom-task-gnome.bb hint. exactly what i'm looking for. Nov 16 00:33:46 is anyone really attached to the 'show diff when an old config file exists' feature in opkg? Nov 16 00:34:27 mturquette: what machine will you be building gnome for? Nov 16 00:34:40 i think i'd prefer not to prompt at all, but just install the package's config file 'foo' as foo-dist or something like that Nov 16 00:34:41 sakoman: touchbook Nov 16 00:34:41 I'd ask that question on an end-user IRC or ML -- such as the #openmoko and #openmoko-cdevel channels. :D Nov 16 00:35:06 mturquette: ah, I've been meaning to try that Nov 16 00:35:08 Personally, i'm ok with a different name. Nov 16 00:35:54 sakoman: will let you know my impressions after i've built it. i might wait for the tb patches to go upstream to L-O first. Nov 16 00:36:28 mturquette: I have some pre-built images that work on beagle & overo, they would likely work on touchbook if you copy over the kernel modules for touchbook Nov 16 00:37:02 mturquette: http://www.sakoman.com/feeds/omap3/glibc/images/gnome/ Nov 16 00:37:13 * RP -> Zzzz Nov 16 00:37:26 RP: gn -- thanks for the help! Nov 16 00:37:47 sakoman: gnome works, but what to do with it when there is nearly no free mem? Nov 16 00:37:59 sakoman: thanks! i will try to check those later on this week, but only time will tell. Nov 16 00:38:52 hrw: seems to work fine for typical web browsing, email, music playing . . . Nov 16 00:43:06 ok, sleep time **** ENDING LOGGING AT Mon Nov 16 02:59:56 2009