**** BEGIN LOGGING AT Wed Jul 08 02:59:59 2009
Jul 08 04:51:28 <dhd> which recipe generates the default etc/passwd and etc/group files for an image?
Jul 08 04:51:35 <dhd> it is totally not obvious to me where they come from
Jul 08 04:52:07 <dhd> also openssh doesn't seem to work properly when you include it in an image, because it needs to have an ssh user in the default passwd/group files
Jul 08 04:52:13 <dhd> and those are only created by the postinst
Jul 08 05:31:55 <mickey|ICE874> morning Sup3rkiddo 
Jul 08 05:32:01 <mickey|ICE874> how's it going?
Jul 08 06:16:59 <khem> dhd: I think openssh might need pkg_postinst_${PN} where you can add the ssh user 
Jul 08 06:23:24 <mickey|ICE874> can anyone recommend a mini-pci card that works reasonably well w/ madwifi?
Jul 08 06:23:33 <mickey|ICE874> the compatibility list seems to have vanished from the docs
Jul 08 06:25:49 <CIA-1> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r988f1e8aac 10openembedded.git/recipes/qt4/ (qt4-embedded.inc qt4-x11-free.inc qt4.inc): qt4: package demos and examples as well
Jul 08 06:33:16 <mckoan> good morning
Jul 08 07:06:43 <methril|work> good morning
Jul 08 07:28:16 <CIA-1> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rfde8767cb8 10openembedded.git/recipes/ffmpeg/ (ffmpeg.inc ffmpeg_git.bb): ffmpeg git: bump SRCREV to get decode_video2 api
Jul 08 07:28:27 <CIA-1> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rc01dca8859 10openembedded.git/recipes/ffmpeg/omapfbplay-xv_git.bb: omapfbplay: add xv version with netsync option
Jul 08 08:33:03 <recalcati> good morning
Jul 08 08:47:43 <florian> good morning
Jul 08 09:49:39 <hrw> morning
Jul 08 09:50:10 <hrw> mickeyl: I have 2 atheros cards at home
Jul 08 09:58:32 <florian> hi hrw 
Jul 08 09:59:19 <hrw> mickeyl: 00:0e.0 Ethernet controller: Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter (rev 01)
Jul 08 10:03:01 <hrw> mickeyl: it is TP-Link TL-WN660G
Jul 08 10:03:20 <hrw> [    7.995067] ath5k phy0: Atheros AR2414 chip found (MAC: 0x79, PHY: 0x45)
Jul 08 10:24:44 <sx> hi all, I have a simple question
Jul 08 10:24:53 <sx> What should I do for to see the touchscreen calibration screen at first starting of gpe?
Jul 08 10:25:17 <hrw> rm /etc/pointercal if it exists
Jul 08 10:26:40 <sx> I've tried this but nothing happens. it works with a ready rootfs, but I compile my own rootfs "x11-gpe-image"
Jul 08 10:28:00 <sx> or can I start the same application? what's the name of the ts calibration application?
Jul 08 10:28:45 <hrw> xtscal
Jul 08 10:30:35 <sx> yes, I have it, but it doesn't work properly, only writes something like "calibration success"
Jul 08 10:34:32 <hrw> what device?
Jul 08 10:36:00 <sx> angstrom, at91sam9261
Jul 08 10:36:50 <sx> now I entered in settings/screen setup in GPE, and there is a button over there named Start
Jul 08 10:37:06 <sx> I've clicked on it, but nothing happens
Jul 08 10:37:32 <sx> maybe I didn't add all needed packages in my .bb file
Jul 08 10:40:28 <hrw> you made own image?
Jul 08 10:44:42 <sx> hrw, yes
Jul 08 10:45:15 <hrw> you have xtscal installed or not?
Jul 08 10:45:32 <hrw> "opkg list_installed|grep xtscal"
Jul 08 10:45:35 <sx> I have
Jul 08 10:45:51 <sx> xtscal - 0.6.3-r7.1 -
Jul 08 10:45:54 <sx> it is
Jul 08 10:46:25 <hrw> "DISPLAY=:0 xtscal" do nothing?
Jul 08 10:47:19 <sx> XCALIBRATE extension missing: Success
Jul 08 10:47:41 <hrw> ok, then I have no idea
Jul 08 10:48:20 <hrw> tomorrow I will get my at91sam9263ek board back and will test some x.org stuff on it
Jul 08 10:49:04 <sx> where can I find the .bb file of the working gpe rootfs?
Jul 08 10:49:47 <sx> the ready one of olimex works without problem, but my rootfs doesn't :(
Jul 08 10:54:51 <hrw> "bitbake x11-image"
Jul 08 10:55:42 <Laibsch1> pb_: any further news on witpa?
Jul 08 10:56:09 <hrw> witpa is that "where is the source?" tool?
Jul 08 11:02:41 <CIA-1> 03Leon Woestenberg <leon@sidebranch.com> 07org.openembedded.dev * reb2aaf8679 10openembedded.git/conf/machine/ (calamari.conf include/tune-ppce500v2.inc): calamari.conf: New machine (MPC8536DS development system).
Jul 08 11:02:51 <CIA-1> 03Leon Woestenberg <leon@sidebranch.com> 07org.openembedded.dev * r68a27fcf8d 10openembedded.git/recipes/linux/ (3 files in 2 dirs): linux: updated 2.6.25 and 2.6.27 for mpc8315e-rdb.
Jul 08 11:03:13 <likewise> hrw: where is the package at
Jul 08 11:03:19 <likewise> hrw: it is my tool
Jul 08 11:03:44 <likewise> hrw: http://www.sidebranch.com/leon/
Jul 08 11:04:12 <likewise> Maybe I can include it in contrib/ ?
Jul 08 11:04:33 <likewise> Laibsch: ^^^
Jul 08 11:05:28 <hrw> its in C...
Jul 08 11:05:41 <hrw> feel free to add to contrib/
Jul 08 11:05:50 * hrw do not like to hack C code
Jul 08 11:06:39 <likewise> hrw: that's why we are complementary to each other. I program in C 99% of what I do.
Jul 08 11:07:27 <Laibsch> hrw, yes, I'm getting increasingly frustrated with *any* build from scratch failing at least 4 to 5 times because sources have vanished
Jul 08 11:07:51 <Laibsch> I think it's silly to spend so much effort on updating SRC_URI (plus now you have to update checksums, too)
Jul 08 11:08:10 <hrw> Laibsch: the solution is to get machine with big bandwith to work as official OE source mirror
Jul 08 11:08:28 <Laibsch> likewise: I would like to see witpa integrated into do_fetch and had a talk about it with pb and kergoth
Jul 08 11:08:29 <xranby> Would it be possible for OE to host all the sourcecode in use  (like what debian does)
Jul 08 11:08:46 <xranby> it would at least solve all the missing SRC_URI
Jul 08 11:08:49 <Laibsch> xranby: that is the second option
Jul 08 11:08:54 <Laibsch> Angstrom has a source mirror
Jul 08 11:08:56 <hrw> xranby: we basically do that with Angstrom
Jul 08 11:09:02 <xranby> thats great
Jul 08 11:09:11 <Laibsch> But, then why should we have SRC_URI in the first place?
Jul 08 11:09:31 <hrw> Laibsch: to show where to check for newer version?
Jul 08 11:09:31 <Crofton|work> So we know where the code came from
Jul 08 11:09:33 <likewise> Laibsch: could you include me in the talks? I have some thoughts on this.
Jul 08 11:10:01 <Laibsch> likewise: on the witpa in do_fetch thing?
Jul 08 11:10:17 <likewise> well, on how to find sources, not the integration per se.
Jul 08 11:10:19 <Laibsch> When we talked about it, I think you were offline
Jul 08 11:10:31 <likewise> Yeah, I just returned from holidays.
Jul 08 11:10:32 <Laibsch> and I wasn't 100% sure about your nick ;-)
Jul 08 11:10:36 <Laibsch> nice
Jul 08 11:10:47 <Laibsch> First thing we need is a witpa-native recipe
Jul 08 11:10:48 <likewise>  I am quite busy also, so pls go ahead, the code is public
Jul 08 11:10:57 <Laibsch> I did a very little bit of work, but failed early
Jul 08 11:11:05 <likewise> but i'ld love to help where possible
Jul 08 11:11:16 <Laibsch> let me pastebin my current recipe
Jul 08 11:11:24 <Laibsch> IIRC, it fails in do_install
Jul 08 11:25:49 <eray> hrw: do you want to see my own .bb file?
Jul 08 11:44:58 <recalcati> I'm still working on a pxa270. anybody can suggest an optimized mpeg4 player ?
Jul 08 11:45:09 <hrw> mplayer?
Jul 08 11:45:16 <recalcati> hi hrw
Jul 08 11:45:42 <recalcati> yes, I'm using it, but I can decode only mpeg2 and mpeg4 320x240. no more
Jul 08 11:45:50 <recalcati> with mad library
Jul 08 11:46:28 <hrw> I do not know more optimized engine then ffmpeg one
Jul 08 11:46:37 <recalcati> I was reading an application note aboute the usage of SRAM for ovl2
Jul 08 11:46:55 <recalcati> Another idea is to have a decoder implemented using IPP
Jul 08 11:47:47 <hrw> recalcati: I never was inside of code
Jul 08 11:48:28 <recalcati> hrw:  ok , no pb
Jul 08 11:48:44 <broonie> That sort of stuff would need kernel support which I don't think is available.
Jul 08 11:49:40 <recalcati> yes broonie: I'm looking if I have somewhere. I bought it some years ago, but I don't remember if I have only for pxa255
Jul 08 12:03:41 <CIA-1> 03Roman I Khimov <khimov@altell.ru> 07stable/2009 * ra83f490558 10openembedded.git/recipes/qemu/ (15 files in 2 dirs): (log message trimmed)
Jul 08 12:03:41 <CIA-1> qemu 0.10.3: port OE patches, make preferable version
Jul 08 12:03:41 <CIA-1> Fixes binary locale generation broken by
Jul 08 12:03:41 <CIA-1> 6065fa491c009118ae282ae933215649cccfcd24.
Jul 08 12:03:41 <CIA-1> Tested to work on ARM OABI (simpad), ARM EABI (qemuarm), PowerPC (efika)
Jul 08 12:03:42 <CIA-1> and i686 (x86-prescott).
Jul 08 12:03:46 <CIA-1> Acked-by: Philipp Zabel <philipp.zabel@gmail.com>
Jul 08 12:17:29 <hrw> likewise: you maintain mpc8315e-rdb right?
Jul 08 12:32:43 <likewise> hrw: yes
Jul 08 12:32:49 <likewise> hrw: I f*cked up stuff?
Jul 08 12:33:24 <pb_> sx: that xtscal error seems fairly clear: your xserver doesn't have the XCALIBRATE extension.
Jul 08 12:33:32 <pb_> admittedly the "Success" is a bit confusing, I guess that should be removed.
Jul 08 12:34:35 <hrw> likewise: no, I would like you to test something
Jul 08 12:35:10 <hrw> likewise: http://diff.pastebin.ca/1488117
Jul 08 12:35:34 <hrw> likewise: at91 patch should be safe for !at91 devices and I would like to not add it for each at91 machine
Jul 08 12:36:14 <likewise> hrw: this diff is scary though: -DEFAULT_PREFERENCE = "-1"
Jul 08 12:37:06 <hrw> likewise: I would like to end era of 'why I got 2.6.14 linux kernel for my new device when tehre is a 2.6.30 one'
Jul 08 12:37:26 <hrw> likewise: that would require testing of course first
Jul 08 12:37:33 <likewise> hrw: hmm, because 2.6.14 was tested and has a defconfig, and 2.6.30 has not?
Jul 08 12:37:55 <likewise> hrw: I think enabling DEFAULT_PREFERENCE for a machine means we at least should have a defconfig for it
Jul 08 12:39:44 <hrw> likewise: for my devices I use one defconfig for all releases - works fine
Jul 08 12:40:51 <likewise> hrw: how can you achieve this? Does kernel.inc include a default file path for defconfig?
Jul 08 12:41:11 <hrw> likewise: recipes/linux/linux/MACHINE/defconfig
Jul 08 12:41:30 <hrw> likewise: or recipes/linux/PN/MACHINE/defconfig ;D
Jul 08 12:43:21 <sx> pb_: my .bb file is http://pastebin.ca/1488120
Jul 08 12:43:29 <likewise> hrw: thanks, I didn't know this. I still find it scary to remove DEFAULT_PREFERENCE for ALL machines. This will probably break half of them. So I do not ack that part of the patch.
Jul 08 12:43:38 <sx> is there a conflict between packages?
Jul 08 12:44:56 <hrw> likewise: ignore it then
Jul 08 12:45:10 <hrw> likewise: I rather wanted to get ack for at91 patch added by default
Jul 08 12:45:17 <likewise> yes, ack for that
Jul 08 12:45:47 <hrw> sx: you use directfb not x11?
Jul 08 12:47:10 <pb_> sx: I don't think there's any conflict, you just need a better xserver.
Jul 08 12:47:14 <likewise> hrw: just commit pls. I will test somewhere this week, I am catching up a lot of work now
Jul 08 12:47:33 <hrw> ok
Jul 08 12:50:14 <sx> pb_: I use x11
Jul 08 12:59:48 <hrw> so far 2.6.30 builds for at91*
Jul 08 14:49:19 <rkirti> What is the right way to add SRC_URI for a recipe that needs to svn co using https ? Will using "svn co <httpslink>" in SRC_URI work ?
Jul 08 14:52:10 <hrw> "proto=https" in SRC_URI svn:// line
Jul 08 15:08:21 <CIA-1> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rdfc54a347a 10openembedded.git/recipes/ffmpeg/omapfbplay-xv_git.bb: omapfbplay-xv: fix typo in recipe
Jul 08 15:36:55 <pb_> hi mickey|FSOteam 
Jul 08 15:37:55 <mickey|FSOteam> morning pb_ 
Jul 08 16:09:02 <hrw> have a nice rest of day
Jul 08 16:16:46 <CIA-1> 03Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> 07org.openembedded.dev * rbe01145f30 10openembedded.git/classes/package_rpm.bbclass: package_rpm.bbclass: be more quiet
Jul 08 16:16:48 <CIA-1> 03Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> 07org.openembedded.dev * r3402525a23 10openembedded.git/recipes/linux/linux_2.6.30.bb: 
Jul 08 16:16:48 <CIA-1> linux: added AT91 patch to SRC_URI for all devices
Jul 08 16:16:48 <CIA-1> AT91 patch do not touch other platforms and I plan to move all AT91
Jul 08 16:16:49 <CIA-1> based devices to 2.6.30 in next commits.
Jul 08 16:16:51 <CIA-1> 03Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> 07org.openembedded.dev * r1ada370e77 10openembedded.git/conf/checksums.ini: checksums.ini: added 2.6.30-at91 patch
Jul 08 16:17:44 <ppol> Hello all!
Jul 08 16:19:31 <ppol> Can anybody help me to run OE under vmware?
Jul 08 16:19:59 <ppol> I built some images fine (minimal-image...) with vmware as conf
Jul 08 16:20:42 <ppol> got the package built fine... but what to do now? I try but fail to install the image
Jul 08 16:29:57 <likewise> How does this exactly work for arm7a:
Jul 08 16:29:58 <likewise> ANGSTROM_BINUTILS_VERSION                ?= "2.18"
Jul 08 16:30:00 <likewise> ANGSTROM_BINUTILS_VERSION_armv7a         ?= "2.18.50.0.7"
Jul 08 16:30:13 <likewise> has _override precedence over ?= ?
Jul 08 16:30:17 <pb_> yes
Jul 08 16:30:42 <likewise> pb_: is this documented somewhere?
Jul 08 16:31:04 <pb_> probably not in so many words, though I think the bitbake manual does describe the semantics of both.
Jul 08 16:31:12 <likewise> pb_: thanks. so ordering of the statements is not important?
Jul 08 16:31:22 <pb_> not in that particular case, no.
Jul 08 16:32:38 <pb_> ?= is an immediate, weak assignment.  it will assign the variable on the left equal to the value on the right if the variable on the left wasn't previously set.  for these purposes (and, basically, all parse-time purposes) the overrides are ignored: ANGSTROM_BINUTILS_VERSION_armv7a and ANGSTROM_BINUTILS_VERSION are independent, unrelated variables at that point.
Jul 08 16:32:57 <ant_work> pb_: hey
Jul 08 16:33:27 <ant_work> pb_: I've read about minimal/vanilla/default...how does it cope with ANGSTROM* ?
Jul 08 16:34:15 <pb_> the overrides are processed later, after parsing is finished.  at that point, the bitbake data core will collapse the overridden variables together, so the value of ANGSTROM_BINUTILS_VERSION_armv7a is assigned to ANGSTROM_BINUTILS_VERSION.  at that point, it doesn't matter how the values were set, only the final result is important.  you could have set the overriding variable with =, or :=, or ?=, or built it up using .=, and the outcome would be just the same.
Jul 08 16:35:05 <pb_> ant_work: I'm not sure I understand the question.  minimal/generic/vanilla is a distro in its own right, it doesn't need to "cope with" angstrom.
Jul 08 16:35:14 <ant_work> the variables name
Jul 08 16:35:34 <pb_> what about them?
Jul 08 16:35:49 <ant_work> ANGSTROM_BINUTILS_VERSION e.g.
Jul 08 16:36:08 <ant_work> should'n all be 'neutral'
Jul 08 16:36:22 <ant_work> as DEFAULT_BINUTILS_* ?
Jul 08 16:36:24 <pb_> oh, right.  it doesn't use those variables, they're just an internal angstrom thing
Jul 08 16:36:42 <ant_work> was the *libc the last one
Jul 08 16:36:44 <ant_work> ?
Jul 08 16:37:35 <pb_> I think some of that logic has been migrated into sane-toolchain.inc, which is used by other distros, but the binutils one is still angstrom only as far as I know.
Jul 08 16:37:38 <ant_work> I would prefer a 'default' distro (with sane preferred providers/versions)
Jul 08 16:37:46 <Crofton|work> heh
Jul 08 16:37:59 <Crofton|work> those tend not to work and/or always be broken :)
Jul 08 16:38:30 <ant_work> yes, at one point A. was the 'default' for OE imho
Jul 08 16:38:44 <ant_work> at least when I started here
Jul 08 16:38:58 <Crofton|work> it is the most reliable
Jul 08 16:39:08 <ant_work> hat off
Jul 08 16:39:09 <Crofton|work> and don't forget about the nslu2 guys either
Jul 08 16:39:45 <ant_work> oh sure
Jul 08 16:41:03 <ant_work> My 2 (euro)cents: in OE there are too many distros and too many images. A nightmare to maintain.
Jul 08 16:41:28 <Crofton|work> well
Jul 08 16:41:32 <ant_work> if some Co. needs customizing, they can do it
Jul 08 16:41:39 <Crofton|work> there are too many unmaintined distros :)
Jul 08 16:41:49 <mickey|FSOteam> that's true
Jul 08 16:41:50 <Crofton|work> but images are another matter
Jul 08 16:41:56 <ant_work> one cannot foresee all posible needs :)
Jul 08 16:42:05 <Crofton|work> that is the image issue
Jul 08 16:42:29 <Crofton|work> still images should be maintained in overalys for most end users
Jul 08 16:42:49 <Crofton|work> where enduser is someone using OE to build sw for a specific solution/device
Jul 08 16:43:17 <Crofton|work> lunch
Jul 08 16:45:22 <mickey|FSOteam> ~bon appetit
Jul 08 16:45:23 <ibot> hmm... bon appetit is smacznego.  Guten Appetit.  Eet Smakelijk.  God Appetitt.  Buon Appetito.  Buen apetito  Bom Apetite. buen apetito  Smaklig måltid!.  Hyvää ruokahalua.  Bo Proveito
Jul 08 17:01:57 <ant_work> bbl
Jul 08 17:13:39 <otavio> someone broken qemu-native in stable
Jul 08 17:13:40 <otavio> :(
Jul 08 17:24:58 <tmartins> a question about a recipe inheriting "autotools": How do I specify a version for automake and autoconf?
Jul 08 17:28:26 <likewise> tmartins: I think some gcc-avr32 recipe does thaty
Jul 08 17:28:47 <tmartins> likewise: thanks. I'll take a look on it
Jul 08 17:34:50 <tmartins> hehe, ok, so, a more generic question: How do I specify the package version on DEPENDS? pn_pv?
Jul 08 17:36:04 <CIA-1> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r40a2e72aed 10openembedded.git/recipes/linux/ (6 files in 2 dirs): linux-omap 2.6.29: fix some vfp and neon bugs
Jul 08 17:36:04 <CIA-1> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rea73bad66e 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev
Jul 08 17:36:06 <CIA-1> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rad39a5d736 10openembedded.git/conf/machine/include/omap3.inc: omap3.inc: bump PR for kernel change
Jul 08 17:36:07 <CIA-1> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r2059a69ede 10openembedded.git/recipes/ffmpeg/omapfbplay-xv_git.bb: omapfbplay-xv: enable omapfb driver as well
Jul 08 17:36:10 <CIA-1> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r06ad37cc9b 10openembedded.git/recipes/qt4/qt4.inc: qt4: add extra hook into configure to munge some qmake stuff
Jul 08 18:20:45 <CIA-1> 03Daniel Willmann <daniel@totalueberwachung.de> 07shr/import * r517882d2ae 10openembedded.git/recipes/intone/intone_svn.bb: intone: vorbis-include-id3tag.patch was applied upstream
Jul 08 18:23:15 <CIA-1> 03Stefan Schmidt <stefan@datenfreihafen.org> 07fso/milestone5.5 * r4038eefac9 10openembedded.git/recipes/openbmap/openbmap-logger_0.3.2.bb: 
Jul 08 18:23:15 <CIA-1> openbmap-logger: Add version 0.3.2
Jul 08 18:23:15 <CIA-1> * Finally distutils support which gives us a sane recipe.
Jul 08 18:23:16 <CIA-1> 03Stefan Schmidt <stefan@datenfreihafen.org> 07fso/milestone5.5 * rde55df2cd8 10openembedded.git/conf/checksums.ini: checksums.ini: Add openbmap-logger 0.3.2 checksum
Jul 08 18:23:17 <CIA-1> 03Stefan Schmidt <stefan@datenfreihafen.org> 07fso/milestone5.5 * r63187e559e 10openembedded.git/recipes/images/fso-image.inc: fso-image.inc: Add openbmap-logger into the images.
Jul 08 18:23:32 <mickey|FSOteam> yay
Jul 08 18:27:00 <tmartins> what, PREFERED_VERSION_autoconf-native has no effect!
Jul 08 18:29:38 <Crofton|work> tmartins, we don't support versioned  dependencies
Jul 08 18:29:44 <tmartins> oh!
Jul 08 18:29:50 <tmartins> ok, any workaround then? 
Jul 08 18:31:11 <Crofton|work> be very careful what you let build 
Jul 08 18:31:11 <likewise> glibc-2.9 not using ports 2.9 (but 2.7) is intentional for what reason?
Jul 08 18:31:53 <likewise> tmartins: *some* recipes have a version in their name (see how gcc-avr32 uses this very very very dirty trick)
Jul 08 18:33:27 <likewise> tmartins: never mind, that already got removed (was binutils, not gcc btw)
Jul 08 18:33:32 <likewise> tmartins: but here's one example: autoconf213_2.13.bb
Jul 08 18:33:39 <tmartins> heh, yes, I could not find it
Jul 08 18:33:52 <tmartins> hmm
Jul 08 18:34:03 <likewise> tmartins: in that very very case, DEPENDS = " autoconf213" will depend on the autoconf213 recipe
Jul 08 18:34:14 <likewise> tmartins: it's something we do not encourage
Jul 08 18:34:17 <tmartins> ok
Jul 08 18:34:30 <tmartins> what would be the "correct" way of doint it then?
Jul 08 18:34:53 <tmartins> I suppose DEPENDS += "autoconf-2.59" won't work either...
Jul 08 18:35:55 <khem> tmartins: create the configure with intended versions and put the patch for that package
Jul 08 18:36:14 <khem> likewise: use eglibc
Jul 08 18:36:24 <khem> likewise: I am in process of testing 2.10 release
Jul 08 18:36:46 <khem> I will propose the new recipes once it runs through tests
Jul 08 18:36:50 <tmartins> ah, of course... heh, a bit dirty, but efficace
Jul 08 18:37:44 <likewise> khem: I am using eglibc actually :-) I just noted that Freescale's BSP for MPC8536E was based on glibc still
Jul 08 18:37:57 <khem> tmartins: ideally we should not regenerate configure unless it is a must 
Jul 08 18:38:18 <khem> likewise: hmm I thought they should have used eglibc I wonder why still glibc
Jul 08 18:38:27 <tmartins> well, but that's precisely what the autotools class does
Jul 08 18:38:51 <khem> 85xx is better supported in eglibc
Jul 08 18:39:14 <likewise> khem: probably started that port years ago :-0
Jul 08 18:39:29 <khem> heh could be
Jul 08 18:43:44 <CIA-1> 03Angus Ainslie <nytowl@openmoko.org> 07fso/milestone5.5 * r62a0007f16 10openembedded.git/: Merge branch 'fso/milestone5.5' of git@git.openembedded.org:openembedded into fso/milestone5.5
Jul 08 18:43:55 <CIA-1> 03Angus Ainslie <nytowl@openmoko.org> 07fso/milestone5.5 * rd6e4fd5887 10openembedded.git/ (32 files in 3 dirs): 
Jul 08 18:43:55 <CIA-1> linux-openmoko_2.6.30.1 : new recipe from openwrt patches
Jul 08 18:43:55 <CIA-1> Thanks Lars and Mirko
Jul 08 18:45:53 <tmartins> khem: but won't I need to regenerate the configure for each different plataform?
Jul 08 18:49:56 <khem> no
Jul 08 18:50:27 <tmartins> well, the configure script that came with the package don't work
Jul 08 18:53:41 <tmartins> i got a "configure: error: cannot run C compiled programs"
Jul 08 18:54:01 <tmartins> hmm, wait, I'm dumb
Jul 08 18:55:43 <tmartins> of course, the HOST isn't being set... d'oh!
Jul 08 18:55:58 <tmartins> is there any HOST variable on bitbake?
Jul 08 19:00:40 <tmartins> joy!
Jul 08 19:01:05 <hrw> re
Jul 08 19:01:38 <hrw> someone here has AT91 board from Atmel other then at91sam9263ek?
Jul 08 19:01:41 <mickey|FSOteam> hi hrw
Jul 08 19:01:43 <mickey|FSOteam> not me
Jul 08 19:02:02 <florian> re
Jul 08 19:02:19 <mickey|FSOteam> yo florian 
Jul 08 19:02:24 <florian> hi mickey|FSOteam 
Jul 08 19:02:29 <mickey|FSOteam> did z. sent you the kontoformular?
Jul 08 19:02:35 <hrw> mickey|FSOteam: I know that you use iPhone and rather consumer devices then devboards
Jul 08 19:02:52 <mickey|FSOteam> true
Jul 08 19:02:59 <hrw> but if we count openmoko phones as cheap s3c devboards....
Jul 08 19:03:04 <BlindMan> re
Jul 08 19:03:05 <mickey|FSOteam> hehe
Jul 08 19:03:07 <florian> hrw: i know some other people with  at91sam9263 and  at91sam9260 based boards
Jul 08 19:03:32 <florian> mickey|FSOteam: not yet
Jul 08 19:03:35 <hrw> florian: I have 2.6.30 for at91 boards built but would like to get it tested before pushing
Jul 08 19:03:57 <mickey|FSOteam> florian: mmhr
Jul 08 19:04:29 <florian> hrw: didn't you have one of these?
Jul 08 19:04:42 <hrw> florian: I have at91sam9263ek
Jul 08 19:05:02 <hrw> tomorrow I take it from my friend who make it live again
Jul 08 19:05:45 <hrw> s/make/made
Jul 08 19:07:55 <CIA-1> 03Stefan Schmidt <stefan@datenfreihafen.org> 07shr/import * r4038eefac9 10openembedded.git/recipes/openbmap/openbmap-logger_0.3.2.bb: 
Jul 08 19:07:55 <CIA-1> openbmap-logger: Add version 0.3.2
Jul 08 19:07:55 <CIA-1> * Finally distutils support which gives us a sane recipe.
Jul 08 19:07:57 <CIA-1> 03Stefan Schmidt <stefan@datenfreihafen.org> 07shr/import * r63187e559e 10openembedded.git/recipes/images/fso-image.inc: fso-image.inc: Add openbmap-logger into the images.
Jul 08 19:07:58 <CIA-1> 03Angus Ainslie <nytowl@openmoko.org> 07shr/import * rd6e4fd5887 10openembedded.git/ (32 files in 3 dirs): 
Jul 08 19:08:00 <CIA-1> linux-openmoko_2.6.30.1 : new recipe from openwrt patches
Jul 08 19:08:02 <CIA-1> Thanks Lars and Mirko
Jul 08 19:08:04 <CIA-1> 03Klaus Kurzmann <mok@fluxnetz.de> 07shr/import * raa080a4b82 10openembedded.git/recipes/shr/elementary-theme-sixteen_git.bb: 
Jul 08 19:08:07 <CIA-1> elementary-theme-sixteen_git.bb: fix DESCRIPTION
Jul 08 19:08:09 <CIA-1> Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
Jul 08 19:08:11 <CIA-1> 03Stefan Schmidt <stefan@datenfreihafen.org> 07shr/import * rde55df2cd8 10openembedded.git/conf/checksums.ini: checksums.ini: Add openbmap-logger 0.3.2 checksum
Jul 08 19:08:14 <CIA-1> 03Angus Ainslie <nytowl@openmoko.org> 07shr/import * r62a0007f16 10openembedded.git/: Merge branch 'fso/milestone5.5' of git@git.openembedded.org:openembedded into fso/milestone5.5
Jul 08 19:08:17 <CIA-1> 03Klaus Kurzmann <mok@fluxnetz.de> 07shr/import * r497f744c17 10openembedded.git/: Merge branch 'fso/milestone5.5' into shr/import
Jul 08 19:10:39 <tmartins> khem: you were right from the start, the provided configure script works just fine, I was just forgetting to set the specific host. Thank you!
Jul 08 19:46:41 <CIA-1> 03Michael 'Mickey' Lauer <mickey@vanille-media.de> 07fso/milestone5.5 * r22c73299cb 10openembedded.git/: Merge commit 'origin/fso/milestone5.5' into ms5.5
Jul 08 19:46:51 <CIA-1> 03Michael 'Mickey' Lauer <mickey@vanille-media.de> 07fso/milestone5.5 * r227e6b811b 10openembedded.git/recipes/freesmartphone/fsodeviced_git.bb: fsodeviced: libcanberra-alsa is a runtime dependency, not a build time dependency
Jul 08 19:46:52 <CIA-1> 03Michael 'Mickey' Lauer <mickey@vanille-media.de> 07fso/milestone5.5 * r4390fe60db 10openembedded.git/recipes/pulseaudio/libcanberra_0.14.bb: libcanberra: PACKAGES_DYNAMIC cosmetics
Jul 08 20:48:49 <cbrake> is there local documentation available for C++ libs -- something similiar to devhelp for gnome, or man pages for libc?
Jul 08 20:54:06 <timtimred> hey cbrake
Jul 08 20:54:13 <timtimred> ftp://gcc.gnu.org/pub/gcc/libstdc++/doxygen/
Jul 08 20:55:14 <khem> cbrake: http://gcc.gnu.org/onlinedocs/libstdc++/
Jul 08 20:56:46 <cbrake> great, thanks
Jul 08 21:28:24 <cbrake> ahh, libstdc++6-4.2-doc package has man pages, libstdc++6-4.3-doc does not (at least for Ubuntu)
Jul 08 21:29:06 <cbrake> there is also a stl-manual package (SGI stuff)
Jul 08 22:43:39 <khem> http://blog.aurel32.net/?p=47
**** ENDING LOGGING AT Thu Jul 09 02:59:56 2009