**** BEGIN LOGGING AT Sat Nov 21 02:59:57 2009
Nov 21 03:04:45 <darkstar62> has anyone seen random issues with gzip and tar erroring out (gzip: stdout: Broken pipe especially) during build?
Nov 21 03:06:51 <kergoth> yep
Nov 21 03:07:01 <kergoth> i assume your'e on stable or something?
Nov 21 03:07:06 <darkstar62> stable/2009, yeah
Nov 21 03:07:15 <kergoth> check .dev for changes to base.bbclass with regard to subprocess
Nov 21 03:07:21 <kergoth> there was a fix for subprocess sigpipe issues
Nov 21 03:07:30 <kergoth> git log --grep= .. :)
Nov 21 03:07:42 <darkstar62> ah, cool, I'll take a look
Nov 21 03:08:04 * kergoth had to cherry pick that into mvl6
Nov 21 03:11:48 <darkstar62> kergoth: base.bbclass: Remove redundant import of subprocess and signal.
Nov 21 03:11:49 <darkstar62> that the one?
Nov 21 03:11:59 <kergoth> nope
Nov 21 03:12:06 <darkstar62> oh, right
Nov 21 03:12:09 <darkstar62> the next one's it
Nov 21 03:12:18 <darkstar62> base.bbclass: Replace os.system with subprocess call.
Nov 21 03:12:43 <kergoth> yep, there ya go, it talks about the gzip issue in the full description
Nov 21 03:12:46 <darkstar62> yeah, I see that
Nov 21 03:12:51 <darkstar62> alright, I'll cherry-pick that in
Nov 21 03:12:53 <kergoth> that should probably go into stable, its an odd, annoying behavior
Nov 21 03:12:56 * kergoth nods
Nov 21 03:14:20 <darkstar62> thanks, kergoth
Nov 21 03:14:50 <kergoth> np
Nov 21 08:44:40 <eFfeM> hm, did a git pull after being afk for a week, do a bitbake console-image for beagle and I get:
Nov 21 08:44:41 <eFfeM> ERROR: Error, lockfile path does not exist!: /home/frans/oe/tmp_angstrom/work/armv7a-angstrom-linux-gnueabi/libsndfile1-1.0.20-r1/packages-split
Nov 21 08:44:59 <eFfeM> anyone an idea what causes this?
Nov 21 09:05:19 <eFfeM> hmm, answwering my own question. no idea, but bitbake -cclean libsndfile1; bitbake libsndfile1 runs smoothly 
Nov 21 09:05:25 <eFfeM> ???puzzled???
Nov 21 11:10:13 <eFfeM> seems I have this problem with multiple packages, guess it is due to some changes in the build system which should have needed a PR bump somewhere ....
Nov 21 13:08:29 <jest> hi
Nov 21 13:09:01 <jest> I have problem with setting up public-key authentication for git
Nov 21 13:10:27 <jest> I have set remote.origin.url to git@git.openembedded.org:openembedded
Nov 21 13:11:49 <jest> i try to use custom private key (not in ~/.ssh) with ssh-agent, but receive:
Nov 21 13:11:50 <jest> Permission denied (publickey).
Nov 21 13:11:50 <jest> fatal: The remote end hung up unexpectedly
Nov 21 13:12:02 <jest> after 'git pull'
Nov 21 13:12:44 <jest> also, when I do 'ssh -l git git.openembedded.org -i /path/to/custom-priv.key' I got error
Nov 21 13:13:14 <jest> is it supposed to work or I'am doing it wrong?
Nov 21 13:30:31 <hrw|gone> darkstar62: send that cherrypick to ML for inclusion please
Nov 21 13:43:53 <pb__> jest: that sounds like your key is just not installed on the server.
Nov 21 13:44:39 <pb__> who did you send it to, and when? 
Nov 21 13:45:27 <jest> pb__: hm, I just wrote to admins; BTW, my keys are in OpenSSH format, I guess it is fine?
Nov 21 13:46:15 <jest> pb__: I sent it to Cliff and Michael and got response yesterday that it should be functioning
Nov 21 13:48:25 <pb__> yeah, the format should be fine.  I guess it was just not installed correctly for some reason.
Nov 21 13:48:37 <pb__> you should probably take that up with whoever told you it should be functioning
Nov 21 14:06:11 <CIA-80> 03Tom Hacohen <tom@stosb.com> 07org.openembedded.dev * r05cb1bdc81 10openembedded.git/recipes/xboard/ (files/no-strip.patch xboard_4.2.7.bb): 
Nov 21 14:06:11 <CIA-80> Updated xboard's recipe and patch to the newest version Removed old recipe as the sources are not available any more
Nov 21 14:06:11 <CIA-80> Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
Nov 21 14:14:02 <Crofton|work> glibc detected *** opkg-cl: realloc(): invalid next size: 0x00000000023bb880
Nov 21 14:14:23 <Crofton|work> any thoughts on debugging this? Occur during do_rootfs
Nov 21 14:14:31 <Crofton|work> and then things hang until I control c
Nov 21 14:49:57 <CIA-80> 03Andrea Adami <andrea.adami@gmail.com> 07org.openembedded.dev * rc45f8972c8 10openembedded.git/recipes/kexecboot/kexecboot_git.bb: 
Nov 21 14:49:57 <CIA-80> kexecboot_git: bump to ddf66724ce68509a8d80727f26f682b9a9341ff5.
Nov 21 14:49:57 <CIA-80> Increase PR.
Nov 21 14:50:09 <CIA-80> 03Andrea Adami <andrea.adami@gmail.com> 07org.openembedded.dev * rd7ac114b4d 10openembedded.git/recipes/kexec/ (4 files in 2 dirs): 
Nov 21 14:50:09 <CIA-80> kexec-tools_2.0.1: add uImage support from upstream. Bump PR of shared
Nov 21 14:50:09 <CIA-80> and static recipes.
Nov 21 14:50:09 <CIA-80> 03Andrea Adami <andrea.adami@gmail.com> 07org.openembedded.dev * r7982e2d271 10openembedded.git/recipes/kexec/kexec-tools-klibc-static_1.101.bb: kexec-tools-klibc-static_1.101.bb: inject 'static' in CFLAGS string
Nov 21 15:09:11 <CIA-80> 03Klaus Kurzmann <mok@fluxnetz.de> 07org.openembedded.dev * r0a7ff95876 10openembedded.git/recipes/shr/e-wm-sysactions-shr_git.bb: 
Nov 21 15:09:11 <CIA-80> e-wm-sysactions-shr: install lock.sh
Nov 21 15:09:11 <CIA-80> Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
Nov 21 15:09:22 <CIA-80> 03Klaus Kurzmann <mok@fluxnetz.de> 07org.openembedded.dev * r92bc0cc561 10openembedded.git/conf/distro/include/sane-srcrevs.inc: 
Nov 21 15:09:22 <CIA-80> sane-srcrevs.inc: bump rev for e-wm-sysactions-shr and e-wm-config-illume-shr
Nov 21 15:09:22 <CIA-80> Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
Nov 21 15:27:45 <zecke> pb_: I have the first bits of a waterfall... certainly not as fancy as buildbot or tinderbox... but it is working
Nov 21 15:33:41 <Crofton|work> heh
Nov 21 15:33:46 <Crofton|work> working is good
Nov 21 15:33:51 <Crofton|work> do you have an url?
Nov 21 15:34:43 <zecke> Crofton|work: hehe... localhost:8000 :(
Nov 21 15:34:54 <Crofton|work> heh
Nov 21 15:34:55 <Crofton|work> ok
Nov 21 15:35:12 <Crofton|work> so this will sort certain builds and display them?
Nov 21 15:35:30 <Crofton|work> so you could display the last build by me of beagle-demo-image?
Nov 21 15:37:34 <zecke> Crofton|work: http://linuxtogo.org/~zecke/oe-stats-waterfall.png
Nov 21 15:37:55 <zecke> one builder == one column
Nov 21 15:38:47 <Crofton|work> what I think is interesting is a table with one axis being distro and the other being image
Nov 21 15:39:01 <Crofton|work> as the entry page
Nov 21 15:39:12 <Crofton|work> then move to waterfall behind it
Nov 21 15:40:27 <zecke> Crofton|work: having a "builder" filter will be nice too... for beagle-demo-image we will have to change the oestats model a bit
Nov 21 15:40:27 <zecke> Crofton|work: you just want to see the last build?
Nov 21 15:40:27 <zecke> Crofton|work: any builder or your builder?
Nov 21 15:40:59 <Crofton|work> no, I want to see that all images we "care" about are building for angstrom
Nov 21 15:41:12 <Crofton|work> and if not, I can see if they fail for other distros
Nov 21 15:41:26 <Crofton|work> this the high level metadata health report :)
Nov 21 15:42:15 <zecke> Crofton|work: hehe... will be easy too
Nov 21 15:42:25 <Crofton|work> yeah
Nov 21 15:42:41 <zecke> Crofton|work: Django is really good.. the Model is also very easy (a bit too easy)
Nov 21 15:44:11 <zecke> wow what a bad business hotel.. no room service and there external delivery hotline is busy... now I need to leave the hotel... *sigh* :)
Nov 21 15:44:15 * zecke is spoiled
Nov 21 15:44:56 <Crofton|work> hmm
Nov 21 15:45:06 <Crofton|work> I see leaving the hotel as a good thing :)
Nov 21 15:45:23 <zecke> Crofton|work: oh, I already had a three hour walk down to the city
Nov 21 15:45:46 <zecke> Crofton|work: I kind of anticipated eating pizza on the bed... I'm not allowed to eat on the bed at home (*haha*)
Nov 21 15:45:53 <Crofton|work> ah
Nov 21 15:45:59 <Crofton|work> yeah, I understand that
Nov 21 15:46:45 <zecke> wow... I wouldn't like if my last name is "Void"
Nov 21 15:47:22 <zecke> Crofton|work: for angstrom.. would you also look for "builders" that you down't know?
Nov 21 15:47:48 <Crofton|work> I think we would want to filter for only "known good" builders
Nov 21 15:48:30 <Crofton|work> basically, people that can run them fairly regularly on a variety of distros
Nov 21 15:48:37 <zecke> So in high level term.. for each_known_builder {  for each_image  { fill column } } }
Nov 21 15:48:46 <Crofton|work> right
Nov 21 15:49:24 <zecke> Crofton|work: maybe next weekend :)
Nov 21 15:49:32 <Crofton|work> :)
Nov 21 15:49:47 <CIA-80> 03Holger Hans Peter Freyther <zecke@selfish.org> 07org.openembedded.dev * r8129d082b7 10openembedded.git/classes/tinderclient.bbclass: tinderclient.bbclass: Less ego...
Nov 21 15:50:05 <zecke> Crofton|work: in my personal evolution... i had to learn that the best technology is nothing if people not look at it
Nov 21 15:50:33 <Crofton|work> yeah, that is why I am thinking a simple screen to show health
Nov 21 15:50:54 <zecke> Crofton|work: e.g. if the "distro" waterfall will be something people look at each morning, or we make it mandantory that it must be "green" before we install things I would be more than happy to do the oestats work
Nov 21 15:51:54 <Crofton|work> well, at the very least we can see when things go bad faster 
Nov 21 15:54:04 <zecke> bbl... pizza hunting
Nov 21 15:54:35 <Crofton> gn
Nov 21 16:05:27 <CIA-80> 03David Lanzendörfer <david.lanzendoerfer@o2s.ch> 07org.openembedded.dev * r94520f4538 10openembedded.git/recipes/mokomaze/mokomaze_0.5.5.bb: 
Nov 21 16:05:27 <CIA-80> mokomaze: missing space between SRC_URI entries
Nov 21 16:05:27 <CIA-80> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Nov 21 16:30:30 <Crofton|work> hmm, lots of changes in opkg lately
Nov 21 16:47:36 <zecke> argh... I have the feeling sdk packages are busted :(
Nov 21 16:49:16 <zecke> hmm.. weird...
Nov 21 16:50:00 <pb__> zecke: awesome
Nov 21 16:51:59 <zecke> pb__: hey, it certainly does not look as fancy as the other waterfalls... but I was never good with art
Nov 21 16:54:31 <pb__> zecke: yeah, I guess the visual bits would be easy enough to adjust later.  
Nov 21 16:54:49 <pb__> it looks like you are making good progress with the functional part though
Nov 21 16:56:49 <zecke> pb__: the thing that makes the code a bit ugly is that HTML tables work "row" wise... where I would prefer to fill them column wise :)
Nov 21 16:57:28 <pb__> zecke: mm, right.  I guess you could work around that with some suitable css rules.
Nov 21 16:58:35 <zecke> pb__: hehe, probably... I jump through some hoops to combine the columns...  what is probably missing for deployment on the OE servers is a way to filter the builders
Nov 21 16:59:35 <pb__> right, the waterfall should probably be restricted to a pre-configured set of build inputs
Nov 21 17:00:15 <pb__> either that or it could be a manually configured opt-in on the client, i.e. an extra variable that you pass to the server if you want to participate in the waterfall chart
Nov 21 17:02:24 <zecke> pb__: or you can select it on the url... (with a nice clickable form on the waterfall gui)
Nov 21 17:03:08 <pb__> or that, yeah
Nov 21 17:03:24 <pb__> I guess allowing people to make their own custom waterfalls in that way would be the ideal thing
Nov 21 17:03:57 <pb__> on the other hand, if we wanted to try to enforce a mozilla-type "no checkin on red" policy then you would need to have an authoritative waterfall to refer to.
Nov 21 17:04:33 <pb__> I'm not sure how far down that road we want to go, that might be a topic for future discussion.
Nov 21 17:05:04 <zecke> pb__: you can still have the "authorotive" waterfall (a configuration we refer to)
Nov 21 17:06:14 <likewise> gm
Nov 21 17:06:33 <zecke> hey
Nov 21 17:09:15 <Crofton|work> does graham glower hand out here?
Nov 21 17:10:35 <pb__> gower.  yes, sometimes.  I think he's known as grg.
Nov 21 17:12:14 <Crofton|work> thanks
Nov 21 17:12:18 <pb__> zecke: yes, true.  well, as soon as you are ready to deploy the waterfall, I will start supplying it with data..
Nov 21 17:12:31 <Crofton|work> I am trying the current opkg to see it it resolves my opkg-cl issue
Nov 21 17:12:42 <Crofton|work> zecke, I will also
Nov 21 17:14:23 <Crofton|work> ok, I can build images again
Nov 21 17:29:54 <CIA-80> 03Leon Woestenberg <leon@sidebranch.com> 07org.openembedded.dev * r0a9b043061 10openembedded.git/conf/machine/include/tune-atom.inc: tune-atom.inc: Use gcc arch and tune options for GCC 4.3.1+
Nov 21 17:42:07 <pb__> g'day kergoth
Nov 21 18:25:52 <CIA-80> 03Sebastian Spaeth <Sebastian@SSpaeth.de> 07org.openembedded.dev * r51044058d7 10openembedded.git/recipes/freesmartphone/ (fsodeviced/fsodeviced fsodeviced_git.bb): 
Nov 21 18:25:52 <CIA-80> fsodeviced: set default niceness to +10 rather than -19
Nov 21 18:25:52 <CIA-80> Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Nov 21 18:37:31 <gregoiregentil> Since upgrade of ubuntu 9.04 to 9.10, I can't compile anymore classpath-native, and I get this error in config.log:
Nov 21 18:37:32 <gregoiregentil> configure:29398: /Additional/OE/build/tmp/staging/i686-linux/usr/bin/ecj-initial -nowarn -source 1.5 -target 1.5 Object.java
Nov 21 18:37:32 <gregoiregentil> cacao-initial: resolve.c:348: resolve_classref_or_classinfo: Assertion `c->state & 0x0002' failed.
Nov 21 18:37:32 <gregoiregentil> /Additional/OE/build/tmp/staging/i686-linux/usr/bin/ecj-initial: line 4: 26326 Aborted                 ${RUNTIME} -Xmx1024m -cp ${ECJ_JAR} org.eclipse.jdt.internal.compiler.batch.Main ${1+"$@"}
Nov 21 18:37:33 <gregoiregentil> configure:29401: $? = 134
Nov 21 18:37:35 <gregoiregentil> configure:29405: error: The Java compiler /Additional/OE/build/tmp/staging/i686-linux/usr/bin/ecj-initial failed (see config.log, check the CLASSPATH?)
Nov 21 18:37:38 <gregoiregentil> What's wrong with my cacao-initial?
Nov 21 18:43:43 <CIA-80> 03Klaus Kurzmann <mok@fluxnetz.de> 07org.openembedded.dev * r7349d07fdb 10openembedded.git/conf/distro/include/sane-srcrevs-fso.inc: 
Nov 21 18:43:43 <CIA-80> sane-srcrevs-fso.inc: bump rev for fsodeviced
Nov 21 18:43:43 <CIA-80> Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
Nov 21 20:08:12 <likewise> gregoiregentil: is that on a OS X host?
Nov 21 20:08:34 <gregoiregentil> likewise: you mean?
Nov 21 20:08:38 <gregoiregentil> which problem?
Nov 21 20:08:56 <likewise> ubuntu 9.10 w/ cacao-initial
Nov 21 20:09:20 <gregoiregentil> not sure to understand your question. it's on ubuntu 9.10
Nov 21 20:09:30 <gregoiregentil> the host is ubuntu 9.10
Nov 21 20:13:28 <likewise> gregoiregentil: I'm sorry, that seemed like a black out on my side :-/
Nov 21 20:15:57 <likewise> gregoiregentil: Someone else reports the same problem when hosting on archlinux. No solution yet though; http://www.hentges.net/irclogs/%23oe/2009/August/20090822_oe.log?lines=all
Nov 21 20:16:16 <gregoiregentil> yes, I saw it!
Nov 21 20:16:29 <gregoiregentil> woglinde added a comment and the guy vanished...
Nov 21 20:16:40 <gregoiregentil> without saying if he had a fix or not :-( Not very fair
Nov 21 20:29:53 <CIA-80> 03Klaus Kurzmann <mok@fluxnetz.de> 07org.openembedded.dev * rbfdc00bd29 10openembedded.git/recipes/tasks/task-shr-feed.bb: 
Nov 21 20:29:53 <CIA-80> task-shr-feed: add xboard
Nov 21 20:29:53 <CIA-80> Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
Nov 21 20:54:11 <RP> morning all
Nov 21 20:54:59 <darkstar62> kergoth, hrw|gone: As requested, I submitted that gzip patch to the mailing list.  It worked beautifully for my build.
Nov 21 20:55:52 <JaMa> RP: morning
Nov 21 20:56:28 <JaMa> RP: do you have some time for review? (I have updated patch if you have..)
Nov 21 20:58:20 <RP> JaMa: ah, the bitbake patches. You have some uupdates?
Nov 21 20:58:49 <JaMa> RP: http://jama.homelinux.org/org.openembedded.shr/bitbake/
Nov 21 20:59:01 <JaMa> RP: 2nd is updated.. 1st is still the same
Nov 21 20:59:31 <JaMa> RP: both are heavilly used by shr builders, because BB_GIT_CLONE_FOR_SRCREV = "1" fails without them
Nov 21 20:59:55 <JaMa> RP: and BB_GIT_CLONE_FOR_SRCREV is in Makefile for shr builders
Nov 21 21:01:09 <RP> JaMa: ok, let me take a look. The first does look a lot cleaner now :)
Nov 21 21:07:18 <RP> JaMa: These are against the 1.8 branch aren't they? :/
Nov 21 21:07:26 <JaMa> yes
Nov 21 21:08:10 <JaMa> would be great to have another 1.8 release, required for oe.dev with sanity check (for SRCPV merging..)
Nov 21 21:08:19 <RP> JaMa: doesn't apply against master or 1.10 :(
Nov 21 21:08:42 <JaMa> I can prepare it for 1.10 or/and master if you want..
Nov 21 21:08:42 <RP> JaMa: Nothing goes into 1.8 that isn't in 1.10 or master. Let me have a look at this though
Nov 21 21:29:38 <RP> JaMa: The first patch is straight forward. The second messes around in something that is already a total mess. I'm going to see if I can't find a cleaner way to implement this. I really don't want to make that code worse :/
Nov 21 21:30:05 <cdbot2> * * OE Bug 5340 has been created by kristoffer.ericson(AT)gmail.com
Nov 21 21:30:07 <cdbot2> * * xorg-server 1.5.1 fails to build for mipsel
Nov 21 21:30:09 <cdbot2> * * http://bugs.openembedded.org/show_bug.cgi?id=5340
Nov 21 21:31:43 <JaMa> RP: I think its cleaner than it was before.. but its your call, you're the boss
Nov 21 21:33:45 <RP> JaMa: That I agree with :/
Nov 21 21:33:59 <RP> JaMa: but I can still barely understand what its doing :/
Nov 21 21:34:47 <JaMa> instead of incrementing localcount by 1 it counts rev-list in git cloned directory
Nov 21 21:35:22 <JaMa> problem is when you cannot do git clone, when trying to expand SRCPV
Nov 21 21:37:10 <RP> JaMa: I know what it does, I just don't like the fact its difficult to read
Nov 21 21:37:23 <JaMa> ah ok
Nov 21 21:39:23 <otavio> likewise: Hello; I found a possible serious problem with your lzma patches
Nov 21 21:39:29 <otavio> likewise: for 2.6.31
Nov 21 21:39:48 <otavio> likewise: appling it in our kernel makes non-lzma squashfs to corrupt
Nov 21 21:39:49 <RP> JaMa: out of time now, back later, sorry :/
Nov 21 21:41:39 <likewise> otavio: you generated the squashfs using the new squashfs-tools?
Nov 21 21:41:39 <JaMa> RP: oki thanks
Nov 21 21:42:04 <JaMa> RP: should I port it to 1.10 or do you want to do it your way?
Nov 21 21:43:23 <otavio> likewise: yes; i did
Nov 21 21:43:45 <otavio> likewise: and I also checked if it was a .config change and it was not
Nov 21 21:43:51 <likewise> otavio: hmm, those patches are taken 1-on-1 from the squashfs project.
Nov 21 21:44:04 <otavio> likewise: our image  gets corrupted using regular compression
Nov 21 21:44:08 <otavio> likewise: yes; I saw
Nov 21 21:44:29 <likewise> otavio: Ok, clear, maybe I can test this tomorrow.
Nov 21 21:44:30 <otavio> likewise: but maybe it depends on something new in 2.6.32
Nov 21 21:45:07 <otavio> likewise: something that 2.6.31 doesn't checks or assume to be safe or like
Nov 21 21:45:16 <likewise> otavio: according to the author, it should work on 2.6.31.   I only tested squashfs-lzma myself, but I will test squashfs (gzip) tomorrow...
Nov 21 21:45:38 <otavio> likewise: and I also found a mistake done by me in the .inc change of the tools and push
Nov 21 21:46:04 <otavio> likewise: anyway even if it was created with old mksquashfs it is suppose to be compatible ;-)
Nov 21 21:46:10 <otavio> likewise: but I did use new -tools
Nov 21 21:52:58 <otavio> likewise: I'm pushing the .inc changes. Please give it a look later
Nov 21 21:55:48 <likewise> otavio: thanks, I'll take some time for this tomorrow.
Nov 21 21:56:00 <otavio> likewise: good
Nov 21 21:56:25 <CIA-80> 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * r2f15c13910 10openembedded.git/recipes/squashfs-tools/ (squashfs-tools.inc squashfs-tools_4.0.bb): 
Nov 21 21:56:25 <CIA-80> squashfs-tools: allow setting of SRC_URI before loading .inc
Nov 21 21:56:25 <CIA-80> Without this change bitbake due a fetcher failure because SRC_URI is
Nov 21 21:56:25 <CIA-80> then cached and later changed.
Nov 21 21:56:25 <CIA-80> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Nov 21 21:56:27 <otavio> likewise: ^
Nov 21 22:04:05 <CIA-80> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * rf1a2168b53 10openembedded.git/conf/distro/include/sane-srcrevs.inc: 
Nov 21 22:04:05 <CIA-80> sane-srcrevs: bump SRCREV for linux-openmoko-shr-drm-devel and glamo-dri-tests
Nov 21 22:04:05 <CIA-80> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Nov 21 22:04:06 <CIA-80> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r80402d4b6d 10openembedded.git/: Merge branch 'org.openembedded.dev' of git.openembedded.org:openembedded into org.openembedded.dev
Nov 21 23:13:25 <else58> where is the right place to discuss a broken package build, such as this: http://tinderbox.openembedded.net/packages/x11vnc/ >
Nov 21 23:14:28 <else58> it needs this patch: http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-misc/x11vnc/files/x11vnc-0.9.8-xshm-header-fix.patch?rev=1.2&content-type=text/plain
Nov 21 23:15:18 <else58> from the 0.9.9 beta to build based on XShm.h changing
Nov 21 23:15:31 <otavio> else58: probably on the mailing list
Nov 21 23:15:48 <otavio> else58: but if you can fix it yourself and post a patch for review on the mailing list
Nov 21 23:16:03 <otavio> else58: so if it is accepted it is commited as soon as someone acks it
Nov 21 23:16:28 <else58> that gentoo link is a patch
Nov 21 23:17:13 <otavio> else58: not an OE one ;-)
Nov 21 23:17:21 <else58> this list: openembedded-devel@lists.openembedded.org ?
Nov 21 23:17:26 <otavio> else58: yes
Nov 21 23:19:28 <else58> I'm still new to oe development method.  would that be a patch that "/openembedded/recipes/vnc/x11vnc_0.9.8.bb" points to?
Nov 21 23:32:35 <RP> JaMa: Still there?
Nov 21 23:32:46 <JaMa> yes
Nov 21 23:34:30 <RP__> JaMa: I'm thinking of adding something like http://tim.rpsys.net/bb_fetch_init.patch
Nov 21 23:35:35 <RP> JaMa: Which then should simplify your patch
Nov 21 23:36:58 <RP> JaMa: obviously with the debug removed :/
Nov 21 23:40:46 <JaMa> RP: its against 1.10/master right? 
Nov 21 23:42:38 <RP> JaMa: its against master. Once I fix master I'll backport
Nov 21 23:45:32 <JaMa> RP: that BB_GIT_CLONE stuff wasnt in master?
Nov 21 23:46:47 <RP> JaMa: no, it was?
Nov 21 23:47:00 <JaMa> it is in 1.8
Nov 21 23:47:45 <JaMa> that's why I'm surprised, I cannot see it in master
Nov 21 23:48:02 <RP> JaMa: It is in master...
Nov 21 23:48:27 <JaMa> now i see sorry
Nov 21 23:51:56 <ant__> RP: no way to backport the runqueue speedups to 1.8.18?
Nov 21 23:53:17 <RP> ant__: Just use 1.10
Nov 21 23:53:31 <ant__> is it blessed now :) ?
Nov 21 23:53:40 <RP> ant__: My backport would just be to copy chunks of 1.10 over 1.8
Nov 21 23:53:45 <RP> ant__: I'm using it...
Nov 21 23:53:48 <ant__> np
Nov 21 23:53:54 <ant__> following
Nov 21 23:54:06 <JaMa> RP: I cannot see how is _sortable_revision_disabled increasing readability of that.. but thats because I haven't read many python code or bitbake code at all...
Nov 21 23:54:38 <RP> JaMa: You didn't find the reason for not being able to raise a parser error I guess? :/
Nov 21 23:55:07 <JaMa> RP: that packageSkip exception?
Nov 21 23:55:10 <RP> JaMa: It makes it a git fetcher internal matter. I can read the code in __init__.py without refernce to that in the git fetcher
Nov 21 23:55:16 <RP> JaMa: yes
Nov 21 23:55:25 <JaMa> no
Nov 21 23:56:38 <JaMa> RP: but you still need to implement that persistent caching I get for free by spliting _sortable_revision and _sortable_buildnumber, don't you?
Nov 21 23:58:19 <RP> JaMa: yes, doing that now
Nov 22 00:08:17 <RP> JaMa: ok, I've pushed something to master
Nov 22 00:09:10 <CIA-80> 03Andrea Adami <andrea.adami@gmail.com> 07org.openembedded.dev * r157c888f6c 10openembedded.git/recipes/opie-networksettings/ (files/wireless.patch opie-networksettings.inc): 
Nov 22 00:09:10 <CIA-80> opie-networksettings: unbreak builds against *actual* linux-2.6.31
Nov 22 00:09:10 <CIA-80> headers.
Nov 22 00:09:10 <CIA-80> Acked-by: Paul Eggleton <bluelightning@bluelightning.org>
Nov 22 00:11:47 <JaMa> RP: this means that if that git repo is not available it returns None right?
Nov 22 00:12:07 <JaMa> RP: than count will be 0 and stored in persistent cache..
Nov 22 00:12:25 <RP> JaMa: Yes, not perfect
Nov 22 00:12:32 <RP> JaMa: I want that to skip the recipe
Nov 22 00:12:42 <JaMa> RP: so you'll have as long as rev is the same
Nov 22 00:12:47 <JaMa> have 0
Nov 22 00:13:26 <RP> JaMa: It needs further work, I agree - returning count isn't much better though :(
Nov 22 00:13:43 <RP> It should just error out
Nov 22 00:14:13 <JaMa> RP: but "buildindex < count" was imho usefull..
Nov 22 00:14:32 <JaMa> RP: if you had ie override before for that count
Nov 22 00:14:42 <JaMa> RP: and higher count is in persistent layer
Nov 22 00:14:52 <RP> JaMa: It it looks like its going backwards it should be a fatal error
Nov 22 00:15:04 <RP> JaMa: and that check doesn't belong in the git fetcher
Nov 22 00:15:14 <JaMa> RP: than you should write an error/skip package/ or at least use count == last_one
Nov 22 00:15:27 <JaMa> RP: ok right, agreed
Nov 22 00:16:15 <RP> JaMa: That commit at least fixes some of the problems, error handling still needs to be done
Nov 22 00:16:26 <RP> I'm out of time :(
Nov 22 00:16:31 <JaMa> packageSkip + fatalError for backward count is better than my solution with returning last value
Nov 22 00:16:57 <RP> JaMa: Agreed, thats why I'm waiting for that ;-)
Nov 22 00:17:33 * otavio curious and too dumb to understand RP and JaMa discussion
Nov 22 00:17:46 <JaMa> RP: thanks for this
Nov 22 00:18:03 <CIA-80> 03Leon Woestenberg <leon@sidebranch.com> 07org.openembedded.dev * rcfacd3ac60 10openembedded.git/recipes/linux/linux-2.6.31/ion/defconfig: linux-2.6.31: Added defconfig for MACHINE ion.
Nov 22 00:18:13 <CIA-80> 03Leon Woestenberg <leon@sidebranch.com> 07org.openembedded.dev * rc652a59cbb 10openembedded.git/recipes/nvidia-drivers/ (3 files in 2 dirs): 
Nov 22 00:18:13 <CIA-80> nvidia-display: Added 190.42 release. Builds but packaging needs clean-up.
Nov 22 00:18:13 <CIA-80> Signed-off-by: Leon Woestenberg <leon@sidebranch.com>
Nov 22 00:18:45 <JaMa> RP: and I know you said before that there is no way SRCPV is expanded sooner than SRCREV was, but why are those BB_GIT_CLONE_FOR_SRCREV exposed AFTER merging SRCPV to shr/merge tree?
Nov 22 00:19:04 <JaMa> s/exposed/bugs exposed/
Nov 22 00:19:12 <likewise> good night all
Nov 22 00:20:07 <CIA-80> 03Andrea Adami <andrea.adami@gmail.com> 07org.openembedded.dev * r38361a2cd9 10openembedded.git/classes/palmtop.bbclass: 
Nov 22 00:20:07 <CIA-80> palmtop.bbclass: fix QA of plugins wrt packaging of -dbg files
Nov 22 00:20:07 <CIA-80> Acked-by: Paul Eggleton <bluelightning@bluelightning.org>
Nov 22 00:21:00 <ant__> argh..fied  -dev files, not -dbg :/
Nov 22 00:22:07 <bluelightning> ant__: oh well, at least the fix is in anyway
Nov 22 00:22:19 <ant__> ;)
Nov 22 00:23:25 <RP> JaMa: You switched to BB_GIT_CLONE_FOR_SRCREV at that point didn't you?
Nov 22 00:24:51 <JaMa> RP: no
Nov 22 00:25:16 <JaMa> RP: it was enabled really long time before..
Nov 22 00:25:52 <JaMa> RP: which I even didn't know because I'm not using shr Makefile and its enabled there...
Nov 22 00:27:03 <JaMa> RP: but when I merged SRCPV to shr/merge branch .. all builders started to scream, because bitbake cannot parse tree (not accessible git repos in about 20 recipes..)
Nov 22 00:27:51 <JaMa> RP: without SRCPV it failed the same, but only if you asked to build that recipe with not accessible git repo
Nov 22 00:28:53 <RP> JaMa: Ah, that is expected - You changed locked down recipes to include the revision number and to calculate the revision number it needed to hit the net
Nov 22 00:28:58 <RP> for the revision count
Nov 22 00:29:19 <RP> Anyhow, bed
Nov 22 00:29:23 * RP -> Zzzz
Nov 22 00:30:28 <JaMa> RP: ah, the same asi including AUTOREV for every recipe in tree to our config..
Nov 22 00:30:38 <JaMa> RP: gnite
Nov 22 00:35:03 <JaMa> all packages generated by bitbake (except -dbg) are stripped by default right?
**** ENDING LOGGING AT Wed Nov 25 03:35:08 2009