[08:45] <xranby> diwic: the contextgetstate.patch worked fine..    and solved the exception bug on arm
[08:45] <diwic> xranby, \o/
[08:46] <diwic> xranby, was it enough to bring up the hajpa hajpa?
[08:46] <xranby> yeah at least for one of the two jvm's
[08:46] <xranby> the other jvm had its own classloader bug..
[08:47] <diwic> xranby, but that was maybe unrelated to pulseaudio?
[08:48] <xranby> diwic: correct the pulse-audio java layer looks bugfixed now   , thanks!     the only thing that can break it now are if the java virtual machine have missed to implement some part of the jvm specification
[08:48] <diwic> ok
[08:49] <xranby> diwic: and for arm we are in the situation that oracle do not provide an opensource reference implementation like on x86 :/ so it takes time to get everything super polished
[08:51] <diwic> xranby, ok so a lot of that reference implementation is written in platform dependent language (e g assembly?)
[08:51] <diwic> xranby, vaguely remember you tried to explain some of that stuff at latest UDS
[08:52] <xranby> diwic: yes highly platform dependent,  and optimized java virtual machine port contains about 80000 lines of platformspecific code
[08:53] <diwic> ouch
[11:09] <TheSeven> hm, is the ARM cross compiler toolchain for x86 currently broken?
[11:09] <TheSeven> (in oneiric)
[11:12] <TheSeven> apparently the libgcc1-armel-cross package is missing
[14:31] <xranby> diwic: it turned out that the reverence implementation did not strictly implement the jni spec :) http://icedtea.classpath.org/hg/icedtea6/rev/23b9bb41de6d
[14:31] <xranby> now \o/ hajpa hajpa work on arm
[14:32] <diwic> hajpa hajpa!
[14:35] <janimo> infinity, ac100-tarball-installer in moderation queue
[16:04] <GrueMaster> ppisati: Can you look at Bug 865479?  Thanks.
[16:04] <ubot2> Launchpad bug 865479 in linux-ti-omap4 "wl1271: ERROR ELP wakeup timeout" [Undecided,New] https://launchpad.net/bugs/865479
[16:04] <GrueMaster> Not sure that it is critical, just that it exists.
[16:07] <GrueMaster> infinity: I'm still consistently getting oem-config to respawn.  Looking at the log files, I believe this may be the problem:   Oct  3 08:12:05 localhost ubiquity: debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable
[16:09] <GrueMaster> Hard to tell, as that message is almost a minute before the respawn message, but it is the only negative message before the next instance of oem-config respawn in syslog.
[16:12] <brandini> I tried to get mongodb working over teh weekend but didn't make it very far
[16:39] <infinity> GrueMaster: I can't get this respawn thing happening at all. :/
[16:40] <infinity> GrueMaster: I can get the installer to explode in general based on cron.daily eating the system alive.  That's about it.
[16:40] <infinity> (And I plan to hack around that with a kludge today)
[16:41] <GrueMaster> Pfft.  Figures.  Most of the bugs I find are easily reproducible here, but no where else.
[16:44] <GrueMaster> I wonder if the cron.daily stuff is blocking me.  Maybe it is doing an apt-get update at the same time?
[16:45] <GrueMaster> That could explain why I see it and others don't.  Timing.
[16:46] <GrueMaster> Oh, and the slideshow works again.  :)
[17:03] <brandini> what steps are involved in bringing support for a new chip like the Cortex A9 to an OS
[17:05] <infinity> The A9 is new?
[17:05] <infinity> GrueMaster: The cron.daily thing can just explode in general due to system load.  I think the debconf DB thing might be a red herring, though.  Let me check the log on a successful install run.
[17:07] <infinity> GrueMaster: Yeah, I have that same debconf locking spew on a successful install.
[17:07] <infinity> GrueMaster: So, while it's likely a bug somewhere, it's probably not causing an issue either.
[17:08] <brandini> infinity: new to that os :)
[17:08] <GrueMaster> I just had ubiquity fall apart when I tried to run without any networking.  Really bad.
[17:09] <infinity> brandini: Well, things like A8->A9 are really just about building support into toolchains and kernels for shiny new features you might care about, and building support into bootloaders to bring them up.
[17:09] <GrueMaster> Hmm.  Something caused the filesystem to remount read-only.
[17:09] <infinity> brandini: But since all your binaries already run (yay backward compat), it's not much effort.
[17:10] <brandini> ok
[17:10] <infinity> GrueMaster: Read-only filesystems usually point to hardware hating you, with a 5% chance of kernel bug...
[17:10] <infinity> (Well, less than 5%, since we tightly control our target platforms here, and we aren't all seeing ro filesystems)
[17:11] <GrueMaster> infinity: I'm the guy that nails that 5%.
[17:11] <infinity> Or your hardware hates you. ;)
[17:12] <infinity> I hate to beat the same dead horse, but when working on SD, I'd tend to blame cards for a filesystem going tits-up before anything else.
[17:12] <infinity> And I really think we should do most of our test installs on hard drives.
[17:12] <GrueMaster> Multiple SD cards and multiple Panda's?  I highly doubt I can be having a complete failure here.  The odds are against it being my HW.
[17:12] <infinity> Except hitting a card once in a while to make sure the code paths still do what we think they do. :P
[17:13] <infinity> GrueMaster: The odds for hardware are still higher than the idea that a deterministic automated installer only fails in one person's house.
[17:13] <GrueMaster> infinity: Can't test on hard drives.  The preinstalled images are designed around SD.  It would be equivalent to testing in a VM.
[17:13] <infinity> GrueMaster: And you've been beating on the same SD cards for a while, I'd guess.
[17:13] <GrueMaster> Some are almost brand new since A2.
[17:14] <infinity> GrueMaster: Preinstalled would work on an HDD just fine.
[17:14] <infinity> (Just need to write it differently)
[17:14] <infinity> But yeah.  I know the situation we're stuck in.  I just dislike it. :P
[17:14] <infinity> I have 5 cards in front of me, and I only trust one of them.
[17:14] <infinity> And that trust won't last forever.
[17:16] <GrueMaster> I have ~2 different cards per board at my disposal.  Varying sizes, speeds, an brands.  To see these issues across multiple SD cards on Panda A1, A2, and A3 systems is extremely rare.
[17:16] <infinity> Well, wait, which issues?  The ro filesystem above sounded like a one-off.
[17:17] <GrueMaster> Remember, I have almost 10 years in hardware validation.  I know very well how to triage hardware failures.
[17:17] <GrueMaster> That was the first time I saw it, but also the first time I booted w/o networking.
[17:17] <infinity> Correlation and causation not being the same thing. :P
[17:18] <GrueMaster> And ubiquity crashed with a UBI failure of some sort.  Just getting ready to look at the log.
[17:18] <infinity> But it's possible 'fixrtc' stopped working or some such, which could lead to network->badtime->fsbreak.
[17:18] <infinity> But that should break early.
[17:18] <infinity> The log will be useless if the filesystem is ro.  Unless you're really lucky.
[17:19] <infinity> dmesg is more likely to be useful.
[17:19] <GrueMaster> fixrtc only runs during boot in initrd I thought.
[17:19] <infinity> Well, it's an at-boot thing.  To fix the clock...
[17:19] <infinity> We don't then break the clock later. :P
[17:19] <GrueMaster> Since these images don't have any way to get a terminal session without first modifying the image prior to boot, there is no way to debug a live session.
[17:19] <infinity> So, if it's not working, then without ntpdate, your clock will be a sad panda.
[17:20] <infinity> Yeah, that's so obviously an ARM preinstalled bug.  I noticed it with the last week of debugging. :/
[17:21] <infinity> Since a real live system has the "ubnutu" user, and a real oem-config system has an oem user.
[17:21] <infinity> But we fail to have either.
[17:21] <infinity> Not fixing that before release, though.
[17:21] <infinity> Worth having on the TODO if jasper survives.
[17:23] <GrueMaster> Log files are a bust.  complete corruption prior to any ubiquity info.  Interesting to see network manager completely freak out though.
[17:24] <GrueMaster> and I have asked for debug hooks of some sort since we started doing preinstalled images.
[17:55] <infinity> GrueMaster: When does the loop happen?
[17:55] <infinity> GrueMaster: I'm going to sit here and try to reproduce this...
[17:56] <GrueMaster> Right around the time it says that it is copying log files.
[17:56] <infinity> GrueMaster: Does everything complete (including the removal)?
[17:56] <GrueMaster> Does not start the removal.
[17:57] <infinity> Hrm.
[17:57] <infinity> I also might not be able to fix the anacron issue this cycle, the more I think about it.
[17:57] <infinity> The fix needs to be in ubiquity, and might be regression-inducing.
[17:58] <infinity> I realised I can't hack around it in jasper, because we don't actually have a sane clock yet.
[17:58] <GrueMaster> Nothing (other than what I previously stated about the config.dat) indicates an issue in any log files I have.
[18:00] <GrueMaster> Hmm.  Doesn't appear to like me hacking in an additional debug user prior to oem-config running.  It has been sitting on "Creating User" for a while now.
[18:14] <GrueMaster> Grrr,  Doesn't appear to like my shadow entry.
[21:06] <infinity> GrueMaster: *poke*
[21:07] <infinity> GrueMaster: Can you do some test runs on your problematic systems with 's/update-apt-xapian-index -q/update-apt-xapian-index -q -u/' in /etc/cron.daily/apt ?
[21:07] <infinity> GrueMaster: Seems to have made mine slightly less grumpy.
[21:30] <GrueMaster> infinity: On it now.
[21:30] <GrueMaster> (took an extended lunch break).
[21:30] <infinity> GrueMaster: All good.  Food sounds like a stellar plan to me too.
[21:49] <GrueMaster> Starting the test now on a freshly zero'd & flashed drive.  Even if this solves the oem-config respawn, we still have another issue where ubiquity crashes when no network available.
[21:54] <infinity> GrueMaster: Do you have logs for the no-network thing?  That one couldn't have been silent... I hope.
[21:54] <infinity> GrueMaster: Or even an apport-filed bug would be nice.
[21:55] <GrueMaster> Well, that was part of the problem.  ubiquity crashed saying it would spawn a desktop session for debugging, but that failed to materialize.  And nothing was captured in the logs as the system had gone read-only.
[21:56] <GrueMaster> I'll try to reproduce it as well.  I would really like to have an image that I can get to a login for testing though.  Otherwise I am just spinning my wheels on useless stuff.
[21:56] <infinity> Oh, that was the read-only one, right.
[21:56] <infinity> I suspect that one might not be reproducible, but if it is, great.
[21:57] <infinity> If the FS isn't readonly, ubiquity crashes will spawn apport, which is good enough for filing bugs with logs, at any rate.
[21:57] <infinity> If jasper survives another cycle, we should remember to add the oem user, though.
[21:58] <GrueMaster> I'll prep another SD to test that, but for desktop, I am kind of limited to single tasking (1 monitor & keyboard for Pandas).
[21:58] <infinity> Oh, wait.  No.  There shouldn't be one, it's deleted by oem-config-prepare before rebooting.
[21:58] <infinity> So, oem-config in general just has no way to debug it.  Hrm.
[21:59] <GrueMaster> Not that I have found useful.
[21:59] <infinity> I've been testing on my ac100 too.  Which picks up slightly different bugs just due to the timing of having faster storage.
[21:59] <infinity> Panda and ac100 together seem to get most everything.. Except your respawn issue. :/
[21:59] <GrueMaster> And fail.  The cron.daily fix is bust.
[22:00] <infinity> Well, it does address *a* problem.  Just not yours, apparently.
[22:00] <infinity> And I honestly can't get ubiquity to crash/respawn at all (or finish/respawn, or any combination thereof), so I'm kinda stumped.
[22:01] <infinity> A full set of logs (heck, just /var/log tarred up) from the SD might be enlightening.
[22:02] <GrueMaster> Unfortunately, it isn't as enlightening as one would expect.  I have yet to find a significant entry in any logs under /var/log.
[22:03] <GrueMaster> The best I had was the debconf config.dat file (which you said wasn't significant).
[22:07] <GrueMaster> Sigh.  I hate the automount "feature".  It really annoys me.  And what's with the AC100 showing (and mounting) all of the SERVICEV001 partitions?
[22:09] <infinity> GrueMaster: It doesn't?
[22:09] <infinity> GrueMaster: At least, it doesn't here.
[22:10] <infinity> GrueMaster: You sure that's not a freshly-flashed card?
[22:10] <GrueMaster> Could be because I upgraded from Natty.
[22:10] <infinity> (It's only SERVICEV001 after it's booted)
[22:10] <GrueMaster> I'm talking about the eMMC.
[22:11] <infinity> Oh.  yeah, I get no weirdness here.
[22:11] <infinity> You might want to try the recent images. :)
[22:11] <infinity> They actually work better than OMAP.
[22:11] <infinity> Which is a bit sad.
[22:11] <infinity> But yay for faster storage.
[22:11] <GrueMaster> As I said, if there is >.01% chance of weirdness, I will hit it.
[22:12] <infinity> Anyhow.  Going to take a late lunch.
[22:12] <infinity> Back later to keep banging on things.
[22:13] <infinity> On the looping installer thing, if you can just let it settle a bit after it loops, so it's sure to have flushed some buffers, yank the card, and give me /var/log in a tarball, maybe I'll spot something that doesn't add up compared to one here.
[22:14] <GrueMaster> I usually wait until it comes up, then switch to text console and 3-finger reset so everything shuts down cleanly.
[22:16] <infinity> You could just alt-sysrq-s to force a sync, wait for the SD light to go out, and yank it.  That has the advantage of basically being a snapshot of the problem area without reboot fluff afterward.
[22:17] <GrueMaster> reboot fluff is minimal (and tarball is in my people.c.c dir (firtname)/20111003-oem-fail-logs.tgz
[22:18] <infinity> Great, I'll look at it after lunch.
[22:18] <infinity> That's the re-spawn one?
[22:18] <GrueMaster> starting on the network-less run.
[22:18] <GrueMaster> Yes.
[22:18] <infinity> Kay.
[22:19] <GrueMaster> W/o network crashes much more ugly before it even gets that far.\
[22:27] <GrueMaster> Grr.  Network crash didn't happen this time around, but oem-config respan did.