**** BEGIN LOGGING AT Fri Aug 17 02:59:58 2012
Aug 17 07:45:41 <ant_work> ka6sox: still awake? Pls check nslu2 #kexecboot logs, not rotating anymore
Aug 17 07:47:45 <marc_> hi all. has anyone done any work towards making psplash work with systemd?
Aug 17 07:49:01 <afournier> hi all
Aug 17 07:52:22 <afournier> i am planning to install buildbot for open embedded, but i was wondering how i could share work between the slaves, any idea ?
Aug 17 07:52:37 <bluelightning> morning all
Aug 17 07:53:02 <marc_> evening.
Aug 17 07:53:12 <bluelightning> marc_: I'd be surprised if it was not working within Angstrom, they've been the main drivers behind systemd
Aug 17 07:53:14 <JaMa> morning
Aug 17 07:54:20 <marc_> i am using angstrom, the splash screen does show, but the progress bar doesn't, um, progress
Aug 17 07:54:42 <bluelightning> ah ok, so systemd is not poking psplash as it progresses
Aug 17 07:55:03 <marc_> not surprising though seeing as it used to be something in the init scripts
Aug 17 07:56:10 <marc_> i thought a way to hack around it would be to create some services that come before/after certain points in startup and then have them update the progress
Aug 17 07:59:32 <bluelightning> surely there's a better way than that...
Aug 17 08:00:00 <afournier> let me rephrase my question, is it possible to configure the package staging so it works over the network ?
Aug 17 08:02:14 <bluelightning> afournier: if you mean shared state (sstate) using OE-Core, yes it is, just use SSTATE_MIRRORS
Aug 17 08:02:36 <bluelightning> with the older packaged staging in OE-Classic, not sure I'm afraid
Aug 17 08:03:17 <afournier> bluelightning: thanks a lot for this pointer !
Aug 17 08:03:58 <bluelightning> note that with the very latest master you will need to append PATH (exactly that) to the end of your URL in SSTATE_MIRRORS
Aug 17 08:04:20 <afournier> ok
Aug 17 08:05:09 <bluelightning> so SSTATE_MIRRORS = "file://.* http://some-server/dir/path/to/files/PATH"
Aug 17 08:05:24 <bluelightning> we should update the example config file to mention that...
Aug 17 08:06:38 <JaMa> bluelightning: and fix fetcher to do better job with it :/
Aug 17 08:06:55 <bluelightning> JaMa: what do you mean?
Aug 17 08:07:19 <JaMa> http://lists.linuxtogo.org/pipermail/openembedded-core/2012-August/027125.html
Aug 17 08:07:40 <JaMa> all files in the same directory + symlinks in prefix + NO .siginfo files
Aug 17 08:08:55 <JaMa> it's hard to debug on host why whole sstate-cache was invalidated or rebuild if not available on SSTATE_MIRRORS when you have no .siginfo files from previous build (sstate downloaded by fetcher)
Aug 17 08:10:34 <JaMa> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2898
Aug 17 08:12:34 <marc_> bluelightning: i can't (yet) think of a better way. i don't think systemd has a way of outputting or interrogating overall progress
Aug 17 08:13:01 <bluelightning> marc_: hmm... something to talk to upstream about maybe...
Aug 17 08:13:29 <JaMa> and something is wrong with runqueue :/ when testing new binutils patches from khem I've noticed that changing BINUVERSION doesn't cause binutils-cross to build right version anymore, it just says that nothing was needed, so wrong version stays in sysroot (and you have to cleansstate binutils manually to switch version)
Aug 17 08:14:44 <bluelightning> JaMa: have you reported that issue?
Aug 17 08:16:24 <JaMa> not yet, I've seen this yesterday.. but same scenario was with rebuilding virtual/kernel few weeks ago (probably still there)
Aug 17 08:16:26 <bluelightning> JaMa: also, is this with OEBasicHash or OEBasic?
Aug 17 08:16:32 <JaMa> OEBasic
Aug 17 08:17:17 <bluelightning> would you mind filing a bug? I think that's the most effective way to get these issues fixed
Aug 17 08:17:21 <JaMa> all stamps stay, so if you upgrade from 2.22 to 2.23 and then switch back to 2.22 then it finds 2.22 stamps and doesn't build anything
Aug 17 08:17:44 <JaMa> then switching back from 2.22 to 2.23 again finds stamps from previous 2.23 build and doesn't do anything
Aug 17 08:18:40 <bluelightning> the build of 2.23 is supposed to delete the stamps from 2.22
Aug 17 08:18:47 <bluelightning> at least the populate_sysroot ones
Aug 17 08:18:57 <woglinde> gm
Aug 17 08:19:25 <JaMa> bluelightning: I had also rm_work enabled.. so I wanted to reproduce this first without rm_work
Aug 17 08:19:37 <JaMa> as rm_work is known to be broken on some cases
Aug 17 08:19:46 <JaMa> and rm_old_work on other cases 
Aug 17 08:20:09 <bluelightning> rm_work is tricky, but this doesn't sound like it's related to that
Aug 17 08:20:29 <JaMa> iirc it's only stamp which gets removed
Aug 17 08:20:32 <marc_> as an aside, is there a way to disable rm_work for a specific recipe while working on it?
Aug 17 08:20:45 <JaMa> so rm_work task is executed after version change
Aug 17 08:21:15 <JaMa> marc_: you can call bitbake -c build
Aug 17 08:21:24 <JaMa> marc_: which wont execute rm_work task
Aug 17 08:29:57 <ant_work> JaMa: yes, that's the simple way without adding an empty task to the recipe
Aug 17 08:30:15 <ant_work> (and forgetting to remove it :)
Aug 17 08:33:13 <marc_> JaMa: thanks mate.
Aug 17 09:04:50 <pb_> morning all
Aug 17 09:05:03 <bluelightning> hi pb_
Aug 17 09:36:36 <woglinde> hi pb_
Aug 17 09:49:15 <JaMa> bluelightning: stamps issue reported https://bugzilla.yoctoproject.org/show_bug.cgi?id=2961
Aug 17 09:49:23 <bluelightning> JaMa: thanks
Aug 17 10:08:26 <pb_> hi woglinde, bluelightning
Aug 17 10:37:39 <woglinde> good
Aug 17 10:37:45 <woglinde> openjdk-6-jre-6b24-1.11.3-r20.0: task do_rm_work: Succeeded
Aug 17 11:56:06 <mario-goulart> woglinde: do you know an alternative location for the jamvm git repository?  berlios.de's git is not responding.
Aug 17 12:29:50 <otavio> ... 
Aug 17 12:29:53 <otavio> Hi
Aug 17 12:34:25 <bluelightning> hi otavio, long time no see :)
Aug 17 12:34:42 <bluelightning> well, it seems like a long time
Aug 17 12:39:13 <likewise> hi bluelightning  otavio 
Aug 17 12:39:46 <likewise> It seems we are finally enjoying (?) Brazilian temperatures here.... pfff :)
Aug 17 12:56:33 <otavio> :-D
Aug 17 12:56:42 <otavio> likewise: ahhahaha
Aug 17 12:56:59 <otavio> well, it all depends on the place in Brazil you're referring to
Aug 17 12:57:16 <otavio> bluelightning: any needs about qt5?
Aug 17 12:57:27 <otavio> bluelightning: i'd like to start working on it in september
Aug 17 12:57:54 <bluelightning> otavio: there's a preliminary layer produced by someone else, meta-qt5
Aug 17 12:58:06 <bluelightning> otavio: I have to admit I have not looked at it yet, but apparently it builds
Aug 17 12:58:43 <otavio> bluelightning: i saw it; however it seems to be using qt4 packaging; not qt5 modules
Aug 17 12:58:59 <bluelightning> right, I guess that's just one of the things that needs work
Aug 17 12:59:17 <bluelightning> it's on my todo list...
Aug 17 13:00:45 <otavio> when do you plan to look at it?
Aug 17 13:00:56 <otavio> mario-goulart: did the tarball work?
Aug 17 13:01:16 <otavio> woglinde: do you know why we're using the git repository instead of the tarball for jamvm?
Aug 17 13:01:41 <mario-goulart> otavio: what tarball?
Aug 17 13:01:57 <otavio> mario-goulart: of jamvm
Aug 17 13:02:18 <otavio> mario-goulart: oh; i thought you were trying to use the tarball ...
Aug 17 13:02:21 <mario-goulart> otavio: I haven't tried it.
Aug 17 13:02:39 <otavio> mario-goulart: and didn't find a repository yet ... did you?
Aug 17 13:02:49 <mario-goulart> otavio: not yet.
Aug 17 13:58:32 <mario-goulart> otavio: just got a reply from Robert Lougher (author of jamvm).  He's unaware of the Berlios problem.  He said he's going to connect from home at night and, if things don't work, he will contact Berlios.
Aug 17 16:12:38 <Tartarus> Sigh, should I fix up all of the u-boot-otherstuff recipes or just add new ones for v2012.07 that are correct
Aug 17 16:12:57 <Tartarus> fw-utils should have been, and now needs to pass HOSTSTRIP
Aug 17 16:13:03 <Tartarus> Never been a reason to set HOSTLD
Aug 17 16:13:12 <Tartarus> Always been (but we don't at all atm) pass HOSTCFLAGS
Aug 17 16:13:38 <Tartarus> Always been (but only mkimage does) pass HOSTLDFLAGS
Aug 17 16:16:11 <otavio> Tartarus: I'd say you to add the khem patch for build system too; this patch has been send to u-boot mailing list and it will be included in next release
Aug 17 16:16:18 <otavio> Tartarus: for gold handling
Aug 17 16:25:20 <Tartarus> otavio: I saw the patch go by, yeah, can't find it in U-Boot patchwork atm
Aug 17 16:25:31 <Tartarus> But I'm talking about fixing up the oe-core recipes :)
Aug 17 16:28:11 <khem> bluelightning: ant mentioned you were trying to boot armv4 machine kernel built with gcc 4.7 . did you succeed ?
Aug 17 16:28:30 <khem> bluelightning: I have a patch that should help which he was trying for gcc
Aug 17 16:29:01 <bluelightning> khem: he sent me a new kernel image, I hope to be able to try booting it tonight
Aug 17 16:29:23 <khem> bluelightning: k
Aug 17 16:29:39 <khem> bluelightning: let me know how it goes
Aug 17 16:39:46 <bluelightning> khem: will do, thanks for the assistance
Aug 17 16:51:50 <otavio> Tartarus: I know; but I am suggesting to put this patch on oe-core so next time it will be easier
Aug 17 16:52:23 <Tartarus> otavio: I can't find it in U-Boot patchwork
Aug 17 16:52:40 <Tartarus> And it's probably a bag of pain I don't want to open yet
Aug 17 16:52:53 <Tartarus> Since other layers with $random U-Boot version will need the patch, probably
Aug 17 16:53:12 <Tartarus> Since most aren't appending to u-boot_${VERSION} but using u-boot.inc
Aug 17 16:53:43 <Tartarus> Or am I mis-remembering the plan (denix?)
Aug 17 16:56:29 <otavio> Tartarus: well, I agree but the master branch is not suppose to not break and sometimes we'll need to break something  to proper cleanup stuff
Aug 17 16:56:33 <otavio> Tartarus: let me find it
Aug 17 16:56:51 <Tartarus> otavio: I'd say just handle it in v2012.10
Aug 17 16:56:58 <Tartarus> Drop from u-boot.inc
Aug 17 16:57:03 <Tartarus> move to the old $VER recipe we keep
Aug 17 16:57:10 <Tartarus> let layers fix up, or better yet, upgrade
Aug 17 16:57:25 <Tartarus> I can help folks that have patches for U-Boot that aren't in mainline :)
Aug 17 16:57:37 <otavio> Tartarus: well, it should be possible to make it backward compatible
Aug 17 16:57:52 <otavio> Tartarus: if you grep by ld.bfd you know if it has the patch or not
Aug 17 16:58:02 <otavio> Tartarus: and if it doesn't you can sed it properly
Aug 17 16:58:17 <otavio> Tartarus: so you don't break previous versions 
Aug 17 16:58:35 <Tartarus> Yeah
Aug 17 16:58:41 <Tartarus> Isn't that the u-boot.inc logic now?
Aug 17 16:58:45 <Tartarus> now that I think about it?
Aug 17 17:01:08 <otavio> Tartarus: http://patchwork.ozlabs.org/patch/174781/
Aug 17 17:01:34 <Tartarus> Ah, I was searching for Khem for some reason :)
Aug 17 17:01:52 <otavio> Tartarus: he has authored the change but I sent
Aug 17 17:06:17 <Tartarus> yeah
Aug 17 17:28:08 <cboyd> Is there any documentation on how to use the sstate-cache to decrease the build time for future builds?
Aug 17 17:28:28 <kergoth> set SSTATE_DIR to a path outside of TMPDIR
Aug 17 17:28:29 <kergoth> done.
Aug 17 17:29:38 <cboyd> kergoth: should I just point it to the sstate-cache directory that is created by oe-core?
Aug 17 17:29:54 <kergoth> i don't understand the question
Aug 17 17:30:01 <kergoth> by default the directory is created under tmp
Aug 17 17:30:09 <kergoth> if you set it elsewhere, it will both write there and read from there
Aug 17 17:31:01 <cboyd> i am using the setup-script git repository for my build environment
Aug 17 17:31:26 <cboyd> kergoth: i am using the setup-script git repository for my build environment
Aug 17 17:31:29 <kergoth> and?
Aug 17 17:31:46 <kergoth> edit local.conf, change SSTATE_DIR to a path outside of TMPDIR.
Aug 17 17:31:49 <kergoth> as i said earlier
Aug 17 17:32:29 <cboyd> kergoth: oe-core creates a sstate-cache directory outside of the temp directory which contains files ending in *_populate-sysroot.tgz
Aug 17 17:33:19 <kergoth> listen: if SSTATE_DIR is pointing to a file with sstate archives, then those archives can be used in subsequent builds
Aug 17 17:33:21 <kergoth> it isn't magic
Aug 17 17:33:32 <kergoth> if the dir survives across builds, then your future builds will use it
Aug 17 17:33:45 <cboyd> kergoth: so if one of my co-workers builds an image, can I set SSTATE_DIR to the sstate-cache directory to avoid rebuilding packages that don't need to be rebuilt
Aug 17 17:34:53 <kergoth> again, it's just a directory. if you point it to a directory where he put his files, then they'll be used
Aug 17 17:35:19 <cboyd> kergoth: thanks
Aug 17 17:35:23 <kergoth> you're making it out to be something difficult. it isn't. to share shared state archives, both of you should point sstate dir to the same place. nothing to it. alternatively, use SSTATE_MIRRORS to point to alternative locations
Aug 17 17:35:32 <kergoth> if you don't want to move your SSTATE_DIR, that's an option
Aug 17 17:35:34 <kergoth> np
Aug 17 17:36:01 <cboyd> kergoth: i know it
Aug 17 17:36:23 <cboyd> kergoth: I know its not rocket science, but I just wanted to make sure
Aug 17 17:36:32 * kergoth nods, np
Aug 17 17:37:13 <cboyd> kergoth: is this functionality new to oe-core? Or is there a way to use sstate cache in oe classic?
Aug 17 17:37:22 <Crofton> new to oe core
Aug 17 17:37:32 <kergoth> oe classic had its own similar mechanism, but it was implemented very differently
Aug 17 17:37:39 <kergoth> (packaged staging)
Aug 17 17:37:55 <cboyd> Crofton: yes
Aug 17 17:45:13 <JimNH> What causes an sstate file to be skipped and a new one generated (or what is in the signature of an sstate file?)
Aug 17 17:46:30 <kergoth> it's a checksum of the metadata used in the task being run, and all that task's dependencies
Aug 17 17:47:15 <kergoth> we track references in the metadata, so it knows what variables reference what others to ensure we only capture what was used
Aug 17 17:47:40 <kergoth> so e.g. adding an unused global variable won't change your checksums
Aug 17 17:48:00 <kergoth> oh, it also includes checksums of local files used in SRC_URI (file:// uris)
Aug 17 18:37:53 <JimNH> ah very cool tu
Aug 17 21:22:36 <ka6sox> ant__, will do
Aug 17 21:25:09 <ant__> great, thx
**** ENDING LOGGING AT Sat Aug 18 03:00:00 2012