**** BEGIN LOGGING AT Fri Jan 15 02:59:57 2010
Jan 15 07:26:57 <CIA-1> 03Steffen Sledz <sledz@dresearch.de> 07org.openembedded.dev * r61f3b32f0a 10openembedded.git/recipes/linux/ (linux-2.6.24/hipox/hipox-nand-vs-pci.patch linux_2.6.24.bb): 
Jan 15 07:26:57 <CIA-1> linux_2.6.24: secure NAND access against PCI activity at hipox machine
Jan 15 07:26:57 <CIA-1> Signed-off-by: Steffen Sledz <sledz@dresearch.de>
Jan 15 07:27:07 <CIA-1> 03Steffen Sledz <sledz@dresearch.de> 07org.openembedded.dev * r04e3f04a8c 10openembedded.git/recipes/linux/linux-2.6.24/hipox/hipox.patch: 
Jan 15 07:27:07 <CIA-1> linux-2.6.24: hipox machine support patch rebased to linux-2.6.24.7
Jan 15 07:27:07 <CIA-1> Signed-off-by: Steffen Sledz <sledz@dresearch.de>
Jan 15 07:34:28 <bkero> Is there any way I could get angstrom to boot with rootfs rw, I keep getting a lot of read-only filesystem errors when booting the sd card.
Jan 15 07:45:51 <mckoan> good morning
Jan 15 07:56:54 <zuencap> Hi, I have compiled 2.6.31 kernel for beagleboard on oe: bitbake linux-omap-2.6.31. Installed all ipkgs produced. Then I copied /boot/uImage-2.6.31-omap1 to fat partition as uImage. But It doesn't boot. Last message on tty: [   14.193878] input: gpio-keys as /devices/platform/gpio-keys/input/input0
Jan 15 08:38:25 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r26067f9147 10openembedded.git/recipes/dillo/dillo2_2.1.1.bb: 
Jan 15 08:38:25 <CIA-1> dillo2: fix RDEPENDS package name
Jan 15 08:38:25 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Jan 15 09:28:50 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * reb0805d926 10openembedded.git/recipes/fltk/efltk/fix.void.cast.patch: 
Jan 15 09:28:50 <CIA-1> efltk: add missing patch
Jan 15 09:28:50 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Jan 15 09:28:50 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * rf34bd22758 10openembedded.git/recipes/tasks/task-shr-feed.bb: 
Jan 15 09:28:50 <CIA-1> task-shr-feed: reenable bluez-hcidump
Jan 15 09:28:50 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Jan 15 10:08:18 <RP> morning all
Jan 15 10:08:58 <rkirti> morning RP, florian
Jan 15 10:09:18 <florian> good morning!
Jan 15 10:10:51 <koobe> is there a recipe for building a drive image for an SD/MMC card? i.e. build an MBR partition table and insert filesystem(s) in the right places within the image?
Jan 15 10:14:13 <mckoan> good morning
Jan 15 10:14:19 <RP> koobe: There is something I once added in poky's scripts directory to add an MBR to a filessystem image...
Jan 15 10:14:30 <RP> hi mckoan 
Jan 15 10:18:35 <CIA-1> 03Thomas Zimmermann <ml@vdm-design.de> 07org.openembedded.dev * r45ee9e2217 10openembedded.git/recipes/e17/illume-keyboard-default_svn.bb: 
Jan 15 10:18:35 <CIA-1> illume-keyboard-default: fix numeric keyboard
Jan 15 10:18:35 <CIA-1> * Numeric.kbd was included instead of Numbers.kbd,
Jan 15 10:18:35 <CIA-1> so illume-keyboard-default-numeric contained only the numberic.png
Jan 15 10:18:35 <CIA-1> * This solves SHR bug #870
Jan 15 10:18:38 <mckoan> I am trying to undestand how xorg-server-1.7.3 is configured, I wonder if exist a place where I can see how configure phase worked, maybe a log
Jan 15 10:19:25 <mckoan> anybody knows whether in tmp there is anything like that?
Jan 15 10:20:17 <koobe> RP, poky-addptable2image i presume. thanks.
Jan 15 10:22:34 <rkirti> morning woglinde
Jan 15 10:25:36 <woglinde> hi rkirti
Jan 15 10:31:46 <filip> woglinde: I've just bugged you via e-mail
Jan 15 10:32:19 <woglinde> hm oh?
Jan 15 10:32:21 <woglinde> what about?
Jan 15 10:32:44 <woglinde> ah eabi
Jan 15 10:33:03 <filip> yup
Jan 15 10:33:27 <woglinde> ah hm softfloat
Jan 15 10:33:38 <woglinde> vs. hardlfoat it looks like
Jan 15 10:34:00 <filip> em? should I tell it to use softfloat with eabi? or not?
Jan 15 10:34:01 <woglinde> I will paste you my patched defconfig for simpad uclibc
Jan 15 10:34:12 <woglinde> aeh yes
Jan 15 10:34:21 <woglinde> no sa1100 device has hardfloat I know of
Jan 15 10:36:28 <filip> woglinde: jornada7xx certainly doesn't have one
Jan 15 10:41:45 <woglinde> jupp
Jan 15 10:44:13 <woglinde> filip -> http://pastebin.ca/1752231
Jan 15 10:44:28 <woglinde> filip and you have to enable eabi in the kernel
Jan 15 10:45:44 <filip> woglinde: yeah I know
Jan 15 10:46:01 <woglinde> okay :)
Jan 15 10:46:24 <woglinde> would be cool if journada works too
Jan 15 10:46:35 <filip> no reason why it wouldn't
Jan 15 10:46:44 <woglinde> jupp
Jan 15 10:46:58 <filip> CONFIG_ARM_OABI=y
Jan 15 10:46:59 <filip> # CONFIG_ARM_EABI is not set
Jan 15 10:47:02 <filip> this is ok?
Jan 15 10:47:14 <woglinde> hm
Jan 15 10:47:17 <woglinde> mom
Jan 15 10:47:54 <woglinde> args
Jan 15 10:47:56 <woglinde> wrong
Jan 15 10:47:57 <woglinde> file
Jan 15 10:47:59 <filip> ;)
Jan 15 10:48:55 <woglinde> http://pastebin.ca/1752233
Jan 15 10:51:19 <filip> woglinde: and this should go into recipes/uclibc/uclibc-0.9.30.1/uClibc.config?
Jan 15 10:51:43 <woglinde> journada
Jan 15 10:53:28 <filip> woglinde: uclibc-0.9.30.1/uClibc.machine.jornada7xx ?
Jan 15 10:53:41 <woglinde> no
Jan 15 10:53:47 <woglinde> uclibc-0.9.30.1/journada
Jan 15 10:54:02 <woglinde> or how machine is known in oe
Jan 15 10:54:03 <filip> uhm
Jan 15 10:54:23 <woglinde> jornada56x.conf  jornada6xx.conf  jornada7xx.conf
Jan 15 10:54:32 <woglinde> si it might bee jornada7xx
Jan 15 10:54:53 <filip> :)
Jan 15 10:55:27 <filip> woglinde: thanks for hints, I will try building it now
Jan 15 10:56:10 <woglinde> :)
Jan 15 10:56:21 <woglinde> check the config after do_patch
Jan 15 10:56:25 <woglinde> in uClibc dir
Jan 15 11:40:20 <jovox> If I want to remove wifi from my image. Is it the bitbake.conf that I should edit?
Jan 15 11:42:43 <jovox> I looked in the conf/distro/include/angstrom.inc and it looks like it's not enabled in there: DISTRO_FEATURES = "nfs smbfs alsa ext2 vfat usbgadget usbhost pci"
Jan 15 11:43:04 <woglinde> jovox hm
Jan 15 11:43:09 <woglinde> there was some wifi taks
Jan 15 11:43:12 <woglinde> args task
Jan 15 11:43:20 <woglinde> look into recipes/tasks
Jan 15 11:44:15 <jovox> task-base.bb has task-base-wifi
Jan 15 11:46:28 <jovox> ${@base_contains('COMBINED_FEATURES', 'wifi', 'task-base-wifi', '',d)}. I read that as "wifi" must be set to make it install it?
Jan 15 11:47:22 <hrw> morning
Jan 15 11:47:24 <jovox> So I thought that if it was in the DISTRO_FEATURES in angstrom.inc it would be but became a but surprised when I saw it wasn't in in there
Jan 15 11:52:18 <woglinde> hi ant
Jan 15 11:57:55 <ant_work> woglinde: hello
Jan 15 11:58:05 <ant_work> morning all
Jan 15 12:00:33 <hrw> florian: ping
Jan 15 12:01:57 <florian> hrw: pong
Jan 15 12:02:12 <jovox> woglinde, could wifi be enabled somewhere else?
Jan 15 12:02:34 <hrw> florian: who maintains gpe-calendar now?
Jan 15 12:07:54 <florian> hrw: Graham Cobb and Neal Walfield mostly
Jan 15 12:10:09 <hrw> thx
Jan 15 12:12:35 <woglinde> jovox hm you could try to run bitbake -g image name
Jan 15 12:12:41 <woglinde> and looh whats drag in wifi
Jan 15 12:12:58 <woglinde> jovox and its different whats get all compiled
Jan 15 12:12:59 <jovox> woglinde, thank you
Jan 15 12:13:03 <woglinde> and whats and ip in the image
Jan 15 12:13:11 <woglinde> ip = up
Jan 15 12:41:31 <pb___> hi all
Jan 15 12:44:51 <florian> hi pb___ 
Jan 15 12:45:44 <rkirti> good morning pb___
Jan 15 12:47:29 <JaMa|W> is message like this "ERROR: Error, lockfile path does not exist!: /home/shr/shr-unstable/tmp/work/all-oe-linux-gnueabi/navit-icons-0.1.0+svnr2871-r0/packages-split" somehow related to changed PACKAGE_ARCH?
Jan 15 12:48:05 <JaMa|W> happens for every pachage where PACKAGE_ARCH is changed, and is resolved if I remove all traces of old package with different arch from my buildhost
Jan 15 12:48:30 <JaMa|W> and navit-icons-0.1.0+svnr2871-r0 should be revision 1 navit-icons-0.1.0+svnr2871-r1 only do_package picks this wrong revision..
Jan 15 12:51:17 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * re5daf085b2 10openembedded.git/conf/distro/include/sane-srcrevs.inc: 
Jan 15 12:51:17 <CIA-1> sane-srcrevs: bump EFL a bit more
Jan 15 12:51:17 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Jan 15 13:06:06 <woglinde> hi pb
Jan 15 13:06:15 <pb___> hi woglinde 
Jan 15 13:16:27 * mckoan is coming across XCalibrateQueryExtension, XCalibrateFindDisplay and XextFindDisplay
Jan 15 13:46:23 <Crofton|work> mckoan, can you check patchwork again
Jan 15 13:46:30 <Crofton|work> and did you work out how to apply patches?
Jan 15 13:46:31 <th1> is there a description of "new style staging" anywhere?
Jan 15 13:53:59 <mckoan> Crofton|work: yep
Jan 15 13:54:14 <Crofton|work> great
Jan 15 13:54:54 <mckoan> Crofton|work: This email address is already in use. Please supply a different email address
Jan 15 13:55:21 <mckoan> Crofton|work: do you mean I should be able to re-register?
Jan 15 13:55:22 <Crofton|work> can you use a differenet address?
Jan 15 13:55:36 <Crofton|work> I don't think it uses it for anything important
Jan 15 13:55:46 <mckoan> Crofton|work: I'd prefer not, but if is the only way O-)
Jan 15 13:55:55 <Crofton|work> it would be easiest
Jan 15 13:56:01 <mckoan> Crofton|work: ok, thanks
Jan 15 13:56:03 <Crofton|work> I do not think it is used or expsoed anywhere
Jan 15 13:56:26 <mckoan> Crofton|work: Registration successful!
Jan 15 13:57:12 <Crofton|work> ok, yu should be able to changes patch states now
Jan 15 13:58:59 <mckoan> Crofton|work: than you :-D
Jan 15 14:12:14 <hrw> morning
Jan 15 14:12:39 <hrw> mckoan: how goes Calibration work?
Jan 15 14:16:18 <mckoan> hrw: is likely I am at the center of the eath now :-D
Jan 15 14:16:28 <mckoan> s/eath/earth
Jan 15 14:16:39 * mckoan digging
Jan 15 14:16:40 <hrw> ?
Jan 15 14:16:44 <hrw> ah
Jan 15 14:17:32 <mckoan> hrw: looks like XextFindDisplay() fails, I am figuring out why
Jan 15 14:20:11 <woglinde> hi mckoan
Jan 15 14:20:19 <mckoan> woglinde: hi
Jan 15 14:20:22 <th1> morning hrw
Jan 15 14:20:50 <th1> do you know if there is a description of what changed in staging and how the "new style" staging works? e.g. a list post or whatever
Jan 15 14:28:42 <woglinde> th1 hm
Jan 15 14:28:52 <woglinde> its mostly copy
Jan 15 14:29:05 <woglinde> from image -> staging dir
Jan 15 14:29:15 <woglinde> locally
Jan 15 14:29:22 <woglinde> than staging stuff get fixt
Jan 15 14:29:29 <woglinde> and is coppied to real stage
Jan 15 14:32:07 <mckoan> I'm lost, I'm looking for XextFindDisplay() in libXext-1.1.1 but isn't there
Jan 15 14:33:54 <woglinde> mckoan maybe its gone?
Jan 15 14:34:25 <mckoan> woglinde: uh, so I wonder how libXcalibrate could call it
Jan 15 14:34:29 <th1> woglinde, ok :)
Jan 15 14:34:40 <th1> I will read in the source then
Jan 15 14:34:53 <th1> it's just that I use pstage and I hope it doesn't screw up too much :)
Jan 15 14:34:59 <th1> already a bit fragile with that
Jan 15 14:36:16 <jovox> I'm still struggling with getting wifi support out of my image. I don't need it and another reason is that madwifi doesnt compile at all:  http://pastebin.com/m2b5c962c 
Jan 15 14:37:33 <jovox> woglinde, I tried the bitbake -g thing you talked about before to figure out why it's still included even though it's not inb my angstrom.inc. I was not able to find anything in there really that helped me.
Jan 15 14:38:37 <rkirti> morning kergoth
Jan 15 14:38:47 <kergoth> hey
Jan 15 14:44:48 <filip> can I determine whether an arm ELF file uses OABI or EABI?
Jan 15 14:45:34 <woglinde> filip hm only way I know
Jan 15 14:45:45 <woglinde> if its working on eabi kernel
Jan 15 14:45:56 <woglinde> without oabi support
Jan 15 14:45:56 <woglinde> its eabi
Jan 15 14:46:02 <woglinde> otherwise its oabi
Jan 15 14:46:15 <woglinde> filip hm but you try to use objdump
Jan 15 14:46:22 <woglinde> and look for bx instructions
Jan 15 14:46:43 <woglinde> if there are bx instructions the compiler messed things up
Jan 15 14:46:49 <woglinde> or linker
Jan 15 14:47:47 <mckoan> looks like XextFindDisplay() find any display
Jan 15 14:49:36 <jovox> Is there any way I can check if wifi is defined or not?
Jan 15 14:50:21 <filip> woglinde: so with EABI there should be no bx instructions?
Jan 15 14:51:10 <woglinde> on armv4 shouldnt be any  bx instructions inside the exec
Jan 15 14:51:21 <woglinde> it was only a hint
Jan 15 14:51:28 <woglinde> if stuff dont works
Jan 15 14:52:22 <hrw> simple way: "file binary"
Jan 15 14:52:57 <hrw> nope.. it worked ;(
Jan 15 14:53:44 <hrw> arm-angstrom-linux-gnueabi-objdump -p binary
Jan 15 14:53:48 <hrw> private flags = 5000002: [Version5 EABI] [has entry point]
Jan 15 14:53:57 <hrw> I do not have oabi binary to check
Jan 15 14:55:45 <hrw> private flags = 2: [APCS-32] [FPA float format] [has entry point]
Jan 15 14:55:47 <hrw> for oabi
Jan 15 14:56:03 <hrw> I used sharprom package as oabi example
Jan 15 14:58:30 <Laibsch> speaking of sharprom.  pb, khem collie for sharprom fails with thumb problems, too: http://tinderbox.openembedded.net/builds/52150/  Not sure why.
Jan 15 14:59:09 <hrw> giounix.c:185: `SSIZE_MAX' undeclared (first use in this function)
Jan 15 14:59:15 <hrw> this is not thumb related iirc
Jan 15 15:00:56 <woglinde> hra ah thanks
Jan 15 15:01:01 <woglinde> didnt know this
Jan 15 15:01:14 <hrw> woglinde: I just checked it ;)
Jan 15 15:01:48 <woglinde> hm could you make a wiki side in oe that would be cool
Jan 15 15:03:06 <Laibsch> hrw: right
Jan 15 15:03:18 <Laibsch> I fixed that error, probably gave the wrong URL to tinderbox
Jan 15 15:03:32 <Laibsch> After fixing that error it fails with a thumb-related error
Jan 15 15:03:39 <filip> hrw: thanks
Jan 15 15:09:08 <jovox> Can anyone just verify that I got this right: task-base.bb will only include the wifi stuff (like madwifi and wireless-tools) is the COMBINED_FEATURES has wifi.  COMBINED_FEATURES is "created" in conf/bitbake.conf.  wifi will only be included in COMBINED_FEATURES is in DISTRO_FEATURES which is defined in conf/distro/include/angstrom.inc (if angstrom is the distro I'm building ofcourse).
Jan 15 15:09:39 <CIA-1> 03Rolf Leggewie <oe-devel@rolf.leggewie.biz> 07org.openembedded.dev * r34e9959a46 10openembedded.git/recipes/irk/ (irk-belkin_0.11.bb irk-targus_0.11.0.bb): irk: move SRC_URI from ewi to openzaurus mirror. Partly closes #5295
Jan 15 15:09:50 <CIA-1> 03Rolf Leggewie <oe-devel@rolf.leggewie.biz> 07org.openembedded.dev * r2bdfa324e4 10openembedded.git/recipes/tmsnc/tmsnc_0.3.2.bb: tmsnc: fix SRC_URI
Jan 15 15:19:00 <hrw> Laibsch: irk? wow
Jan 15 15:19:27 <Laibsch> I noticed fetch failures on the sourcemirror
Jan 15 15:19:49 <Laibsch> I'm working on "bitbake -c fetchall world" to succeed
Jan 15 15:20:06 <Laibsch> or the equivalent since world would never start for me
Jan 15 15:20:53 <hrw> 16:20 hrw@home:dl_dir$ ls irk*
Jan 15 15:20:53 <hrw> irk-0.11.0.tgz  irk-0.11.0.tgz.md5  irk-current.tgz  irk-current.tgz.md5
Jan 15 15:21:32 <hrw> Laibsch: if you will hit missing sources then notify me. I have some files from beginning of my OE work
Jan 15 15:21:58 <filip> btw, is there a way to customize world (or maybe there is another target) for a specific distro?
Jan 15 15:22:21 <filip> I'd like to decide which packages are to be provided as ipks by this particular distro
Jan 15 15:22:40 <Laibsch> hrw: http://paste.debian.net/56761/ although I fixed one or two in that list already
Jan 15 15:23:14 <hrw> those files are missing for you?
Jan 15 15:23:18 <Laibsch> yes
Jan 15 15:23:45 <Laibsch> according to grep, sed and friends
Jan 15 15:26:52 <Laibsch> hrw: maybe it's easiest you make available via http for a brief time your whole folder
Jan 15 15:26:56 <Laibsch> even if via DSL
Jan 15 15:27:25 <hrw> Laibsch: I have 62 entries from your list
Jan 15 15:27:31 <Laibsch> nice
Jan 15 15:27:43 <Laibsch> can you do http?
Jan 15 15:27:48 <hrw> Laibsch: I can not provide my DL_DIR for public. it contains clients data too
Jan 15 15:27:52 <hrw> Laibsch: will check
Jan 15 15:27:53 <Laibsch> OK
Jan 15 15:28:01 <Laibsch> then let me see how many I've got
Jan 15 15:28:10 <Laibsch> I can pull from here via http
Jan 15 15:28:17 <Laibsch> I will give you an updated list later
Jan 15 15:28:30 <kergoth> we need to find a way to leverage witpa or whatever that was
Jan 15 15:28:38 <kergoth> I'm not sure what the best way of doing it is
Jan 15 15:29:01 <Laibsch> kergoth: this has become much of a problem now that we maintain an official OE mirror
Jan 15 15:29:13 <Laibsch> It's exactly for that mirror that I search these sources
Jan 15 15:29:29 <kergoth> I think itd be cool if it could automatically use witpa to locate an alternative source for you if upstream is a 404
Jan 15 15:29:30 <Laibsch> most of them will be very obscure and probably nobody is ever going to need them
Jan 15 15:29:38 <kergoth> actually, we could use urlllib/httplib to check if its a 404 before calling wget
Jan 15 15:29:42 <Laibsch> kergoth: yes, we talked about that
Jan 15 15:30:07 <Laibsch> somebody needs to do it
Jan 15 15:30:18 <Laibsch> I did work on a witpa native recipe at that time
Jan 15 15:30:25 <Laibsch> but didn't get it done
Jan 15 15:30:39 <Laibsch> I think you even said you may take a look at crafting one yourself
Jan 15 15:30:50 <Laibsch> but that never materialized ;-)
Jan 15 15:30:51 <kergoth> yeah.. but that todo list just keeps growing.. :)
Jan 15 15:30:58 <kergoth> it is starting to annoy me enough that it may  move up the list
Jan 15 15:31:09 <Laibsch> See, that is why I think we are doing fine with the complete source mirror
Jan 15 15:31:11 <hrw> how to check what reside on my inet port?
Jan 15 15:31:22 <Laibsch> kergoth: you have problems with missing sources?
Jan 15 15:31:29 <hrw> lighttpd says that something is on port 80 but nothing occupies it ;(
Jan 15 15:31:50 <filip> hrw: netstat -lptn | grep :80
Jan 15 15:32:00 <filip> hrw: maybe it's misreporting, try stracing it
Jan 15 15:32:02 <kergoth> Laibsch: not in mvl6, since they mirror everything, but when i poke at oe and poky recipes, sure, its always a problem
Jan 15 15:32:04 <Laibsch> kergoth: do you use the official OE mirror?  if you are not more than a half year behind you should have the OE mirror by default
Jan 15 15:32:21 <kergoth> we do now that i synced us with oe ;)
Jan 15 15:32:23 <hrw> filip: thx
Jan 15 15:32:26 <kergoth> but as of last week, no
Jan 15 15:32:36 <Laibsch> OK
Jan 15 15:32:38 <kergoth> :)
Jan 15 15:32:54 <Laibsch> The patch should be easy enough to cherry-pick
Jan 15 15:33:06 <Laibsch> Maybe poky wants to use that, too
Jan 15 15:33:24 <jovox> I think it's time for me to give this up soon :-/ Just grabbed a fresh version of oe and run 'bitbake console-image' and got: NameError: global name 'os' is not defined.  Is the "getting started" docs outdated?
Jan 15 15:33:39 <kergoth> jovox: sounds like you're using an old bitbake
Jan 15 15:33:40 <Laibsch> I consider the constant "source unfetchable" problem solved
Jan 15 15:33:45 <kergoth> jovox: make sure you're on 1.8.18
Jan 15 15:33:59 <Laibsch> jovox: I think you may need a newer bitbake version
Jan 15 15:33:59 <jovox> it's 1.8.12
Jan 15 15:34:07 <Laibsch> too old
Jan 15 15:34:09 <jovox> Ok
Jan 15 15:38:55 <jovox> That worked better
Jan 15 15:57:52 <hrw> did someone built uicmoc-native 3.3.5 lately?
Jan 15 16:02:05 <Laibsch> hrw: I think I at least tried
Jan 15 16:02:08 <Laibsch> check tinderbox
Jan 15 16:02:34 <Laibsch> I did
Jan 15 16:02:39 <Laibsch> but only earlier version
Jan 15 16:03:57 <Laibsch> Yay!
Jan 15 16:04:02 <Laibsch> scim finally built
Jan 15 16:05:18 <hrw> Laibsch: failed for you too
Jan 15 16:05:55 <Laibsch> hrw: you mean uicmoc-native?
Jan 15 16:06:10 <Laibsch> I think the older version built
Jan 15 16:06:20 <Laibsch> and I have no record of building the newer version
Jan 15 16:06:23 <Laibsch> at least not on tinderbox
Jan 15 16:06:46 <Laibsch> oh
Jan 15 16:06:55 <Laibsch> I was looking at uicmoc, not uicmoc3
Jan 15 16:07:10 <Laibsch> yes
Jan 15 16:07:12 <Laibsch> you are right
Jan 15 16:08:42 <filip> private flags = 5000002: [Version5 EABI] [has entry point]
Jan 15 16:08:49 <filip> I wonder if it will run
Jan 15 16:26:43 <CIA-1> 03Rolf Leggewie <oe-devel@rolf.leggewie.biz> 07org.openembedded.dev * r60c4cc003f 10openembedded.git/conf/checksums.ini: checksums.ini: update tmsnc and irk entries to go along with my last two commits
Jan 15 16:38:01 <woglinde> re pb
Jan 15 16:38:16 <woglinde> pb do you know how I can debug kernel network stack?
Jan 15 16:38:42 <kergoth> i think you're going to need to be more specific.
Jan 15 16:39:14 <woglinde> kergoth hm I trying to setup wlan briding
Jan 15 16:39:20 <woglinde> and somehow works
Jan 15 16:39:26 <woglinde> but only for interface
Jan 15 16:39:42 <kergoth> what do you mean by only for interface?
Jan 15 16:39:47 <woglinde> yeah
Jan 15 16:39:49 <woglinde> mom
Jan 15 16:40:20 <Laibsch> If I am on git branch A can I commit the changes in the working tree to branch B?
Jan 15 16:41:57 <kergoth> Laibsch: not directly.  if it lets you, you can just git checkout B and then commit
Jan 15 16:42:01 <kergoth> otherwise I'd suggest using git stash
Jan 15 16:42:08 <kergoth> git stash; git checkout B; git stash apply
Jan 15 16:42:13 <Laibsch> ok
Jan 15 16:42:15 <Laibsch> thanks
Jan 15 16:42:25 <kergoth> stash saves all your local changes, working copy & index both, and can restore them later
Jan 15 16:42:28 <kergoth> *really* handy at times
Jan 15 16:44:30 <woglinde> host 1 wlaniface1 <-> wlaniface bridgehost <-> bridgeiface <-> bridgehost wlaniface <-> wlaniface host2
Jan 15 16:44:54 <woglinde> the wlan iface which the bridge takes works fine
Jan 15 16:45:01 <woglinde> assume its host2
Jan 15 16:45:13 <woglinde> so packets from host2 goes to bridge and back
Jan 15 16:45:41 <woglinde> packets from host2 going to host1 and back works too
Jan 15 16:45:48 <woglinde> packets from bridge got host1 works
Jan 15 16:46:03 <woglinde> host1 sees the packets from bridge
Jan 15 16:46:08 <woglinde> and answers
Jan 15 16:46:31 <woglinde> but these packets never occurs on wlanifac on the bridgehost
Jan 15 16:46:41 <woglinde> its now clear?
Jan 15 16:47:14 <woglinde> so I want found out whats happening to this packets which not arrives
Jan 15 16:47:39 <kergoth> hmm
Jan 15 16:47:41 * kergoth thinks
Jan 15 16:49:54 <woglinde> is there a debug mode where I can see all packages?
Jan 15 16:50:24 <woglinde> dont know if my skills are good enough to interpret wlan monitor mode
Jan 15 16:51:14 <ynezz> tcpdump ?
Jan 15 16:51:36 <ynezz> or you think, they get lost in lower layer?
Jan 15 16:52:02 <woglinde> ynezz *sigh* without tcpdump I wouldnt know the packges from host1 to bridge will occur on the bridge wlan interface
Jan 15 16:52:11 <ynezz> ah, ok
Jan 15 16:52:13 <woglinde> args +not occur
Jan 15 16:53:46 <ynezz> do you have the links in between hosts on different channels?
Jan 15 16:54:13 <woglinde> ynezz jupp diffrent channels
Jan 15 16:54:18 <woglinde> and diffrent ad-hoc
Jan 15 16:54:33 <woglinde> ynezz I am puzzeld becaus host1 to host2 is working
Jan 15 16:54:39 <woglinde> host2 to bridge
Jan 15 16:55:00 <woglinde> but not the packages from host1 to bridge directly
Jan 15 16:56:20 <ynezz> maybe you can just enable debug mode in wifi drivers
Jan 15 16:56:41 <woglinde> ynezz sure
Jan 15 16:56:55 <ynezz> or put your own debug messages to see what's going in/out
Jan 15 16:57:19 <ynezz> if it isn't getting in the driver somehow than you've to debug air proto
Jan 15 16:57:28 <ynezz> wlan monitor mode :)
Jan 15 16:57:35 <woglinde> ynezz I aksed maybe there is standard way of debugging network monitors
Jan 15 16:57:45 <woglinde> ynezz yes I know this mode too
Jan 15 16:57:59 <woglinde> but I think its diffrent layer
Jan 15 16:58:30 <ynezz> I use separate host/laptop to do this
Jan 15 16:58:59 <ynezz> I wouldn't try to debug this on the hosts directly
Jan 15 16:59:40 <woglinde> hm you can clone wlan ifaces
Jan 15 16:59:50 <woglinde> and set them into monitor mode
Jan 15 17:00:52 <kergoth> I'd probably start by doing a tcpdump on each end, see if the packet's showing up at all
Jan 15 17:00:54 <kergoth> heh
Jan 15 17:01:01 <ynezz> they don't
Jan 15 17:01:10 <kergoth> man, I'm rusty on the network stuff, i need to brush up
Jan 15 17:01:44 <ynezz> it can be something on lower layer
Jan 15 17:01:53 <woglinde> kergoth I already used tcpdump to verify 
Jan 15 17:02:09 <woglinde> so I kown host1 send the packets
Jan 15 17:02:22 <woglinde> okay till later
Jan 15 17:02:27 <woglinde> my son wants to pla
Jan 15 17:02:27 <woglinde> y
Jan 15 17:04:05 <kergoth> heh, berlios was comprimised? I'm glad bitbake is in git now
Jan 15 17:21:02 <pb__> morning kergoth
Jan 15 17:21:07 <kergoth> hey pb__ 
Jan 15 17:21:09 * pb__ returns from the nursery
Jan 15 17:21:31 <kergoth> heh, fun
Jan 15 17:21:48 <pb__> yeah, an afternoon with ten zero-to-one-year-olds
Jan 15 17:22:14 <kergoth> worn out? :)
Jan 15 17:23:20 <florian> pb__: heh
Jan 15 17:24:14 * kergoth is experimenting with git-imap-send + gmail
Jan 15 17:24:36 * kergoth tries send-email or whatever instead
Jan 15 17:26:34 <woglinde> re
Jan 15 17:27:00 <kergoth> hrm.. why the heck can't send-email take patches from stdin?
Jan 15 17:29:34 <pb__> kergoth: well, luckily I didn't need to actually do much.  heh.
Jan 15 17:29:37 <Zygo> is there a way to tell OE to build something out of a local git repository, without making its own clone and tarballs out of it?
Jan 15 17:29:37 <kergoth> heh
Jan 15 17:30:01 <kergoth> Zygo: you'd have to bypass the whole fetch/unpack process
Jan 15 17:30:04 <pb__> basically just spent my time trying to keep out of the way of flying food, toys and suchlike.
Jan 15 17:30:09 <kergoth> Zygo: see srctree.bbclass
Jan 15 17:30:16 <kergoth> Zygo: and possibly gitver.bbclass, if you want that too
Jan 15 17:34:44 <woglinde> flying food
Jan 15 17:34:45 <woglinde> oha
Jan 15 17:34:57 <woglinde> pb my wife decided not to come to brussel
Jan 15 17:36:08 <pb__> woglinde: ah, fair enough
Jan 15 17:47:06 <pb__> I guess we should have a wiki page or something to record who is going to be there.
Jan 15 17:47:14 <kergoth> anyone recall what python version oe is requiring right now?  is it still 2.4?
Jan 15 17:47:27 <woglinde> pb jupp
Jan 15 17:47:38 <woglinde> no 2.6 for dev
Jan 15 17:47:42 <pb__> kergoth: I think it might be 2.5 nowadays
Jan 15 17:47:51 <pb__> or 2.6 if you use bitbake master
Jan 15 17:48:02 <kergoth> 2.6 doesn't sound right for dev, bitbake 1.8 doesn't require it
Jan 15 17:48:06 <woglinde> pb bitbake for dev is 2.6 too
Jan 15 17:48:11 <kergoth> huh?
Jan 15 17:48:13 <woglinde> hm
Jan 15 17:48:14 <pb__> woglinde: no, it isn't
Jan 15 17:48:17 <woglinde> okay
Jan 15 17:48:20 <woglinde> my fault
Jan 15 17:48:25 * kergoth was just wondering about 2.4 vs 2.5
Jan 15 17:48:34 <pb__> I still have 2.5.x on all my machines, and bitbake 1.8.18 with the .dev tree runs fine
Jan 15 17:48:44 <kergoth> mvl6 is still on 2.4, and we're using oe classes fine, so i guess we aren't really taking advantage of it
Jan 15 17:48:48 <kergoth> just added any() and all() functions to base.bbclass
Jan 15 17:49:37 <hrw> kergoth: we are at 2.4 iirc still
Jan 15 17:50:11 <kergoth> hmm, well, if its 2.4 I'd like to push the any/all functions, they're quite handy, and i use them in some places in stuff i'll be pushing eventually
Jan 15 17:50:31 <pb__> sounds reasonable
Jan 15 17:50:42 <kergoth> okay, will send to list then
Jan 15 17:51:06 <RP> kergoth: We have 2.4 support at the moment. I wouldn't be fussed about losing it though
Jan 15 17:51:38 * RP just got a dummy client/server class which doesn't actually fork working with bitbake master
Jan 15 17:52:10 <RP> bitbake 1.10 can therefore be master with the xmlrpc bits turned off using that code instead
Jan 15 17:55:01 <RP> heh, apart from a mild cpu burning problem :)
Jan 15 17:59:31 <pb__> heh
Jan 15 18:08:17 <Laibsch> BTW, what's the planned procedure on voting for the next TSC?  eV members only, people with RW, just everybody?  or is this as of now undecided?
Jan 15 18:09:34 <kergoth> isn't it a standard vote by eV members as documented in the policies?
Jan 15 18:09:58 <pb__> Previously it was e.V. members only, and I think that's a reasonable way to proceed.
Jan 15 18:10:07 <pb__> I don't think you can have a meaningful ballot of "just everybody", there's no way to police it.
Jan 15 18:10:50 <pb__> In theory you could do "everybody with R/W", but then you would effectively be setting up a second parallel voting structure alongside the e.V., which sounds like a waste of time.
Jan 15 18:11:26 <pb__> (plus, that would disenfranchise those e.V. members who don't happen to have r/w access, which would also not be a very good thing)
Jan 15 18:11:58 <kergoth> agreed.
Jan 15 18:15:52 <pb__> It might, possibly, be a good idea to tweak the e.V. voting procedures in light of what happened last time, but that's a separate issue.
Jan 15 18:16:12 * kergoth guesses he should probably read the procedures at some point
Jan 15 18:16:23 <pb__> heh
Jan 15 18:16:56 <kergoth> we should really think about breaking up base.bbclass at some point
Jan 15 18:21:43 <kergoth> erm
Jan 15 18:21:57 <kergoth> it amuses me that base.bbclass has an entry in the eventhandler to print a "task is complete" message
Jan 15 18:22:06 <kergoth> but it doesn't print it, because there is no task is complete, only success/failure
Jan 15 18:22:10 <kergoth> and nobody noticed :)
Jan 15 18:22:17 <kergoth> guess we can live without that one :)
Jan 15 18:22:22 <pb__> hah
Jan 15 18:22:23 <pb__> yeah
Jan 15 18:22:52 <kergoth> also, bb.event.getName is *disgusting*
Jan 15 18:23:08 <kergoth> isinstance(e, TaskSucceeded, TaskFailed) > string comparisons
Jan 15 18:23:12 <kergoth> heh
Jan 15 18:23:19 <kergoth> erm, forgot the extra parens
Jan 15 18:23:21 <kergoth> but you get the point
Jan 15 18:23:23 <Tartarus> heh
Jan 15 18:23:28 * kergoth adds to the list of cleanup tasks
Jan 15 18:23:38 <pb__> yeah, name.startswith("BuildStarted") is particularly distasteful
Jan 15 18:23:53 <kergoth> indeed
Jan 15 18:24:03 <pb__> I guess I can sort of live with testing for equality, but substrings?  ugh.
Jan 15 18:24:35 <kergoth> also: the Handled/NotHandled thing is a remnant, there's no good usecase for halting the chain of event handlers.. this isn't an interrupt handler :)  we should deprecate it, and remove all the explicit returns of those values from all event handlers in the metadata
Jan 15 18:24:43 * kergoth sighs, the list keeps growing and growing..
Jan 15 18:24:53 <hrw> and basically 'everybody with r/w' can apply for e.V. membership
Jan 15 18:25:01 <kergoth> yeah
Jan 15 18:39:41 <CIA-1> 03Ulf Samuelsson <ulf.samuelsson@atmel.com> 07org.openembedded.dev * rba82dd70f3 10openembedded.git/recipes/at91bootstrap/ (9 files in 9 dirs): (log message trimmed)
Jan 15 18:39:41 <CIA-1> From: Ulf Samuelsson <ulf.samuelsson@atmel.com>
Jan 15 18:39:41 <CIA-1> Add support for at91bootstrap-2.13.
Jan 15 18:39:41 <CIA-1> Fixes problem with stack, breaking all boards, compared to 2.13-rc[1-7]
Jan 15 18:39:41 <CIA-1> Updates kconfig to 2.6.32
Jan 15 18:39:42 <CIA-1> More options to save code on SRAM constrained SAM9260.
Jan 15 18:39:46 <CIA-1> Builds for the following at91 chips.
Jan 15 18:39:48 <CIA-1> 03Ulf Samuelsson <ulf.samuelsson@atmel.com> 07org.openembedded.dev * rf3569dca53 10openembedded.git/conf/checksums.ini: Add checksum for at91bootstrap-2.13
Jan 15 18:46:20 <CIA-1> 03Ulf Samuelsson <ulf.samuelsson@atmel.com> 07org.openembedded.dev * r48c47f275e 10openembedded.git/recipes/u-boot/u-boot_2009.08.bb: Make u-boot-2009.98 the preferred bootloader for sam9g45ek
Jan 15 18:49:16 * pb__ stabs fedex.com
Jan 15 18:49:29 <pb__> stupid browser compatibility check
Jan 15 18:54:00 <CIA-1> 03Ulf Samuelsson <ulf.samuelsson@atmel.com> 07org.openembedded.dev * r7ebc3015cb 10openembedded.git/recipes/linux/linux-2.6.32/ (4 files in 2 dirs): (log message trimmed)
Jan 15 18:54:00 <CIA-1> From: Ulf Samuelsson <ulf.samuelsson@atmel.com>
Jan 15 18:54:00 <CIA-1> Add Linux-2.6.32 recipe for AT91SAM9G45EK.
Jan 15 18:54:00 <CIA-1> Two patches are included.
Jan 15 18:54:00 <CIA-1> 1) Patch which will allow the NAND flash partitioning to be configurable
Jan 15 18:54:02 <CIA-1> 2) Patch which will fix reset for SAM9260, not needed for SAM9G45 though
Jan 15 18:54:06 <CIA-1> Signed-off-by: Ulf Samuelsson <ulf.samuelsson@atmel.com>
Jan 15 18:54:10 <CIA-1> 03Ulf Samuelsson <ulf.samuelsson@atmel.com> 07org.openembedded.dev * r6564d21fc6 10openembedded.git/recipes/linux/linux_2.6.32.bb: Add linux-2.6.32 recipe for sam9g45ek, missing from previous commit
Jan 15 19:08:29 <khem> pb__: fedex does not support FF 
Jan 15 19:08:31 <khem> gm all
Jan 15 19:09:57 <khem> about a year and half ago we has 5000 files to parse today its around 8000
Jan 15 19:10:03 <khem> s/has/had
Jan 15 19:17:55 <kergoth> khem: damn :)
Jan 15 19:18:49 <khem> We should start cutting crap out 
Jan 15 19:19:29 <khem> or may be bitbake should parse based on some info about arch/distro/machine 
Jan 15 19:19:35 <khem> oh well
Jan 15 19:19:42 <kergoth> need to do more profiling, i think
Jan 15 19:19:49 <khem> easier option is to buy a faster boz
Jan 15 19:19:51 <khem> box
Jan 15 19:19:53 <kergoth> hehe
Jan 15 19:20:07 <pb__> khem: yeah, indeed
Jan 15 19:20:26 <pb__> the fedex site seems to actually work perfectly well with FF, you just get this annoying popup saying that your browser is no good
Jan 15 19:20:35 <khem> heh
Jan 15 19:20:45 <pb__> anyway, all I needed to do on this occasion was order some supplies, so mission accomplished.
Jan 15 19:20:45 <khem> I will stop using fedex
Jan 15 19:20:55 <kergoth> erk, not all bluez4 recipes were converted to use bluez4.inc?  i think someone wants to make my life more difficult for no reason
Jan 15 19:20:57 <kergoth> hrmph
Jan 15 19:21:11 <khem> kergoth: this time its not me
Jan 15 19:21:29 * kergoth is refactoring the bluez crap to use pb's separate-libs.patch and bluez-apps recipe
Jan 15 19:21:33 <kergoth> heh :)
Jan 15 19:21:44 <pb__> kergoth: yeah, probably.  I seem to have a long line of people wanting to make my life more difficult for no obvious reason.
Jan 15 19:21:57 <pb__> seems only fair that the same should happen to everyone else :-}
Jan 15 19:22:06 <kergoth> such is life :)
Jan 15 19:22:11 <pb__> quite
Jan 15 19:22:37 <khem> pb__: all should make more conservative and complete changes or you have to change :)
Jan 15 19:22:41 <kergoth> and we really need that extendclass for versions, somehow
Jan 15 19:22:52 <kergoth> this is getting ridiculous with the recipe explosion
Jan 15 19:23:05 <pb__> yeah
Jan 15 19:23:16 <kergoth> would speed up the parse, too
Jan 15 19:23:16 <khem> hmmm cpio configure thinks that rmt can not be build for uclibc for some reason 
Jan 15 19:23:18 <kergoth> probably substantially
Jan 15 19:23:58 <pb__> I had some plan at one point to pay zecke to implement some kind of version wildcarding in bitbake, but that never happened due to reasons.
Jan 15 19:25:04 <khem> hmmm missing sgtty.h 
Jan 15 19:25:12 <kergoth> thoughts on eventually killing these bluez recipe variants (i.e. -cups-backend) in favor of subpackages + DISTRO_FEATURES?
Jan 15 19:26:16 <pb__> we have this problem at the moment where there are 2652 released versions of our main application, and approximately 8858 released versions of the filesystem image.  clearly it is silly to have a separate .bb file for each of them.
Jan 15 19:26:37 <kergoth> yow
Jan 15 19:26:54 <pb__> kergoth: if the cups backend is buildable separately then I would be happy to keep it as a separate package.
Jan 15 19:27:29 <kergoth> it just builds the bluez3 sources with --enable-cups, still has --enable-initscripts and crap, and I'm sure it rebuilds the libs and all
Jan 15 19:27:40 <kergoth> just to get a ${libdir}/cups/backend/bluetooth
Jan 15 19:27:42 <kergoth> this makes me sad
Jan 15 19:28:10 * kergoth shrugs, will look at it at some point in the future, apps-libs bits for now..
Jan 15 19:28:32 <pb__> yeah, that is a bit sad.  but forcing people to decide statically for their DISTRO whether they want the cups backend or not is also a little bit sad.  I wonder how hard it would be to refactor the source so that you could build the cups backend against staged headers/libs without recompiling the whole of the rest of bluez.
Jan 15 19:28:53 <pb__> if that were possible, I think that would be the ideal outcome.
Jan 15 19:29:07 <pb__> if that isn't feasible, yeah, the DISTRO_FEATURES thing would be better than what we have now.
Jan 15 19:29:36 <kergoth> well, itll be a separate package regardless, just a matter of deciding if you want to build cups or not when you're populating your feeds, but yeah, separated would be better yet
Jan 15 19:29:46 <CIA-1> 03Marcin Juszkiewicz <marcin@buglabs.net> 07org.openembedded.dev * r0c6053228d 10openembedded.git/conf/machine/bug.conf: bug: use full X.org
Jan 15 19:29:52 <CIA-1> 03Marcin Juszkiewicz <marcin@buglabs.net> 07org.openembedded.dev * r71e458d425 10openembedded.git/recipes/linux/linux-bug_2.6.27.2.bb: linux-bug: bumped SRCREV
Jan 15 19:30:01 <khem> USE flags are nice
Jan 15 19:31:37 * kergoth mutters under his breath about separating responsibilities and the fugliness of DEFAULT_PREFERENCE_angstrom in a recipe
Jan 15 19:31:39 <kergoth> :)
Jan 15 19:37:46 <khem> kergoth: I need to have a file not installed when building for uclibc in cpio
Jan 15 19:38:05 <khem> should I just override do_install
Jan 15 19:38:16 <khem> or is there some other elegant way
Jan 15 19:39:03 <khem> do_install_append
Jan 15 19:39:21 <kergoth> I'd just do_install_append and rm the thing :)
Jan 15 19:39:34 <khem> do_install_append_linux and do_install_append_linux-gnueabi
Jan 15 19:40:01 <khem> is libc also an override
Jan 15 19:40:20 <khem> can I say do_install_append_eglibc or do_install_append_uclibc
Jan 15 19:42:26 <Laibsch> hrw: wget finished.  thanks.
Jan 15 19:42:34 <hrw> long ;)
Jan 15 19:42:46 <Laibsch> I wasn't hand-holding it
Jan 15 19:42:52 <Laibsch> It probably finished a while ago
Jan 15 19:42:59 <hrw> Laibsch: removed forward rule
Jan 15 19:43:11 <Laibsch> ok
Jan 15 19:43:14 <khem> OVERRIDES .= ":libc-glibc"
Jan 15 19:43:15 <Laibsch> thank you for the sources
Jan 15 19:43:23 <hrw> np
Jan 15 19:43:26 <khem> and OVERRIDES .= ":libc-glibc"
Jan 15 19:43:28 <khem> cool
Jan 15 19:43:31 <khem> let me use them
Jan 15 19:44:08 <khem> but this will only work for distros which include distro/include/uclibc.inc and distro/include/gclibc.inc
Jan 15 19:44:53 <khem> which means only angstrom
Jan 15 19:44:55 <khem> :)
Jan 15 19:45:23 <khem> oh well
Jan 15 19:45:59 <CIA-1> 03Ulf Samuelsson <ulf.samuelsson@atmel.com> 07org.openembedded.dev * r9e6dafe9e3 10openembedded.git/conf/machine/ (at91sam9g45ek.conf include/AT91-LCD.inc include/AT91.inc): (log message trimmed)
Jan 15 19:45:59 <CIA-1> Add support for AT91SAM9G45EK (SAM9M10G45EK with AT91SAM9G45 chip)
Jan 15 19:45:59 <CIA-1> Split up into three files to allow easier maintenance of AT91 boards.
Jan 15 19:45:59 <CIA-1> machine/<board>.conf
Jan 15 19:45:59 <CIA-1> machine/include/AT91.inc
Jan 15 19:46:02 <CIA-1> machine/include/AT91-LCD.inc
Jan 15 19:46:04 <CIA-1> A machine with an LCD controller would normally include "AT91-LCD.inc"
Jan 15 19:49:59 <khem> kergoth: I using bitbake syntax file for vim 
Jan 15 19:50:28 <khem> kergoth: it errors out on function names which have say a variable
Jan 15 19:50:35 <khem> like pkg_postinst_${PN}
Jan 15 19:50:38 <kergoth> yep
Jan 15 19:50:42 <kergoth> never got around to fixing it
Jan 15 19:50:53 <khem> and everything after that is white and ref
Jan 15 19:50:55 <khem> red
Jan 15 19:50:55 <kergoth> someone online modified the syntax file i made with some improvements, google it, maybe that fixes it
Jan 15 19:51:13 <khem> thats one I use
Jan 15 19:51:14 <kergoth> otherwise you can learn the vim script syntax, or wait till i get around to it :P
Jan 15 19:51:17 <khem> rsalveti
Jan 15 19:51:24 <khem> has them
Jan 15 19:51:34 <khem> I tried to look into the regexp but it outgrew me
Jan 15 19:51:42 <kergoth> hehe
Jan 15 19:51:57 <khem> I know the syntax its just the laziness that prevails
Jan 15 19:53:11 <kergoth> i just haven't gotten sufficiently annoyed by it yet
Jan 15 19:53:47 <khem> bbPyFuncDef needs some love in bitbake.vim
Jan 15 19:56:07 <kergoth> hmm
Jan 15 19:56:19 <ynezz> is it known? http://pastebin.ca/1752737 it's a lates dev
Jan 15 19:56:28 <ynezz> s/lates/latest/
Jan 15 19:57:05 <khem> ynezz: check tinderbox
Jan 15 19:58:00 <khem> kergoth: it could be bbFunction too
Jan 15 19:58:03 <ynezz> maybe I'm blind, but how to search for exact package?
Jan 15 20:00:05 <ynezz> found it, but no entry, strange
Jan 15 20:07:20 <ynezz> ah, seems like problem with BBTHREADS, building gtk manually works
Jan 15 20:07:46 <khem> kergoth: http://khem.pastey.net/131500
Jan 15 20:08:06 <khem> gets rid of red background and flashing and what not :)
Jan 15 20:09:41 <CIA-1> 03Rolf Leggewie <oe-devel@rolf.leggewie.biz> 07org.openembedded.dev * rc9e9997c8b 10openembedded.git/recipes/monotone/ (7 files): monotone: drop obsolete and unfetchable recipes
Jan 15 20:12:25 <ynezz> what's sane for 2 core CPU? I've now PARALLEL_MAKE = "-j 4" and BB_NUMBER_THREADS = "10"
Jan 15 20:13:00 <pb__> mm, those libc-xxx overrides are teh suck.  if you need to treat uclibc separately, your best option is to examine HOST_SYS and see whether it has "uclibc" in it.
Jan 15 20:13:03 <Tartarus> -j CPU_N * 1.5, threads = CPU_N
Jan 15 20:13:39 <kergoth> khem: nice
Jan 15 20:13:53 <kergoth> khem: if it works, should go ahead and update the .vim in contrib
Jan 15 20:14:23 <khem> kergoth: it is better than what we have but its not best I say
Jan 15 20:14:23 <pb__> ynezz: it depends on your I/O to some extent, but BB_NUMBER_THREADS=10 is probably excessive for a 2-core system
Jan 15 20:14:44 <kergoth> khem: well, if it gets the job done.. :)
Jan 15 20:16:23 <ynezz> Tartarus, pb__: ok, thanks
Jan 15 20:18:11 <khem> kergoth: yes, I attended class on Good engineering practice and essentially they said sometimes best is not an option :)
Jan 15 20:18:42 <kergoth> hehe
Jan 15 20:19:37 <kergoth> hm, think I'm almost done with the bt crap.. man itll be nice to have this task off my plate
Jan 15 20:19:44 <kergoth> estimated 2 weeks, but its been longer than that..
Jan 15 20:19:52 <kergoth> i need to start keeping track of estimated vs actual on my tasks
Jan 15 20:20:37 <khem> pb__: I resorted to TARGET_OS override
Jan 15 20:21:24 <khem> infact I could have used if else but I trusted bitbake more :)
Jan 15 20:21:41 <khem> and it did not betray me
Jan 15 20:22:11 <khem> I built cpio on mips-uclibc mips-linux and arm-gnueabi worked in all cases
Jan 15 20:25:22 <Laibsch> cbrake: need your help
Jan 15 20:26:04 <khem> pb__: kergoth here is my cpio change http://paste.ubuntu.com/357231/
Jan 15 20:26:58 <cbrake> Laibsch: yes
Jan 15 20:27:10 <Laibsch> how do you restart git-daemon?
Jan 15 20:27:20 <Laibsch> Is there a trick needed?
Jan 15 20:27:32 <kergoth> khem: seems reasonable.  not particularly pretty, but may be the best we can do given our options..
Jan 15 20:27:33 <kergoth> heh
Jan 15 20:28:33 <khem> kergoth: I sometimes feel bitbake language is like german you can keep appending and still its one word :)
Jan 15 20:28:38 <kergoth> hehe
Jan 15 20:29:07 <khem> Donaudampfschiffahrtsgesellschaftskapitän
Jan 15 20:30:05 <cbrake> Laibsch: /etc/init.d/git-daemon -- have you tried that?
Jan 15 20:30:17 <cbrake> Laibsch: bahh, that is a binary
Jan 15 20:30:19 <cbrake> hmm
Jan 15 20:31:19 <pb__> khem: not very pretty, and I guess it will break for non linux, but it probably does do the job.
Jan 15 20:31:27 <Laibsch> cbrake: yes, of course
Jan 15 20:31:30 <cbrake> Laibsch: /etc/sv/git-daemon/run
Jan 15 20:31:37 <cbrake> that is how it gets started
Jan 15 20:31:59 <Laibsch> Is that standard or OE practice?
Jan 15 20:32:35 <pb__> khem: I think the best way to handle that is to put something along the lines of "case $TARGET_OS in; *-uclibc*) ;; *) ...;; esac" in your do_install method.
Jan 15 20:33:32 <khem> pb__: yeah I thought so too
Jan 15 20:33:36 <pb__> that way you don't end up having to do everything twice for regular linux and gnueabi (and for any future TARGET_OS variant that isn't uclibc)
Jan 15 20:33:46 <cbrake> Laibsch: its from the git-deamon-run package
Jan 15 20:33:48 <khem> right I think I will do that 
Jan 15 20:34:12 <cbrake> Laibsch: so its probably standard for debian
Jan 15 20:34:23 <Laibsch> cbrake: OK
Jan 15 20:34:39 <pb__> for the postinst, you can just do "if [ -f ${libexecdir}/rmt.${PN} ]; then .. fi"
Jan 15 20:34:52 <pb__> rather than having separate postinsts for the two cases
Jan 15 20:34:54 <pb__> bbiab
Jan 15 20:35:04 <Laibsch> cbrake: the thing is the process just does not seem to start
Jan 15 20:35:26 <cbrake> Laibsch: I'm trying to figure out what fires off /etc/sv stuff
Jan 15 20:36:12 <Laibsch> I would venture to guess that /etc/init.d should be OK
Jan 15 20:36:20 <Laibsch> I think there are leftover processes
Jan 15 20:36:27 <Laibsch> that hinder a proper restart
Jan 15 20:36:32 <Laibsch> I will hard kill them
Jan 15 20:36:42 <cbrake> Laibsch: all the git-upload-pack processes?
Jan 15 20:36:47 <Laibsch> yes
Jan 15 20:36:53 <Laibsch> for example
Jan 15 20:37:19 <Laibsch> I was wondering if they were responsible for the frequent "remote end hung up unexpectedly" errors
Jan 15 20:37:28 <Laibsch> git process stopped
Jan 15 20:37:39 <Laibsch> anything left will be annihilated ;-)
Jan 15 20:38:19 <Laibsch> There is definitely something wrong with those processes
Jan 15 20:38:27 <Laibsch> they don't respect a normal kill
Jan 15 20:39:31 <Laibsch> cbrake: have you restarted git?
Jan 15 20:39:44 <cbrake> Laibsch: /usr/share/doc/git-daemon-run/README.Debian has some useful info
Jan 15 20:39:48 <cbrake> Laibsch: no, I have not
Jan 15 20:39:55 <Laibsch> OK
Jan 15 20:40:05 <Laibsch> Seems it gets restarted automatically from somewhere
Jan 15 20:40:50 <cbrake> its still not running
Jan 15 20:41:08 <cbrake> /etc/init.d/git-daemon start seemed to work
Jan 15 20:42:03 <khem> pb__: http://paste.ubuntu.com/357235/
Jan 15 20:46:28 <khem> kergoth: there are no .vim on contrib
Jan 15 20:46:42 <kergoth> khem: its in bitbake's, iirc
Jan 15 20:47:01 <khem> oh I see
Jan 15 20:48:15 <kergoth> damnit bluez
Jan 15 20:48:18 * kergoth grumbles
Jan 15 20:48:41 <Laibsch> cbrake: I think it's back up
Jan 15 20:48:56 <Laibsch> All those strange upload-pack processes are gone, too
Jan 15 20:49:06 <kergoth> 4.53/4.56 are past a buildsystem rework, need to redo separate-libs, but its a bit easier said than done, because there's no BLUEZ_LIBS anymore, they're hard referencing the .la... time to reintroduce that
Jan 15 20:49:12 <Laibsch> let's see about connection failures
Jan 15 20:49:18 <kergoth> hrmph
Jan 15 20:50:38 <Laibsch> cbrake: It seems I can connect without the problems I used to see now
Jan 15 20:50:54 <khem> kergoth: I also have rsalveti's changes
Jan 15 20:51:01 <khem> which are not in git versio
Jan 15 20:51:02 <kergoth> good :)
Jan 15 20:51:06 <khem> should they will committed too
Jan 15 20:55:49 <Laibsch> cbrake: and only a few minutes into the process we already have the first git-upload-pack zombie process: 20268
Jan 15 20:56:00 <Laibsch> I'll look into backporting a newer git-core
Jan 15 20:56:29 <khem> kergoth: hmmm I dont have write access to bitbake repo can you commit it for me
Jan 15 21:01:45 <kergoth> khem: sure
Jan 15 21:03:56 <hansdampf> hi, are there any serverproblems at the moment??
Jan 15 21:04:22 <hansdampf> ahhh.... runs again
Jan 15 21:04:54 <hansdampf> git clone git://git.openembedded.org/openembedded.git openembedded 
Jan 15 21:04:54 <hansdampf> Initialized empty Git repository in /home/moritz/OE/openembedded/.git/
Jan 15 21:04:54 <hansdampf> git.openembedded.org[0: 140.211.169.165]: errno=Connection refused
Jan 15 21:04:54 <hansdampf> fatal: unable to connect a socket (Connection refused)
Jan 15 21:06:47 <khem>  git clone git://git.openembedded.org/openembedded
Jan 15 21:07:25 <hansdampf> yea its downloading now
Jan 15 21:07:32 <hansdampf> but before that i got kicked
Jan 15 21:07:44 <pb__> khem: right, like that.  obviously you want to lose those _appends now, but other than that it looks good.
Jan 15 21:08:07 <pb__> oh, and your postinst/preinst has a syntax error, you're missing the "then"
Jan 15 21:08:28 <khem> pb__: yes already removed those
Jan 15 21:09:02 <pb__> and, as a matter of principle, I would suggest you quote the arguments to "mv"
Jan 15 21:09:25 <pb__> obviously the existing do_install() is a bit slack in that regard, but you might as well fix it while you are there.
Jan 15 21:10:57 <khem> and tested this one http://paste.ubuntu.com/357250/
Jan 15 21:12:07 <khem> I missed one quote but fixed it here now
Jan 15 21:17:40 <pb__> right, very good
Jan 15 21:18:46 * khem thinks may be this is the last hurdle to get native-sdk building on uclibc/nptl
Jan 15 21:20:00 <pb__> excellent
Jan 15 21:20:09 <pb__> out of interest, why do you not get rmt for uclibc builds?
Jan 15 21:20:41 <khem> because rmt needs stty stuff from libc and uclibc does not have it
Jan 15 21:20:53 <woglinde> re
Jan 15 21:20:54 <pb__> righto
Jan 15 21:21:00 <khem> so configure checks for sgtty.h 
Jan 15 21:21:04 <pb__> I wonder whether even glibc users actually want rmt in their cpio packages.
Jan 15 21:21:12 <woglinde> khem uclibc 0.9.32
Jan 15 21:21:14 <khem> I have mentioned that in the commit message :)
Jan 15 21:21:22 <pb__> heh
Jan 15 21:21:30 <khem> woglinde: heh you are way too ahead
Jan 15 21:21:37 <woglinde> yes yes
Jan 15 21:21:49 <khem> woglinde: .31 will have nptl
Jan 15 21:22:04 <woglinde> khem will you do the update?
Jan 15 21:22:25 <khem> I will
Jan 15 21:22:31 <woglinde> thanks
Jan 15 21:22:37 <khem> but if you feel like doing it go ahead
Jan 15 21:22:41 <woglinde> okay
Jan 15 21:22:47 <woglinde> gnome-games fixed again
Jan 15 21:22:51 <khem> I have now qemu set for mips arm and x86
Jan 15 21:23:05 <woglinde> and it is working?
Jan 15 21:23:10 <khem> yep
Jan 15 21:23:25 <woglinde> cool
Jan 15 21:23:28 <khem> one day I will get ppc also working
Jan 15 21:23:42 <khem> and I use qemu from my ubuntu box
Jan 15 21:23:51 <woglinde> jo ph5
Jan 15 21:24:02 <pH5> hej woglinde
Jan 15 21:24:03 <khem> btw. arm is still using 2.6.26-rp kernel
Jan 15 21:24:11 <khem> it should be updated to something newer 
Jan 15 21:24:22 <woglinde> qemu?
Jan 15 21:24:28 <woglinde> hm
Jan 15 21:24:29 <khem> qemuarm yes
Jan 15 21:24:35 <woglinde> update it
Jan 15 21:24:42 <woglinde> you have my +1
Jan 15 21:24:48 <khem> I havent tested 2.6.31 on arm yet
Jan 15 21:24:56 <khem> it worked fine for mips and x86
Jan 15 21:25:35 <khem> I plan to add mipselqemu and powerpcqemu someday
Jan 15 21:25:40 <khem> first one should be easy
Jan 15 21:27:02 <woglinde> okay
Jan 15 21:30:51 <filip> damn
Jan 15 21:30:54 <filip> NOTE: Running task 258 of 262 (ID: 8, /home/filip.zyzniewski/pda/oe/openembedded/recipes/nspr/nspr-native_4.8.2.bb, do_populate_staging)
Jan 15 21:30:58 <filip> cp: cannot stat `/home/filip.zyzniewski/pda/oe/build_dir/tmp/work/i686-linux/nspr-native-4.8.2-r0/sysroot-destdir//home/filip.zyzniewski/pda/oe/build_dir/tmp/*': No such file or directory
Jan 15 21:31:02 <filip> what is this thing
Jan 15 21:31:25 <woglinde> re ant
Jan 15 21:31:29 <CIA-1> 03Henning Heinold <heinold@inf.fu-berlin.de> 07org.openembedded.dev * re53ccdb7a7 10openembedded.git/recipes/gnome/gnome-games_2.24.0.bb: gnome-games: add virtual/libsdl as dependency and bump PR
Jan 15 21:31:32 <woglinde> so gnome-games fixed again
Jan 15 21:31:49 <ant__> hey woglinde . good
Jan 15 21:32:15 <woglinde> so what to do next
Jan 15 21:32:19 <woglinde> hm crda upload
Jan 15 21:32:23 <woglinde> for lenny
Jan 15 21:32:26 <khem>  native-sdk-image for uclibc/nptl builds 
Jan 15 21:32:32 <khem> I am glad
Jan 15 21:32:37 <woglinde> khem hehe
Jan 15 21:33:17 <ant__> khem, woglinde: did you test any minimal-uclibc image recently?
Jan 15 21:33:32 <ant__> should I fire off a build for armv5te?
Jan 15 21:33:32 <woglinde> no
Jan 15 21:33:45 <hansdampf> sudo bitbake console-image
Jan 15 21:33:45 <hansdampf> /usr/lib/pymodules/python2.6/bb/COW.py:29: DeprecationWarning: the sets module is deprecated
Jan 15 21:33:45 <hansdampf>   import types, sets
Jan 15 21:33:45 <hansdampf> ERROR: Please set the 'PERSISTENT_DIR' or 'CACHE' variable.
Jan 15 21:33:52 <woglinde> I am mostly testing angstroem/uclibc/eglibc
Jan 15 21:33:56 <woglinde> or micro uclibc
Jan 15 21:34:00 <hansdampf> any suggestions? Cant find anything to fix on the web
Jan 15 21:34:01 <woglinde> for more I dont have tome
Jan 15 21:34:03 <woglinde> args time
Jan 15 21:34:16 <ant__> Angstrom 'just works' ;)
Jan 15 21:34:31 <woglinde> hansdampf hm never had this error with python 2.6
Jan 15 21:34:32 <ant__> I could invest a bit of time in other distros (overnight ;)
Jan 15 21:34:32 <hansdampf> nol it doesnt ;)
Jan 15 21:34:42 <woglinde> and I am using bitbake from git
Jan 15 21:34:59 <hansdampf> i'm using the one from the ubuntu repositories
Jan 15 21:35:09 <ant__> woglinde: which I suggest to everybody
Jan 15 21:35:20 <ant__> is much faster in parsing
Jan 15 21:35:30 <woglinde> hansdampf bitbake?
Jan 15 21:35:38 <woglinde> dont do thise
Jan 15 21:35:44 <ant__> he
Jan 15 21:35:56 <hansdampf> so u suggest to compile m y own?
Jan 15 21:35:56 <woglinde> they packages mostly are far behind
Jan 15 21:36:02 <hansdampf> okee
Jan 15 21:36:07 <woglinde> bitbake dont need to compile
Jan 15 21:36:10 <woglinde> is python
Jan 15 21:36:12 <hansdampf> ahh
Jan 15 21:36:15 <hansdampf> python script
Jan 15 21:36:16 <hansdampf> i see
Jan 15 21:36:49 <hansdampf> bitbake_1.8.12-1build1_all.deb
Jan 15 21:36:52 <hansdampf> whats actual
Jan 15 21:37:52 <ant__> go straight for 1.10
Jan 15 21:38:11 <ant__> or at least 1.8.18
Jan 15 21:38:58 <woglinde> for dev
Jan 15 21:39:13 <ant__> ah, yes
Jan 15 21:39:13 <woglinde> stable you need bitbake from oe stable branch
Jan 15 21:40:05 <hansdampf> bitbake_1.8.12-1build1_all.deb is from stable branch
Jan 15 21:40:25 <hansdampf> or isnt it...
Jan 15 21:40:26 <hansdampf> nah
Jan 15 21:40:28 <hansdampf> bullshit
Jan 15 21:42:49 <woglinde> no bitbake_1.8.12 seems to be from berlios
Jan 15 21:43:04 <woglinde> but bitbake is now maintained in oe git repos
Jan 15 21:44:36 <hansdampf> http://en.wikipedia.org/wiki/Bitbake
Jan 15 21:44:42 <hansdampf> so the wiki article is wrong?
Jan 15 21:45:14 <hrw> every wiki lies
Jan 15 21:45:33 <woglinde> he now you can edit it
Jan 15 21:45:39 <woglinde> or
Jan 15 21:45:46 <woglinde> let it delete
Jan 15 21:45:52 <woglinde> because its not relevant
Jan 15 21:45:54 <woglinde> hahahahaaaa
Jan 15 21:45:57 <hansdampf> ;)
Jan 15 21:46:04 <hansdampf> q
Jan 15 21:46:11 <hansdampf> where do i get the recources?
Jan 15 21:46:11 <hansdampf> http://developer.berlios.de/projects/bitbake/
Jan 15 21:46:20 <woglinde> no
Jan 15 21:46:28 <woglinde> ah sure
Jan 15 21:46:33 <woglinde> tars you can get there
Jan 15 21:46:43 <woglinde> or you checkt out with tag from oe repos
Jan 15 21:47:03 <GNUtoo|oeee> mmm what is wrong? that it's derived from portage?
Jan 15 21:47:33 <woglinde> git://git.openembedded.net/bitbake
Jan 15 21:47:39 <hrw> bye
Jan 15 21:49:35 <hansdampf> what do i have to do with the setup.py ?
Jan 15 21:49:53 <woglinde> nothing?
Jan 15 21:50:05 <hansdampf> usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
Jan 15 21:50:05 <hansdampf>    or: setup.py --help [cmd1 cmd2 ...]
Jan 15 21:50:05 <hansdampf>    or: setup.py --help-commands
Jan 15 21:50:05 <hansdampf>    or: setup.py cmd --help
Jan 15 21:50:05 <hansdampf> error: no commands supplied
Jan 15 21:50:14 <woglinde> check it out
Jan 15 21:50:21 <hansdampf> yea
Jan 15 21:50:21 <woglinde> point our BBPATH there
Jan 15 21:50:21 <hansdampf> i did
Jan 15 21:50:25 <woglinde> thats it
Jan 15 21:50:41 <hansdampf> so why is there a setup.py ?
Jan 15 21:51:03 <woglinde> path is enough
Jan 15 21:51:06 <woglinde> dont know
Jan 15 21:51:10 <woglinde> didnt test it
Jan 15 21:51:19 <hansdampf> k thx
Jan 15 21:51:36 <woglinde> but you probaly want master
Jan 15 21:51:44 <hansdampf> master?
Jan 15 21:51:44 <woglinde> checkout a localbranch with tag
Jan 15 21:51:56 <hansdampf> master branch?
Jan 15 22:04:27 * kergoth stabs bluez
Jan 15 22:05:05 <woglinde> kergoth *g*
Jan 15 22:05:18 * kergoth has spent half the day trying to clean up this pile of recipes
Jan 15 22:06:21 <kergoth> pb__: i think i may have a bluez 4.56 that uses pkg-config to check for an existing libbluetooth in the search paths which is the same version as this, and if it doesn't find it, automatically builds the internal one, otherwise doesn'td
Jan 15 22:06:23 <kergoth> s/d$//
Jan 15 22:06:46 * kergoth grumbles
Jan 15 22:06:55 <pb__> kergoth: oh, very good.
Jan 15 22:07:40 <kergoth> now to sort out every other version...
Jan 15 22:08:44 <woglinde_> args
Jan 15 22:09:17 <woglinde_> why I cannt clone ubuntus packages repos
Jan 15 22:09:19 <woglinde_> this suckz
Jan 15 22:12:33 <Laibsch> hansdampf: Easiest way is http://blog.leggewie.org/?p=39
Jan 15 22:12:58 <Laibsch> OE environment in minutes
Jan 15 22:12:59 <hansdampf> hmmm
Jan 15 22:13:06 <hansdampf> sounds nice
Jan 15 22:13:26 <GNUtoo|oeee> lol wow
Jan 15 22:14:38 <Laibsch> woglinde_: thanks.  there is an open ticket in the tracker about gnome-games.  Can you take a look if there is anything left in there we may want and then close it?
Jan 15 22:14:53 <Laibsch> #4607
Jan 15 22:15:11 <woglinde_> Laibsch yes I know let it close by this lovecroft guy
Jan 15 22:15:26 <Laibsch> why depend on him?
Jan 15 22:15:35 <woglinde_> didnt he report it?
Jan 15 22:15:40 <Laibsch> so?
Jan 15 22:15:43 <Laibsch> he reports
Jan 15 22:15:45 <Laibsch> we fix
Jan 15 22:15:47 <Laibsch> we close
Jan 15 22:15:51 <ant__> Laibsch: hi, have you build minimal-uclibc recently?
Jan 15 22:15:53 <woglinde_> let him test
Jan 15 22:15:57 <ant__> *built
Jan 15 22:15:59 <woglinde_> so he is glad
Jan 15 22:16:02 <Laibsch> users don't close tickets, at least of them don't
Jan 15 22:16:07 <Laibsch> sure
Jan 15 22:16:17 <Laibsch> Set it to NEEDSINFO in the meantime
Jan 15 22:16:27 <Laibsch> that status is exactly for this kind of situation
Jan 15 22:16:52 <Laibsch> ant__: no, I never bother with libc things and just take what's given to me
Jan 15 22:17:19 <ant__> ok, I'll try tonite
Jan 15 22:17:34 <ant__> btw, there are some minor issues wrt splash
Jan 15 22:17:47 <GNUtoo|oeee> yes I saw...
Jan 15 22:17:53 <GNUtoo|oeee> on the ml and on my devicce
Jan 15 22:18:10 <GNUtoo|oeee> it complained because it couldn't find the splash all over the boot proocedure
Jan 15 22:19:09 <Laibsch> ERROR: QA Issue with recode: No GNU_HASH in the elf binary: '/data/oe/laibsch/tmp/minimal/org.openembedded.dev/work/armv5te-oe-linux-gnueabi/recode-3.6-r1/packages-split/recode/usr/lib/librecode.so.0.0.0'
Jan 15 22:19:18 <Laibsch> do these kinds of errors normally fail a build?
Jan 15 22:19:37 <Laibsch> or did I set something somewhere to fail on QA errors?
Jan 15 22:19:39 <ant__> Laibsch: I caught this: http://fr.pastebin.ca/1752905
Jan 15 22:20:11 <Laibsch> yes, I'm aware of it
Jan 15 22:20:12 <ant__> Laibsch: you descovered the bug in a seldom-built recipe, probably
Jan 15 22:20:19 <Laibsch> it's nothing major, though
Jan 15 22:20:31 <Laibsch> it gets built but I don't assume it ends up in the image
Jan 15 22:20:39 <ant__> we had lot of GNU_HASH fixes last summer
Jan 15 22:20:51 <Laibsch> not for recode apparently
Jan 15 22:21:00 <ant__> immediately after the QA was made fatal iirc
Jan 15 22:21:39 <GNUtoo|oeee> GNU_HASH now fails
Jan 15 22:21:59 <woglinde_> GNU_HASH should be fixed
Jan 15 22:22:04 <woglinde_> fix is mostly easy
Jan 15 22:26:00 <GNUtoo|oeee> yes depends
Jan 15 22:26:11 <GNUtoo|oeee> sometimes you have to hack arround
Jan 15 22:26:18 <GNUtoo|oeee> the build system
Jan 15 22:26:56 <Laibsch> woglinde_, GNUtoo|oeee: can you guys please take a look at the recode qa problem then?
Jan 15 22:27:08 <Laibsch> It prevents me from building and verifiying other stuff
Jan 15 22:27:33 <Laibsch> Can I use insane.bbclass and still continue on QA errors?
Jan 15 22:27:40 <woglinde_> laibsch open qgit
Jan 15 22:27:44 <Laibsch> I think that used to be possible with a configure switch
Jan 15 22:27:48 <woglinde_> search for GNU_HASH
Jan 15 22:27:56 <woglinde_> and you will see easy commits
Jan 15 22:28:39 <woglinde_> mostly
Jan 15 22:28:41 <woglinde_> TARGET_CC_ARCH += "${LDFLAGS}"
Jan 15 22:28:42 <woglinde_> works
Jan 15 22:28:57 <CIA-1> 03Christian Rüb <christian.rueb@gmx.net> 07org.openembedded.dev * r25825354ff 10openembedded.git/recipes/wpa-supplicant/ (5 files in 2 dirs): (log message trimmed)
Jan 15 22:28:57 <CIA-1> wpa-gui: Add version 0.6.9
Jan 15 22:28:57 <CIA-1> * build Qt4 version of wpa-gui
Jan 15 22:28:57 <CIA-1> * patch to compile with Qt4 with and without session manager
Jan 15 22:28:57 <CIA-1> * patch to use librsvg not inkscape
Jan 15 22:28:59 <CIA-1> * include stylesheet for SHR distribution
Jan 15 22:29:03 <CIA-1> Signed-off-by: Christian Rüb <christian.rueb@gmx.net>
Jan 15 22:29:09 <CIA-1> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r73ee7c4e18 10openembedded.git/recipes/tasks/task-shr-feed.bb: 
Jan 15 22:29:09 <CIA-1> task-shr-feed: add wpa-gui
Jan 15 22:29:10 <CIA-1> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Jan 15 22:30:19 <Laibsch> woglinde_: http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=667b7cb389a4cd8677fe5272f16c0d31bd77a4da may be easy for you
Jan 15 22:30:29 <Laibsch> It's nothing in MY comfort zone
Jan 15 22:31:13 <khem> Laibsch: its just adding ${CFLAGS} ${LDFLAGS} in there
Jan 15 22:31:22 <Laibsch> OK
Jan 15 22:31:29 <Laibsch> I guess I can do that, then ;-)
Jan 15 22:32:29 <Laibsch> woglinde_: btw, gnome-games still fails here
Jan 15 22:32:32 <Laibsch> see tinderbox
Jan 15 22:34:14 <woglinde_> let see
Jan 15 22:35:20 <woglinde_> thats somethin diffrent
Jan 15 22:35:29 <woglinde_> maybee you mixed up something
Jan 15 22:35:31 <woglinde_> make clean
Jan 15 22:36:10 <woglinde_> bitbake -c clean gnome-games
**** BEGIN LOGGING AT Fri Jan 15 22:39:35 2010
Jan 15 22:41:04 <khem> woglinde_: 
Jan 15 22:41:05 <khem> do you have a uclibc 0.9.28 build lying around locally ?
Jan 15 22:41:05 <khem> or 0.9.30.x
Jan 15 22:44:41 <Laibsch> if GNU_HASH is so easy to fix then it's not time wisely spent for me
Jan 15 22:44:41 <Laibsch> Because it's not easy to fix for me
Jan 15 22:45:01 <Laibsch> Somebody else please have a look at recode
**** BEGIN LOGGING AT Fri Jan 15 23:09:17 2010
Jan 15 23:15:56 <khem> thats why I asked if you have build trees lying around
Jan 15 23:16:11 <khem> grep -r "\TARGET_CC_ARCH.*\LDFLAGS" * |wc
Jan 15 23:16:11 <khem> 63
Jan 15 23:16:11 <khem> so far we have that many 
Jan 15 23:18:10 * RP agrees with kergoth's comments on event handlers :/
Jan 15 23:18:10 <RP> pb__: You say the event name startswith is ugly - what do you do instead?
Jan 15 23:21:42 <woglinde> khem???
Jan 15 23:21:47 <woglinde> khem but seems I didnt yet check in a build fix
Jan 15 23:22:21 <woglinde> hms
Jan 15 23:22:21 <woglinde> hm whats going on here
Jan 15 23:22:22 <woglinde> freenode
Jan 15 23:23:34 <woglinde> back in some seconds
Jan 15 23:59:16 <CIA-55> 03Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * r2de03b509f 10openembedded.git/recipes/recode/recode_3.6.bb: recode: GNU_HASH QA error fix
Jan 16 00:19:55 <CIA-55> 03Rolf Leggewie <oe-devel@rolf.leggewie.biz> 07org.openembedded.dev * r974954f5e2 10openembedded.git/recipes/gtk-webcore/ (10 files in 3 dirs): midori: move some old and obsolete recipes to obsolete directory
Jan 16 00:20:16 <Laibsch> hm
Jan 16 00:20:23 <Laibsch> old and unfetchable, of course
Jan 16 00:20:27 <Laibsch> but anyway
Jan 16 00:20:29 <Laibsch> ;-)
Jan 16 00:20:32 <Laibsch> good night
Jan 16 00:34:00 <woglinde> re
Jan 16 00:34:04 <woglinde> ~ping khem
Jan 16 00:34:06 <ibot> pong khem
Jan 16 00:34:15 <khem> woglinde: yes
Jan 16 00:34:25 <woglinde> lib was there
Jan 16 00:34:35 <khem> woglinde: cool thx
Jan 16 00:34:40 <woglinde> hm
Jan 16 00:34:42 <khem> was it .28 or .30
Jan 16 00:34:47 <woglinde> 30.1
Jan 16 00:34:51 <woglinde> as usal
Jan 16 00:34:53 <khem> ok 
Jan 16 00:34:57 <woglinde> I dont test older stuff
Jan 16 00:35:03 <woglinde> hm
Jan 16 00:35:09 <khem> I will inspect the older ones 
Jan 16 00:35:14 <woglinde> I have one patch in the que
Jan 16 00:35:18 <woglinde> for install
Jan 16 00:35:25 <khem> I need to move the nonshared.a files to -dev package from -static
Jan 16 00:35:33 <khem> otherwise native linking wont work
Jan 16 00:35:41 <woglinde> hm hm
Jan 16 00:36:05 <woglinde> than we dont need a static package at all?
Jan 16 00:36:58 <khem> no you still need it
Jan 16 00:37:09 <khem> for normal fully blown .a
Jan 16 00:37:20 <khem> these files are necessary to link
Jan 16 00:37:41 <woglinde> hm right
Jan 16 00:37:43 <woglinde> I remeber
Jan 16 00:37:57 <khem> they are like 3kb in size
Jan 16 00:43:38 <CIA-55> 03Thomas Zimmermann <ml@vdm-design.de> 07org.openembedded.dev * r5cf674abee 10openembedded.git/ (conf/checksums.ini recipes/vagalume/vagalume_0.8.2.bb): 
Jan 16 00:43:38 <CIA-55> vagalume: update to version 0.8.2
Jan 16 00:43:38 <CIA-55> * depends now on gst-plugin-gconfelements
Jan 16 00:43:38 <CIA-55> * recommends hicolor-icon-theme to show the icons
Jan 16 00:43:40 <CIA-55> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Jan 16 00:43:49 <CIA-55> 03Thomas Zimmermann <zimmermann@vdm-design.de> 07org.openembedded.dev * re519704f95 10openembedded.git/recipes/matchbox2/matchbox-panel-2_svn.bb: 
Jan 16 00:43:49 <CIA-55> matchbox-panel-2: add -Wno-error to TARGET_CFLAGS to build with gcc 4.4
Jan 16 00:43:49 <CIA-55> Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
Jan 16 00:43:51 <CIA-55> 03Thomas Zimmermann <zimmermann@vdm-design.de> 07org.openembedded.dev * r211d149374 10openembedded.git/recipes/efl1/libefso_svn.bb: libefso: add efreed dependency
Jan 16 00:45:49 <woglinde> khem hm
Jan 16 00:46:02 <woglinde> for my install fix patch
Jan 16 00:46:12 <woglinde> we need to do RUNTIME_PREFIX=${prefix}/ for tools
Jan 16 00:47:13 <woglinde> good you quick test
Jan 16 00:47:17 <woglinde> for some older
Jan 16 00:47:21 <woglinde> if 
Jan 16 00:47:22 <woglinde>   oe_runmake STRIPTOOL=true PREFIX=${D} DEVEL_PREFIX=${prefix}/ RUNTIME_PREFIX=/ \
Jan 16 00:47:23 <woglinde>                 install_utils
Jan 16 00:47:29 <woglinde> args
Jan 16 00:47:43 <woglinde> oe_runmake STRIPTOOL=true PREFIX=${D} DEVEL_PREFIX=${prefix}/  RUNTIME_PREFIX=${prefix}/ 
Jan 16 00:47:47 <woglinde> works?
Jan 16 01:03:37 <woglinde> re pb
Jan 16 01:42:53 <CIA-55> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r8de9ba3d37 10openembedded.git/recipes/xserver-kdrive-common/xserver-nodm-init.bb: 
Jan 16 01:42:53 <CIA-55> xserver-nodm-init: add procps directly to RDEPENDS as procps is pulled usually only by task_cli_tools_debug and busybox version doesn't support 'ps -e x'
Jan 16 01:42:53 <CIA-55> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Jan 16 01:52:12 <CIA-55> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * rb89042296b 10openembedded.git/recipes/xserver-kdrive-common/xserver-nodm-init.bb: 
Jan 16 01:52:12 <CIA-55> xserver-nodm-init: add procps directly to RDEPENDS as procps is pulled usually only by task_cli_tools_debug and busybox version doesn't support 'ps -e x'
Jan 16 01:52:12 <CIA-55> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Jan 16 02:03:13 <CIA-55> 03Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * reec66cdff9 10openembedded.git/recipes/cpio/cpio_2.5.bb: 
Jan 16 02:03:13 <CIA-55> cpio: Dont munge rmt during do_install on uclibc.
Jan 16 02:03:13 <CIA-55> * cpio configure checks for sgtty.h in order to
Jan 16 02:03:13 <CIA-55> enable rmt to build as part of cpio package but
Jan 16 02:03:13 <CIA-55> this header is not available on uclibc so we
Jan 16 02:03:13 <CIA-55> have to adapt do_install accordingly.
Jan 16 02:03:16 <CIA-55> Signed-off-by: Khem Raj <raj.khem@gmail.com>
Jan 16 02:03:20 <CIA-55> 03Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * r17fe732b37 10openembedded.git/recipes/uclibc/uclibc.inc: 
Jan 16 02:03:23 <CIA-55> uclibc: Package uclibc_nonshared.a into ulibc-dev.
Jan 16 02:03:25 <CIA-55> * uclibc_noshared.a and libpthread_nonshared.a are
Jan 16 02:03:27 <CIA-55> right now packaged into uclibc-static which does
Jan 16 02:03:29 <CIA-55> not get installed along with uclibc-dev. These libraries
Jan 16 02:03:31 <CIA-55> are required on target for native SDK to work.
Jan 16 02:03:33 <CIA-55> Signed-off-by: Khem Raj <raj.khem@gmail.com>
Jan 16 02:04:14 <woglinde> khem wouldnt it be easier to make depend on static uclibc package?
**** ENDING LOGGING AT Sat Jan 16 02:59:56 2010