**** BEGIN LOGGING AT Sat Sep 08 02:59:57 2007 **** BEGIN LOGGING AT Sat Sep 08 03:22:13 2007 Sep 08 03:56:49 hey Sep 08 03:57:31 I'm going to fall over now Sep 08 06:25:30 morning Sep 08 06:49:13 Zero_Chaos: the preferred place for patches is the bugtracker Sep 08 06:52:54 i'm having problem with the latest (pulled about 12hours ago) openmoko-image on an a780, after mounting the rootfs and freeing kernel mem. nothing else happens any more on the phone, isn't there supposed to come some X-apps up? Sep 08 07:23:47 Wiki markup on the OE website fixed Sep 08 07:23:56 that only leaves the reversed news to deal with Sep 08 07:40:37 libx11-native is version 1.0.1, yet it downloads version 1.1.1 Sep 08 07:40:52 Either rename it to 1.1.1, or make it download 1.0.1 Sep 08 07:42:42 Strangely, libx11-native depends on a package named xcb-xlib which I could never find... Sep 08 07:43:41 ...version 1.1.1, of course Sep 08 07:49:48 Version 1.0.1 fails due to a floating point exception with makekeys, and the only way to fix it is to replace makekeys.c from 1.0.3, or backport the changes. Sep 08 07:50:17 koen: do i have to flash my phone in order to start OM succesfully on there, or is boot-usb supposed to work? Sep 08 07:50:45 afaik it needs to be flashed, but you'd better ask on #openezx Sep 08 08:58:25 koen, are you able to build gcc-cross-4.2.1-r3 with uclibc? Sep 08 08:58:59 ynezz: nope :( Sep 08 08:59:18 I suspect we need to patch uclibc 0.9.29 a bit more Sep 08 09:00:17 is somebody already working on it? Sep 08 09:01:24 koen: It comes out that fontconfig-native 2.3.91 builds when built against freetype 2.1.10 (as opposed to 2.3.5). Sep 08 09:01:24 or should I try to fix it? Sep 08 09:02:06 Maybe fontconfig-native should be updated to 2.4.1 (which is the latest version of fontconfig on OE). Sep 08 09:02:34 I think hrw said something... Sep 08 10:10:41 openmoko-devel-image is not building: error: no free space on volume? I have around 300gb Sep 08 10:10:49 on the build volume Sep 08 10:11:00 what might be the problem here? Sep 08 10:21:44 03pfalcon 07org.oe.dev * ra724d999... 10/ (1 packages/linux/linux-handhelds-2.6_2.6.21-hh15.bb): linux-handhelds-2.6: Add 2.6.21-hh15. Sep 08 10:21:59 03pfalcon 07org.oe.dev * r6e4ac932... 10/ (1 packages/xorg-xserver/xserver-kdrive-common.inc): xserver-kdrive: Put back w100 support, screwed up by megacommit from Poky. Sep 08 10:22:06 03pH5 07org.oe.dev * ra2a37015... 10/ (5 files in 3 dirs): Sep 08 10:22:06 xserver-kdrive-w100: split configure.ac and Makefile.am out of w100 patch Sep 08 10:22:06 * those two have to be adapted for 1.4/git and I don't want to Sep 08 10:22:06 duplicate the whole w100 patch. Sep 08 10:33:51 maybe somebody could have a look at this paste? It is just saying no space left.. http://www.pastebin.ca/686976 Sep 08 10:37:53 dcordes: "genext2fs: couldn't allocate a block (no free space)" Sep 08 10:38:05 that means that genext2fs can't fit it all into 64mb Sep 08 10:42:10 koen: how can I fix it? Sep 08 10:42:16 moin Sep 08 10:42:19 moin Sep 08 10:42:37 increase the image size Sep 08 10:42:56 where is that set? Sep 08 10:43:06 zecke: it still looks like I'm going to stay at your place at OEDEM, unless I find a sponsor Sep 08 10:45:09 koen: that is fine Sep 08 10:50:46 thanks Sep 08 10:52:01 koen: am I looking for ROOT_FLAS_SIZE = "58" in akita.conf? Sep 08 10:52:21 s/ROOT_FLAS_SIZE/ROOT_FLASH_SIZE Sep 08 10:52:41 koen: just bring me a bottle/package of vla Sep 08 10:53:09 hmm, anybody got some knowledge about this commit: Sep 08 10:53:10 http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=blobdiff;h=aa57e87bbc44689eca071924e45a57af499dcab3;hp=c4caff92215f2f9ef99ca2c59dbd5d7391a7af9d;hb=02d09105113fb9b560a770fe15f7bb041165831c;f=hw/kdrive/linux/tslib.c Sep 08 10:54:01 pH5: I can explain the licensing foobar :) Sep 08 10:54:05 ? I need to get the struct TslibPrivate pointer into Xext/xcalibrate.c, because the global tslib_raw_event_closure and tslib_raw_event_hook pointers are no more Sep 08 10:54:27 zecke: great ;) Sep 08 10:54:56 pH5: try poking daniels on #xorg or something Sep 08 10:55:00 ~seen daniels Sep 08 10:55:02 daniels <~daniels@amnesiac.heapspace.net> was last seen on IRC in channel #freedesktop, 933d 10h 3m 3s ago, saying: ' 89792 total'. Sep 08 10:55:28 oh that is many d Sep 08 10:55:30 is #xorg gimpnet or oftc or something like that? Sep 08 10:56:00 #xorg-devel on freenode AFAIK Sep 08 10:56:24 koen: thanks Sep 08 11:00:31 03pfalcon 07org.oe.dev * r5de580ab... 10/ (1 packages/xorg-xserver/xserver-kdrive_1.3.0.0.bb): xserver-kdrive 1.3.0.0: Bump PR for w100 fix. Sep 08 11:00:38 03pH5 07org.oe.dev * r8c52f70c... 10/ (2 files in 2 dirs): Sep 08 11:00:38 xserver-kdrive-1.3.0.0: drop version specific hide-cursor-and-ppm-root.patch Sep 08 11:00:38 * it's identical to the one in xserver-kdrive/ Sep 08 11:04:03 heh Sep 08 11:04:12 800 days ago I wrote OE from scratch Sep 08 11:08:05 hehe Sep 08 11:08:25 time to rewrite it with git :) Sep 08 11:12:31 Philippe: ping Sep 08 11:42:07 Is there any solution to the git fetch for u-boot failing atm? Sep 08 12:09:55 yes Sep 08 12:09:59 don't build uboot Sep 08 12:10:13 90% of the people isn't going to reflash their bootloader Sep 08 12:16:34 zecke: paper is so last century ;) Sep 08 12:31:19 koen, maybe we should make the kernel recipes depend on u-boot tools, which builds from a tarball Sep 08 12:31:32 then we can drop the machine dependencies Sep 08 12:32:04 since for davinci, we need u-boot for mkimage, and the only available u-boot support is in git Sep 08 12:37:38 Crofton : To get only mkimage you can use uboot-native Sep 08 13:22:19 steliosk: do you have any probs building a kernel with the binutils-2.18-r0? Sep 08 13:22:31 my generated zImage.bin is a sparse file with 3.2 GB ! Sep 08 13:22:55 indeed I can not "flash" an 3 GiB kernel onto the hardware ;) Sep 08 13:30:40 Cyberdeck : haven't tried with 2.18 yet Sep 08 13:33:55 Cyberdeck : we are working to get ACE files generated from OE Sep 08 13:39:07 steliosk: well ok. thank you! Sep 08 13:40:05 steliosk: i now recompile the whole stuff with gcc-4.2.1 maybe i'll then give me some valid kernel... Sep 08 13:51:34 good morning Sep 08 13:55:32 hey mickeyl Sep 08 13:55:36 hey sakoman Sep 08 13:56:00 good morning koen Sep 08 13:56:04 hi boys and girls Sep 08 13:58:10 * koen looks at the kernel panic on his a780 Sep 08 13:58:49 koen: finally solved the modules.dep issue on gumstix! Sep 08 13:59:18 sakoman: what was the solution? Sep 08 14:01:11 module-init-tools-cross Sep 08 14:03:34 easy to discover once you find a clue amidst all the noise: http://www.sakoman.net/oe/modules.dep.issue.txt Sep 08 14:06:11 explains why it was intermittent! Sep 08 14:06:56 depending on what I might have built previously and whether it built module-init-tools-cross Sep 08 14:12:13 * zecke is almost done reading the paper about GCC and detecting pipeline hazards for the instruction scheduler Sep 08 14:22:06 is webkit-gtk-0.0+svnr25435-r25432 something that is taking usually long to build? Sep 08 14:22:33 yes Sep 08 14:32:03 it's building now for one hours or so Sep 08 14:40:09 Cyberdeck : what error do you get when the xilinx kernel fails ? Sep 08 14:40:25 koen|away: I raised the root flash size in my machien conf but still get the no space left error (paste above) Sep 08 14:40:58 Greetings all. Sep 08 14:53:09 could somebody scroll up and give me the link to the paste I pasted? Sep 08 14:53:54 or even better have a glance at it and tell me how to fix Sep 08 14:57:24 03koen 07org.oe.dev * r1fd077a9... 10/ (1 packages/linux/linux-ezx_2.6.21.bb): Sep 08 14:57:24 linux-ezx: remove 'noinitrd' to fix booting from tf Sep 08 14:57:24 * also tweaked nfs params to be more inline with OE defaults for usbnet Sep 08 15:05:59 dcordes: this one? http://www.pastebin.ca/686976 Sep 08 15:06:38 Crofton: ping! Sep 08 15:11:23 sakoman: yes thanks Sep 08 15:11:47 how can I make it build without maximum image size? Sep 08 15:13:34 :( Sep 08 15:55:24 "bitbake openmoko-devel-image" is failing on gettext-native for me while trying to link msgcmp: Sep 08 15:55:39 | msgcmp-msgcmp.o: In function `usage': Sep 08 15:55:39 | msgcmp.c:(.text+0x28): undefined reference to `program_name' Sep 08 15:55:39 | msgcmp-msgcmp.o: In function `match_domain': Sep 08 15:55:39 | msgcmp.c:(.text+0x2df): undefined reference to `error_with_progname' Sep 08 15:55:41 etc. ... Sep 08 15:55:50 Any ideas for how to debug this? Sep 08 16:05:26 cworth: hi, weird. Check if Fedora has a patch to gettext? Sep 08 16:05:50 03koen 07org.oe.dev * r2ef48259... 10/ (6 files in 5 dirs): netbase: remove bogus a780 and e680 interface files Sep 08 16:11:01 hmm, I get the "Could not init font path element built-ins, removing from list!" / "could not open default font 'fixed'" error with kdrive 1.4 Sep 08 16:13:50 is there any one using glade3 + libglade to develop GUI? Sep 08 16:36:00 zecke: Check what, where? Sep 08 16:40:45 cworth: I assume youuse fedora? It might be your distro people already have a patch for this behaviour. Otherwise go to the buildtree which is in ${TMPDIR}/work/*/gettext-native (normally tmp/ or oetmp/) and grep for program_name Sep 08 16:41:20 cworth: I would say that program_name normally gets expanded by autotools to something else (but this is just a guess) Sep 08 16:41:27 * zecke heads home *bye* Sep 08 16:42:02 03koen 07org.oe.dev * r54ac81d4... 10/ (1 packages/base-files/base-files_3.0.14.bb): base-files: make machine specific Sep 08 17:00:21 03pH5 07org.oe.dev * r9d07274a... 10/ (4 files in 2 dirs): Sep 08 17:00:21 xserver-kdrive: move enable-builtin-fonts.patch out of -common.inc Sep 08 17:00:21 * I hope 1.4 will do without this hack Sep 08 17:52:33 ok, xserver-kdrive 1.4 works now, but tslib segfaults if I don't specify the input event device on the command line, like "-mouse tslib,1,device=/dev/input/touchscreen0". Sep 08 17:52:44 as ts_open is public api, I guess that's a bug in tslib? Sep 08 17:59:05 tslib doens't check for NULL or NOENT? Sep 08 18:01:32 koen: no, and it should be fixed. also we could add some default to the kdrive/tslib driver: http://en.pastebin.ca/687344 Sep 08 18:02:01 looks good Sep 08 18:02:09 did you manage to get a hold of daniels? Sep 08 18:02:58 jack? yes... Sep 08 18:03:08 koen: yes, he told me how to connect xcalibrate again. though I'm sure what I came up with is a bit .. ugly, it works. Sep 08 18:03:11 http://en.pastebin.ca/687348 Sep 08 18:11:47 sakoman, pong Sep 08 18:14:19 Crofton: fixed the modules.dep issue finally Sep 08 18:14:41 how? Sep 08 18:15:15 module-init-tools-cross Sep 08 18:15:30 ah, where does this get added? Sep 08 18:15:51 Without that package, the creation of modules.dep (&kin) fails almost silently Sep 08 18:15:57 urg Sep 08 18:16:32 There is one line or error message buried in the mass of build output Sep 08 18:18:11 It makes sense to me to add it to the linux recipe much like u-boot-mkimage-openmoko-native Sep 08 18:19:11 I've been playing with a set of recipes that allow me flexibility to build for various configurations of gumstix modules + my own custom hw Sep 08 18:19:33 So I haven't used the stuff in the tree directly Sep 08 18:20:49 ok, so the linux recipe needs module-init-tools-cross, because that supplies arm-angstrom-linux-uclibcgnueabi-depmod-2.6 Sep 08 18:21:05 yes Sep 08 18:23:27 Maybe this line in kernel.bbclass needs updating Sep 08 18:25:12 which line? Sep 08 18:25:20 DEPENDS += "virtual/${TARGET_PREFIX}depmod-${@get_kernelmajorversion('${PV}')} v Sep 08 18:25:20 irtual/${TARGET_PREFIX}gcc${KERNEL_CCSUFFIX} update-modules" Sep 08 18:25:22 sorry Sep 08 18:27:30 I wish someone skilled at kernel.bbclass was around ... Sep 08 18:28:02 Ah, yes should be HOST_PREFIX Sep 08 18:28:19 ? Sep 08 18:28:58 also it is depmod, not the cross one Sep 08 18:29:58 Yeah, I didn't want to muck with kernel.bbclass -- too many possible side effects for others Sep 08 18:30:54 yeah, I think this is the place it needs fixing Sep 08 18:30:59 But it does appear that the DEPENDS and then what actually gets used in the build don't match :-) Sep 08 18:32:05 Well, at least I have a reliable build now and can do real work :-) Sep 08 18:33:27 Are you going to be the one helping Craig get his stuff integrated into the OE distribution? Sep 08 18:33:44 most likely Sep 08 18:33:52 since I can actually test some stuff Sep 08 18:34:50 I fear that the approach he is taking, while perfect for 98% of gumstix customers, won't quitework for me Sep 08 18:35:34 well, as you mat have gathered, we try to do what most people need and can agree on Sep 08 18:35:56 Indeed, and OE is flexible enough to make me happy too Sep 08 18:35:59 but, many people maintain somewhat "private" dbs for the last little bit Sep 08 18:36:37 they key is to keep the last bit reasonable Sep 08 18:36:43 If you want to look at what I am doing, you are more than welcome to see what the lunatic fringe wants Sep 08 18:37:19 it helps when the lunatic fringe shows what they have to do to make product :) Sep 08 18:38:52 a quick cut & paste of my custom recipes: http://www.sakoman.net/oe/gumstix-custom.txt Sep 08 18:39:25 Goal was ultimate flexibility in preparing a number of product images based upon gumstix processors Sep 08 18:40:50 yeah Sep 08 18:41:24 sakoman: please use linux.inc for kernel recipes Sep 08 18:41:26 gumstix are an interesting machine, due to the number of permutations Sep 08 18:41:31 and the size of the user base Sep 08 18:41:35 that will give you a proper do_configure and do_deploy Sep 08 18:41:49 I think linux.inc in its current form requires the death of kittens Sep 08 18:42:01 too much machine dependent stuff Sep 08 18:42:22 ? Sep 08 18:42:29 S100?? named after the bus? Sep 08 18:42:45 what machine dependant stuff? Sep 08 18:42:52 It's a product number, but a pun on the bus too! Sep 08 18:43:08 sakoman, also try to work BBCOLLECTIONS so you can keep stuff outside the main tree Sep 08 18:43:17 heh Sep 08 18:43:38 where do I learn about BBCOLLECTIONS? Sep 08 18:43:58 in the bitbake and OE manuals :) Sep 08 18:44:30 http://bitbake.berlios.de/manual/ch04s02.html Sep 08 18:44:33 bottom of page Sep 08 18:45:15 koen, did you the kernel module issue above? Sep 08 18:45:23 koen: machine specific DEPENDS, CMDLINE, UBOOT_ENTRYPOINT Sep 08 18:45:50 sakoman: and how does duplicating parts of it make it more maintainable? Sep 08 18:45:59 it doesn't :) Sep 08 18:46:13 right Sep 08 18:46:16 but it get peopls working stuff while we figure out proper solutions Sep 08 18:46:25 yes! Sep 08 18:46:32 linux.inc *is* the proper solution Sep 08 18:46:42 only when it works .... Sep 08 18:46:50 it works Sep 08 18:47:06 I agree -- and I also think linux.inc should not have to be changed every time a new machine uses it! Sep 08 18:47:22 ok, must go Sep 08 18:47:38 Soon it will have a hundred lines of machine specific stuff! Sep 08 18:47:43 I can do away with the machine specific depends, but some people will throw a fit about bloat :) Sep 08 18:48:07 sakoman: so instead of changing like 2 lines in linux.inc you add a zillion line recipes Sep 08 18:48:19 huh? Sep 08 18:49:51 How about setting things up so linux.inc has zero machine specifics and linux-2.6.xx.bb has all the machine specific stuff Sep 08 18:50:21 that's ass-backwards Sep 08 18:50:25 Maybe just a religious argument :-) Sep 08 18:50:38 linux.inc is about getting the common stuff into one file, so every kernel recipe can use it Sep 08 18:50:49 it's about avoiding duplication Sep 08 18:50:58 and since OE is about multiple machines... Sep 08 18:53:37 I guess maybe I'm confused Sep 08 18:54:26 I was envisioning linux.inc as the pure essence of building linux, no machine specifics Sep 08 18:55:15 Any machine specifics to be set by the recipe including linux.inc Sep 08 18:55:28 Where have I gone wrong? Sep 08 19:01:13 why I am overwriting the hole /etc/apmd with this http://pastebin.ca/687405 ? Is there something like update-rc.d for apmd? Sep 08 19:01:39 linux.inc had the commong stuff, the version file contains the version specific stuff Sep 08 19:01:54 the attempting to have all machine stuff in linnux.inc is hard Sep 08 19:02:53 I thought you ran away :-) Sep 08 19:03:01 sisters came in for a bit Sep 08 19:03:31 I think maybe it's just a religious argument Sep 08 19:03:54 I like to minimize the number of files to touch when I add a new machine Sep 08 19:04:02 koen, what modules-tools-init-cross? Sep 08 19:04:13 koen is optimizing for OE goals Sep 08 19:04:26 I think some degree of religon is involved Sep 08 19:04:35 the packages/linux directory is a mess though Sep 08 19:05:08 Yes, I found all of the conflicting styles to be very confusing Sep 08 19:05:39 Part of rolling my own was to get a better understanding of how things work Sep 08 19:07:42 Crofton: I managed to get rid of the uboot dependency and finally built angstrom images for davinci; will try it on monday (board is at work) Sep 08 19:07:48 ok Sep 08 19:08:23 we may need to adjust how we build uboot, especially from git to avoid this problem in the future Sep 08 19:09:05 it would be nice to have uboot optional Sep 08 19:09:11 yeha Sep 08 19:09:12 yeah Sep 08 19:09:13 i.e. an easy setting in local conf Sep 08 19:09:22 but, we need mkimage Sep 08 19:09:32 mkimage is in uboot-utils Sep 08 19:09:46 that's how I built the kernel, changed the dep from uboot to uboot-utils Sep 08 19:09:58 but your kernel bb includes the omap.inc, so I had to hack that in there Sep 08 19:10:26 heh Sep 08 19:10:33 I need to make it work with linux.inc ... Sep 08 19:11:36 we love kittens :-) Sep 08 19:12:38 right Sep 08 19:14:18 I'm still not clear why linux.inc can't be machine independent, with all the machine dependent stuff in the version bb? Sep 08 19:14:34 sakoman: "number of files to touch" is a bad metric Sep 08 19:14:56 "reusing existing infrastructure" is a better one :) Sep 08 19:15:09 but 50% of OE right now is arcane crap Sep 08 19:15:24 and that's why we have IRC support ;) Sep 08 19:15:29 I agree with reusing existing infrastructure! Sep 08 19:16:37 but when the architecture requires that you touch lots of files, probability of errors skyrockets! Sep 08 19:16:44 in the past we had a lot of MACHINE=foo DISTRO=open-foo kernel=linux-foo ; bitbake foo-image Sep 08 19:17:00 everybody thought he/she was special Sep 08 19:17:42 to its parent every machine is special :-) Sep 08 19:17:48 anyway, what I am more interested in at the moment is the apparentl missing modules-cross dependency :) Sep 08 19:18:07 Hey come on, help me start a religious war! Sep 08 19:18:17 heh Sep 08 19:18:18 no Sep 08 19:18:19 :) Sep 08 19:18:35 need to stay focused on fixing problems Sep 08 19:18:38 * mwester dons his shield and sword... Sep 08 19:18:42 Seems to me that kernel.bbclass is the right place to fix it Sep 08 19:18:53 so when I get home, I can get a working gumstix Sep 08 19:19:02 or work on how to fix the tmpfs issue Sep 08 19:19:13 * steliosk hides Sep 08 19:19:14 what tmpfs issue :-) Sep 08 19:19:40 kernel config for fumstix seems not support enough options Sep 08 19:20:09 It goes away if your remove the gumstix ramfs mode patch Sep 08 19:20:22 ah! Sep 08 19:20:26 I knew it! Sep 08 19:20:34 ~lart vendor patches Sep 08 19:20:35 * ibot lowers vendor patches's priority Sep 08 19:21:00 having a size argument for ramdisks is pretty bogus in 2.6 Sep 08 19:21:14 they are dynamically sized upto 1/2 ram size Sep 08 19:21:33 I'm actually quite happy with the build I'm getting from OE right now Sep 08 19:21:45 I need to keep working on image size Sep 08 19:21:53 Still too fat Sep 08 19:22:03 But the core concepts are really great Sep 08 19:22:22 * koen finally booted a sane kernel on his motorola phone: http://dominion.kabel.utwente.nl/koen/cms/angstrom-running-on-an-motorola-a780 Sep 08 19:22:23 While we're on the topic, is there an historical reason why we mount a ramdisk on /media/ram by default? Sep 08 19:22:45 mwester: familiar used that to put logfiles and user ramdisks in Sep 08 19:22:57 mwester: to minimize flash writes Sep 08 19:23:03 dunno if it's still needed Sep 08 19:23:24 Ok. Sounds like it's obsoleted by the new volatiles mechanism (which puts a ramdisk at /var/volatile) Sep 08 19:23:35 yeah Sep 08 19:23:49 see my above comment about arcane crap Sep 08 19:23:57 koen: tried to slim down task-base with a task-base-headless experiment Sep 08 19:23:59 I check with rwhitby to see if we should remove it from SlugOS, and file a bug on OpenMoko to get rid of it there too. Sep 08 19:24:22 Builds faster at least :-) Sep 08 19:24:29 Or I could just remove it, commit the change, and see who yells... Sep 08 19:33:26 Crofton: I fixed the hwclock issue too Sep 08 19:34:25 mwester: think bigger Sep 08 19:34:39 mwester: we're talking about OE, not distros Sep 08 19:35:04 * koen hates people filing OE bugs not in the OE bugtracker Sep 08 19:35:23 :) Ok. Sep 08 19:35:35 fstabs are per machine Sep 08 19:39:00 can some one hint me why I am overwriting /etc/apmd compleatly with "install -m 0755 ${WORKDIR}/S98lock-apm ${D}${sysconfdir}/apmd/suspend.d/S98lock-apm" ? Sep 08 19:40:04 after installing the resulting package all stuff in /etc/apmd/* does no longer exists Sep 08 19:47:15 koen: btw, why there is ipkg missing in agstrom-minimal-image ? Sep 08 19:59:50 ynezz: I'm not sure Sep 08 20:01:57 but it should be there right? Sep 08 20:02:20 I think, that it makes no sense without Sep 08 20:03:29 i've added bluetooth to MACHINE_FEATURES, do I need to rebuild whole image so I've bluetooth support added to image? Sep 08 20:04:06 if you frob MACHINE_FEATURE you have to 'bitbake -c clean task-base ; bitbake task-base' or bump PR in task-base Sep 08 20:04:27 ah, thanks Sep 08 20:05:12 if you are building minimal image, it's probably task-boot you need to clean Sep 08 20:07:12 oh it downloads some X crap Sep 08 20:10:39 i don't have "screen" in MACHINE_FEATURES so I wonder why would I need X windows to be built for bluetooth support :) Sep 08 20:14:58 gstreamer pulls it in Sep 08 20:15:07 build time, not run time Sep 08 20:17:05 koen: I've pushed kdrive 1.4, but the evdev support still needs some work. currently the evdev keyboard driver doesn't accept any options unless xkb is enabled. Sep 08 20:17:16 ah, so it's also ok that it adds 400 additional tasks? Sep 08 20:17:29 ynezz: probably Sep 08 20:17:38 the joys of task-base :-) Sep 08 20:17:59 be thankfull it's only buildtime :) Sep 08 20:18:24 i hope so :) Sep 08 20:18:44 Would there be a way to modify task-base so that it only builds those things enabled by MACHINE and DISTRO features? Sep 08 20:19:18 Even though it is "only" a build time issue :-) Sep 08 20:20:55 I know all things are possible, but it is it the good idea that it appears to be on the surface? Sep 08 20:25:47 koen: don't you think we should drop the kdrive enable-epson.patch and add --enable-kdrive-vesa to EXTRA_OECONF instead? Sep 08 20:29:12 sakoman: it's possible, we just haven't found a way that doesn't end up being an unmaintanable mess Sep 08 20:29:24 pH5: you'd have to ask florian Sep 08 20:29:39 koen: ok Sep 08 20:32:36 koen: I figured there must have been a good reason Sep 08 20:35:45 03pH5 07org.oe.dev * r23e04b7b... 10/ (15 files in 3 dirs): (log message trimmed) Sep 08 20:35:45 xserver-kdrive: add 1.4 for X11R7.3 release Sep 08 20:35:45 * The tslib mouse driver has to be selected with "-mouse tslib", it Sep 08 20:35:45 defaults to the /dev/input/touchscreen0 evdev device in this build. Sep 08 20:35:45 * The evdev keyboard driver is available, but not very useful yet. It Sep 08 20:35:45 doesn't accept any command line options as long as XKB is disabled. Sep 08 20:35:49 * xcalibrate and tslib are taped together with a bit of ugly code in Sep 08 20:46:13 don't see any mention in BZ, but does a segmentation fault on launch of avahi-daemon sound familiar? (pxa255 processor, uclibc) Sep 08 20:48:05 you'd have to gdb or catchsegv it Sep 08 20:49:46 that's the next step -- just wanted to make sure I wasn't going to go chasing a known issue Sep 08 21:44:46 03pH5 07org.oe.dev * rbb6d6c5f... 10/ (5 files in 2 dirs): xserver-kdrive: move enable-epson.patch out of -common, prep for git fixup Sep 08 21:44:55 03pH5 07org.oe.dev * r71084962... 10/ (26 files in 6 dirs): Sep 08 21:44:55 xserver-kdrive: patch shuffle and cleanup Sep 08 21:44:55 * drop unused build-fix-panoramix, devfs and faster-rotated patches Sep 08 21:44:55 * move some version specific patches into xserver-kdrive-1.1.0 Sep 08 21:44:55 and move some 1.4 patches that also apply to git into Sep 08 21:44:59 unversioned xserver-kdrive Sep 08 21:45:02 03pH5 07org.oe.dev * r6f9cd410... 10/ (6 files in 3 dirs): Sep 08 21:45:02 xserver-kdrive-git: fixup Sep 08 21:45:04 * convert to use xserver-kdrive-common.inc Sep 08 21:45:06 * make patches apply Sep 08 21:45:10 03pH5 07org.oe.dev * r4eabb0e2... 10/ (1 packages/xorg-xserver/xserver-kdrive_git.bb): Sep 08 21:45:12 xserver-kdrive-git: drop "--enable-kdrive-vesa" again Sep 08 21:45:14 * the vesa server needs sys/vm86.h, which is not staged by arm glibc. Sep 08 22:00:56 just in time Sep 08 22:02:26 xserver-kdrive-git now builds again, I finally got to fix a bug during oe bugdays :) Sep 08 22:18:39 03pH5 07org.oe.dev * r297f1557... 10/ (3 files in 3 dirs): xserver-kdrive-git: add enable-epson.patch for git Sep 08 22:18:43 03pH5 07org.oe.dev * r28a6be70... 10/ (3 files in 3 dirs): xserver-kdrive-git: small w100 build fix Sep 08 22:18:54 03pH5 07org.oe.dev * r05869130... 10/ (3 files in 3 dirs): xserver-kdrive-git: add build fix for xephyr Sep 08 22:47:10 mwester: I'm happy with removing /media/ram from SlugOS Sep 08 22:48:14 The default answer to "Shall we change this thing in SlugOS which is done some standard way in OE now" is usually yes. Sep 08 22:48:31 (that is, change it to be the standard way now) Sep 08 22:49:03 Well in this case, the /media/ram thing is the current standard in OE; it just seems superfluous (sp?) with /var/volatile Sep 08 22:50:31 When I find where to change it, I'll post a note to the OE mailing list to get reactions, and change it across-the-board. If someone is using it, it would be rude to remove it or replace it with a symlink to /var/volatile with no notice whatsoever. Sep 08 23:51:59 koen: with http://ynezz.true.cz/gcc-uclibc.patch I've now working 2008.1-uclibc Sep 09 00:01:38 03pfalcon 07org.oe.dev * r371291ba... 10/ (5 files in 2 dirs): Sep 09 00:01:38 qmake-base.bbclass: Rename to qmake_base.bbclass. Sep 09 00:01:38 * Hyphens are bad in function names. Sep 09 00:01:38 * Fixes OPIE build. Sep 09 00:01:45 03pfalcon 07org.oe.dev * re1e87016... 10/ (3 files in 2 dirs): uicmoc-native: Follow qmake-base rename. Sep 09 00:01:53 03pfalcon 07org.oe.dev * r47b95f57... 10/ (8 files in 6 dirs): Follow qmake-base rename. Sep 09 00:03:10 03pfalcon 07org.oe.dev * r66ade007... 10/ (1 classes/qt3e.bbclass classes/qt3x11.bbclass): qt3e.bbclass, qt3x11.bbclass: Follow qmake-base rename. Sep 09 02:27:54 who is pfalcon? Sep 09 02:31:26 pfalcon: if you're going to rename a class file, a simple file | xargs grep will find *all* uses of that class. Sep 09 02:31:29 * rwhitby pushes a fix Sep 09 02:52:00 03rwhitby 07org.oe.dev * r04064a09... 10/ (5 files in 4 dirs): qmake_base: Fix packages that refer to qmake-base instead of qmake_base. OE needs a class files naming convention - choose hyphens or underscores, not both. **** ENDING LOGGING AT Sun Sep 09 02:59:56 2007