**** BEGIN LOGGING AT Tue Dec 05 02:59:57 2006 Dec 05 03:49:55 hi, all! Dec 05 03:51:24 if I want to use some particuar file on distro x on arch y how should I write FILES_${PN}_distro_arch or FILES_${PN}_arch_distro? Dec 05 04:38:18 !pester CoreDump|home about test something Dec 05 04:38:25 ~pester CoreDump|home about test something Dec 05 04:38:27 CoreDump|home about test something: Are we there yet? .. Are we there yet? .. Are we there yet? see http://beverlys.net/LJ/BuggingYou.swf Dec 05 04:38:43 lol good one Dec 05 04:47:05 ~pester CoreDump|home to fix bug xyz Dec 05 04:47:07 CoreDump|home to fix bug xyz: Are we there yet? .. Are we there yet? .. Are we there yet? see http://beverlys.net/LJ/BuggingYou.swf Dec 05 04:58:02 if I want to use some particuar file on distro x on arch y how should I write FILES_${PN}_distro_arch or FILES_${PN}_arch_distro? Dec 05 04:58:11 rhi, all! Dec 05 04:58:14 rehi Dec 05 05:01:57 slapin_nb: Don't think you can do that... you can do distro or arch, but not both. Look at the definition of OVERRIDES in bitbake.conf Dec 05 07:02:10 * Ifaistos wakeup ifaistos Dec 05 08:08:46 hey koen Dec 05 08:18:53 morning all Dec 05 08:20:05 Heyas Dec 05 08:21:02 RP: Do you have any experience with the USB controller on spitz/borzoi under 2.6? Dec 05 08:21:18 NAbyss_: A small amount... Dec 05 08:21:56 RP: Recently changed from OZ .dev to angstrom.. having a bit of USB trouble with 2.6.18 on spitz with angstrom unstable.. lsusb seems to show that the root hub is unpowered (?), with MaxPower 0mA, and fails to negotiate a configuration for a downstream device (maxpower 160mA) whereas under OZ 3.5.4.1 the device worked fine.. any id Dec 05 08:22:02 eas? Dec 05 08:23:37 We did add in a power restriction which might have been 150mA Dec 05 08:24:55 Ahh, that'd do it :) Dec 05 08:25:18 NAbyss_: See power_budget in arch/arm/mach-pxa/spitz.c Dec 05 08:25:19 RP: Thanks Dec 05 08:31:09 good morning all Dec 05 08:31:56 morning Dec 05 08:33:52 hey XorA Dec 05 08:43:06 morning Dec 05 08:43:59 morning all Dec 05 08:45:08 someone has a clue why my gcc-cross-initial fails ? why the hell does it try to pass this -Qy option to the arm version of as ? http://pastebin.ca/268077 Dec 05 08:45:26 RP: you fixed it? ;) Dec 05 08:45:53 zecke: it seems tinderbox doesn't like multithreaded bitbake Dec 05 08:47:49 koen: right Dec 05 08:49:13 zecke: maybe, we'll see :) Dec 05 08:59:00 monring all Dec 05 08:59:08 morning all, even Dec 05 09:01:34 could someone have a look at this bug : Dec 05 09:01:37 !oebug 1613 Dec 05 09:01:39 * * Bug 1613, Status: NEW, Created: 2006-11-23 09:14 Dec 05 09:01:40 * * ronan(AT)aimao.org: New recipe - mplayerplug-in_3.31.bb Dec 05 09:01:40 * * http://bugs.openembedded.org/show_bug.cgi?id=1613 Dec 05 09:02:43 i need an advise about how to get/set dynamically a variable like my MOZILLA_HOME Dec 05 09:04:01 Genesis, what do you mean by dynamically? Dec 05 09:04:22 in function of the default virtual/mozilla installed Dec 05 09:04:29 in my case firefox-1.0.7 Dec 05 09:05:01 Genesis: you need to get mozilla/firfox.bb to drop the info into staging somewhere (if they use pkgconfig it might already be there) then read it back from your package Dec 05 09:05:44 it could be have more than one mozilla installed Dec 05 09:06:43 XorA, : i already modify firefox that it does that , but it's not commited , bug 1612 Dec 05 09:06:52 !oebug 1612 Dec 05 09:06:53 * * Bug 1612, Status: NEW, Created: 2006-11-23 09:09 Dec 05 09:06:54 * * ronan(AT)aimao.org: Improved firefox_1.0.7.bb Dec 05 09:06:55 * * http://bugs.openembedded.org/show_bug.cgi?id=1612 Dec 05 09:07:30 ~oebug 1648 Dec 05 09:07:30 !oebug 1648 Dec 05 09:07:30 * * Bug 1648, Status: NEW, Created: 2006-12-04 10:34 Dec 05 09:07:30 * * goxboxlive(AT)gmail.com: Angstrom fails while rebooting Dec 05 09:07:30 * * http://bugs.openembedded.org/show_bug.cgi?id=1648 Dec 05 09:07:30 XorA: did you got #1648? Dec 05 09:07:32 hrw|work: is that diveide by zero? Dec 05 09:08:09 hrw|work: yes, I get that Dec 05 09:10:25 can you confirm bug? Dec 05 09:11:18 hrw|work: done Dec 05 09:12:53 http://www.drobe.co.uk/riscos/artifact1748.html Dec 05 09:13:08 hrw|work: can you assasinate one of your countryman please? Dec 05 09:13:37 XorA: which one and why? Dec 05 09:14:00 hrw|work: Grzegorz Getler for thinking that divx win32 dlls are running on his Ipaq Dec 05 09:14:22 ~lusers Dec 05 09:14:24 lusers are multiple luser(s). see luser Dec 05 09:14:58 ah. Dec 05 09:14:59 ~users Dec 05 09:15:01 so this is what we get for sharing our unpaid volunteer work with you? complaints and accuses? well done, this clearly supports our motivation to continue working on open source projects. Dec 05 09:19:08 03koen 07org.oe.dev * r42b98a21... 10/ (1 packages/pango/pango_1.15.1.bb): (log message trimmed) Dec 05 09:19:08 pango: update to 1.15.1, changes LIBV to 1.6.0 Dec 05 09:19:08 from the NEWS: Dec 05 09:19:08 * Optimizations: Dec 05 09:19:08 - Rework PangoLayout algorithms to avoid calling a recursive call to Dec 05 09:19:09 pango_layout_get_extents(). Avoids one pango_font_get_glyph_extents() Dec 05 09:19:11 call per glyph per layout rendering. We now make 2 such calls. Dec 05 09:19:31 koen: more speed? Dec 05 09:21:21 XorA: more caching, thus more speed Dec 05 09:21:37 !oebug 1648 Dec 05 09:21:38 * * Bug 1648, Status: RESOLVED, Created: 2006-12-04 10:34 Dec 05 09:21:40 * * goxboxlive(AT)gmail.com: Angstrom fails while rebooting Dec 05 09:21:40 * * http://bugs.openembedded.org/show_bug.cgi?id=1648 Dec 05 09:21:46 !oebug 1582 Dec 05 09:21:47 * * Bug 1582, Status: RESOLVED, Created: 2006-11-14 04:35 Dec 05 09:21:48 * * marcusbrutus(AT)internode.on.net: un-initialised variables in if statement make script error Dec 05 09:21:49 * * http://bugs.openembedded.org/show_bug.cgi?id=1582 Dec 05 09:22:22 has anyone this unrecognized option '-Qy' problem when building gcc-cross-initial ? Dec 05 09:23:45 koen: 1.15.1 is default one now? Dec 05 09:24:05 if you don't have PREFERRED_VERSION somewhere, yes Dec 05 09:24:27 koen: and it has new soname? Dec 05 09:25:05 no, different LIBV Dec 05 09:25:36 /usr/lib/pango/LIBV/modules Dec 05 09:25:44 no libpango_LIBV.so Dec 05 09:25:50 not* Dec 05 09:26:08 hay Dec 05 09:26:24 sorry, wrong screen Dec 05 09:27:43 vlo|work: That means you tried to use an Intel (g)as with arm code Dec 05 09:27:53 Or it did yesterday for me anyway :} Dec 05 09:28:13 s/Intel/ix86/ Dec 05 09:30:15 RP: ok but I haven't changed anything: it's from a bare new mtn update of yesterday for my mx31ads build .. how should I fix this ? Dec 05 09:31:05 vlo|work: No idea, sorry. I saw it under very different circumstances Dec 05 09:31:45 vlo|work: All I know is that an arm as allows -Qy, an ix86 one does not... Dec 05 09:32:49 RP: hum, an x86 one allows, an arm one not ! Dec 05 09:33:57 RP: is there a makefile for timetest.c somewhere? Dec 05 09:34:15 RP: I'm too lazy to find all the -I and -l flags by hand Dec 05 09:35:18 vlo|work: ok, I had it the wrong way around :} Dec 05 09:35:24 koen: Where is timetest.c from? Dec 05 09:36:24 folks.o-hand.com/jorn// Dec 05 09:37:22 hey florian_kc Dec 05 09:38:16 koen: It it doesn't mention them at the top of the file, I don't know offhand sorry. Jorn isn't around atm either :-/ Dec 05 09:38:24 Hello Dec 05 09:38:29 yo B_Lizzard Dec 05 09:38:36 Maybe someone can explain this to me: Dec 05 09:38:59 good morning Dec 05 09:39:09 hey florian_kc Dec 05 09:39:37 I built a GPE image, extracted it on me CF card, booted it, and configuring locale-base-en-gb just hangs Dec 05 09:40:01 But only does so when I have the static devices in /dev Dec 05 09:40:10 If I remove them, all goes ok Dec 05 09:40:12 :| Dec 05 09:41:17 It seems to be a command in the postinstall script Dec 05 09:41:50 This makes no sense to me Dec 05 09:42:32 RP: gcc `pkg-config pango --libs --cflags` `pkg-config gtk+-2.0 --libs --cflags` -o timetext timetext.c Dec 05 09:42:40 It's the localedef command that hangs Dec 05 09:43:35 koen: was that for me? Dec 05 09:43:46 B_Lizzard: sounds like you disabled ENABLE_BINARY_LOCALE_GENERATION Dec 05 09:44:08 morning around Dec 05 09:44:12 But what has that to do with the static links in /dev? Dec 05 09:45:22 ping zecke Dec 05 09:46:38 hi greentux Dec 05 09:46:49 Ok, so I go into my local.conf and change that into = "1" Dec 05 09:46:54 hi hrw|work what about the 54 mbit cf card? Dec 05 09:47:03 See if that makes any difference Dec 05 09:47:04 greentux: in progress Dec 05 09:47:07 Thanks koen Dec 05 09:47:13 greentux: sort of pong Dec 05 09:48:07 zecke: morning, do You know if there are plans for porting openmoko to road? Dec 05 09:48:33 zecke: the gsmd etc is the thing the road is missing... Dec 05 09:48:35 greentux: hehe, no idea Dec 05 09:49:00 zecke: should be a nice target (and a second available next year) Dec 05 09:49:17 greentux: we can provide external processes with a pseudo terminal already Dec 05 09:49:35 greentux: and I'm still not convinced by Harald's "Why it has to be in the kernel" statement :) Dec 05 09:49:36 I need qemu, eh... Dec 05 09:49:53 greentux: but I have no idea about the plans of ROAD Dec 05 09:49:59 zecke: ok the kernel idea is something special... Dec 05 09:51:32 zecke: and You have no time next year for doing that I assume? Dec 05 09:51:57 greentux: I have not visited the ROAD since last FOSDEM Dec 05 09:52:23 greentux: and I have no time schedule for next year, it will be more relaxed than this year though Dec 05 09:52:25 zecke: no reason to do something on the device ... if it will be produced Dec 05 09:52:46 RP: my patch does sadly not look at -L but this is on the todo Dec 05 09:53:29 Well, it has passed the postinstall stage Dec 05 09:53:40 It seems it was just going painfully slowly Dec 05 09:53:47 20 mins :| Dec 05 09:54:30 Is enabling ENABLE_BINARY_LOCALE_GENERATION good practice though? Dec 05 09:54:43 how can we force a .bb file not to build not use paralle_build ? Dec 05 09:54:46 Should I enable it anyways? Dec 05 09:55:07 RP: you commit rev #1000 to poky :) Dec 05 09:55:23 Ifaistos: PARALLEL_MAKE = "" in recipe Dec 05 10:29:01 This might be a stupid question, but does ENABLE_BINARY_LOCALE_GENERATION = "1" or ENABLE_BINARY_LOCALE_GENERATION = "0" enable generating binary locale files at build-time? Dec 05 10:30:08 "1" Dec 05 10:33:41 Ah Dec 05 10:33:49 Well, it didn't seem to work Dec 05 10:34:11 Probably because my qemu package doesn't provide an sh3 module Dec 05 10:34:18 Or something like that Dec 05 10:34:33 hum ... looks like I have unrecognized option '-Qy' because when building the gcc-cross-initial the ix86-comme SITE file is used Dec 05 10:34:33 B_Lizzard: you build for sh3? Dec 05 10:34:38 NOTE: SITE files /home/valentin/EPFL/iMXBoard/linux/openembedded/org.openembedded.dev/site/endian-little /home/valentin/EPFL/iMXBoard/linux/openembedded/org.openembedded.dev/site/ix86-common Dec 05 10:34:55 hrw, yes Dec 05 10:35:08 B_Lizzard: can you look at #1525 bug? Dec 05 10:35:12 !oebug 1525 Dec 05 10:35:13 Sure thing Dec 05 10:35:13 * * Bug 1525, Status: NEW, Created: 2006-10-23 12:16 Dec 05 10:35:14 * * kristoffer_e1(AT)hotmail.com: Crosscompiling GCC 4.1.1 fails at end Dec 05 10:35:15 * * http://bugs.openembedded.org/show_bug.cgi?id=1525 Dec 05 10:35:21 Ah Dec 05 10:35:29 I've already built GCC 4.1.1 Dec 05 10:35:44 B_Lizzard: you build gcc-cross. its gcc what breaks Dec 05 10:35:58 No, I built the native sh3 gcc Dec 05 10:36:02 the gcc for sh3 Dec 05 10:36:06 for jlime Dec 05 10:36:06 4.1.1? Dec 05 10:36:08 yes Dec 05 10:36:12 jlime-donkey? Dec 05 10:36:14 yes Dec 05 10:36:23 on 32bit machine? Dec 05 10:36:28 yes Dec 05 10:36:49 During compilation, it seems that OE doesn't build a binary called fix-headers Dec 05 10:37:05 have a patch? Dec 05 10:37:09 And bb fails at install Dec 05 10:37:17 I just put a 32-bit version Dec 05 10:37:40 B_Lizzard: cheated? Dec 05 10:37:47 It seems that fix-headers is not used anymore Dec 05 10:38:03 it is not included in any of the core gcc packages Dec 05 10:38:43 It's not in OE's gcc, not in my system's gcc Dec 05 10:39:07 From what I've seen in google, it's not an oft-used program Dec 05 10:40:04 As far as I know, just replacing fix-header with any file will not do much bad Dec 05 10:40:13 Or just telling bb not to build it Dec 05 10:41:13 And, it seems to have been fixed in GCC upstream Dec 05 10:42:24 oops Dec 05 10:46:11 ~seen zecke Dec 05 10:46:21 zecke was last seen on IRC in channel #oe, 53m 35s ago, saying: 'RP: my patch does sadly not look at -L but this is on the todo'. Dec 05 10:47:14 Bloody hell, this locale thingie is getting on my nerves Dec 05 10:58:10 zecke: poky tinderbox failed :-(, I'm not sure if it had the checkin I committed to fix that error or not though... Dec 05 10:58:36 * RP hopes not... Dec 05 10:58:39 rp zecke isnt here Dec 05 10:58:53 woglinde: he? Dec 05 10:59:02 woglinde: why did you ditch the lecture? Dec 05 10:59:03 it's his evil twin Dec 05 10:59:23 koen: the evil twin of the evil original? Dec 05 10:59:38 hu Dec 05 10:59:44 hm Dec 05 10:59:52 ah Dec 05 11:00:01 damnit didnt seen the join Dec 05 11:00:03 zecke: can you do autobuilds with LC_ALL=C set? Dec 05 11:00:14 "make[2]: Für das Ziel »all-am« ist nichts zu tun." Dec 05 11:00:20 zecke hm how about BS? Dec 05 11:00:24 hrw|work: hehe, I can... Dec 05 11:00:51 woglinde: I'm almost finished, I started this assignment directly after the class (the one you ditched) Dec 05 11:01:01 hm I see Dec 05 11:01:10 okay than I will do it myself Dec 05 11:01:13 too Dec 05 11:01:39 woglinde: hehe, when is the deadline? I have a couple of mistakes to fix Dec 05 11:02:16 zecke next week Dec 05 11:02:50 RP: I#m at rev 999 Dec 05 11:03:26 zecke: ok, the fix is in #1000 so there is hope yet :) Dec 05 11:03:38 RP: next build then :) Dec 05 11:04:47 ~seen lkcl Dec 05 11:05:13 lkcl is currently on #htc-linux (2d 19m 54s) #oe (2d 19m 54s) #openmoko (2d 19m 54s) #edev (2d 19m 54s) #openezx (2d 19m 54s) #handhelds.org (2d 19m 54s). Has said a total of 181 messages. Is idling for 2h 13m 20s, last said: 'allo goboxlive. just wanted to test the cgi irc gateway so i can go online here, at work. ... Dec 05 11:06:14 RP: I should try to send config.log as well... Dec 05 11:06:55 zecke: Its useful for debugging... Dec 05 11:08:12 restarted all builds with LC_ALL Dec 05 11:11:58 thx Dec 05 11:12:31 zecke: which DISTRO you use for .oz354x? 3.5.4.1 or 3.5.4.2? Dec 05 11:17:55 zecke: gnutls built :) Dec 05 11:20:15 koen: do you see a problem in adding detect-stylus to gpe-task-base? Dec 05 11:20:37 florian_kc: it's only needed for 2.4 machines Dec 05 11:21:31 hrw|work: I could suck and still use 3.5.4.1 Dec 05 11:21:36 koen: hmm... well, what sets up the X stuff then? Dec 05 11:21:58 zecke: ok. I will change 3.5.4.1.conf then Dec 05 11:22:13 hrw|work: no, I can build 3.5.4.2 as well Dec 05 11:22:18 Just tell me what to build Dec 05 11:22:49 zecke: 3.5.4.1/3.5.4.2 should both be buildable. I need to fix 3.5.4.1 Dec 05 11:22:49 koen: i don't mean detect-tsdevice... detect-stylus does some X setup as well. Dec 05 11:23:12 woglinde: hey, the class was quite boring. We are done with Memory and started talking about files Dec 05 11:23:19 hrw|work: hmm http://ewi546.ewi.utwente.nl/tinderbox/showlog.pl?machine_id=142&logfile=20061205072202.log&page=1 Dec 05 11:23:27 zecke I will look at the slides Dec 05 11:23:31 florian_kc: if X needs it you should add it Dec 05 11:23:38 hrw|work: DISTRO now only contains the DISTRO name, where is the version number stored? Dec 05 11:23:47 woglinde: join #opie.de Dec 05 11:24:06 zecke: argh. quil 0.39 Dec 05 11:24:36 FSCK. I forgot to push tslib 1.0 Dec 05 11:24:52 ~curse me Dec 05 11:24:56 koen: yes, it sets some useful properties... i guess we could do this in a more clever way some time but we don't have a better solution. Dec 05 11:24:57 May the fleas of a thousand camels infest your most sensitive regions, hrw|work ! Dec 05 11:25:05 zaurusd patching fails :) Dec 05 11:27:29 I know Dec 05 11:28:41 re Dec 05 11:36:56 03hrw 07org.oe.oz354x * rf12143ef... 10/ (1 conf/distro/openzaurus-3.5.4.1.conf): openzaurus 3.5.4.1: use newer zaurusd Dec 05 11:40:49 *gnaa* Dec 05 11:42:03 koen: have you ever seen this effect that infoprints are shown fullscreen? Dec 05 11:42:27 florian_kc: no, but I don't use gpe-what Dec 05 11:42:30 * florian_kc plays with Angström on a new toy Dec 05 11:42:40 koen: same with gpe-conf e.g. Dec 05 11:43:11 Looks like i need to spend more time with OE and Angström :-) Dec 05 11:43:31 * koen hands floran an Ã… :) Dec 05 11:43:53 s/floran/florian_kc / Dec 05 11:44:10 Ã… need to many keystrokes Dec 05 11:44:13 :-) Dec 05 11:44:25 ralt+rshit+[ and shift-a Dec 05 11:44:28 right :-) Dec 05 11:44:30 option-shift-a over here Dec 05 11:46:55 zecke: can you bonsai stuff give us a page that lists: Dec 05 11:47:18 1) all commit messages between $startdate and $enddate Dec 05 11:47:32 2) all new bugs between $startdate and $enddate Dec 05 11:47:40 3) all resolved bugs between $startdate and $enddate Dec 05 11:47:41 ? Dec 05 11:47:52 sure Dec 05 11:48:00 cool Dec 05 11:48:10 * koen removes another point from his OEDEM todo Dec 05 11:49:35 one step closer to tarball releases Dec 05 11:49:46 koen: 3) is easy to do with bugzilla search Dec 05 11:49:52 2) also Dec 05 11:50:10 hrw|work: I'd like an automated way via ikada Dec 05 11:52:39 florian_kc: What information does X need from detect-stylus? Dec 05 11:55:29 RP: "need" is maybe the wrong word but it sets up some bits... iirc the stylus mode hint read by some gtk patch and the cursor theme. Dec 05 11:57:20 florian_kc: Those specific packages should really have the dependency and ensure the command runs then... Dec 05 11:59:13 RP: right... even if we *should* have a better way to handle this... Dec 05 11:59:33 DEPENDS += "${@base_contains("MACHINE_FEATURES", "touchscreen", "detect-stylus", "",d)}" Dec 05 12:00:10 florian_kc: right, ideally there should be a better way but until then we should at least have the right dependencies in the right places... Dec 05 12:01:44 RP: yep Dec 05 12:01:58 koen: that's even better :-) Dec 05 12:08:41 03Laibsch 07org.oe.dev * r78bde696... 10/ (1 packages/ppp/ppp_2.4.1.bb packages/ppp/ppp_2.4.3.bb): ppp|all versions: fix SRC_URI Dec 05 12:08:50 03koen 07org.oe.dev * r9a127619... 10/ (1 packages/angstrom/task-angstrom-x11.bb): task-angstrom-x11: add detect-stylus, since it's still needed for the xcursor theme Dec 05 12:22:11 03koen 07org.oe.dev * rdbe2d7e4... 10/ (3 files in 3 dirs): angstrom: add source mirror for angstrom Dec 05 12:29:21 Cool Dec 05 12:29:53 Can somebody please verify that I did not make a mistake in my first commit? Thank you. Dec 05 12:32:44 Laibsch: the diff looks ok Dec 05 12:33:12 Laibsch: Looks good to me too Dec 05 12:33:14 Thanks. Commit message, etc.? Dec 05 12:34:31 !topic OpenEmbedded Developer Lounge | http://www.openembedded.org | FOSDEM'07: 24-25.02.2007 with OE booth. Official OE hotel astridhotel.be Dec 05 12:36:04 Laibsch: first commit? congratulations :) Dec 05 12:38:52 tada! ;-) Dec 05 12:39:29 fixed bug 1651 which was an easy pick. Dec 05 12:39:35 unfetchable stuff for angstrom-bootstrap-image should be gone now Dec 05 12:40:04 maybe git stuff, but that's broken by design ;) Dec 05 12:42:32 stupid firewall... Dec 05 12:47:05 RP: http://cgi.ebay.co.uk/HP-HX2750-Ipaq-With-Finger-print-scanner_W0QQitemZ200053677822QQihZ010QQcateg - h2750 for 77 quids Dec 05 12:47:57 hrw|work: and it's one of the rare ones with 128MB ram Dec 05 12:48:14 yes Dec 05 12:48:38 but Ania would kill me if I will buy it. Dec 05 12:49:49 wow, didiwiki is only 14kB Dec 05 12:50:02 hrw|work: Someone was asking me about getting an ipaq recently... :} Dec 05 12:51:01 RP: I would get such beast but have to get rid of zauri first Dec 05 12:51:18 hrw|work: The Zaurii are better ;-) Dec 05 12:51:41 RP: the ipaq is better for g3nt00 Dec 05 12:51:45 RP: s/better/bigger Dec 05 12:51:51 * koen washes mouth with soap Dec 05 12:52:06 RP: tosa is fsking huge (uselss), spitz is huge and heavy Dec 05 12:52:19 c7x0 is huge and slow resuming Dec 05 12:52:51 collie/poodle are .... Dec 05 12:52:51 The hx2750 is a neat size I must admit. I should fix up its kernel more... Dec 05 12:53:20 RP: currently I use my phone for pim because none of my 6 pda models is not usable for pim stuff Dec 05 12:59:34 hrw|work: I'm hoping my phone problems might get resolved soon ;-) Dec 05 12:59:41 * RP looks at mickeyl Dec 05 13:03:50 * mickeyl gives a confirming look back and nods slightly towards RP, then fading into a light smile Dec 05 13:05:24 I will probably wait for BT model Dec 05 13:05:44 *sigh* ;) Dec 05 13:05:54 the B word again Dec 05 13:06:14 depends how much 1st ver will cost anyway Dec 05 13:06:17 if you would know how much i have been fighting for BT you wouldn't turn the knife in the wound Dec 05 13:06:40 sory man but sometimes true hurts ;( Dec 05 13:06:44 heh Dec 05 13:07:15 let's see... in 7 days we know more Dec 05 13:08:15 mickeyl: new prototype? Dec 05 13:08:15 *nod* Dec 05 13:08:15 besides... if I were you I wouldn't think about phone costs .... :)) Dec 05 13:08:15 ;D Dec 05 13:15:22 Laibsch: your commit looks correct. welcome on board, dude! Dec 05 13:17:02 grep -rn IMAGE_LINGUAS * in org.openembedded.dev --> some use export, some use not. What is correct? Dec 05 13:17:26 s/use/do Dec 05 13:21:08 Is there a way to force an x86_64 host to build and i686 toolchain and use it ? Dec 05 13:21:26 Ifaistos: linux32 bitbake blah Dec 05 13:21:27 i always do two things Dec 05 13:21:34 a) BUILD_HOST=i686 Dec 05 13:21:41 b) uname hack s/x86_64/i686/ Dec 05 13:21:51 (on a 32bit userland) Dec 05 13:22:06 that seems to work fine here Dec 05 13:23:02 poor x86_64 Dec 05 13:23:34 it seems that there are a number of problems when using a mix of x86_64 and i686 host in an icecc compile farm Dec 05 13:23:45 indeed. but that was the only way I could get it to compile an image Dec 05 13:24:59 The other problem is that unpacking/configure/packing takes way longer than compiling now ;) Dec 05 13:25:18 Ifaistos: use bitbake trunk then Dec 05 13:26:12 hrw|work : This is the next step. I'll try and get a dual core machine also as the "farm master" Dec 05 13:26:34 Ifaistos: trunk make nice use of threading Dec 05 13:31:10 root Dec 05 13:31:16 password Dec 05 13:35:17 how do I cope with packages that do not use autotools, but only GNU make? (using $(CC) etc throughout its build) ? Dec 05 13:36:18 it should just work (depending on the Makefile) Dec 05 13:36:25 oe_runmake is your friend Dec 05 13:36:41 zecke: thanks Dec 05 13:36:58 zecke: I do not need to inherit a class in the package .bb? Dec 05 13:37:56 oe_runmake comes from base.bbclass Dec 05 13:38:06 but there is certain make magic I don't get... Dec 05 13:38:09 e.g. CC=Foo make Dec 05 13:38:19 vs. make CC=Foo Dec 05 13:38:27 Inheriting autotools can sometimes still help if things like make install work... Dec 05 13:39:12 mithro: hello Dec 05 13:39:27 rp: ok, will remember that if I cannot make it work without. Dec 05 13:39:58 likewise: check, nettools I battled with pb_'s Makefile there... Dec 05 13:40:05 I still don't have a clue though Dec 05 13:43:09 wow another merge with svn where it blows up the wc badly... Dec 05 13:49:36 RP: Are you ever going to implement the RFE from bug 97 or should this be WONTFIX? Dec 05 13:49:41 !oebug 97 Dec 05 13:49:42 * * Bug 97, Status: NEW, Created: 2005-06-15 03:57 Dec 05 13:49:43 * * openembedded(AT)hrw.one.pl: BBINCLUDELOGS should have option to display only XX last lines Dec 05 13:49:44 * * http://bugs.openembedded.org/show_bug.cgi?id=97 Dec 05 13:50:01 hum, interesting, bug 1449 is exactly the same problem I have here Dec 05 13:51:37 !oebug 1449 Dec 05 13:51:38 * * Bug 1449, Status: RESOLVED, Created: 2006-10-03 20:25 Dec 05 13:51:39 * * axel.lin(AT)gmail.com: package gcc-cross-4.1.1-r7: task do_compile: failed Dec 05 13:51:40 * * http://bugs.openembedded.org/show_bug.cgi?id=1449 Dec 05 13:51:54 Laibsch: Its a good idea which is why its still open. Patches welcome... Dec 05 13:52:47 Laibsch: lib/bb/build.py need patching Dec 05 13:53:09 currently it open log and print it line by line Dec 05 13:53:40 but the answer doesn't give me much information how to solve my issue ... Dec 05 13:53:49 one of solutions would be exec('tail -n%s %s' % (number_of_lines, logfile)) probably Dec 05 14:01:24 wow and another blown up merge by svn... Dec 05 14:07:10 RP, zecke, Laibsch: http://rafb.net/paste/results/CCanIn34.html Dec 05 14:08:25 sorry busy fighting broken svn... Dec 05 14:08:29 np Dec 05 14:08:54 A useful HINT: DON'T USE SVN if you want to synchronize branches! Dec 05 14:15:06 morning Dec 05 14:15:26 zecke: I use svnmerge for this :) Dec 05 14:15:32 morning Dec 05 14:18:58 chouimat: I normally have svk... Dec 05 14:19:22 chouimat: but my setup is easy. One development trunk and one branch for vendors following trunk Dec 05 14:19:37 zecke: :) Dec 05 14:19:39 chouimat: when ever vendor needs a stable release I stabilize their bits in the branch Dec 05 14:19:57 chouimat: at some point vendor branches and trunk should be identical again... Dec 05 14:20:22 with mtn I would just create multiple heads... Dec 05 14:22:15 zecke: for one project I used to have 25 differents branches (in cvs) was a joy to work with ... Dec 05 14:32:34 did mtn change the db format again with 0.31 ? Dec 05 14:33:54 Yeah, they did AFAIK Dec 05 14:34:02 You need to re-rosterify the database, from memory Dec 05 14:34:39 yeah blindly did it over night, seems to still pull and update, so thats good, not tried to commit yet though Dec 05 14:39:31 Is it possible to tell bitbake from the command line to build the cvs version of glibc? Or do I absolutely need to set this in one of the conf files? Dec 05 14:43:00 bitbake package-version Dec 05 14:47:01 hrw|work: Is there anything to do with tty redirection that patch would break? Dec 05 14:48:37 RP: did not tested redictioning Dec 05 14:49:07 hrw|work: ok, I've saved it for testing at some point, thanks Dec 05 14:49:44 ade|desk: they didn't, they changed it in 0.30, not in 0.31 Dec 05 14:51:17 anyone: I would like to create a .bb that builds against the HEAD of a very active (local) CVS tree. However, OE/bb seems to tar cvs checkouts (even if tag=HEAD) and re-use them. Dec 05 14:51:32 RP: http://bugs.openembedded.org/show_bug.cgi?id=97 - added Dec 05 14:51:46 likewise: SRCDATE = "now" Dec 05 14:51:53 hrw|work: thanks Dec 05 14:52:53 no problem - I submited that bug Dec 05 14:52:56 koen: ah hmm ok my mtn 0.30 binary was fine then with the new 0.31 all stop Dec 05 14:53:19 oh well Dec 05 14:53:29 It'd be nice to clear the bugs < 100 :) Dec 05 14:53:44 ade|desk: I updated from 0.30 to 0.31 today and no db troubles Dec 05 14:53:55 how strange Dec 05 14:57:03 hrw|work: Ah, I had tried package_version! Dec 05 14:57:18 Laibsch: :D Dec 05 14:57:48 RP: look which bugs were closed during bugdays Dec 05 14:57:50 RP: <300 ones Dec 05 14:58:00 hrw|work: Well, does not work. "Nothing provides dependency glibc-cvs" Dec 05 14:58:10 Or is cvs not a version? Dec 05 14:58:18 it isn't Dec 05 14:58:26 Well, how do I build it? Dec 05 14:58:30 Just once. Dec 05 14:58:55 argos-wlan:~/Projects/OpenEmbedded/org.openembedded.dev/packages/glibc koen$ grep ^PV * Dec 05 14:58:55 glibc_cvs.bb:PV = "2.3.5+cvs${SRCDATE}" Dec 05 14:59:55 hrw|work: I know, I tackled a lot of low numbers ones on the session before last :} Dec 05 15:05:55 I would like to verify bug 151 Dec 05 15:10:59 Is cvs the version that is being built in a normal openzaurus build? IOW, I bug 151 is fixed, right? Dec 05 15:12:28 OK, I see that hrw is taking care of it now. Dec 05 15:13:49 Laibsch: its glibc_cvs.bb one - #151 Dec 05 15:15:39 How about bug 99. Looks very "close-worthy", too ;-) Dec 05 15:15:47 * Laibsch extends the bug days another 24h Dec 05 15:16:09 hrw|work: SRCDATE = "now" combined with bitbake -i, then rebuild? Dec 05 15:17:11 Laibsch: Was the patch in #99 added? Dec 05 15:17:24 Did not check. Dec 05 15:17:38 But gcc-cross builds here. Dec 05 15:17:49 Laibsch: Check and if so or something equivalent, close it Dec 05 15:23:26 RP: Indeed, the proposed patch is already in OE. Dec 05 15:23:51 39 bugs fixed in last week. Who will make it 40? Dec 05 15:24:02 ~praise Laibsch for bug tracker work Dec 05 15:24:11 All hail Laibsch for bug tracker work! Dec 05 15:26:51 Laibsch, my bugs are easy to close , look at the 1612 :-) Dec 05 15:27:48 i'd like someone look 2sec before commit them ( 1612 , and its child ) Dec 05 15:28:25 !oebug 1612 Dec 05 15:28:26 * * Bug 1612, Status: NEW, Created: 2006-11-23 09:09 Dec 05 15:28:27 Genesis: I only do the easy stuff. That means obvious things like 404 URLs. Plus CJKV. I don't mess with adding stuff Dec 05 15:28:27 * * ronan(AT)aimao.org: Improved firefox_1.0.7.bb Dec 05 15:28:28 * * http://bugs.openembedded.org/show_bug.cgi?id=1612 Dec 05 15:28:52 oki sorry Dec 05 15:29:19 Genesis: is the gnash recipe in the bugtracker up to date? Dec 05 15:29:28 i work on it Dec 05 15:29:31 but I do have a strange feeling you might have gotten likewise interested. Dec 05 15:29:33 ;-) Dec 05 15:29:57 koen, : i work on it since last week , i read the full autobook to correct their gnu build system that is a mess Dec 05 15:30:10 m4 is not easy i find Dec 05 15:30:11 Laibsch: I was only helping you with a URL -) Dec 05 15:30:16 ~hail author of oebug Dec 05 15:30:21 * ibot bows down to author of oebug and chants, "I'M NOT WORTHY!!" Dec 05 15:30:24 yes, very nice. Dec 05 15:30:42 koen, : i've a better agg recipe , if you're interessting i can post it ... Dec 05 15:30:54 Genesis´ bugs (couple of new recipes): http://tinyurl.com/yjrttf Dec 05 15:31:00 Genesis: sure, add it to the bugtracker Dec 05 15:31:10 RP: jorn changed http://folks.o-hand.com/jorn/pango-benchmarks/timetext.c :) Dec 05 15:31:47 anyone: Is this OK for me to do? EXTRA_OEMAKE = "LDFLAGS=-L${LIBDIR}" Dec 05 15:32:00 koen: I didn't say anything either but I think he was going to rerun the test :) Dec 05 15:32:15 RP: I mailed him Dec 05 15:32:25 koen: ah, right :) Dec 05 15:32:51 Laibsch, : noone wants have a look at this lololol Dec 05 15:34:04 MOZILLA_HOME = firefox-1.0.7 <- i don't think i can avoid the pb with a pkg-config , perharps it would be better to use the /opt/netscape/plugin dir , but i don't think so. Dec 05 15:34:33 ( http://bugs.openembedded.org/attachment.cgi?id=987 ) Dec 05 15:36:12 i think my recipes are more usefull is the dev tree that on the tracker :) Dec 05 15:41:16 ~seen nicolasfr Dec 05 15:41:30 nicolasfr was last seen on IRC in channel #oe, 21h 41m 51s ago, saying: 'hrw: comparable!'. Dec 05 15:42:22 !oebug 634 Dec 05 15:42:23 * * Bug 634, Status: REOPENED, Created: 2006-01-26 15:19 Dec 05 15:42:24 * * hvontres(AT)tns.net: apm 3.2.2-r6 crashes during suspend on 5600 Dec 05 15:42:25 * * http://bugs.openembedded.org/show_bug.cgi?id=634 Dec 05 15:42:54 Now that poodle is on 2.6 kernel this one could be closed Dec 05 15:43:25 anyone can close bugs, btw Dec 05 15:44:03 634 closed Dec 05 15:44:51 hrw|work: hehe...I type faster than you do :) Dec 05 15:45:01 I wrote longer text Dec 05 15:45:27 * hvontres|poodle bows down to hrw|work's fast fingers :) Dec 05 15:45:51 Laibsch: there you go, #40 fixed Dec 05 15:46:27 ~praise hrw|work for hitting the magix 40 treshhold Dec 05 15:46:29 All hail hrw|work for hitting the magix 40 treshhold! Dec 05 15:47:14 hello Dec 05 15:47:38 ~praise hvontres|poodle for spotting the bug who made it 40 Dec 05 15:47:40 All hail hvontres|poodle for spotting the bug who made it 40! Dec 05 15:47:57 hrw: what about #54 Dec 05 15:48:02 !oebug 54 Dec 05 15:48:04 * * Bug 54, Status: REOPENED, Created: 2005-06-02 01:38 Dec 05 15:48:05 * * stephane.gourichon_oebz(AT)m4x.org: Flakey on/off suspend/resume behavior on Embedix kernel (SL5600+SL6000) with OZ3.5.3 and OZ3.5.4-RC Dec 05 15:48:06 * * http://bugs.openembedded.org/show_bug.cgi?id=54 Dec 05 15:49:13 hrw|work: what about #54 Dec 05 15:50:08 hvontres|poodle: #54 is holy grail Dec 05 15:50:39 hvontres|poodle: and it is 'simple' to close it ;D Dec 05 15:50:50 hvontres|poodle: finish collie/2.6 port Dec 05 15:51:22 * hvontres|poodle chuckles... Dec 05 15:51:23 atleast I treat this bug in this way Dec 05 15:52:10 Laibsch: and 40 bugs is small.. we still have more opened then closed (per month) Dec 05 15:52:16 hi Crofton Dec 05 15:52:38 hrw|work: But 1/3 of the bugs are close. I find that quite good. If more bugs are coming in, that is also good. Dec 05 15:52:45 closed Dec 05 15:53:50 let me login to my buildmachine Dec 05 15:55:01 gm Dec 05 15:59:14 started 'bitbake nano' with generic-uclibc/gcc 3.4.4 Dec 05 16:02:17 CoreDump|home: can you look at #331 bug? you probably have best knowledge of sd crap in 2.4-crapix systems Dec 05 16:06:11 Trying to get granule to compile from CVS: http://oz.leggewie.org/wip/granule/granule_cvs.bb. I added a task do_bootstrap which calls bootstrap.pda after do_patch and before do_configure. That file also does "./configure --enable-pda=yes". Should I comment out that .configure line from bootstrap.pda or can I just omit do_configure? If so, how? Add "do_configure () {}" to the bb file? Dec 05 16:06:56 why don't you simply override do_configure ? Dec 05 16:07:22 because this is essentially what your bootstrap does isn't it? Dec 05 16:08:35 I think so. Dec 05 16:08:55 Overriding is what I thought "do_configure () {}" might do. Dec 05 16:09:09 Or would this be done differently? Dec 05 16:09:15 no, that's it, but Dec 05 16:09:19 {} or { ...} ? Dec 05 16:09:26 first one just zaps it Dec 05 16:09:34 last one puts your bootstrap stuff in place where configure gets called Dec 05 16:09:35 * cbrake notes that "bitbake task-base -crebuild" does not seem to catch new RDEPENDS added w/ DISTRO_EXTRA_RDEPENDS when building ... Dec 05 16:10:15 mickey|devel: Probably second option is better and getting rid of do_bootstrap. Dec 05 16:10:19 so, just s/bootstrap/configure and remove that bootstrap Dec 05 16:10:20 righto Dec 05 16:10:28 For now I would be happy just to get it compiling. Dec 05 16:10:35 heh, that's another story :D Dec 05 16:10:36 I can always beautify it later ;-) Dec 05 16:10:49 Ok, thanks a lot. Dec 05 16:10:52 np Dec 05 16:11:02 cbrake: rebuild task does not care about it Dec 05 16:11:15 hrw|work: ahh, ok Dec 05 16:11:46 Laibsch: PV = "1.1+cvs" -> PV = "1.1+cvs${SRCDATE}" Dec 05 16:12:03 Ok Dec 05 16:12:06 hrw|work: so, is cleaning task-base stamps the best way then to get your task-base dependencies built if you add things to DISTRO_EXTRA_RDEPENDS? Dec 05 16:12:41 hrw|work: other than manually buiding? Dec 05 16:12:55 cbrake: I would say 'use -cclean' but you have autoclean enabled somehow.. Dec 05 16:13:21 cbrake: you can also bump PR of task-base - PR="r15.1" for example Dec 05 16:13:53 hrw|work: is autoclean what causes task-base dependencies to be cleaned when you clean task-base ? Dec 05 16:13:54 ibot: botmail for nicolasfr: http://linuxtogo.org/~koen/sharprom/ Dec 05 16:15:23 cbrake: I would call it that way Dec 05 16:15:24 * mickey|devel can't believe it that it took 4 years evangelizing to make SharpROM users use OpenEmbedded Dec 05 16:15:31 well, three years Dec 05 16:15:42 cbrake: do you have tinderclient inherited? Dec 05 16:17:13 Laibsch: I think I got kaffee-qt to build but it seems to have some bugs with garbage collection, so even HelloWorld won't run :( Dec 05 16:17:22 sharprom using OE, guylhem and dhns using OE, what's next... pdaXrom? Dec 05 16:17:24 * mickey|devel chuckles Dec 05 16:17:50 who is sharp rom? Dec 05 16:18:01 mickey|devel: pdaX develusers would be nice Dec 05 16:18:01 who are you referring to? Dec 05 16:18:02 s/sharp rom/sharp rom interest group/ Dec 05 16:18:08 hrw|work: I don't think I have tinderclient inherited. Dec 05 16:18:10 Laibsch: some folks on oesf Dec 05 16:18:14 mickey|devel: sharp itself using OE ;) Dec 05 16:18:17 heh Dec 05 16:18:26 koen: sharp dropped zaurus line Dec 05 16:18:35 mickey|devel: Microsoft using OE :) Dec 05 16:18:37 Laibsch: sharprom - the original software on the Sharp Zaurus Dec 05 16:18:58 hrw|work: Its officially dropped now? Dec 05 16:19:00 cbrake: last time I had autoclean with tinderclient Dec 05 16:19:27 RP: officially no. but sl-c3500 had to be released over half year ago (3100 with wifi) Dec 05 16:19:28 RP: but mickey|devel cannot possibly be referring to that. He meant some group on oesf. Never heard about them, though. Dec 05 16:20:24 Laibsch: They're people using OE in a way to stay compatible with those images Dec 05 16:21:05 mickey|devel: I wonder how long it takes for people to realize that "sharprom + tons of OE build software" is virtually equal to "OE built distro" Dec 05 16:21:09 hrw|work: You can't conclude that although it doesn't look good... Dec 05 16:21:36 koen: you meant 'OE built ROM' - right? Dec 05 16:22:44 koen: probably never... Dec 05 16:23:04 i wonder what's up with cacko and pdaXrom teams anyway. are they still active? Dec 05 16:23:33 RP: from one side it would be fine for me to not see anything new from sharp (as they cant follow normal market needs) but if they will not release new devices then zaurus #@$@#%@^Wusers will migrate to other communities and we will meet them again ;( Dec 05 16:24:12 mickey|devel: sash does not give any sign of life Dec 05 16:25:39 * mickey|devel reading http://www.oesf.org/forums/index.php?showtopic=22239&hl= Dec 05 16:30:30 What do I need to do to have access to Dec 05 16:30:46 glib-gettextize and intltoolize during compilation of a package Dec 05 16:30:49 ? Dec 05 16:31:11 bootstrap.pda calls them. Dec 05 16:31:15 inherit gettext? Dec 05 16:31:35 thanks. I will try that. Dec 05 16:31:54 mickey|devel: its kind of 'we are not dead yet, we just smells like' Dec 05 16:34:59 hehe Dec 05 16:35:29 we can be dead bigger and better Dec 05 16:36:21 I can say that OZ is stalled when it comes to development but it show some progress. pdaX mostly show frustrated users/devs Dec 05 16:37:20 it's all about chances that someone picks up work. OZ is totally transparent, everything is available and open for people to jump on the bandwagon. can't really say that about cacko and pdaX Dec 05 16:37:40 and they lack hardware for testing... let insearchof join our darkside so he would get possibility of getting hardware to test Dec 05 16:38:10 cacko died year ago or more Dec 05 16:38:18 later guys Dec 05 16:38:24 no sign of anything new from them Dec 05 16:38:37 pdax switched to 2.6 and failed Dec 05 16:38:54 I think that it is hard to follow 2.6/zaurus without using OE Dec 05 16:40:31 NOTE: package uclibc-0.9.28-r7: task do_compile: failed Dec 05 16:43:28 good night Dec 05 16:43:34 g'night Genesis Dec 05 16:51:59 have to go - cu Dec 05 17:03:00 Making progress with http://oz.leggewie.org/wip/granule/granule_cvs.bb. Configure is being run, but no Makefile is being created and thus do_install fails: http://rafb.net/paste/results/c6Ca4f46.html Dec 05 17:03:30 I thought ./configure would write out the Makefile? Dec 05 17:04:10 it should Dec 05 17:04:44 do_configure took a while and I did see m4 et al in top. Dec 05 17:05:14 * koen gets some epineferine Dec 05 17:05:23 allergic reaction to crappy buildsystems Dec 05 17:18:26 How do I get into the bitbake shell? Dec 05 17:18:53 bitbake -i Dec 05 17:20:26 pH5: Thanks. Dec 05 17:20:35 re Dec 05 17:49:05 wow, the new cups web interface is sweet Dec 05 17:49:10 * koen adds cups 1.2.7 to OE Dec 05 17:51:20 configure fails for me in the bitbake shell for all bb files: http://rafb.net/paste/results/ro6gLk10.html I have rebuilt quilt-native-0.45 but the problem remains Dec 05 18:01:57 RP, I applied your usb_pxa27x_udc-r0.patch and usb_add_epalloc-r1.patch patches. Now I have my board looking like a mass storage device :-) However, it is running very slow and I'm getting DMA errors. Is there other patches I need? I'm also NOT running a preemptive kernel so I don't know if that could cause problems. Dec 05 18:02:38 Hello Dec 05 18:04:54 Whilst building Dillo, I'm getting that CROSS COMPILE Badness error, and I'm trying to fix the makefile. Dec 05 18:05:18 The problematic part seems to be this: -I/usr/include Dec 05 18:05:35 What would be a sane target? Dec 05 18:05:57 To replace that with Dec 05 18:07:34 03koen 07org.oe.dev * r70f46234... 10/ (1 packages/cups/cups_1.2.7.bb): cups: add 1.2.7, a recipe with less hacks as 1.1.13 Dec 05 18:08:03 B_Lizzard: do you honor CFLAGS, CPPFLAGS, CXXFLAGS? Dec 05 18:08:15 B_Lizzard: if you do/it does just remove it Dec 05 18:08:24 Ah Dec 05 18:08:59 The part I gave you is in the CFLAGS line of the makefile Dec 05 18:09:02 koen: no comments for http://bugs.openembedded.org/show_bug.cgi?id=1631 I guess we should implement your suggestion of ASSUME_PROVIDED of qte for Sharp ROM. Shall I do it? Dec 05 18:09:24 B_Lizzard: OE puts -I dirs in CFLAGS and or CPPFLAGS Dec 05 18:09:32 the makefile should honor them :) Dec 05 18:09:34 Laibsch: ask zecke or mickey|devel Dec 05 18:09:40 So, if the distro gives a sane alternative, can delete them? Dec 05 18:10:11 If OE gives a sane... Dec 05 18:10:29 Ok, I'll take your words in consideration and fix it Dec 05 18:10:38 Thanks zecke Dec 05 18:11:11 zecke: Can you take a look at koen's suggestion from bug 1631 to have ASSUME_PROVIDED of qte for Sharp ROM? Dec 05 18:13:34 for Sharp ROM? I will bite on my tongue now Dec 05 18:15:25 Laibsch: you don't want -fno-visibility-inlines-hidden in your CXXFLAGS for sharp compat (gcc < 4.0) Dec 05 18:20:14 Would adding CXXFLAGS_sharprom-compatible = "" be the way to implement this? Dec 05 18:20:35 No it won't Dec 05 18:21:43 zecke: But I guess the line 'CXXFLAGS += "-fno-visibility-inlines-hidden"' needs to be suppressed for Sharp ROM. How to do that? Dec 05 18:24:29 Laibsch: wait a second Dec 05 18:25:21 Laibsch: in the quest to free space I removed my OE tree :} Dec 05 18:25:48 Laibsch: check who sets this (it is not bitbake.conf) Dec 05 18:26:02 Laibsch: make sure this doesn't work with Sharp Compat Dec 05 18:26:43 zecke: Good choice. You will have lots of free space now ;-) Dec 05 18:27:45 zecke: 'CXXFLAGS += "-fno-visibility-inlines-hidden"' is set in qte-common.inc. But I want to suppress this for Sharp ROM. How? Dec 05 18:34:41 Laibsch: your above line wasn't bad at all Dec 05 18:35:07 Laibsch: or simply uncomment this completely as it makes issues and should be detected by the QtE buildsystem... Dec 05 18:35:15 But the problem is it would kill other CXXFLAGS set so far. Dec 05 18:37:04 Laibsch: ah a uncareful workaround bites your ass :) Dec 05 18:37:22 Laibsch: he should have used oe_filter_out Dec 05 18:37:24 zecke: my ass? Dec 05 18:37:26 OMG! Dec 05 18:37:28 Help! Dec 05 18:38:04 Laibsch: yes, take a close look at the mirror Dec 05 18:38:08 Your ass was bitten! Dec 05 18:39:48 Laibsch: grep for oe_filter and apply this to filter out -fvisibility-inlines-hidden Dec 05 18:41:01 0 hits in conf/ Dec 05 18:41:27 2 hits in uclibc.inc and klibc.inc Dec 05 18:41:39 Did I look in the right place? Dec 05 18:41:46 * Laibsch thinks not. Dec 05 18:42:28 Or maybe yes. Is oe_filter_out that new function to strip stuff from config lines? Dec 05 18:42:55 wow I'm rusty Dec 05 18:43:13 take a look at base.bbclass it defines the functions :) Dec 05 18:43:28 Laibsch: and you give it a string and a token it should remove Dec 05 18:44:06 Laibsch: let us start over again Dec 05 18:44:12 Apart from links, gpe-mini-browser, minimo, firefox and dillo, is there any other web browser available for use in X? Dec 05 18:44:15 :) Dec 05 18:44:25 * Laibsch guesses CFLAGS := "${@oe_filter_out('-fno-visibility-inlines-hidden', '${CXXFLAGS}', d)}" Dec 05 18:44:31 ??? Dec 05 18:44:34 Laibsch: almost :) Dec 05 18:44:54 I buy 2 X, sir! Dec 05 18:45:02 Laibsch: someone added -fno-visibiluty-inlines-hidden because -fivisibility-inlines-hidden fails Dec 05 18:45:17 http://www.openembedded.org/repo/org.openembedded.dev/packages/qte/qte-common_2.3.10.inc Dec 05 18:45:34 Laibsch: this line labeled "# Workaround" Dec 05 18:45:40 * Laibsch guesses CXXFLAGS_sharprom-compatible := "${@oe_filter_out('-fno-visibility-inlines-hidden', '${CXXFLAGS}', d)}" Dec 05 18:45:54 Laibsch: kaelter Dec 05 18:46:05 Really? Dec 05 18:46:09 * Laibsch sad Dec 05 18:46:16 CXXFLAGS := "{@oe_filter_out( Dec 05 18:46:19 looked correct Dec 05 18:46:42 Laibsch: http://rafb.net/paste/results/go6ekl97.html Dec 05 18:46:54 Laibsch: this guy added this flag because of another error Dec 05 18:47:32 Laibsch: he wanted to use oe_filter_out Dec 05 18:48:40 OK, just a second Dec 05 18:48:44 I think I got it. Dec 05 18:49:14 * Laibsch guesses CXXFLAGS := "${@oe_filter_out('-fvisibility-inlines-hidden', '${CXXFLAGS}', d)}" Dec 05 18:49:19 plus or minus the -f Dec 05 18:49:43 give it a try Dec 05 18:49:50 OK, thanks. Dec 05 18:49:55 I'll let you know. Dec 05 18:52:58 mickey|devel: http://www.oesf.org/forums/index.php?showtopic=22239&view=getlastpost Dec 05 18:53:05 who is the author of oebug? Wouldn't it be nice to have it automatically react whenever somebody says something of the form "bug NNN"? Dec 05 18:53:17 Laibsch: CoreDump|home Dec 05 18:53:40 koen: OK. And what do you think about this idea? Dec 05 18:55:09 hi zecke, mreimer Dec 05 18:55:21 pb_: master, how are you? Dec 05 18:55:32 hey pb_! What are you up to these days? Dec 05 18:57:05 morning all Dec 05 18:57:17 koen: crap mac mini still awaits core duo 2 update Dec 05 18:57:41 Laibsch: what idea? Dec 05 18:57:51 zecke: very well, thanks. how are you? Dec 05 18:58:27 koen: To have oebug not only react to !oebug but also to "bug NNNN" inside normal chat lines. Dec 05 18:58:28 pb_: emotionally I'm a wreck but otherwise I'm fine :) Dec 05 18:58:50 Laibsch: could be a nice idea Dec 05 18:59:04 OK Dec 05 18:59:21 CoreDump|home: What do you think about it? Feasible? Good idea? Dec 05 19:01:06 zecke: heh. oh dear, that doesn't sound too good. Dec 05 19:01:16 pb_: how is receiva going? Dec 05 19:01:40 pb_: hehe, I'm just a crybaby Dec 05 19:01:50 pretty good. we have more customers these days, and you can buy our products in several of the big electrical store chains here in the uk. Dec 05 19:02:12 that is good Dec 05 19:02:16 congratulation Dec 05 19:07:59 thanks Dec 05 19:11:43 hi pb_ Dec 05 19:11:52 hi chouimat Dec 05 19:17:37 psokolovsky: ping Dec 05 19:18:55 zecke: Your advice helped me to fix all the packages with Compile Badness errors Dec 05 19:18:58 THANKS A LOT Dec 05 19:19:11 /hugs zecke Dec 05 19:19:13 ok.. it's getting serious again :> programming flash Dec 05 19:19:31 last time it ended in a desaster :) Dec 05 19:20:31 B_Lizzard: ah, so I can scream next time and we are equal :} Dec 05 19:20:41 ;) Dec 05 19:23:33 http://www.heise.de/newsticker/meldung/82083 Dec 05 19:25:04 ~botmail read Dec 05 19:27:24 oen: I saw that you removed detect stylus from htcuniversal in tslib. That's ok, but udev doesnt create a touchscreen0 for our device. The touchscreen is /dev/input/event0 on the htcuniversal. Dec 05 19:27:27 oen Dec 05 19:28:19 ~botmail check Dec 05 19:28:37 i'll write a bug. Dec 05 19:29:13 goxboxlive: you local.rules have SUBSYSTEM=="input", KERNEL=="event[0-9]*", SYSFS{modalias}=="input:*-e0,1*,3,*a0,1,*18,*", SYMLINK+="input/touchscreen0" Dec 05 19:30:20 ok, i'll take a look at it Dec 05 19:31:42 mreimer, pong Dec 05 19:32:10 psokolovsky: FYI, I'm still having resume problems. It resumes fine until I load w100fb. Dec 05 19:32:28 psokolovsky: also found some more pt_regs that need to be remove, as in pxa2xx_pcmcia Dec 05 19:32:52 mreimer, weird. I tested that after fixing pax27x_udc, resume works reliably - on bare kernel with initrd I gave link to. Dec 05 19:33:07 psokolovsky: yeah, it's weird Dec 05 19:33:08 mreimer, yeah, there're still lots to remove Dec 05 19:33:27 psokolovsky: maybe it's the problem pH5 was seeing: corruption that shows up other places Dec 05 19:34:14 mreimer, corruption due to non-platform_driver'ness? Dec 05 19:34:25 psokolovsky: something like that Dec 05 19:36:43 phuu.. finally.. got the kernel into flash :) enough for today, 'night Dec 05 19:37:24 I have a long question to make, so please, bear with me Dec 05 19:38:04 Has anyone encountered a problem with the cursor under tslib jumping around? Dec 05 19:38:32 Has anyone experienced severe cursor jitter under tslib? Dec 05 19:38:39 mreimer, well, then we need to keep reviewing the code Dec 05 19:38:50 psokolovsky: yep. I'm working on it Dec 05 19:38:56 nice! Dec 05 19:39:03 Searching on the net tells me that it's some kind of tslib bug Dec 05 19:39:21 http://www.google.com/trends?q=open+embedded&ctab=0&geo=all&date=all Dec 05 19:39:42 And that I have to link tslib to kdrive in order for the touchscreen to work better under X Dec 05 19:39:55 RP: online? have a q regarding w100fb driver. Dec 05 19:42:02 psokolovsky: yes Dec 05 19:46:01 RP: could you look at these changes: http://handhelds.org/cgi-bin/cvsweb.cgi/linux/kernel26/drivers/video/w100fb.c.diff?r1=1.25&r2=1.26&f=h Dec 05 19:46:22 RP: and say, is they required, or at least helpful, or acceptable for mainline at all Dec 05 19:47:35 Is it possible to compile a kernel using the full glibc that fits into 16M of flash? Dec 05 19:48:07 root: the kernel doesn't use glibc Dec 05 19:48:14 hey koen Dec 05 19:48:20 hey mreimer Dec 05 19:48:51 koen|away: I hope those pango patches close the 2.6 vs 2.8/10 perf gap. Have you benchmarked them yet? Dec 05 19:50:39 mreimer: I haven't benchmarked them yet Dec 05 19:50:58 koen: I think they'll probably help my major perf problem (GtkTextView) a lot Dec 05 19:51:34 So that's my current confusion as I try to get up to speed with embedded -> zImage vs. uImage. Dec 05 19:51:57 psokolovsky: interesting: just loading w100fb without loading hx4700-lcd makes resume not work. The probe routine isn't even called. Dec 05 19:52:09 Is it bootloader-related? Or am I missing it completely... Dec 05 19:52:20 psokolovsky: sorry, geting distracted - will look in 10 mins Dec 05 19:52:27 RP: thanks Dec 05 19:52:31 Laibsch: did it work? Dec 05 19:52:35 mreimer: gtkscrolledwindow probably needs more love Dec 05 19:52:58 mreimer, well, it's strange. you don't have anything on screen w/o w100fb, right? ;-) Dec 05 19:53:42 koen: I wonder if the imgblit patch for w100fb would help? Dec 05 19:54:04 psokolovsky: right. I'm just trying to narrow down what is causing the resume failure Dec 05 19:54:05 mreimer: xw100 and kernel w100 don't play well together iirc Dec 05 19:54:33 koen: good to know. I'm not presently starting Xw100 as I hunt down this resume bug Dec 05 19:56:03 psokolovsky: Why were they added - did something change in the driver model that needed that? Dec 05 19:58:21 RP: we have some argument between hh.org developers here, and would like to know your opinion. my analysis is that the changes are sematically equivalent to what it was before (in mainline) (modulo typo bugs ;-) ) Dec 05 20:00:36 RP: have you seen the imgblit w100fb patch? Dec 05 20:01:52 psokolovsky: Yes, that would be my view as well - it seemingly amounts to the same thing Dec 05 20:02:21 mreimer: The s/memcpy_fromio/memcpy/ one? Dec 05 20:02:28 RP: ok, thanks! Dec 05 20:02:58 RP: no, an accelerated imgblit, so cfgimgblit isn't used. http://downloads.sourceforge.net/libw100/w100-extaccel.patch?modtime=1162683759&big_mirror=0 Dec 05 20:06:46 bbiab Dec 05 20:06:48 mreimer: Ah, yes, I know the patch. Its just a question of finding time to check it out Dec 05 20:18:03 hi all Dec 05 20:18:38 koen: I have seen the botmail! that's very cool :) Dec 05 20:24:03 nicolasfr: untar /tmp/sharprom.tar into your website and edit include/config.inc to fix the path to the database Dec 05 20:25:32 koen: That's fantastic! php is not enabled on regular linuxtogo accounts, I have to bug florian for that Dec 05 20:25:45 I can do that as well :) Dec 05 20:26:11 hehe Dec 05 20:28:57 ah, hmm Dec 05 20:29:14 * koen stabs gforge Dec 05 20:29:53 # WARNING - turning on php will allow any user Dec 05 20:29:53 # to upload a php file to your server, and include Dec 05 20:29:53 # the gforge local.inc file and get your password to Dec 05 20:29:53 # connect to the database and have total control. Dec 05 20:30:03 which idiot designed gforge? Dec 05 20:31:03 koen, lol ;-) I wonder, if that hinted only that php had, have, and will have known security holes ;-) Dec 05 20:31:03 lol Dec 05 20:32:11 psokolovsky_: gforge uses the php equivalent of #defice PASSWORD foobar in a public .h file Dec 05 20:32:38 in other news, the uni approved hosting for the source mirror Dec 05 20:36:51 koen: this gforge notice is stupid. I run a shared hosting web server and hopefully users can't include files from other users dirs :) Dec 05 20:37:31 wooooo Dec 05 20:37:36 my efika is in paris now Dec 05 20:38:23 koen: running php in safe mode is a first thing to do so php scripts are runned with file owner privilege, not webserver privileges. Dec 05 20:39:01 koen: do you want me to grab your efika :) Dec 05 20:39:08 :) Dec 05 20:39:36 zecke: tinderbox failed for qemuarm again - its pulling in /usr/lib for some kind of xml stuff in gcc :-( Dec 05 20:40:44 RP: so I will need to add sending of config.log? Dec 05 20:41:03 does anyone know what OE packages need to be installed to get the "fixed" font to be fount by xserver-xorg? I'm currently getting the following when I try to start X: could not open default font 'fixed' Dec 05 20:41:25 zecke: I don't know if that will help or not with gcc... Dec 05 20:42:12 gcj :) Dec 05 20:42:30 I think I can waste some time on it tomorrow Dec 05 20:42:59 I wondered about disabling java but thats a bit like cheating... Dec 05 20:43:10 he zecke Dec 05 20:43:21 woglinde: hey, how are you? Dec 05 20:43:34 woglinde: my mouse driver sucks badly Dec 05 20:44:03 woglinde: I can barely find information on the 9-bit 2 clompement numbers... Dec 05 20:44:14 hi woglinde Dec 05 20:44:46 hi pb Dec 05 20:48:31 * cbrake copies fonts/misc from desktop to target system and now X works. Hmm, how to generate fonts in misc directory ... Dec 05 20:53:00 zecke: do you have gerwinin's email address? Dec 05 20:54:40 koen: I don't think I have his current one Dec 05 20:54:56 zecke: in that case we share the same problem Dec 05 20:55:19 is that the one you have? Dec 05 20:55:31 yes Dec 05 20:55:49 was he at t-dose? Dec 05 20:56:14 he was Dec 05 20:56:24 I'll wait for his phonecall Dec 05 20:56:45 I think we'll have a dedicated 1U OE server next week :) Dec 05 20:57:14 how does he look like? Dec 05 20:58:09 he wears a bright green shirt labeled "T-DOSE" Dec 05 20:58:19 zecke: btw, logfs rocks Dec 05 20:58:37 hehe, why? Dec 05 20:58:53 i thought jffs2 was log based? :} Dec 05 20:59:15 logfs stores its tree on 'disk', so it uses less ram Dec 05 20:59:27 does logfs work with flash? Dec 05 20:59:28 in the ROM? Dec 05 20:59:39 :) Dec 05 20:59:55 ~fishslap zecke Dec 05 20:59:57 * ibot slaps zecke up side the head with a wet fish. Dec 05 21:00:24 logfs? url? Dec 05 21:01:00 chouimat|away: http://wh.fh-wedel.de/~joern/logfs.pdf Dec 05 21:01:36 jffs2 will break if we get >4G flash devices Dec 05 21:01:58 chouimat|away: http://lkml.org/lkml/2006/8/24/176 Dec 05 21:02:54 koen thanks ...btw ever looked at this www.nilfs.org ? Dec 05 21:03:39 * koen reads Dec 05 21:06:43 hi Dec 05 21:06:43 bbl need a few beer ... today was boring like never before Dec 05 21:08:45 "Continuing with the long tradition of calling the filesystem exactly what it is not, LogFS is a journaled filesystem, while JFFS and JFFS2 were true log-structured filesystems." *g* Dec 05 21:08:50 zecke: I'm not sure my libtool foo is up to this. There are references to "-rpath /usr/lib" all over a "normal" set of compile/install logs. I think its just luck it happens to work atm :-/ Dec 05 21:09:56 tmbinc: during Jörns presentation "On ffs, fast file system, writes are slow, they may have been fast in the past, but they are not anymore" Dec 05 21:09:58 RP: -rpath is okay Dec 05 21:10:07 RP: -rpath-link,/usr/lib would worry me Dec 05 21:10:21 RP: we need -rpath /usr/lib for all these -dev packages :) Dec 05 21:13:45 zecke: right, yes, I'm getting confused. There is some problem triggered on the tinderbox machine that results in -L/usr/lib and that isn't in my local builds Dec 05 21:16:00 koen: I kinda like poofs... poof & your data is gone :) Dec 05 21:16:19 no poofters! Dec 05 21:43:34 Hi all! Dec 05 21:44:56 If I want to use bitbake, do I need configure? I wrote an small opie-application which I want to bitbake for my iPAQ. Dec 05 21:46:44 'build gpe-image' for angstrom keeps failing at pcmciautils. Any suggestions? Dec 05 21:46:46 autoconf is always the sanest way to go Dec 05 21:46:56 you go through instanity to get to sanity Dec 05 21:47:05 Floh: that depends. You are not required to use OE to build your application Dec 05 21:47:22 Floh: there is a README.OE in the opie directory Dec 05 21:47:25 floh yeah check the autotools doku it isnt to hard Dec 05 21:47:26 As I though that autoconfig may the way. Dec 05 21:47:42 And the .bb file is written by hand, am I right? Dec 05 21:47:54 Floh: for opie stuff use qmake it the easiest way to get it compile Dec 05 21:48:11 Floh: yes these are written and tested by hand and the learning curve is still steep Dec 05 21:48:17 I'm familiar with qmake. :) Dec 05 21:48:33 I did already compile my apps on my notebook (for test purpose). Dec 05 21:48:35 Floh: if you have not cross compiled by hand before, do it once by hand Dec 05 21:49:19 I don't know if familiar offers pre built toolchains so you might need OE to build one Dec 05 21:50:51 good nite Dec 05 21:52:56 Sorry, my notebook crashed. Dec 05 21:53:12 uh Dec 05 21:53:17 So far I know/understand: Dec 05 21:53:40 yeah make it first with qmake Dec 05 21:53:49 than write a .bb file Dec 05 21:53:53 and file bugs Dec 05 21:53:53 Makefile are created by qmake (it's no problem), .bb file should be written by hand and configure by autoconf. Dec 05 21:54:00 with the patches Dec 05 21:54:18 if you want it in oe Dec 05 21:54:30 No, I only want to bitbake. Dec 05 21:54:42 Because I have installed oe. Dec 05 21:54:51 and bitbaked the whole thing. Dec 05 21:55:34 Now I only want to compile my application and install it directly on ipaq. Dec 05 21:55:43 It's for my diploma thesis. Dec 05 21:57:39 Ok: 1. qmake 2. write bb-file. Dec 05 21:58:01 And 3. autoconf? or should I use autoconf before writing bb-file? Dec 05 21:58:16 doen Dec 05 21:58:20 snt matter Dec 05 21:58:28 Ok. Dec 05 21:58:31 you can later iherit autotools Dec 05 21:58:31 Thank you. Dec 05 21:58:35 inherit Dec 05 21:58:44 Good to know. Dec 05 21:58:48 that will call all the autotoolmagic Dec 05 21:58:51 I'll try that later. :) Dec 05 21:58:55 and produce a configure Dec 05 21:58:57 bye Dec 05 21:59:24 Thanx! Goodbye woglinde! Dec 05 22:02:10 Ah... last thing... Dec 05 22:02:53 never mind. :) Dec 05 22:02:53 cu Dec 05 22:02:54 re koen Dec 05 22:03:10 freidrich engels? Dec 05 22:03:14 he is dead Dec 05 22:03:17 long time dead Dec 05 22:03:31 hey mickeyl Dec 05 22:05:23 hiho Dec 05 22:09:16 mreimer, mickeyl: http://mail.gnome.org/archives/performance-list/2006-December/msg00006.html Dec 05 22:09:45 that's not BAD Dec 05 22:09:47 koen: I was just reading that! looks like we might be back on par with 2.6. But I'm confused by the times Dec 05 22:09:49 pretty close to 2.6 Dec 05 22:10:04 must be the granularity of the clock? Dec 05 22:12:02 * mickeyl really glad that the issue finally got voices and movement Dec 05 22:12:05 ping nicolasfr Dec 05 22:12:17 hi Laibsch Dec 05 22:13:01 Hey Dec 05 22:13:11 Did you write anything yet about Sharp ROM? Dec 05 22:13:23 re Dec 05 22:13:32 root@h2200:/data# ./timetext Dec 05 22:13:32 Drawn label 2221 times. Average time spent drawing (in seconds): 0.001166 Dec 05 22:14:04 gtk 2.10.6-xft + cairo 1.3.4 + pango 1.15.1 Dec 05 22:14:13 coolness Dec 05 22:14:23 koen: right on! Dec 05 22:14:29 Laibsch: nope, ... not much time during the week. I hope to do that on the week end Dec 05 22:14:46 OK, let me know and I will take a look. Dec 05 22:14:54 mreimer: timetext has compiling instructions now, so more people can test it now :) Dec 05 22:15:12 koen: should I take that as a hint? :-) Dec 05 22:15:23 :) Dec 05 22:16:31 koen: I'm hoping to work on video performance, getting the new w100 mplayer driver working on hx4700 (if I get hx4700 on .19 to suspend/resume) Dec 05 22:17:14 mreimer: try catching sirfred when he's in here Dec 05 22:17:26 koen: is he the libw100 guy? Dec 05 22:17:33 yes Dec 05 22:17:37 ~seen sirfred Dec 05 22:17:39 koen: thanks, I will Dec 05 22:17:58 sirfred was last seen on IRC in channel #oe, 11d 5h 43m 57s ago, saying: '56Mb of source code'. Dec 05 22:24:39 for people with armv5 EABI: http://www.openembedded.org/~koen/timetext Dec 05 22:26:56 XorA|gone: "One of the examples is the new armv5te optimized idct in MPlayer 1.0rc1, can anybody benchmark it?" Dec 05 22:27:53 koen: That looks like a promising performance figure :) Dec 05 22:28:48 RP: it just proves that a 400MHz xscale running OE built stuff is faster as a n770 running unknown stuff Dec 05 22:33:10 koen: I think those tests are on a c7x0 ;-) Dec 05 22:35:15 RP: I think your hx2750 will go upto 3k draws Dec 05 22:35:24 anyway Dec 05 22:35:27 * koen zzzz Dec 05 22:38:18 03koen 07org.oe.dev * r60c4b1f7... 10/ (1 packages/cairo/cairo_git.bb): cairo git: cairo is at 1.3.5 now Dec 05 23:09:05 !help Dec 05 23:19:50 Anybody has an idea about PM_SYSFS_DEPRECATED crap in 2.6.19? Should this be defined for current OE? Dec 05 23:22:42 psokolovsky: what startup.txt do you use for booting your hx4700 with initrd? Dec 05 23:22:54 psokolovsky: I've removed more drivers and am still having suspend/resume problems Dec 05 23:23:33 mreimer, sample startup is provided in the same dir, http://celib.sourceforge.net/linux-ppc/ (watch mtype) Dec 05 23:23:52 pfw's are also h4000-specific ;-) Dec 05 23:23:56 thanks Paul Dec 05 23:28:00 psokolovsky: RAMDISK: Couldn't find valid RAM disk image starting at 0. \n No filesystem could mount root, tried: ext2 msdos vfat \n Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) Dec 05 23:28:12 psokolovsky: do you have a suggestion? I haven't used initrd for so long Dec 05 23:29:28 mreimer, you have all needed config options in kernel? Dec 05 23:29:39 psokolovsky: it's your hx4700_static_defconfig Dec 05 23:29:47 mreimer, also, do you use fresh enough haret? Dec 05 23:30:04 psokolovsky: mine is probably 0.3.6 Dec 05 23:30:08 I'll try a newer one Dec 05 23:30:29 mreimer, that's too old to boot that kernel with initrd. Dec 05 23:31:15 mreimer, please try 0.3.8. caveat: with it, udc won't work ;-\. and damn, we don't have newer release still, though should have... Dec 05 23:31:18 no time ;-( Dec 05 23:31:40 mreimer, anyway, trying 0.3.8 is the quickest thing Dec 05 23:31:52 psokolovsky: ok, thanks. I have a serial cable, so I'll be ok Dec 05 23:32:00 ok Dec 05 23:34:30 psokolovsky: that fixed it Dec 05 23:34:40 mreimer, nice ;-) Dec 05 23:34:49 mreimer, so, it booted? Dec 05 23:35:00 psokolovsky: yes, but it didn't resume Dec 05 23:35:09 psokolovsky: is there a way to replace welcome.exe with haret.exe? Dec 05 23:35:11 damn! Dec 05 23:35:25 mreimer, probably, but noone knows of it ;-) Dec 05 23:35:30 :-) Dec 05 23:36:20 mreimer, more exactly, one way to get around calib. screen all the time is to use synce to request haret.exe startup over usb, using RAPI protocol Dec 05 23:36:38 mreimer, I have setting up that in my todo for long time ;-) Dec 05 23:37:09 that's a good idea Dec 05 23:53:36 psokolovsky: what version of gcc are you using? Dec 05 23:54:15 mreimer, 3.4.1 from ftp.hh.org Dec 05 23:54:26 psokolovsky: same here Dec 05 23:54:41 mreimer, so, doesn't resume? Dec 05 23:54:50 psokolovsky: no Dec 05 23:55:27 mreimer, how do you suspend it? Dec 05 23:55:47 echo mem > /sys/power/state Dec 05 23:56:26 weird. let me try yesterday's kernel Dec 05 23:57:01 Hi all. Dec 05 23:57:34 I think, I need a bit help for make my source bitbake-ready. Dec 05 23:58:06 If I want to create configures, I should use autoscan. Dec 05 23:58:54 I mean before I want to use autoconf I should use autoscan. Unfortunatelly it complains, there is no configure.ac. Dec 05 23:59:32 mreimer, still resumes here. wanna me putting the exact version of kernel/haret which works for me on d/l? Dec 06 00:00:14 psokolovsky: yes please. I'll put up my kernel for you to try Dec 06 00:00:21 mreimer, ok Dec 06 00:06:21 mreimer, http://handhelds.org/~pfalcon/ports/hx4700-2.6.19-hh3/ Dec 06 00:06:26 thanks Paul Dec 06 00:07:13 mreimer, complete setup, just in case. startup.txt has some long lines, haret throws errors on startup, just click thru them (watch for background msgboxes! ;-)) Dec 06 00:07:18 ok Dec 06 00:09:41 psokolovsky: http://frodo.vpop.net/~mreimer/zImage-hx4700 Dec 06 00:11:10 psokolovsky: http://frodo.vpop.net/~mreimer/hx4700-diffs Dec 06 00:11:24 mreimer, thanks, trying now Dec 06 00:12:20 I must be doing something really obvious and stupid Dec 06 00:12:30 mreimer, note that in the end, I didn't defined PXA_SUSPEND_SAVE_EXTRA_REGS. hx4700 was always known to work w/o it. (how good is another q...) Dec 06 00:12:43 psokolovsky: I've tried it both ways Dec 06 00:14:19 psokolovsky: your kernel resumed Dec 06 00:14:50 mreimer, yours - no ;-) Dec 06 00:15:08 so at least we know it's not a hardware issue Dec 06 00:15:24 psokolovsky: do you have any significant uncommitted diffs? Dec 06 00:15:46 psokolovsky: is the config you used to build that kernel identical with hx4700_static_defconfig? Dec 06 00:15:55 mreimer, significant - no. but I missed to commit Makefile before tagging -hh3 ;-) Dec 06 00:16:09 oops :-) Dec 06 00:16:10 03rpurdie 07org.oe.dev * rf55d909c... 10/ (1 classes/patch.bbclass): patch.bbclass: Fix errors when reapplying patches Dec 06 00:16:11 mreimer, yes, I used hx4700_static_defconfig Dec 06 00:16:14 03rpurdie 07org.oe.dev * rc4d28a6e... 10/ (10 files in 4 dirs): linux-rp: Fix tosa 2.6.17/18 patches (thanks for hints from CyrilRomain) Dec 06 00:16:18 grr Dec 06 00:16:39 mreimer, would you want me to try current HEAD now? Dec 06 00:16:53 (I'll need to move -hh3 tag anyway to make it correct) Dec 06 00:16:54 psokolovsky: if you wouldn't mind, please Dec 06 00:16:59 ok! Dec 06 00:36:34 good night Dec 06 00:37:14 good night ! Dec 06 00:39:30 RP: If I have "fixes 1234" in my commit message is the bug 1234 automatically closed? Dec 06 00:39:47 Laibsch: no, its just good form to reference the bug Dec 06 00:39:57 I see. Dec 06 00:48:06 psokolovsky: when I comment out this line from drivers/mtd/maps/Makefile, it won't resume: #obj-$(CONFIG_MACH_H4700) += hx4700-flash.o Dec 06 00:48:43 mreimer, *comment out*? Dec 06 00:48:53 psokolovsky: yes. strange, huh? Dec 06 00:49:03 psokolovsky: otherwise, it resumes Dec 06 00:49:40 mreimer, sorry, I still build zImage (got both OE and manual build run on the same tree, breaking each other %) ) Dec 06 00:49:52 psokolovsky: :-) Dec 06 00:49:52 mreimer, yes. very strange. Dec 06 00:50:07 mreimer, but at least culprit is found... Dec 06 00:50:35 psokolovsky: maybe. not loading w100fb was another "culprit" before Dec 06 00:51:09 psokolovsky: btw, I think the reason I was using PXA_SUSPEND_SAVE_EXTRA_REGS was to get hx4700 to resume at full speed. I'll see if that's needed when cpufreq is compiled in Dec 06 00:51:46 mreimer, very, very weird. mainline folks just crazy (as always) to have done switchover it that way ;-\ Dec 06 00:51:56 ok Dec 06 00:55:21 mreimer, anyway, I can confirm that HEAD with hx4700_static_defconfig as is resumes with bare kernel. Will retag that as -hh3 (changes since yesterday were minimal, affecting only HTC ports) Dec 06 00:55:54 psokolovsky: can you try commenting out hx4700-flash in drivers/mtd/maps/Makefile? Dec 06 00:56:09 mreimer, will do in a min Dec 06 00:56:43 03rpurdie 07org.oe.dev * r66047859... 10/ (37 files in 7 dirs): linux-rp: Add w100 acceleration patch from sirfred. Add pcmcia card ID from pdaXrom user. Add 2.6.19 version Dec 06 01:02:15 psokolovsky: it will resume if I comment out that line *and* don't add the platform_device hx4700-flash in hx4700.c Dec 06 01:03:28 mreimer, i.e. with hx4700-flash device in hx4700.c it doesn't resume either? Dec 06 01:04:10 psokolovsky: if the hx4700-flash platform_device is added in hx4700.c but hx4700-flash.o isn't compiled, it fails. Otherwise, it succeeds. ??? Dec 06 01:04:37 mreimer, what means "fails"? Dec 06 01:04:44 psokolovsky: it won't resume Dec 06 01:04:55 ok, testing that case now Dec 06 01:05:56 I think there must be some other bug lurking somewhere that this combination provokes Dec 06 01:07:13 ok, dev in, driver out: Dec 06 01:07:15 doesn't resume, confirmed! Dec 06 01:07:53 bizarre Dec 06 01:09:18 psokolovsky: time for me to go. thanks for your help today Dec 06 01:09:43 mreimer, ok. good night! Dec 06 01:09:52 good night Paul Dec 06 01:11:19 03Laibsch 07org.oe.dev * reedaf239... 10/ (1 packages/qte/qte-common_2.3.10.inc): gpe-common: strip visibility-inlines-hidden instead of negating it. Fixes bug 1631 and possibly 1521. zecke-approved ;-) **** ENDING LOGGING AT Wed Dec 06 02:59:57 2006