**** BEGIN LOGGING AT Tue Jan 12 02:59:56 2010 Jan 12 05:27:27 well e-image fails horribly on oe-dev Jan 12 05:41:43 http://pastebin.com/m1e8ee4ac Jan 12 05:41:47 can't build e-image Jan 12 07:42:14 good morning Jan 12 07:42:39 hi Jan 12 07:43:33 I like to ask few doubt, regarding contribute some stuff to OE Jan 12 07:46:50 ok so I deleted the stuff inside deploy.../beagleboard Jan 12 07:46:58 and now when I run bitbake it wont build the uImage :( Jan 12 07:49:52 mornig all Jan 12 07:49:58 bala: ~ask Jan 12 07:51:04 hi gremlin[it] Jan 12 07:51:21 hi mckoan ! Jan 12 08:19:06 Hi, I got an error when building u-boot for beagle--patch problem. I think it's patch format errors, but I don't know exactly. can you help? Jan 12 08:21:30 hello? Jan 12 08:39:20 Hi, I got an error when building u-boot for beagle. I think it's like patch format errors, but I don't know how exactly. can you help? Jan 12 09:38:46 florian: good morning Jan 12 09:40:56 good morning Jan 12 09:56:23 03Martin Jansa  07org.openembedded.dev * rf83f44fe62 10openembedded.git/recipes/tasks/task-shr-feed.bb: Jan 12 09:56:23 task-shr-feed: remove phoneme-advanced-foundation, build hangs and probably noone is using it in SHR now Jan 12 09:56:23 Signed-off-by: Martin Jansa Jan 12 09:56:25 03Martin Jansa  07org.openembedded.dev * rd7e1635bcd 10openembedded.git/recipes/fbreader/ (5 files): fbreader: bump PR for bzip2 changes Jan 12 09:58:28 morning Jan 12 10:00:21 hi hrw Jan 12 10:51:10 what this message means? "offline root mode: not running" Jan 12 10:52:13 it means that opkg is in offline root mode, which causes the postinsts to be suppressed. Jan 12 11:01:47 pb_: I don't understand what would be the result :-( Jan 12 11:05:50 mckoan: essentially that the packages are left in SS_UNPACKED. Jan 12 11:07:02 03Koen Kooi  07org.openembedded.dev * r5fd21e706e 10openembedded.git/recipes/linux/ (4 files in 4 dirs): Jan 12 11:07:02 linux-omap 2.6.32: move SRCREV back a bit Jan 12 11:07:02 - the newer rev has more of our patches applied, but it is way more unstable that the earlier rev Jan 12 11:07:07 pb_: and doex exist variable to switch this behaviour? Jan 12 11:07:12 03Koen Kooi  07org.openembedded.dev * rbe7010a058 10openembedded.git/recipes/bzip2/bzip2_1.0.5.bb: Jan 12 11:07:12 bzip2: put libbz2 in its own package to avoid further SOVERSION breakage Jan 12 11:07:12 * 'bzip2' depends on the libbz2 package, so upgrade paths remain intact Jan 12 11:07:38 mckoan: It does not run the scripts that come with a package for a good reason. Running the scripts wouldl be problematic e.g. because you would have to call the binaries you just installed which are likely to be for a different architecture. Jan 12 11:09:48 mckoan: What are you trying to achieve? Jan 12 11:11:08 what is the cia bot trying to say? Jan 12 11:11:58 CIA-1: The push messages from OE git. Jan 12 11:15:35 florian: a kaeilos/oe user is trying to build and is facing to this weird error Jan 12 11:17:03 mckoan: Its just a note, not an error... its absolutely expected to show up when building images with OE. Jan 12 11:17:30 florian: he's building all from scratch http://tinderbox.openembedded.net/public/logs/task/4371665.txt Jan 12 11:18:56 mckoan: I see... take a look at the end of the log. The real error are summarized there... it fails to find some packages. Jan 12 11:19:21 Any body, contributed to OE?, B'Coz I have some doubt regarding OE contribution Jan 12 11:19:58 * florian paitiently waits for one of his buildservers migrating to a new hardware Jan 12 11:20:27 bala_holmes: yes quite a lot... what's your doubt? Jan 12 11:21:19 florian: yep, thx Jan 12 11:26:36 mckoan: yw Jan 12 11:28:37 have clear steps to add new machine conf file along with recipes to OE? Jan 12 11:30:53 bala_holmes: just add the machine conf and tha matching kernel support. of course there are other bits you might want to touch in order to refine support... Jan 12 11:33:46 thats I did in my local machine Jan 12 11:33:53 I need to commit my changes to OE... Jan 12 11:34:30 bala_holmes: just send your patches to the mailing list, or file them in bugzilla Jan 12 11:37:08 Any standard is there? to send patches to mailing list.. Jan 12 11:37:46 Same as for the Linux kernel (~= what git format-patch does) Jan 12 11:40:31 florian: what hardware you use for buildmachine? Jan 12 11:40:47 pxa270 Jan 12 11:43:41 hrw: Its an old IBM 8677 with a pile of P4 based blades. Jan 12 11:44:50 nearly one file i have modified (linux-2.6.25.bb) and five files were newly added, so may I send all in one patch? or all are in seprate patches? Jan 12 12:08:30 bala_holmes: make it separate patches, that's what git does as well. Jan 12 12:12:14 florian : Whether I need to send my u-boot & kernel patches also? Jan 12 12:14:58 bala_holmes: Would be useful... without these support for your device would not make sense. Jan 12 12:25:35 03Koen Kooi  07org.openembedded.dev * r3dba48e672 10openembedded.git/recipes/linux/ (19 files in 4 dirs): linux-omap-psp 2.6.32: add beagle support and backport some fixes Jan 12 12:31:33 morning pb_, laibsch Jan 12 12:32:05 aw, that was yesterday Jan 12 12:32:12 ~lart xchat aqua just because Jan 12 12:32:13 * ibot hereby declares xchat aqua just because a troll Jan 12 12:33:55 florian : u r correct, my doubt is... Will the OE-Dev mailing list will review conf files and recepies only or corresponding kernel patches also? Jan 12 12:35:03 florian : B'Coz I havn't follow any standard in my kernel and u-boot code ;-( Jan 12 12:36:21 bala_holmes: no... if they work and do not damage anything else that's fine. Jan 12 13:01:16 Laibsch: ping ? Jan 12 13:01:27 pong Jan 12 13:01:35 good morning, jeremy_laine Jan 12 13:01:40 thank you for your fantastic support Jan 12 13:02:21 florian : OE-Dev mailing list itself commit my changes or patches? Jan 12 13:03:27 Laibsch: ok, regarding your questions, do you deploy as a .deb ? Jan 12 13:03:42 yes Jan 12 13:03:56 ok, unless I am mistaken the .pyc is not contained in the .deb Jan 12 13:04:05 yes Jan 12 13:04:09 It shouldn't Jan 12 13:04:11 so the only action you needed was to restart apache Jan 12 13:05:50 I wouldn't have had to remove that pyc file? Jan 12 13:06:02 Laibsch: were was the .pyc file ? Jan 12 13:06:39 at /var/lib/python-support/python2.5/oestats/templatetags/oestats_tags.pyc Jan 12 13:08:04 ok, then it's fine, it's generated at postinst and garanteed to be up to date Jan 12 13:08:23 so the only action was indeed to restart apache Jan 12 13:08:33 dpkg --contents django-oestats_0.5.17-1_all.deb | grep pyc Jan 12 13:08:37 => no results Jan 12 13:09:13 yes Jan 12 13:09:20 Laibsch: so if that's OK with you I'll close the ticket regarding the timezone Jan 12 13:09:20 that is what I did before Jan 12 13:09:26 Sure Jan 12 13:09:41 I wonder if it's possible for a package to restart apache? Jan 12 13:10:12 eh, I'd rather not, it's bad form.. we don't know for sure that apache is used to host the app Jan 12 13:10:55 the only thing I'd like to fix is that it looks as though you edited the template Jan 12 13:11:03 (replacing "for" by "in") Jan 12 13:11:10 Laibsch: just and idea.. is it possible to get some more statistics from tinderbox like packages which are failing the most? (no idea how to truncate history with not so relevant info - like old version was failing everytime, but now nobody is using that old version) Jan 12 13:11:35 we need a wording that works for "UTC" and something like "Europe/Paris" Jan 12 13:11:40 jeremy_laine: yes, I was about to suggest that wording ;-) Jan 12 13:11:59 "times are in timezone XY" sounds more familiar to me Jan 12 13:12:04 But we should ask the natives Jan 12 13:13:00 or maybe "Times are in XY timezone" Jan 12 13:13:04 JaMa|W: http://bugs.openembedded.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Infrastructure&component=tinderbox&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEEDSINFO&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emai Jan 12 13:13:20 or even "Times are in XY" Jan 12 13:13:35 JaMa|W: especially Jan 12 13:13:40 !oebug 5118 Jan 12 13:13:44 !oebug 5136 Jan 12 13:14:03 let's keep the bug reports focused people I only have 24h in a day :) Jan 12 13:14:15 I know Jan 12 13:14:21 (and I'm expected to work on my day job at times :)) Jan 12 13:14:21 Don't worry Jan 12 13:14:25 I'm patient Jan 12 13:14:37 I hope some people will join in the coding Jan 12 13:14:44 Laibsch: are we ok with "All times are in XY" ? Jan 12 13:14:44 I would if I knew more python Jan 12 13:15:00 And zecke already did hack on oestats Jan 12 13:15:08 jeremy_laine: sounds fine Jan 12 13:16:23 jeremy_laine: 5118 and 5136 are not focused enough for your taste? I thought they were actionable (not talking about how long it would take to implement them which I cannot guess). BTW, I did talk to zecke to try and entice him to pick them up. Jan 12 13:16:28 Laibsch: i'll just look at the "/" issue Jan 12 13:16:38 if you have time Jan 12 13:16:45 IMHO that one is rather minor Jan 12 13:16:50 Again, I don't want to rush you Jan 12 13:17:01 I very much appreciate the superb support you are giving Jan 12 13:17:34 5118 would be very valuable, I'm just not sure how to translate it to an SQL request which doesn't kill the DB Jan 12 13:17:43 JaMa|W: I think packages which are failing the most is not so interesting as packages which failed but and which have not run successfully since. Jan 12 13:18:02 jeremy_laine: cache the result in a temporary table? Jan 12 13:18:07 or parts of it Jan 12 13:18:22 s/but// Jan 12 13:18:25 Laibsch: yeah, that's great.. I didn't known about this whole tinderbox improving bugs.. thanks Jan 12 13:18:43 tinderbox is REALLY awesome Jan 12 13:18:59 much better than manually reporting compile failure bugs to the tracker Jan 12 13:19:01 hmm, the problem is that as there's a notion of "this happened after that", so I think it means walking over all the package builds in chronological order, no? Jan 12 13:19:41 jeremy_laine: I think you could take the failed tasks and see if there is a successful one for the same task that comes after it Jan 12 13:19:57 not being very elaborate in the wording here Jan 12 13:20:54 SELECT time FROM tasks WHERE failed;SELECT time FROM tasks WHERE success Jan 12 13:20:59 and then compare the two tables Jan 12 13:21:24 spit out the ones from the second query where t2 > t1 Jan 12 13:22:14 one has to be careful about which targets to include, though. a failed do_compile should not be overriden by a successful do_setscene IMHO Jan 12 13:24:04 g.m. Jan 12 13:28:52 jeremy_laine: I'll cross 5118 off the list. It's essentially the same as 5136. Jan 12 13:35:17 If OE-Dev mailing list accepted my patches then, what is my next step? Jan 12 13:35:50 If it commited by myself then, what commit rights I have? Jan 12 13:35:57 Can I commit with out "Signed-off-by" line? Jan 12 13:35:59 http://marcin.juszkiewicz.com.pl/2010/01/12/my-expansion-board-for-beagleboard/ Jan 12 13:38:57 mickey|office: heh, good morning Jan 12 13:47:28 mhhh ... about FOSDEM days ... does we have some meeting ??? or not cause not all TSC/members are in Brussels ? Jan 12 13:48:59 I don't think there will be a GA at FOSDEM. That's not to say that we can't have some kind of meeting, though. Jan 12 13:50:04 I guess the TSC can decide for themselves whether they want to hold a meeting there. I suspect the answer will probably be no but you never know. Jan 12 13:50:15 pb_, ok ... just cause i'm booking fly and hotel ... :D Jan 12 13:51:40 for a GA, you need six weeks' notice so the invitation would have needed to go out some time ago if we were to have one at FOSDEM. Jan 12 13:52:02 but, in any case, I don't think there is any business that we need to transact at present, so there is no need to have a GA anyway. Jan 12 13:53:02 ok pb_ ... u'll be there ? Jan 12 13:54:21 yeah Jan 12 13:54:56 Laibsch: hello. Any idea about opie-taskbar? It failed overnight and I could not compare the logs with the angstrom-glibc build Jan 12 13:55:06 unfortunately, no Jan 12 13:55:16 well, I founs smthg perhaps: -lpthread Jan 12 13:55:27 I've seen the breakage myself and was waiting for bluelightning to come around to discuss Jan 12 13:55:47 it builds in A? Jan 12 13:55:50 yes Jan 12 13:55:53 with glibc Jan 12 13:55:53 mickey|office: on the subject of the TSC, is there any public information about the outcome of last week's meeting? Jan 12 13:56:38 iirc there was recent discussion about lpthread (on eglibc?) Jan 12 14:04:21 how should a makefile make its way around fork() in a uclibc system Jan 12 14:05:12 ant_work: (e)glibc things are above my skills so I would not have noticed Jan 12 14:05:18 khem: Can you shed some light? Jan 12 14:06:29 Laibsch: or a missing include? I see LnkProperties::~LnkProperties() is in lnkproperties.cpp (google) Jan 12 14:07:29 but same recupe did build with glibc (and with uclibc, not so long ago) Jan 12 14:08:22 We'll see later. Khem is in deep USA timezone... Jan 12 14:18:23 rob_w: uclibc, or uclinux? Jan 12 14:19:13 ah both ?! Jan 12 14:19:29 i mean user space rather then kernel inside Jan 12 14:19:30 if you're on uclinux, there is no fork() Jan 12 14:19:41 you can use vfork(), but that's as close as it gets Jan 12 14:19:52 right Jan 12 14:20:16 but how does others do .. do they blend in vfork() or is make doing someting there ? Jan 12 14:20:24 03Koen Kooi  07org.openembedded.dev * r04dfa74724 10openembedded.git/recipes/linux/linux-omap-psp-2.6.32/beagleboard/defconfig: linux-omap 2.6.32: enable TI media in beagleboard defconfig Jan 12 14:24:59 how would I unstage a library? Jan 12 14:25:05 to test for FTBFS? Jan 12 14:25:15 I don't think you can, reliably, unless you are using packaged-staging. Jan 12 14:25:18 -c clean sufficient? Jan 12 14:25:26 I am using packaged-staging Jan 12 14:25:38 I think you need to clean and then rerun setscene. Jan 12 14:25:54 -c clean seems to be sufficient Jan 12 14:25:57 thanks Jan 12 14:25:59 ah right Jan 12 14:26:10 I will add an FAQ to the wiki Jan 12 14:28:44 Starting a development for pxa270 is good the following commit? HEAD is now at 5433465 xserver-common: added missing 89xdgautostart.sh file Jan 12 14:29:27 akita, I mean Jan 12 14:32:36 morning Jan 12 14:32:55 morning Jan 12 14:35:37 morning kergoth Jan 12 14:35:42 03Rolf Leggewie  07org.openembedded.dev * re736165f7e 10openembedded.git/recipes/cairo/cairomm_1.8.2.bb: cairomm: add libsigc++-2.0 to DEPENDS of the latest recipe to fix FTBFS Jan 12 14:35:56 morning, kergoth Jan 12 14:36:06 kergoth: what was the name of that class again that you wrote to inspect a bb file for superfluous settings of PR and stuff? Jan 12 14:40:44 Did the Zaurus ROM use ipk in a different from what we use today (essentially a deb package)? Jan 12 14:41:02 $ dpkg --info /export/oe/tmp/sharprom-compatible/org.openembedded.dev/deploy/ipk/armv4/zten_1.6.2-r1_armv4.ipk Jan 12 14:41:02 dpkg-deb: `/export/oe/tmp/sharprom-compatible/org.openembedded.dev/deploy/ipk/armv4/zten_1.6.2-r1_armv4.ipk' is not a debian format archive Jan 12 14:41:06 Laibsch: yes Jan 12 14:41:10 darn Jan 12 14:41:23 I wanted to take a look at run-time deps Jan 12 14:41:30 the sharp rom used "old style" ipks, which are tar-in-tar rather than tar-in-ar Jan 12 14:41:30 pb_: yeah, RP is supposed to send the minutes soonish Jan 12 14:41:33 any way to do that without installing on the device? Jan 12 14:41:51 I think ipkg-unbuild can handle them, or you can pull them apart by hand Jan 12 14:41:59 mickey|office: okay, jolly good, thanks Jan 12 14:42:13 what does ipkg-unbuild do? Jan 12 14:42:26 unpacks an .ipk Jan 12 14:42:31 sort of the opposite of ipkg-build Jan 12 14:44:33 Laibsch: the initial prototype was kergoth_sanity, it was renamed to the more appropriate recipe_sanity. it's a class that provides a task of the same name Jan 12 14:44:45 Nice Jan 12 14:44:49 Thank you Jan 12 14:44:56 np Jan 12 14:46:55 pb_: OK. thank you. If anything like "dpkg --info $deb" would have been available that would have been handy, of course. Jan 12 15:01:41 yeah, I don't think there is any such for old format ipk. Jan 12 15:26:05 RP: do you happen to know if the xml/rpc calls/objects/api in general for bitbake master are documented anywhere yet, for third party frontends to utilize to write their implementations? Jan 12 15:26:27 RP: i assume not, and will throw something together, but figured i'd check Jan 12 16:06:59 hmm Jan 12 16:11:10 hrm, xf86-input-evtouch no longer builds with older xorg, it seems Jan 12 16:32:16 03Marcin Juszkiewicz  07org.openembedded.dev * rbfb74990c0 10openembedded.git/recipes/pointercal/ (files/at91sam9263ek/pointercal pointercal_0.0.bb): Jan 12 16:32:16 pointercal: dropped at91sam9263ek data as people connect other displays Jan 12 16:32:16 It was reported some time ago that people connect other displays to this Jan 12 16:32:16 developer board. So let each user calibrate. Jan 12 16:32:16 Under X.org evdev driver works and do not require calibration anyway. Jan 12 16:34:35 hrm Jan 12 16:35:21 mrh Jan 12 16:36:06 * kergoth still fixing build errors after his attempted sync of all the mvl6 collections with oe.. madness Jan 12 16:37:23 kergoth: tslib uses one /etc/pointercal for all TS devices nevermind how many machine has? Jan 12 16:38:02 i think so, but there's an env var to override it Jan 12 16:38:44 xf86-input-tslib will probably ignore it anyway Jan 12 16:39:05 my bug has 2 lcd+ts modules and each has other calibration data Jan 12 16:39:17 ah, fun.. Jan 12 16:39:28 are usable with data from any of them anyway Jan 12 16:40:04 * kergoth thinks tslib was a nice concept, but may not be very suitable anymore Jan 12 16:41:49 atmel board uses X.org without tslib now Jan 12 16:43:03 not really in the loop, but seems like people are leaning toward kernel filtering Jan 12 16:44:03 * kergoth yawns Jan 12 16:44:41 ah, crazy kernel h4x0rs Jan 12 16:44:52 quite Jan 12 16:49:36 ERROR: QA Issue with staging: xmlsec1-gnutls.pc failed sanity test (tmpdir) in path /home/clarson/oe/projects/sync/tmp/staging/i686-mv-linux/usr/lib/pkgconfig Jan 12 16:49:44 hrm... guess i screwed up the merge of the sysroot stuff, somehow Jan 12 17:06:58 heh Jan 12 17:07:24 Fixing up the pkgconfig stuff for sysroot wasn't hard, but the foo-config ones are annoying Jan 12 17:07:37 yeah, that binconfig stuff is annoying in every way Jan 12 17:18:56 OE should think about taking a cue from firmwarelinux and set up a private symlinked dir for the PATH and remove /usr/bin, etc from it, so the build machine binaries we rely on would be more explicit Jan 12 17:45:09 jo Jan 12 17:48:21 bye all Jan 12 17:48:21 hi woglinde, zecke Jan 12 17:48:53 kergoth: yeah, that's not a bad idea. that'd avoid that libtool thing we were talking about with RP the other day. Jan 12 17:49:11 heh, that's a good point, i didn't even think about that :) Jan 12 17:50:45 hoi pb Jan 12 17:50:46 bye hrw Jan 12 17:50:48 Anyone ever play with filesystems for what the TMPDIR ends up in? Jan 12 17:51:11 tartarus? Jan 12 17:51:36 As in, using ext3 or xfs or whatever for where you build Jan 12 17:52:06 ah that you mean Jan 12 17:52:12 what you mean with playing? Jan 12 17:53:16 Tartarus: no, I've only ever used ext3. I doubt it makes a huge amount of difference to be honest, OE is not all that filesystem-intensive. Jan 12 17:53:32 * pb_ go home now Jan 12 17:53:33 later all Jan 12 17:53:36 pb_, that's what I suspect :( Jan 12 17:53:37 thanks Jan 12 17:55:44 till later pb Jan 12 17:56:05 I tested ext2 jffs2 and ubi Jan 12 17:58:44 03Koen Kooi  07org.openembedded.dev * r8929bf6bb0 10openembedded.git/recipes/linux/ (3 files in 3 dirs): linux-omap-psp 2.6.32: disable mmc debug spew and fix omap3evm sound Jan 12 17:58:46 03Koen Kooi  07org.openembedded.dev * r80d46f080b 10openembedded.git/ (conf/checksums.ini recipes/cpufreqd/cpufrequtils_006.bb): cpufrequtils: add 006 Jan 12 17:58:46 03Koen Kooi  07org.openembedded.dev * r12fccaa9ba 10openembedded.git/recipes/linux/linux-omap-psp-2.6.32/omap3evm/defconfig: linux-omap-psp 2.6.32: fix powertop for omap3evm Jan 12 18:13:59 kergoth: Are you reporting your build failures to tinderbox? Jan 12 18:14:16 http://wiki.openembedded.net/index.php/How_do_I_send_automatic_success_and_failure_reports Jan 12 18:14:33 most of my builds are with MVL6 rather than full OE, so I haven't been utilizing tinderbox. I'll think about doing so for my stock OE builds Jan 12 18:16:06 please do Jan 12 18:18:04 thanks for the link Jan 12 18:18:06 * kergoth adds to todo Jan 12 18:18:26 * kergoth still needs to sit down and make use of the sheevaplug collecting dust in his garage Jan 12 18:19:06 hihi Jan 12 18:19:14 I have an alix board now Jan 12 18:19:18 only for one week Jan 12 18:20:59 dinner Jan 12 18:27:08 re Jan 12 18:30:29 hi likewise Jan 12 18:30:40 hi woglinde, how's life Jan 12 18:33:34 fine Jan 12 18:46:45 why is glib-2.0 failing for sharprom-compatible but not for other distributions and what can be done about it? Jan 12 18:47:24 http://tinderbox.openembedded.org/search/?distro=sharprom-compatible Jan 12 18:47:38 http://tinderbox.openembedded.org/packages/421517/ for exampe Jan 12 18:47:42 example Jan 12 18:48:03 giounix.c:185: `SSIZE_MAX' undeclared (first use in this function) Jan 12 18:48:47 {e,}glibc version? Jan 12 18:49:55 not sure Jan 12 18:50:10 I found the following via google related to this problem Jan 12 18:50:12 http://www.mail-archive.com/gtk-devel-list@gnome.org/msg00726.html Jan 12 18:50:32 well, what version is sharprom-compat on? Jan 12 18:50:34 let me check the version Jan 12 18:51:55 Hm Jan 12 18:52:05 maybee SSIZE_MAX is in another macro Jan 12 18:52:13 aeh header Jan 12 18:52:14 sorry Jan 12 18:52:16 I didn't find anything interesting. Here is the output of $ find /export/oe/tmp/sharprom-compatible/org.openembedded.dev/|grep glibc|pastebinit :http://paste.debian.net/56493/ Jan 12 18:52:40 Is glibc built when using a precompiled toolchain? Jan 12 18:52:51 no Jan 12 18:52:55 but depends Jan 12 18:53:05 But there's libc stuff put somewhere, iirc, from the prebuilt Jan 12 18:53:24 from sharprom-compatible.conf: PREFERRED_VERSION_glibc = "2.2.5" Jan 12 18:53:24 depends if you only have thre compiler Jan 12 18:53:25 or more Jan 12 18:53:42 Does that answer the question? Jan 12 18:53:48 hm Jan 12 18:53:48 Is SSIZE_MAX defined by the sharprom stuff? Jan 12 18:53:49 bits/posix1_lim.h:# define SSIZE_MAX LONG_MAX Jan 12 18:54:07 If not, it looks like what woglinde just pasted is what i was going to say Jan 12 18:55:34 would that break things for other people, IOW should that be applied only conditionally? Jan 12 18:55:54 Laibsch definitly Jan 12 18:56:01 only pxarom patch Jan 12 18:58:54 the little I understand about it seems to suggest that SSIZE_MAX is defined to some integer? http://paste.debian.net/56494/ Jan 12 18:59:55 http://paste.debian.net/56497/ is the complete /usr/local/arm/2.95.3/arm-linux/include/bits/posix1_lim.h file Jan 12 19:00:54 Tartarus, woglinde: line 94 of http://paste.debian.net/56497/ , no? Jan 12 19:02:36 gcc -E the glib file that's failing to see why that file isn't included Jan 12 19:02:56 (ie figure out how should be included indirectly and then see why it' not) Jan 12 19:08:22 ähm Jan 12 19:08:25 say what? Jan 12 19:08:26 ;-) Jan 12 19:08:41 Go up to the glib failing build Jan 12 19:08:54 and run arm-....-gcc .... -E -o whatever.i Jan 12 19:08:54 Let me see if I got this right Jan 12 19:09:13 Then, see how is normally included Jan 12 19:09:23 I guess will conditionally bring it in Jan 12 19:09:29 "bitbake -c clean glib-2.0;bitbake -c patch glib-2.0" and then patch some file before continuing, right? Jan 12 19:09:45 no, bitbake -c compile glib-2.0 Jan 12 19:09:57 up until it fails Jan 12 19:09:59 OK Jan 12 19:09:59 Then by hand, run gcc like it's compiled Jan 12 19:10:00 but with -E Jan 12 19:10:08 So that gcc does the preprocessing instead Jan 12 19:10:15 Oh, sounds tough Jan 12 19:10:18 and you can see what all is brought in Jan 12 19:11:08 03Rolf Leggewie  07org.openembedded.dev * r22384f5427 10openembedded.git/recipes/gpe-clock/gpe-clock_svn.bb: gpe-clock: unify svn recipe Jan 12 19:11:11 03Rolf Leggewie  07org.openembedded.dev * r5af33ced74 10openembedded.git/recipes/gpe-clock/ (9 files): Jan 12 19:11:11 gpe-clock: atd is a runtime not a compile-time dependency. Closes #2219 Jan 12 19:11:11 * introduce INC_PR Jan 12 19:14:22 Tartarus: Apologies, this probably sounds stupid. But how should I run gcc by hand? I guess I need to reproduce the environment as created by bitbake first, don't I? Jan 12 19:14:53 Well, in temp/log.do_compile.XXX you'll have the whole command Jan 12 19:15:03 I see Jan 12 19:15:05 just invoke gcc directly instead, it /opt/sharprom..../bin/arm-...gcc Jan 12 19:15:11 instead of having it be found in PATH Jan 12 19:15:16 OK Jan 12 19:16:33 $ l /export/oe/tmp/sharprom-compatible/org.openembedded.dev/work/armv4-linux/glib-2.0-2.22.1-r5.2/ Jan 12 19:16:33 glib-2.22.1/ glibconfig-sysdefs.h temp/ Jan 12 19:17:03 does that look OK? why is glibconfig-sysdefs.h in that directory and not in $S? Jan 12 19:19:47 http://paste.debian.net/56503/ is run.do_compile but I'm not sure where to extract the gcc command. I see that gcc seems to be already called with -E Jan 12 19:25:02 ah Jan 12 19:25:08 log.do_compile Jan 12 19:52:30 Tartarus: Is the call in http://paste.debian.net/56509/ correct? Jan 12 19:53:15 almost Jan 12 19:53:28 you might want to change the -o part at the end Jan 12 19:53:45 and you'll need to give the full path to gatomic.c Jan 12 19:59:48 Tartarus: might want to change the -o part? in what way? Jan 12 20:01:20 Well, unless ./.libs exists it'll be mad about that Jan 12 20:01:40 and it's a .i file now, so -o gatomic.i would make sense Jan 12 20:02:15 .libs exists, but is an empty directory Jan 12 20:02:26 whatever a .i file is Jan 12 20:02:33 ;-) Jan 12 20:05:08 did anyone ever work out the xserver-common situation? Jan 12 20:08:24 Tartarus: next attempt: http://paste.debian.net/56511 Jan 12 20:08:29 kergoth: -v, please Jan 12 20:08:55 hm? Jan 12 20:09:12 just a link to a previous discussion may suffice Jan 12 20:09:29 Tartarus: why is that file not found, it should be included, no? Jan 12 20:09:41 oh, just xserver-kdrive-common seemed to be used even in xorg images, and it has conditionals that aren't particularly useful with xorg Jan 12 20:09:44 iirc, anyway Jan 12 20:09:54 ./ is included and ./glib/gtestutils.h exists Jan 12 20:10:31 kergoth: used as in "included" or used as "bitbake compiles both xorg and kdrive"? Jan 12 20:10:49 xserver-kdrive-common != xserver-kdrive. the former is /etc scripts and the like Jan 12 20:11:01 the former is included via task-x11, iirc, regardless of which x server you're using Jan 12 20:11:07 unless matters have changed recently Jan 12 20:11:18 Laibsch, run the command from the same dir that the compile does, is probably why Jan 12 20:11:19 kergoth: I keep pondering on it, but never really came to satisfactory solution Jan 12 20:13:35 XorA|gone: okay, thanks, was wondering Jan 12 20:14:38 kergoth: I did wonder about rather than one monolithic script doing a source-$MACHINE and using overrides to install the right file Jan 12 20:15:05 I gues could extend that to source $MACHINE-xorg or source $MACHINE-kdrive Jan 12 20:15:27 Tartarus: I thought that is what I was doing. running the command from the glib/ subdirectory works fine now. What does that tell us? Jan 12 20:15:31 * kergoth also just had someone run into startx wanting /usr/bin/X, not /usr/bin/Xfbdev Jan 12 20:15:50 Laibsch, yes, you preprocessed the file now instead of compiling it Jan 12 20:16:03 Now you can see what the compiler was going to compile, for real Jan 12 20:16:10 and see if was included or not Jan 12 20:16:37 how? ;-) Jan 12 20:16:44 strip -E? Jan 12 20:16:58 No, ${PAGER} .libs/whatever it was.o Jan 12 20:17:02 Since it's not an object now Jan 12 20:19:29 03Kristoffer Ericson  07org.openembedded.dev * rb091aba966 10openembedded.git/conf/distro/jlime-2009.1.conf: Jan 12 20:19:29 No reason to use diet-x11 any longer for jlime-2009.1.conf Jan 12 20:19:29 Signed-off-by: Alex Ferguson Jan 12 20:19:29 Signed-off-by: Kristoffer Ericson Jan 12 20:19:30 03Kristoffer Ericson  07org.openembedded.dev * r66cf00231c 10openembedded.git/conf/machine/jornada6xx.conf: Jan 12 20:19:34 Update kernel version and needed packages for jornada6xx. Jan 12 20:19:36 Signed-off-by: Alex Ferguson Jan 12 20:19:38 Signed-off-by: Kristoffer Ericson Jan 12 20:19:40 03Kristoffer Ericson  07org.openembedded.dev * rf1f6bd0dd3 10openembedded.git/recipes/linux/linux-jlime-jornada6xx_2.6.32.bb: Add linux-hpc.git branch v2.6.32 for jornada6xx kernel recipe. Jan 12 20:24:01 Tartarus: http://oss.leggewie.org/wip/libgatomic_la-gatomic.o.txt (added the txt extention so apache would serve it as text) Jan 12 20:24:13 no reference to bits/posix1_lim.h Jan 12 20:24:57 Nethack :( Jan 12 20:25:46 Laibsch, right Jan 12 20:25:56 So how is normally brought in? Jan 12 20:26:06 grep around in /opt/..../usr/include Jan 12 20:29:02 Laibsch: why is way around fork needed on uclibc is it because of linuxthreads ? Jan 12 20:29:36 khem: are you referring to a bug ticket? Jan 12 20:29:56 or to the discussion that ant initiated a few hours ago? Jan 12 20:29:58 Laibsch: there was a question asked by rob_w Jan 12 20:30:06 yeah that discussiion Jan 12 20:32:46 khem: I assume you read that discussion here. There isn't much else that I can contribute. Except that the build of opie-taskbar does indeed fail for me as well. ant said it builds in Angstrom and that got us thinking if it wasn't a toolchain issue. toolchain = khem in my head ;-) Jan 12 20:33:09 some difference between eglibc and glibc Jan 12 20:33:17 the word lpthread fell Jan 12 20:33:39 03Kristoffer Ericson  07org.openembedded.dev * r8e3f31d6ef 10openembedded.git/recipes/linux/linux-jlime-jornada7xx_2.6.19rc6.bb: Jan 12 20:33:39 fixed patch download location, added include Jan 12 20:33:39 Signed-off-by: Filip Zyzniewski Jan 12 20:33:39 Signed-off-by: Kristoffer Ericson Jan 12 20:33:40 03Kristoffer Ericson  07org.openembedded.dev * rd3b22318d8 10openembedded.git/recipes/icu/icu_3.6.bb: Jan 12 20:33:43 fixed calling native binaries with host libraries Jan 12 20:33:45 Signed-off-by: Filip zyzniewski Jan 12 20:33:47 Signed-off-by: Kristoffer Ericson Jan 12 20:33:49 03Kristoffer Ericson  07org.openembedded.dev * r562ac60eee 10openembedded.git/recipes/python/python_2.6.2.bb: Jan 12 20:33:52 fixed calling native binaries with host libraries Jan 12 20:34:41 Signed-off-by: Filip Zyzniewski Jan 12 20:34:41 Signed-off-by: Kristoffer Ericson Jan 12 20:34:41 03Kristoffer Ericson  07org.openembedded.dev * re679efd298 10openembedded.git/conf/checksums.ini: Jan 12 20:34:42 some download URIs changed, update. Jan 12 20:34:44 Signed-off-by: Filip Zyzniewski Jan 12 20:34:46 Signed-off-by: Kristoffer Ericson Jan 12 20:35:19 Laibsch: whats the error Jan 12 20:37:26 khem: http://tinderbox.openembedded.org/packages/opie-taskbar/ for example http://tinderbox.openembedded.org/public/logs/task/4375934.txt Jan 12 20:38:52 http://tinderbox.openembedded.org/packages/391521/ is a failing report (same error AFAICT) against angstrom Jan 12 20:39:38 Laibsch: which version of gcc are you using 4.4.2 ? Jan 12 20:40:13 Whatever is set for minimal. I think that would be 4.4.2, yes. But let me check Jan 12 20:40:33 Laibsch: ok cool Jan 12 20:40:40 and angtrom too Jan 12 20:40:50 so its seen in both gcc 4.4 and 4.3 Jan 12 20:42:06 and angstrom and minimal use different versions of binutils too Jan 12 20:42:14 yes, stamps tells me it's 4.4.2 Jan 12 20:42:19 same error with two sets of toolchains Jan 12 20:42:35 OK, so it's not a toolchain problem? Jan 12 20:42:37 chances of toolchain error are less but never say never Jan 12 20:42:47 I see Jan 12 20:42:57 Let's wait for bluelightning so he can have a look Jan 12 20:43:06 Unless you have some time on your hands ;-) Jan 12 20:43:14 if I could have a look at the build tree I could see more Jan 12 20:43:30 OK Jan 12 20:43:35 I will tar it up for you Jan 12 20:43:41 * khem is trying to revice mips uclibc/nptl these days Jan 12 20:43:46 ok cool Jan 12 20:44:03 thanks Jan 12 20:47:46 http://oss.leggewie.org/wip/khem.tar.bz2 Jan 12 20:48:19 lnkproperties.cpp seems to have the definition for the destructor in question Jan 12 20:48:26 so I wonder why it is not findinf it Jan 12 20:49:41 Laibsch: 10 mins to download :) I will have lunch meanwhile Jan 12 20:55:33 Tartarus: http://paste.debian.net/56518/ Jan 12 20:56:10 I'm a bit surprised to see it's usually included from /usr/include and not from the staging area of OE Jan 12 20:58:42 work/*/glib-2.0-2.22.1-r5.2/glib-2.22.1/glib/.deps/gdir.Plo and work/armv5te-linux/glib-2.0-2.22.1-r5.2/glib-2.22.1/glib/.deps/gspawn.Plo point to an existing file Jan 12 21:02:39 Laibsch: i guess include paths order is different Jan 12 21:03:16 khem: for the opie-taskbar issue or for the sharprom issue with glib-2.0? Jan 12 21:03:24 glib Jan 12 21:04:29 /usr/local/arm/2.95.3/ Jan 12 21:04:42 how does it get into the env Jan 12 21:11:45 Anyone tried to build fltk2 for the Angstrom dev branch? Jan 12 21:12:06 Laibsch: can you search for lnkproperties.cpp in your tmp Jan 12 21:14:05 john268: check tinderbox Jan 12 21:14:40 Laibsch: Thanks Jan 12 21:15:40 that's a bit shorter ;-) Jan 12 21:16:25 john268: seems to build for most people: http://tinderbox.openembedded.org/packages/fltk2/ Jan 12 21:16:29 except me :-( Jan 12 21:17:27 Laibsch: Strange as I'm trying to build for Angstrom dev branch and I get errors Jan 12 21:17:59 Laibsch: http://pastebin.com/m5265b21b Jan 12 21:18:15 !tinderbox Jan 12 21:18:20 ~tinderbox Jan 12 21:18:21 well, tinderbox is mozilla.org's system for making sure the build tree doesn't catch on fire Jan 12 21:18:28 that may be true Jan 12 21:18:38 * Laibsch wishes our bot was revived Jan 12 21:18:50 * Laibsch looks in CoreDump's direction Jan 12 21:18:54 please Jan 12 21:19:31 john268: http://wiki.openembedded.net/index.php/How_do_I_send_automatic_success_and_failure_reports Jan 12 21:20:18 Laibsch: I'll do that. Thanks Jan 12 21:20:37 looks exactly like the error that I was getting Jan 12 21:20:44 so, it's probably for real Jan 12 21:21:04 at the same time, the openmoko builder is building the same revision and succeeds at doing that Jan 12 21:21:40 Laibsch: I even updated the rev to the latest FLTK2 and still it has errors Jan 12 21:22:46 it's likely a problem inside OE, like incompatible versions of something Jan 12 21:22:51 Laibsch: seem that XFT_MAJOR is not defined correctly for Font_xft.cxx, even though it is defined in Xft.h. Jan 12 21:22:56 and the openmoko builder was lucky in piccking the right one Jan 12 21:23:18 * Laibsch doesn't like to be pinged all that much Jan 12 21:24:52 I was able to build FLTK2 on Ubuntu without any problems. Works fine. Jan 12 21:25:28 john268: preprocess the faulting file Jan 12 21:26:01 and check where it gets the definition of _XftFont Jan 12 21:26:29 on ubuntu you did a native compile here you are doing cross compile which is lot more errorprone Jan 12 21:27:43 Laibsch: btw I've checked that fltk bug you pinged me.. and seems sort off already included.. fluid is built but packaged in another package.. and tests can be packaged separately too (instead of disabling them completely.. ) but I'll check more later.. (seen some breakage..) Jan 12 21:27:59 JaMa|W: you have a number? Jan 12 21:29:47 what's the recipe variable for the host staging dir? Jan 12 21:30:01 hkem: cannot seem to find where _XftFont is defined Jan 12 21:30:05 I mean tmp/staging/armv4-linux Jan 12 21:30:55 filip: bitbake -e can help you to find variable definitions Jan 12 21:31:27 yay, thanks khem :) Jan 12 21:31:49 john268: that could be because something did not get installed which was a build requisite Jan 12 21:31:58 http://oss.leggewie.org/wip/khem_grep.txt Jan 12 21:31:59 see which package provides this header Jan 12 21:33:35 khem: On my Ubuntu machine it is defined in /usr/include/X11/Xft/Xft.h Jan 12 21:33:43 Laibsch: 4725 Jan 12 21:33:53 Laibsch: can you tar up libqpe-opie-1.2.2-r7.0 for me plz Jan 12 21:33:54 yes, just found it Jan 12 21:34:12 khem: yes, just a minute Jan 12 21:34:16 john268: check yout staging area Jan 12 21:34:25 do you have it there ? Jan 12 21:34:36 and if yes check if structure is defined Jan 12 21:34:42 in the staged header file Jan 12 21:35:10 hi,mmm | .../install: cannot stat `...i/glibc-initial-2.9-r35.3/build-arm-angstrom-linux-gnueabi/gnu/lib-names.h': Jan 12 21:35:20 khem: yes the file is there Jan 12 21:36:03 JaMa|W: fltk2 fails to build for me (as currently discussed). If you feel like it, can you package the tests separately and close the ticket? Jan 12 21:36:42 Laibsch: sure.. but later.. Jan 12 21:36:52 great Jan 12 21:36:54 no rush Jan 12 21:36:55 Laibsch: I'll also check your build error with fltk2 Jan 12 21:37:01 john268: is the struct in there Jan 12 21:37:11 khem: yes Jan 12 21:37:31 and it has definitions for missing members Jan 12 21:37:52 khem: no Jan 12 21:38:27 khem: the workdir is basically empty (I use rm_work) except for the logs: http://oss.leggewie.org/wip/libqpe-opie-1.2.2-r7.0/ Jan 12 21:38:43 ok that would mean that xft you built and staged is not good enough for fltk2 version you are building Jan 12 21:39:24 Laibsch: hmmm I was interested in objects too Jan 12 21:39:36 khem: if XFT_MAJOR =2 as defined in Xft.h, then this code should not exist Jan 12 21:39:55 I can recompile without rm_work, that is what you are after, right? Jan 12 21:40:27 yeah Jan 12 21:40:34 Laibsch: I moved to minimal/x11-image in the meantime Jan 12 21:40:56 khem: It'll be a while, though. Jan 12 21:40:59 it seems x11-image.bb needs SPLASH ?= "" Jan 12 21:41:02 john268: and check who defines it Jan 12 21:41:08 Laibsch: its ok Jan 12 21:41:20 Laibsch: meanwhile you can upload libqpe.so.1.5 Jan 12 21:41:26 binary Jan 12 21:41:59 or see if you have libqpe.a in staging then that too Jan 12 21:42:28 khem: who defines what? Jan 12 21:43:35 XFT_MAJOR Jan 12 21:44:29 khem: Font_xft.h -> x.h -> x11.h -> Xft.h, which defines XFT_MAJOR Jan 12 21:45:10 #define XFT_MAJOR 2 Jan 12 21:46:10 john268: so it seems to me that the package you are tryn to build expects XFT_MAJOR < 2 Jan 12 21:46:19 http://oss.leggewie.org/wip/khem/ Jan 12 21:46:22 Laibsch: perhaps minimal should set SPLASH Jan 12 21:46:31 yes Jan 12 21:46:41 I've been thinking it should Jan 12 21:46:48 But will have to ask mickey Jan 12 21:47:03 and then again, minimal is about making "minimal" assumptions Jan 12 21:47:20 it doesn't break anything, or does it? Jan 12 21:47:27 ok, then we should standardize the setting in the images Jan 12 21:47:40 some sets SPLASH ?= Jan 12 21:48:00 khem: Since font->core does not exist, I think XFT_MAJOR should > 1 Jan 12 21:49:58 john268 you could probably choose a version of fltk which is buildable with xft 2.1 Jan 12 21:50:25 whats your distro ? Jan 12 21:50:33 Angstrom Jan 12 21:50:35 and which version of fltk Jan 12 21:50:41 are you baking Jan 12 21:51:00 khem: just a min Jan 12 21:51:37 khem: 6995 Jan 12 21:52:13 khem: I tried the default OE fltk2 version and it also gave me errors Jan 12 21:55:18 guys, let me know what solution you come up with for fltk2. JaMa|W and me are also interested in it. Let's make sure it's properly fixed in OE .dev Jan 12 21:55:47 http://oss.leggewie.org/wip/khem/libqpe-opie-1.2.2-r7.0/ build is done Jan 12 21:56:10 Building the default OE version of fltk2 now Jan 12 21:56:21 khem: if you prefer, I can make a tar out of that directory. Jan 12 21:58:02 khem: same error Jan 12 22:00:01 john268: my guess is that you have to patch fltk Jan 12 22:00:12 to cater for newer libxft Jan 12 22:01:01 khem: Any idea why this build fine on Ubuntu? Jan 12 22:01:16 khem: that is a completely different task Jan 12 22:01:42 same sources ? Jan 12 22:01:49 the combinations of software is completely different, plus they compiley natively, we cross-compile Jan 12 22:01:50 Yes Jan 12 22:02:07 Agreed Jan 12 22:02:31 I dont have much idea other than what I said Jan 12 22:02:39 you have to play cat and mouse with the define Jan 12 22:04:46 khem: you are looking at both the opie-taskbar issue (minimal distro) as well as the glib-2.0 issue (sharprom-compatible), right? just so that I don't send you information that has nothing to do with what you are looking for. This also touches two different computers: a fast 64bit host for minimal and a slow 32bit host for sharprom (which does not go along with 64bit) Jan 12 22:05:16 I managed to build fltk2 on my BeagleBoard running Ubuntu, but the LXDE desktop seems to have a problem with variable font Jan 12 22:06:29 Tartarus: Are you Tom R.? Jan 12 22:07:00 Laibsch: 00000c5c T LnkProperties::~LnkProperties(void) Jan 12 22:07:17 which means the reported function should be picked from this library Jan 12 22:07:22 when linking task bar Jan 12 22:08:42 yes Jan 12 22:09:00 Laibsch: actually 0012a7f4 T LnkProperties::~LnkProperties(void) Jan 12 22:09:36 Laibsch: can you also upload opie-taskbar-1.2.4-r1 build tree Jan 12 22:09:40 Tartarus: I see. I didn't notice you in the bug tracker anymore and figured you had left. Nice to see you around. Jan 12 22:09:47 heh Jan 12 22:09:50 just busy with work Jan 12 22:10:35 Thanks for your help guys Jan 12 22:10:49 * Laibsch takes extended breaks from time to time Jan 12 22:12:26 john268: is the issue resolved or just "time's up"? Jan 12 22:12:42 khem: does opie-taskbar compile for you? Jan 12 22:13:39 Laibsch: no idea I am ususally use console-image or native-sdk-image Jan 12 22:13:55 plus my harddisk is small (80G) Jan 12 22:13:57 :) Jan 12 22:14:00 with my slow connection it may be quicker to build yourself ;-) Jan 12 22:14:24 oh, you're cursed with a small HD ;-) Jan 12 22:14:24 heh no not with my slow machine :) Jan 12 22:14:46 I'm digging in to find a solution. Will let you know if I get something that works Jan 12 22:14:47 and its has got enough bad sectors now Jan 12 22:14:55 I should replace it some time soon Jan 12 22:16:21 there are 500G disks under $50 these days Jan 12 22:16:29 I will buy one for abuse Jan 12 22:17:15 * khem drives to airport Jan 12 22:17:17 * khem away Jan 12 22:17:38 Have a safe trip Jan 12 22:19:45 khem: http://80.81.242.146/opie-taskbar-1.2.4-r1/ Jan 12 22:21:39 khem: that link will be active for about 12 hours. Please (w)get it. Jan 12 22:31:32 Laibsch: minimal/x11-image built fine Jan 12 22:31:45 some odd NOTES on screen, though Jan 12 22:32:18 for do_package Jan 12 22:32:25 cp: cannot stat `/oe/build/tmp/work/all-oe-linux-gnueabi/angstrom-gpe-task-settings-1.0-r35/image/*': No such file or directory Jan 12 22:32:25 cp: cannot stat `/oe/build/tmp/work/c7x0-oe-linux-gnueabi/angstrom-gpe-task-base-1.0-r40/image/*': No such file or directory Jan 12 22:32:34 cp: cannot stat `/oe/build/tmp/work/c7x0-oe-linux-gnueabi/angstrom-x11-base-depends-1.0-r43/image/*': No such file or directory Jan 12 22:32:49 probably there are more, I wasn't paying attention to th elogs Jan 12 22:34:49 why x11-image? Jan 12 22:34:57 xorg-image builds fine for me Jan 12 22:35:06 I usually build console- opie- and x11-image Jan 12 22:35:37 c7x0 doesn't use xorg Jan 12 22:42:53 i see Jan 12 22:48:56 ..and there are still enough bugs in the x11-image image ;) Jan 12 22:50:18 re Jan 12 22:50:29 hi woglinde_ Jan 12 22:50:56 oh Jan 12 22:51:02 khem fixed opie too? Jan 12 22:51:11 I wanted to push that fix too Jan 12 22:51:31 laibsch do you already pushed it? Jan 12 22:52:00 no Jan 12 22:52:05 you have a fix? Jan 12 22:52:13 we're all looking for it Jan 12 22:52:45 hm at least compiling Jan 12 22:52:45 * ant__ is battling with 2.6.33+ Jan 12 22:52:57 and maybee loosing some functionality Jan 12 22:53:00 ant__: seen my e-mail? Jan 12 22:53:09 hi, no... Jan 12 22:53:23 but opie seems to work quit nice when I comment the lnk:properties Jan 12 22:53:32 I think I will push it Jan 12 22:53:37 mom Jan 12 22:53:39 confirmed what we talked about.. Jan 12 22:54:18 re jama Jan 12 22:55:21 JaMa: great Jan 12 22:55:26 woglinde_: re woglinde Jan 12 23:06:11 Tartarus: Did you have a chance to take a look at http://paste.debian.net/56518/? Jan 12 23:07:00 last thing we were talking about was how to correctly include posix1_lim.h Jan 12 23:14:35 pushed Jan 12 23:14:39 03Henning Heinold  07org.openembedded.dev * r63004ac58a 10openembedded.git/recipes/opie-taskbar/ (opie-taskbar/launcher.patch opie-taskbar_1.2.4.bb): Jan 12 23:14:39 opie-taskbar: compile fix Jan 12 23:14:39 * comment the use of LnkProperties Jan 12 23:14:39 * maybee opie losses some functionality, but it's better to Jan 12 23:14:39 have something working for now Jan 12 23:14:41 * bump PR Jan 12 23:18:48 03Martin Jansa  07org.openembedded.dev * rcf17b9d8ac 10openembedded.git/recipes/ (2 files in 2 dirs): Jan 12 23:18:48 linux-2.6.32+2.6.33-rc3: enable physmap and magic sysrq (the same for kexecboot) Jan 12 23:18:48 Signed-off-by: Martin Jansa Jan 13 00:04:53 03Andrea Adami  07org.openembedded.dev * rfc21bcc967 10openembedded.git/recipes/kexecboot/ (4 files in 4 dirs): Jan 13 00:04:53 linux-kexecboot: update Zaurus clamshell's defconfigs for Jan 13 00:04:53 2.6.32/2.6.33-rc3 Jan 13 00:08:02 03Andrea Adami  07org.openembedded.dev * rd5d56d7f5c 10openembedded.git/recipes/kexecboot/linux-kexecboot-2.6.32+2.6.33-rc3/akita/defconfig: linux-kexecboot-2.6.32+2.6.33-rc3: use the spitz defconfig for akita too Jan 13 00:08:25 ant__: Did you talk to anyone owning an Akita? Jan 13 00:08:31 yes, Jay7 Jan 13 00:08:45 old kexecboot kernels shared same defconfig Jan 13 00:08:59 good Jan 13 00:09:24 actually it would be almost possible to create a single kernel for all Jan 13 00:09:36 (don't ask me ;) Jan 13 00:09:58 Laibsch: practically vanilla Jan 13 00:10:20 that is something we should aim for, then Jan 13 00:10:26 great work has been done! Jan 13 00:10:29 I'm always for untangling any mess Jan 13 00:10:33 Yes, apparently Jan 13 00:10:47 Kudos to the folks who did it Jan 13 00:10:55 only collie is astep back.. Jan 13 00:10:59 Really? Jan 13 00:11:03 that's sad Jan 13 00:11:12 What's holding it back? Jan 13 00:11:23 Can you give me a status update? Jan 13 00:14:20 Laibsch: btw we 'discovered' an en-jp .db3 dictionary in the Zaurus ROM Jan 13 00:14:39 yes Jan 13 00:14:48 the stock Zaurus shipped with something Jan 13 00:14:54 I never had a chance to look at it Jan 13 00:15:01 is it in an open format? Jan 13 00:15:06 I thought it wasn't Jan 13 00:15:42 no idea, seems db3 Jan 13 00:15:42 woglinde_: compile is indeed successful now. We shouldn't forget to ask bluelightning about it, though. Jan 13 00:16:31 ant__: you never poked inside? How were you able to tell its contentc? from the name? Jan 13 00:18:53 Laibsch: read zaurus-devel ML Jan 13 00:18:59 there is a long post Jan 13 00:19:24 available on gmane? Jan 13 00:19:55 yes Jan 13 00:19:59 ...is Jan 13 00:19:59 in fact EN-JP DB3 file-partition ( Jan 13 00:20:03 ... Jan 13 00:20:09 vibrant mailing list Jan 13 00:20:10 Nice Jan 13 00:22:36 ant__: are you sure the list is on gmane? Jan 13 00:22:51 zaurus-devel@lists.linuxtogo.org/ Jan 13 00:23:20 found it Jan 13 00:23:22 gmane! Jan 13 00:23:32 old but working pipermail Jan 13 00:23:33 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel Jan 13 00:25:08 basically the kernel hackers are filtering the LAKML for us wrt Zaurus Jan 13 00:27:03 cherry-picking the interesting posts Jan 13 00:27:20 anyone around? Jan 13 00:27:26 nope Jan 13 00:27:26 have a problem with .32 Jan 13 00:27:37 it boots fine the first time Jan 13 00:27:53 and I can even use my camera Jan 13 00:28:07 but after I have done the depmod -a Jan 13 00:28:16 I guess some modules get loaded that dont gel well Jan 13 00:28:28 but the next time I restart the beagleboard, it gets stuck on modprobe Jan 13 00:28:36 keeps having soft lockup errors Jan 13 00:28:46 hm better aks on #beagleboard? Jan 13 00:28:52 see topic Jan 13 00:29:12 btw Ithink the latest 2.6.32 was unstable. see koen commits Jan 13 00:43:31 03Michael 'Mickey' Lauer  07org.openembedded.dev * refa8f608e5 10openembedded.git/recipes/libnl/libnl2_git.bb: libnl2: ship libnl2-cli seperately Jan 13 00:43:41 03Michael 'Mickey' Lauer  07org.openembedded.dev * r27ecb17f1c 10openembedded.git/ (3 files in 2 dirs): msmcommd: new recipe; support daemon for qualcomm modems w/ binary protocol Jan 13 00:48:37 Laibsch: the situation of SPLASH is interesting: just three distro declaring it Jan 13 00:49:07 and most (but not all) images.bb have that SPLASH ?= "" Jan 13 00:49:29 if it is in IMAGE_INSTALL Jan 13 00:49:59 moreover, there are a couple of angstromizms in some images Jan 13 00:50:51 I realized that I have hardwired the splash thing locally Jan 13 00:50:58 e.g. x11-gpe-image, redeclaring SPLASH ?= ' ${@base_contains("MACHINE_FEATURES", "screen", "psplash-angstrom", "",d)}' as in Angstrom.2008.1.inc Jan 13 00:51:07 I didn't feel like fiying it properly at the time I stumbled across it Jan 13 00:51:27 I think we should raise it on the ml Jan 13 00:51:39 I guess the safe default is to use the OE splash Jan 13 00:51:49 and distros can deviate if the choose to Jan 13 00:51:55 now it's abit reverse Jan 13 00:52:05 distro can have custom splash Jan 13 00:52:15 in some situations you will ge the angstrom splash unless you take deliberate action not to Jan 13 00:52:21 exactly Jan 13 00:52:30 distros can have a custom splash Jan 13 00:52:36 but they need to define it Jan 13 00:52:39 imho the correct setting in the images is SPLASH ?= "" Jan 13 00:52:46 and define it before Jan 13 00:52:53 I would disagree Jan 13 00:53:08 default is SPLASH ?= "psplash" globally Jan 13 00:53:11 at least most recipes are like this Jan 13 00:53:30 and distro and people can deviate from that Jan 13 00:53:31 I grepped in /distro and in /images Jan 13 00:54:13 at least minimal doesn't define it. I got the error Jan 13 00:54:49 http://fr.pastebin.ca/1749045 Jan 13 00:54:51 do you understand what I'm proposing? Jan 13 00:55:14 there are distro for headless machines Jan 13 00:55:21 03Rolf Leggewie  07org.openembedded.dev * r1020db745d 10openembedded.git/ (conf/checksums.ini recipes/gourmet/gourmet_0.15.2.bb): Jan 13 00:55:21 gourmet: initial commit Jan 13 00:55:21 * gourmet is a mealmaster-format compatible recipe collection software Jan 13 00:55:21 * compiles, testing on-device to be done (may require higher than VGA resolution) Jan 13 00:55:30 they would not bother with screen/splash Jan 13 00:55:54 preferably Jan 13 00:56:27 they can set SPLASH = "" Jan 13 00:56:54 in the distro conf file? Jan 13 00:57:01 I would think so Jan 13 00:57:30 I would consider that preferable to a situation where a distro is somehow broken unless it defines SPLASH Jan 13 00:57:54 I think the sane default is "psplash" or some other generic OE splash Jan 13 00:57:58 and not "" Jan 13 00:58:07 But then again Jan 13 00:58:09 I don't have strong opinion for or against. is a variable more Jan 13 00:58:26 just this Jan 13 00:58:28 "" may be the sane default and distro should define their own preferred splash if they want to Jan 13 00:58:58 well, again, minimal is about showing assumptions in OE metadata that should not be there Jan 13 00:59:04 really the matter should be discussed with distro maintainers Jan 13 00:59:11 on the ML Jan 13 00:59:15 yes Jan 13 00:59:19 let say..we throw the stone Jan 13 00:59:31 I'm starting to lean towards "" as default Jan 13 01:00:13 actually the recipes have been fixed only if someone stumbled in this errors Jan 13 01:00:21 the images-recipes Jan 13 01:01:08 we already discussed the possibility to have a matrix of distro/images successfully built Jan 13 01:01:27 these simpl errors would immediately come out Jan 13 01:02:05 ok, have to sleep now Jan 13 01:02:10 gn Jan 13 01:02:24 re kergoth Jan 13 02:01:59 03Khem Raj  07org.openembedded.dev * recb41b75cd 10openembedded.git/recipes/uclibc/ (2 files in 2 dirs): Jan 13 02:01:59 uclibc-nptl: Fix booting problems on mips nptl. Jan 13 02:01:59 * This patch fixes the fundamental problems in getting a Jan 13 02:01:59 bootable system based on uclibc nptl for mips. Patch is Jan 13 02:01:59 submitted upstream. Jan 13 02:02:01 Signed-off-by: Khem Raj Jan 13 02:38:42 khem: Are you still there? Jan 13 02:43:38 khem: Thank you for those patches. Can you document their upstream status as described in http://wiki.openembedded.net/index.php/Push_patches_upstream ? **** ENDING LOGGING AT Wed Jan 13 02:59:57 2010