**** BEGIN LOGGING AT Thu Sep 15 02:59:57 2011
Sep 15 05:04:09 <darkopium> If I enabled an extra command in busybox, does anyone know how to make it appear in the /bin directory? I enabled ipcrm for example, but I have to manually create the link after deploying the image to the target.
Sep 15 07:13:52 <mckoan> otavio: thanks
Sep 15 08:08:46 <blunderer> hi
Sep 15 08:08:58 <blunderer> I have trouble login in patchwork
Sep 15 08:09:06 <blunderer> it says my account is inactive
Sep 15 08:09:50 <blunderer> I only subscribed to the oe mailing list, what else should I do?
Sep 15 08:33:06 <mr_nice> GNUtoo: I had the same error with liboil yesterday, can you try this patch http://lists.linuxtogo.org/pipermail/openembedded-core/2011-September/009605.html ?
Sep 15 08:50:38 <GNUtoo|work> JaMa|Off, hi
Sep 15 08:50:50 <JaMa|Off> hi
Sep 15 08:51:02 <GNUtoo|work> morphis broke stuff with his tslib append stuff
Sep 15 08:51:20 <GNUtoo|work> the appends are not machine specific
Sep 15 08:51:26 <GNUtoo|work> it's in meta-palm
Sep 15 08:51:40 <GNUtoo|work> that is to say the path are not machine specific
Sep 15 08:51:52 <GNUtoo|work> and meta-palm is used by angstrom....
Sep 15 08:51:53 <Jay7> meta-facepalm
Sep 15 08:51:56 <Jay7> sorry :)
Sep 15 08:52:02 <GNUtoo|work> ?
Sep 15 08:52:19 <GNUtoo|work> I didn't understood the joke
Sep 15 08:52:34 <Jay7> nevermind :)
Sep 15 08:55:03 <mr_nice> GNUtoo|work: hi, can you try this (http://lists.linuxtogo.org/pipermail/openembedded-core/2011-September/009605.html) liboil patch for me? 
Sep 15 08:57:51 <GNUtoo|work> mr_nice, yes of course I had the same issue
Sep 15 08:58:01 <GNUtoo|work> I worked arround in the recipe tough
Sep 15 08:58:28 <GNUtoo|work> like that:
Sep 15 08:58:30 <GNUtoo|work> +export CCASFLAGS="${CFLAGS} -mfpu=vfp"
Sep 15 08:58:35 <GNUtoo|work> but it's not a good fix
Sep 15 08:58:40 <GNUtoo|work> your fix is way better
Sep 15 09:00:04 <mr_nice> GNUtoo|work: ok, thx
Sep 15 09:08:11 <GNUtoo|work> mr_nice|afk, did you do the patch or found it somewhere?
Sep 15 09:08:28 <GNUtoo|work> ah upstream patch
Sep 15 09:08:32 <GNUtoo|work> sorry for the noise
Sep 15 09:09:15 <JaMa|Off> GNUtoo|work: please ping morphis to fix that
Sep 15 09:09:30 <GNUtoo|work> else I could fix?
Sep 15 09:09:36 <GNUtoo|work> but I don't know how:
Sep 15 09:09:47 <GNUtoo|work> did he do a machine_class
Sep 15 09:09:55 <GNUtoo|work> for the several palmpre?
Sep 15 09:10:03 <GNUtoo|work> or is there an override for all palmpre
Sep 15 09:10:11 <GNUtoo|work> like palmpre,palmpre2
Sep 15 09:16:31 <bluelightning> morning all
Sep 15 09:16:48 <anarsoul> morning bluelightning 
Sep 15 09:30:42 <PaulePanter> Hi everyone. The Patchwork instance on our server seems to be not allowing new users to register. There were several reports on the list and in this channel. Who is administrating this instance?
Sep 15 09:40:05 <bluelightning> PaulePanter: either khem or ka6sox I would think
Sep 15 09:41:09 <PaulePanter> bluelightning: Thanks. Do you know if they are aware of that problem?
Sep 15 09:41:26 <bluelightning> PaulePanter: I haven't heard anything, I would imagine not
Sep 15 09:41:38 <bluelightning> I don't think many people use patchwork
Sep 15 09:41:45 <PaulePanter> Looking at oe-core and the Wiki I think bluelightning asked how to improve that.
Sep 15 09:42:03 <PaulePanter> I noticed that oe-core is not mentioned on the start page.
Sep 15 09:42:04 <bluelightning> ?
Sep 15 09:42:17 <bluelightning> ah yes... hmm... we probably need a news posting
Sep 15 09:42:20 <bluelightning> at the very least
Sep 15 09:42:42 <PaulePanter> Also searching for »oe-core« does not return OpenEmbedded-core as the first result.
Sep 15 09:43:43 <PaulePanter> Regarding patchwork, it used to be used quite a lot. A write up on the current work flow would be quite nice. And I emphasize that although Richard seems to use it this way, that a mailing list is not a patch tracker.
Sep 15 09:44:09 <PaulePanter> At least not in the current way, where people do not use v2, v3 and so on consistently.
Sep 15 09:49:59 <GNUtoo|work> PaulePanter, it's khem 
Sep 15 09:52:07 <pb_> well, the (or a) mailing list may not be a "patch tracker" but it does seem to work fine for oe-core's purposes.
Sep 15 09:52:26 <pb_> I've never really found that patchwork does anything except create a load of extra work.
Sep 15 09:58:23 <bluelightning> pb_: I agree... if it was at the very least able to figure out when a patch got merged automatically it would be a huge step forward
Sep 15 09:58:51 <bluelightning> I've gone in and manually marked my patches as merged a few times but now I don't bother because nobody else seems to...
Sep 15 09:59:38 <pb_> yeah, quite
Sep 15 10:00:29 <pb_> I don't think it would be massively hard to link it to a git hook so that it could automatically mark patches as merged, but I am a bit loath to spend the effort even to do that when the whole thing seems like a waste of time.
Sep 15 10:01:23 <pb_> and, especially given that we seem to be moving to a world where only one person has commit access to any given repo, the concept of a central patchwork seems like it just doesn't fit with the way the universe is going to be arranged in future.
Sep 15 10:05:13 <pb_> I guess I can see how (in theory) it might have been a valuable thing in the old oe.dev "scrum development" approach, when there were multiple people who might each have committed a patch.
Sep 15 10:05:38 <pb_> but, even then, in practice it always seemed more of a hindrance than a help.
Sep 15 10:07:17 <bluelightning> pb_: the one useful aspect is tracking patches that might otherwise have been forgotten
Sep 15 10:07:32 <bluelightning> pb_: or not immediately mergeable but could be merged a short time later
Sep 15 10:07:55 <bluelightning> if it only shows unmerged stuff it would be workable for that purpose
Sep 15 10:08:12 <bluelightning> I've heard a lot of good reviews of gerrit, as an alternative platform
Sep 15 10:08:15 <bluelightning> never tried it though
Sep 15 10:09:04 <pb_> right, might be worth a look.
Sep 15 10:09:26 <pb_> still, I guess it's really a question for each tree owner to figure out the workflow that works for them
Sep 15 10:09:31 <bluelightning> PaulePanter: this is mediawiki's broken search... I just added a comment containing "oe-core" to that page and still it will not find it despite it being able to find other keywords within the comment :/
Sep 15 10:10:10 <bluelightning> pb_: sure.
Sep 15 10:10:21 <PaulePanter> bluelightning: That is unfortunate. Can you add oe-core in parantheses to the title?
Sep 15 10:11:19 <PaulePanter> Regarding patchwork, there are example hooks for the Git server. It was proposed several times but not implemented.
Sep 15 10:11:38 <bluelightning> pb_: I have also found it occasionally useful for presenting a patch and related discussion as an easily linkable one-page summary (more easily reviewable than typical ml archives)
Sep 15 10:12:01 <CIA-77> 03Steffen Sledz <sledz@dresearch-fe.de> 07org.openembedded.dev * r750e869586 10openembedded.git/recipes/eglibc/ (eglibc-2.9/make-3.82.patch eglibc_2.9.bb): 
Sep 15 10:12:01 <CIA-77> eglibc-2.9: allow building with GNU make >= 3.82
Sep 15 10:12:01 <CIA-77> GNU make >= 3.82 does not allow mixed implicit and normal rules
Sep 15 10:12:01 <CIA-77> Signed-off-by: Steffen Sledz <sledz@dresearch-fe.de>
Sep 15 10:12:01 <CIA-77> Acked-by: Khem Raj <raj.khem@gmail.com>
Sep 15 10:12:01 <CIA-77> Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
Sep 15 10:12:09 <PaulePanter> The only benefit is indeed to help with patch iterations and to not forget patches.
Sep 15 10:12:11 <bluelightning> PaulePanter: ah, that gives me an idea... I'll try creating a second page called "oe-core" with a redirect
Sep 15 10:12:20 <PaulePanter> bluelightning: Nice.
Sep 15 10:12:54 <PaulePanter> And importing a patch from patchwork for testing is much easier too in my experience.
Sep 15 10:13:28 <PaulePanter> Regarding Gerrit there is unfortunately no command line interface as far as I know and you have to use the Web interface.
Sep 15 10:13:54 <PaulePanter> But in theory hooking up Jenkins (continuous integration) with Gerrit is quite nice.
Sep 15 10:14:22 <PaulePanter> coreboot does it this way and it helps a lot to catch build errors.
Sep 15 10:14:45 <bluelightning> PaulePanter: ah, that worked perfectly :)
Sep 15 10:14:48 <PaulePanter> I guess the ressources from TI and Intel should actually be big enough to cover a lot of machines.
Sep 15 10:14:54 <PaulePanter> bluelightning: Great!
Sep 15 10:15:01 <bluelightning> PaulePanter: thanks for pointing out the issue
Sep 15 10:15:36 <PaulePanter> Regarding Patchwork it should be decided what to do. If nobody is using it just take it down.
Sep 15 10:16:07 <PaulePanter> But it is unfair to have it written in the Wiki and wasting people times who actually read the guidelines and try to adhere to it.
Sep 15 10:23:38 <sanket> has anybody worked on Pollux NC600 board
Sep 15 10:24:13 <sanket> I required an help regarding ...porting u-boot on NC600
Sep 15 10:25:12 <bluelightning> PaulePanter: I agree...
Sep 15 10:35:25 <kobe> What is the best way to let SRC_URI refer to a local folder while doing development  (not a local tar.gz file)?
Sep 15 10:45:13 <pb_> you can't, though you can set ${S} to a local folder directly
Sep 15 10:45:35 <pb_> if you want to pull from a folder into ${S} then I guess you can provide a custom do_fetch()
Sep 15 11:01:14 <nine_pt> i am using a embedded device and can't create /dev/pts/0 with mkdnod /dev/pts/0 c 136 0
Sep 15 11:01:23 <nine_pt> if I open a ssh connection to it, it creates the device and it continue to exist after close the ssh connection
Sep 15 11:01:43 <nine_pt> any idea how I can create the /dev/pts/0 without establish a ssh connection ?
Sep 15 11:04:38 <pb_> openpty()?
Sep 15 11:05:31 <nine_pt> pb_ : it's for me ? don't know the command  ... and don't have avaiable on the board ... but maybe I can't compile it
Sep 15 11:16:39 <kobe> ok, thanks
Sep 15 13:34:46 <joelagnel> Tartarus, hi
Sep 15 13:45:19 <bluelightning> btw, I've updated the layer index, splitting out the multi-layer repos into separate entries for each layer: http://www.openembedded.org/wiki/LayerIndex
Sep 15 13:45:42 <bluelightning> I think this makes more sense and gets these layers the exposure they deserve
Sep 15 13:57:33 <mgundes> Hi everybody
Sep 15 13:58:09 <mgundes> Is there a way to search oe channel chat history?
Sep 15 13:59:47 <JaMa|Off> ~logs
Sep 15 13:59:47 <ibot> All conversations are logged to http://ibot.rikers.org/%23oe/ Lines starting with spaces are not logged. Logs are updated daily.
Sep 15 13:59:56 <JaMa|Off> mgundes: ^
Sep 15 14:01:16 <mgundes> thanks but there is no search availability on that site
Sep 15 14:01:33 <mgundes> can I search any pattern on those logs?
Sep 15 14:03:08 <JaMa|Off> bluelightning: thanks, looks good
Sep 15 14:03:28 <JaMa|Off> !logs
Sep 15 14:03:50 <bluelightning> JaMa|Off: btw, the meta-samsung layer has "palm" in the readme
Sep 15 14:04:04 <GNUtoo|work> yes and meta-palm has some issues:
Sep 15 14:04:31 <GNUtoo|work> *tslib files are not palmpre specific(I'll fix that and send a patch)
Sep 15 14:04:42 <JaMa|Off> bluelightning: thanks, fixed
Sep 15 14:04:48 <GNUtoo|work> *palmpre is a machine and a MACHINE_CLASS
Sep 15 14:05:09 <Tartarus> hey joelagnel
Sep 15 14:05:39 <bluelightning> JaMa|Off: also would it be worth marking the "old" meta-shr layer ( http://git.shr-project.org/git/?p=meta-shr.git;a=summary ) in some way that indicates it shouldn't be used?
Sep 15 14:05:48 <bluelightning> (or deleting it)
Sep 15 14:06:27 <JaMa|Off> bluelightning: http://git.shr-project.org/git/?p=meta-shr.git;a=commit;h=07bc2bb8b3908e980935c4e639c528b83e577ad7
Sep 15 14:06:37 <JaMa|Off> I thought that marks it enough
Sep 15 14:07:12 <bluelightning> JaMa|Off: ah, heh... that is kind of obvious, I hadn't realised it had no files in it :)
Sep 15 14:07:26 <bluelightning> nevermind :)
Sep 15 14:08:04 <JaMa|Off> I wanted to keep repo open just for README so people doing just git pull will notice :)
Sep 15 14:09:20 <GNUtoo|work> JaMa|Off, btw could you do that:
Sep 15 14:09:39 <GNUtoo|work> sed 's/_/-/' in the modules names in the machines configs
Sep 15 14:09:47 <GNUtoo|work> in autoload_foo_bar
Sep 15 14:09:56 <GNUtoo|work> -> autoload_foo-bar
Sep 15 14:12:38 <GNUtoo|work> JaMa|Off, all modules with _ in it are not autoloaded
Sep 15 14:14:29 <GNUtoo|work> JaMa|Off, or should I send a patch for that this night?
Sep 15 14:20:22 <JaMa|Off> GNUtoo|work: no read that commit
Sep 15 14:20:38 <GNUtoo|work> what commit
Sep 15 14:20:43 <GNUtoo|work> the s/-/_
Sep 15 14:21:30 <GNUtoo|work> c920280084606e60935ea0c71aa3bad649a90eec ?
Sep 15 14:22:44 <CIA-77> 03Steffen Sledz <sledz@dresearch-fe.de> 07org.openembedded.dev * r5fc0f27dc6 10openembedded.git/recipes/rsyslog/ (5 files in 2 dirs): (log message trimmed)
Sep 15 14:22:44 <CIA-77> rsyslog: switch to new upstream version 5.8.4
Sep 15 14:22:44 <CIA-77> * many bug fixes and systemd support, see:
Sep 15 14:22:44 <CIA-77> http://www.rsyslog.com/changelog-for-5-8-1-v5-stable/
Sep 15 14:22:44 <CIA-77> http://www.rsyslog.com/changelog-for-5-8-2-v5-stable/
Sep 15 14:22:45 <CIA-77> http://www.rsyslog.com/changelog-for-5-8-3-v5-stable/
Sep 15 14:22:46 <CIA-77> http://www.rsyslog.com/changelog-for-5-8-4-v5-stable/
Sep 15 14:23:29 <JaMa|Off> GNUtoo|work: yes
Sep 15 14:24:59 <GNUtoo|work> ah thanks a lot
Sep 15 14:25:43 <JaMa|Off> GNUtoo|work: 15:25:05 < JaMa|Off> whoever cares about shr-core on n900: seems like omap3-isp makes kernel segfault.. so remove /etc/modutils/omap3-isp before you reboot after last kernel upgrade
Sep 15 14:26:01 <GNUtoo|work> ok
Sep 15 14:26:02 <JaMa|Off> GNUtoo|work: this is ^ small sideeffect of fixini module_autoload
Sep 15 14:26:07 <GNUtoo|work> I'll try later at home
Sep 15 14:26:11 <GNUtoo|work> or in the train
Sep 15 14:26:27 <GNUtoo|work> but maybe we should update to newer kernels for n900
Sep 15 14:26:31 <GNUtoo|work> that may fix isp
Sep 15 14:26:37 <GNUtoo|work> since they reworked isp
Sep 15 14:26:59 <GNUtoo|work> isp was for camera right?
Sep 15 14:30:04 <JaMa|Off> GNUtoo|work: probably as stack trace from segfault ends in v4l2
Sep 15 14:30:32 <GNUtoo|work> ok
Sep 15 14:30:41 <JaMa|Off> but I haven't seen it whole as it's longer then 1 screen 
Sep 15 14:31:56 <GNUtoo|work> ok
Sep 15 14:32:10 <GNUtoo|work> I know media-controller a bit from userspace
Sep 15 14:33:10 <JaMa|Off> any hint for "ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored." ? seems like even fetcher2 cannot use git-native properly now
Sep 15 14:33:29 <GNUtoo|work> someone in irc had the same issue
Sep 15 14:35:20 <JaMa|Off> GNUtoo|work: nschle reported it and then did rebuild from scratch..
Sep 15 14:35:32 <GNUtoo|work> ok
Sep 15 14:35:39 <GNUtoo|work> another user did also
Sep 15 14:35:47 <JaMa|Off> ah ok
Sep 15 14:50:09 <GNUtoo|work> but it was in a pastebin and I can't find it anymore
Sep 15 15:08:09 <otavio> ericben: I have fixed the translation support
Sep 15 15:08:17 <otavio> ericben: for qt
Sep 15 15:08:42 <ericben> hi otavio 
Sep 15 15:09:03 <ericben> otavio: ok GNUtoo|work was working on it just now ;-)
Sep 15 15:09:37 <ericben> otavio: can you send the patch ? (so that wez can try it)
Sep 15 15:10:00 <otavio> ericben: sure; will send in a minute
Sep 15 15:10:18 <ericben> perfect, we will launch a compile tonight
Sep 15 15:13:41 <otavio> ericben: https://github.com/OSSystems/oe-core/commit/d9385e26a1f8fbbe4d315c69631ebff5e6ea6a32
Sep 15 15:15:29 <otavio> ericben: seems OK?
Sep 15 15:17:53 <GNUtoo|work> we'll test it
Sep 15 16:24:56 <GNUtoo|work> hi otavio 
Sep 15 16:25:45 <GNUtoo|work> in https://github.com/OSSystems/oe-core/commit/d9385e26a1f8fbbe4d315c69631ebff5e6ea6a32 you forgott to bump PR for qt4-embedded.inc
Sep 15 16:26:13 <GNUtoo|work> oops let me look
Sep 15 16:26:39 <GNUtoo|work> s/PR/INC_PR/
Sep 15 17:28:32 <mikeypizano> hello, can someone help me get a wifi card working, its a clie wl110 card based on prism2.5
Sep 15 17:38:33 <mikeypizano> hello, can someone help me get a wifi card working, its a clie wl110 card based on prism2.5???
Sep 15 17:42:32 <mikeypizano> i am trying to get a prism2.5 based wifi card (sony clie pega-wl110) working on my sharp zaurus c700 running cacko 1.23, can anyone help me?
Sep 15 17:55:09 <mikeypizano> i am trying to get a prism2.5 based wifi card (sony clie pega-wl110) working on my sharp zaurus c700 running cacko 1.23, can anyone help me?
Sep 15 17:56:10 <GNUtoo> mikeypizano, hi, try #angstrom
Sep 15 17:56:26 <mikeypizano> i did, no one is answering there
Sep 15 17:56:40 <GNUtoo> they may have a more up to date distro
Sep 15 17:56:40 <GNUtoo> and we're not a distro but a build system at #oe
Sep 15 17:57:05 <mikeypizano> well, technically im running cacko, but the room is empty
Sep 15 17:57:34 <mikeypizano> reason im askin here is i tried doing what wiki says but wont work
Sep 15 17:58:41 <GNUtoo> they you made a typo
Sep 15 17:58:48 <GNUtoo> because the room is not empty
Sep 15 17:58:54 <mikeypizano> #cacko?
Sep 15 17:58:58 <GNUtoo> no #angstrom
Sep 15 17:59:09 <GNUtoo> I'm not sure #crako is still developped
Sep 15 17:59:19 <mikeypizano> i tried in there, no one is answering me, and i dont think it is, the cacko site is down
Sep 15 17:59:33 <GNUtoo> ok
Sep 15 17:59:54 <mikeypizano> been going crazy for weeks with this c700
Sep 15 17:59:57 <GNUtoo> I've no zaurus yet so I don't know it enough
Sep 15 18:00:08 <mikeypizano> ah
Sep 15 18:00:12 <GNUtoo> I'll arrive soon
Sep 15 18:00:13 <GNUtoo> bbl
Sep 15 18:00:15 <GNUtoo> at home...
Sep 15 18:30:50 <Crofton> any suggestions for fixing this
Sep 15 18:30:51 <Crofton> http://pastebin.com/6ybxQkWf
Sep 15 18:31:01 <Crofton> oe-core laye.conf message
Sep 15 18:35:23 <Jack_Handy> this may be a dumb question but how do I select the linux kernel version?
Sep 15 18:35:41 <Jack_Handy> my default build is using 2.6.36 and I want to move to 2.6.37
Sep 15 18:35:49 <msm> PERFERRED_VERSION_virtual/kernel = "2.6.37"
Sep 15 18:36:02 <Jack_Handy> put that in local.conf?
Sep 15 18:36:11 <msm> i think that should work
Sep 15 18:36:25 <Jack_Handy> is that documented anywhere? i've been googling for that for almost a half hour
Sep 15 18:36:28 <msm> assuming a 2.6.37 exists in your recipes somewhere
Sep 15 18:36:44 <GNUtoo> Jack_Handy, in machine config
Sep 15 18:36:58 <msm> PREFERRED_PROVIDER_pkgname and PREFERRED_VERSION_pkgname are documented somewhere….
Sep 15 18:37:10 <GNUtoo> you can override it in local.conf tough
Sep 15 18:37:10 <GNUtoo> I don't remember exactly how tough
Sep 15 18:37:10 <GNUtoo> it may be with _pn
Sep 15 18:37:12 <GNUtoo> or something like that
Sep 15 18:37:35 <msm> GNUtoo: why won't it work in local.conf?
Sep 15 18:38:05 <Jack_Handy> ok i'll try in local.conf first
Sep 15 18:38:13 <GNUtoo> no idea
Sep 15 18:38:15 <Jack_Handy> and if that doesn't work I'll add _pn to the var name
Sep 15 18:38:24 <GNUtoo> grep for _pn first
Sep 15 18:38:28 <Jack_Handy> and if that doesn't work I'll do it in the machine config
Sep 15 18:38:31 <Jack_Handy> tru
Sep 15 18:38:49 <Jack_Handy> why is linux kernel package in OE called "virtual/kernel"?
Sep 15 18:39:39 <msm> its a dummy package name
Sep 15 18:39:45 <msm> which can be provided by any recipe
Sep 15 18:40:04 <msm> so i can make my own recipe for linux and say it PROVIDES = "virtual/kernel"
Sep 15 18:40:14 <msm> then it's selectable by PREFERRED_PROVIDER
Sep 15 18:44:13 <Jack_Handy> is "virtual" considered the provider then?
Sep 15 18:45:06 <housel> The provider is the recipe that contains the PROVIDES=
Sep 15 18:45:11 <Jack_Handy> since the slash makes me think of a file path syntax, I'm inclined to think there's some kind of hierarchy of package names
Sep 15 18:45:19 <Jack_Handy> ah ok
Sep 15 18:45:53 <Jack_Handy> does "virtual/" have special meaning to bitbake?
Sep 15 18:48:18 <housel> Yes
Sep 15 18:49:22 <Jack_Handy> does that mean there is some kind of hierarchical organization to the package names?
Sep 15 18:49:51 <housel> No
Sep 15 18:50:04 <kergoth> virtual/ are *not* special to bitbake.
Sep 15 18:50:34 <Jack_Handy> so "virtual/kernel" is just another name to bitbake like "foobar"
Sep 15 18:50:52 <Jack_Handy> ?
Sep 15 18:51:04 <housel> There is plenty of code in bitbake that says "if p.startswith('virtual/'):"
Sep 15 18:51:04 <kergoth> yes. it's an item in a recipe's PROVIDES variable
Sep 15 18:51:08 <kergoth> housel: no.
Sep 15 18:51:15 <kergoth> there's one line, which excludes them from world builds
Sep 15 18:52:35 <Jack_Handy> ah ok
Sep 15 18:53:01 <Jack_Handy> are there any other specially recognized prefixes like "virtual/"?
Sep 15 18:53:08 <kergoth> it's convention
Sep 15 18:53:10 <kergoth> that's all
Sep 15 18:53:16 <kergoth> and no, that's it
Sep 15 20:58:55 <MrCurious> anyone here at ohsummit or watching it?
Sep 15 21:03:32 <MrCurious> i am guessing with bitbake, you keep running it, and trying to fix issues as they happen
Sep 15 21:03:43 <MrCurious> fix checksums, manually re-download...
Sep 15 21:04:05 <msm> are you having a particular problem?
Sep 15 21:05:08 <MrCurious> just failed wgets mostly
Sep 15 21:05:21 <MrCurious> the odd wrong checksum
Sep 15 21:08:30 <msm> most like the download was incorrect, i just do a bitbake -c cleanall pkgname
Sep 15 21:08:36 <msm> or try to find the file in the sources/ folder
Sep 15 21:10:00 <MrCurious> yeah. manually nuking the file in sources
Sep 15 21:10:28 <MrCurious> i am guessing towards the end, it will just be the broken items remaining
Sep 15 21:10:42 <MrCurious> 2251 of 5308 :D
Sep 15 21:11:15 <msm> you can do a bitbake -c fetchall image
Sep 15 21:11:21 <msm> and it will try to get all the files irs
Sep 15 21:11:25 <msm> first*
Sep 15 21:12:39 <MrCurious> i will try that next failure
Sep 15 21:12:43 <MrCurious> thanks
Sep 15 21:42:01 <Crofton> I am in a screen session
Sep 15 21:42:06 <Crofton> How do I fix:
Sep 15 21:42:08 <Crofton>     The console for use in patch error resolution is not available, please install xterm or set TERMCMD and TERMCMDRUN (as documented in local.conf)
Sep 15 21:42:35 <msm> you can change the TERMCMD to use screen
Sep 15 21:42:41 <CosmicPenguin> or install xterm?
Sep 15 21:42:43 <Crofton> how?
Sep 15 21:42:55 <Crofton> yeah, I am not rtfming :)
Sep 15 21:43:18 <msm> its already in your local.conf
Sep 15 21:44:45 <Crofton> hmm, not mine
Sep 15 21:48:08 <Crofton> PATCHRESOLVE = "noop"
Sep 15 21:48:11 <Crofton> :)
Sep 15 21:56:03 <msm> Oh they changed that recently I think
Sep 15 22:06:04 <Crofton> I am trying to get going with oe-core
Sep 15 22:06:14 <Crofton> but it seems to not try to fetch
Sep 15 22:06:31 <Crofton> feels like fetch is disables, and trying to unpack an already fetched tarball
Sep 15 22:06:51 <fray> what is it not fetching?
Sep 15 22:07:01 <Crofton> quilt from cvs
Sep 15 22:07:07 <Crofton> first thing it tries to do
Sep 15 22:07:11 <fray> I'm using oe-core right now and not having that problem
Sep 15 22:07:17 <fray> are you behind a firewall or anything?
Sep 15 22:07:20 <Crofton> no
Sep 15 22:07:28 <Crofton> I put this together from koen's setup script
Sep 15 22:07:47 <fray> I simply pull down oe-core, and pull down bitbake from with it..
Sep 15 22:07:56 <fray> run . ./oe-init-build-env build
Sep 15 22:08:06 <fray> setup the conf/local.conf and go.. it's working here on a F13 and a F14 machine
Sep 15 22:12:13 <ant__> fray: there is an issue with 'modern' machines (see log.do_package)
Sep 15 22:12:17 <ant__> error: magic_load(ms, /usr/share/misc/magic) failed: File 5.4 supports only version 7 magic files. `/usr/share/misc/magic.mgc' is version 8
Sep 15 22:12:18 <ant__> rpmdeps: rpmfc.c:1154: rpmfcClassify: Assertion `mg != ((void *)0)' failed.
Sep 15 22:12:56 <ant__> first question is why is it looking at buildhost? Second is why so old versions in oe-core?
Sep 15 22:13:46 <ant__> I use ipk and atm I don't see any issue, though
Sep 15 22:27:34 <fray> ant__ it shouldn't be looking at the host at all.. if you can give me a reproducer, I'll get it fixed.. AFAIK this was fixed a few weeks ago...
Sep 15 22:28:22 <ant__> I have a pull from today
Sep 15 22:28:28 <ant__> building on Gentoo here
Sep 15 22:31:05 <fray> I can't find the bug in the Yocto bugzilla.. if you could file a new one and include the error from package log, and the host system you are on that would be appreciated..  (if you can't file a bug, or don't want to, post to the oe-core mailing list that info and I'll file it)
Sep 15 22:31:27 <ant__> fray: first occurrences are in update-modules-1.0-r10 and /update-rc.d-0.7-r4  in all-oe-linux
Sep 15 22:31:35 <ant__> log.do_package
Sep 15 22:31:54 <fray> I know we've hit that before, but I also know we thought we fixed that issue
Sep 15 22:32:12 <fray> a change went into RPM to use the local version not system version..
Sep 15 22:32:26 <fray> obviously something is still wrong though if you get that issue
Sep 15 22:33:09 <ant__> I would not have noticed it without version mismatch
Sep 15 22:33:38 <ant__> again I only build ipk, no rpm
Sep 15 22:34:23 <fray> thats fine.. the code causing the problem should be the same in both
Sep 15 22:34:40 <fray> I've got to go.. I should be back in a few hours
Sep 15 22:39:22 <MrCurious> it appears my bitbake now has all the sources it needs :)
**** ENDING LOGGING AT Fri Sep 16 02:59:56 2011