[10:04] <Snark> plop
[10:05] <Snark> doko, I would like to help on https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/713985
[10:05] <ubot2`> Launchpad bug 713985 in eglibc "[armel] Function tgammal has precision issues in version 2.12.1-0ubuntu10.2 on ARM" [Undecided,Confirmed]
[10:12] <Snark> doko, if you have a clue about the problem but no time to work on it, I'll take the clue and try to do something with it
[10:12] <Snark> if you have no clue, I'll just try anyway :-p
[10:14] <doko> Snark, I won't work on it. first thing might be to recheck with 2.13 and 2.15
[10:14] <Snark> it's still there with 2.13
[10:14] <Snark> where can I get 2.15 ?
[10:18] <doko> in the ubuntu-toolchain-r/glibc ppa
[10:19] <Snark> and there is an armel package too?
[10:21] <Snark> aie
[10:21] <Snark> found it
[10:29] <Snark> hmmm... adding the ppa isn't enough :-/
[10:30] <Snark> it basically wants to remove the rest of the system
[10:50] <Snark> doko, the only place where I find lgammal mentioned in eglibc_2.13-20ubuntu5.diff.gz is in a patch for sysdeps/ia64/fpu/libm_error.c, so I guess the bug is upstream
[11:24] <doko> you should debootstrap a precise chroot
[11:32] <Snark> doko, I don't think I have enough room on this poor box :-/
[13:16] <rbasak> How can I generate an installer uInitrd (as found at http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/current/images/omap4/netboot/uInitrd)? I'm trying to test different kernels with the installer.
[13:17] <ogra_> rbasak, only by building the installer
[13:17] <ogra_> which is highly complex
[13:17] <ogra_> what exactly do you want to test ?
[13:18] <rbasak> The current installer kernel panics on my panda sometimes. I've now automated a repeated test to find out if a given installer uImage/uInitrd is good or bad.
[13:18] <ogra_> (if its only the booting of the installer you can just replace the uImage
[13:18] <rbasak> ppisati asked me to test the latest kernel that is in the archive but not in the installer right now
[13:18] <rbasak> and if it is I'll need to bisect
[13:18] <ogra_> if its more than just booting it gets more complex since d-i uses the udeb packages your kernel build created during the package creation
[13:18] <rbasak> Won't I need the modules in uInitrd though?
[13:19] <rbasak> Yeah it panics some time in userspace after the kernel boots
[13:19] <ogra_> ah, yeah, that would mean to roll d-i from scratch and make it use the newly created udebs
[13:19] <rbasak> Surely there's a script somewhere that builds the installer? Or does that depend heavily on hitting the archive?
[13:19] <ogra_> (and indeed that means creating the udebs, not sure that works in a cross way at all)
[13:20] <ogra_> the "script" is a makefile in the installer source
[13:20] <ogra_> in fact a ton of different scripts
[13:20] <ogra_> that are used by that makefile
[13:20] <rbasak> It hits the archive for the kernel I take it?
[13:20] <ogra_> well... apt-get source debian-installer
[13:21] <rbasak> I'll have a poke around, thanks
[13:21] <ogra_> building it pulls in a lot of other packages, then takes the udebs (from the kernel and elsewhere) and generates the initrd from it
[13:21] <rbasak> what I'd really like is an archive overlay system
[13:21] <ogra_> there might be a way to pull in the udebs manually from tty4
[13:22] <ogra_> as long as you manage to do the boot up to that point
[13:22] <ogra_> (apt-install is the command to install udebs iirc, i havent touched the installer for a while)
[13:22] <rbasak> Can I get to tty4 down ttyO2?
[13:23] <ogra_> i dont think so, but on serial you can use the "back" option in the installer, that gets you to the menu where you can select the shell
[13:23] <rbasak> ah ok, thanks
[13:24] <rbasak> I wonder if I could just hack the uInitrd and insert the kernel modules manually
[13:26] <ogra_> you could try indeed...
[14:07] <rbasak> what can we do to get the installer updated to use the new kernel?
[14:42] <kos_tom> hello
[14:42] <kos_tom> is there a place with a known-working version of MLO+u-boot.bin+kernel+Ubuntu rootfs that works on BeagleBoard XM rev C, with USB and graphics?
[14:43] <kos_tom> so far, we have something that boots, but no USB devices are detected (nothing in the kernel logs)
[15:48] <Snark> doko, where are the file dependencies to be found in glibc's sources?! I don't know if my platform uses sysdeps/ieee754/ldbl-128/e_lgammal_r.c or sysdeps/ieee754/ldbl-96/e_lgammal_r.c...
[17:06] <ppisati> GrueMaster: question, did you try to change eth0 mac address with latest omap3 kernel?
[17:07] <GrueMaster> My latest omap3 kernel I tested had a serious bug with mmc.  Haven't tried anything later.
[17:07] <GrueMaster> I'll check it shortly though.  What rev?
[17:15] <GrueMaster> rbasak: Have you filed a bug against the kernel in the netinstaller for panda?
[17:15] <rbasak> no
[17:16] <rbasak> I was wondering whether to add a debian-installer task to the existing bug
[17:16] <rbasak> I've been working on trying to test the latest kernel but that turns out to be quite complicated
[17:18] <GrueMaster> Well, it appears to only affect armhf.  I just rebuilt a panda with armel no problem.  I'm checking my mirror now to make sure the two are in sync.
[17:19] <GrueMaster> They appear to be.
[17:19] <ogra_> would be hard fro them to be out of sync :)
[17:20] <ogra_> (same source and d-i would ftbfs if they werent the same version)
[17:20] <GrueMaster> you haven't seen my mirror.
[17:20] <GrueMaster> It occasionally gets out of sync with ports.u.c.
[17:27] <GrueMaster> Hmmm.  armel failed on the same platform as armhf, but one machine reimaged with armel just fine.  This may need further research.
[17:27] <ppisati> any output?
[17:28] <GrueMaster> ppisati: http://paste.ubuntu.com/822806/
[17:29] <ppisati> GrueMaster: this is the 1404 kernel, and that bug was fixed in 1405
[17:48] <GrueMaster> Right, just odd that it fails on some of my platforms but not others.  And it appears to be older ones only (EA1, A1).
[17:59] <GrueMaster> rbasak: While you are waiting for an updated netinstall, I have found that using the newer kernel with the exisiting uInitrd works fine for installing.  Running here now w/o errors so far, and it is into the base system step.
[18:23] <rbasak> GrueMaster: that's great, thanks! I was writing a script to inject the newer kernel modules into an older uInitrd, but I can leave that for now then :-)
[18:24] <GrueMaster> Yea, I'm not sure what modules get loaded during netinstall, but obviously no critical modules.
[22:51] <rbasak> GrueMaster: I'm getting occasional failures on armhf with a hand-built latest git tree kernel on armhf. But quite rare, and unhelpfully the error message is reported to be in syslog, which I can't get to over ttyO2.
[22:51] <rbasak> GrueMaster: I'm running the install in a loop, I'll see tomorrow what the success/failure proportion is.
[22:51] <GrueMaster> Try adding "earlyprintk=ttyO2,115200".
[22:52] <GrueMaster> And make sure "quiet" is not in your boot.scr.
[22:52] <rbasak> yes, i have those. It's a debootstrap failure
[22:53] <rbasak> http://paste.ubuntu.com/823204/
[22:53] <GrueMaster> Ah.  Well, there is a way to enable the web interface in the preseed so that you can monitor syslog from the web.
[22:53] <rbasak> I've seen it twice now
[22:54] <infinity> debootstrap failures are generally mirror/network issues.
[22:54] <infinity> But you could skip doing this as an installer loop and just loop debootstrap a few dozen times.
[22:54] <GrueMaster> I haven't seen this at all.  Can you past your preseed and I'll see if I can reproduce it here?
[22:55] <rbasak> I'm running through a squid proxy, don't see any errors in the log though I might be missing it
[22:55] <infinity> Squiq won't show errors, but the client system sure might.
[22:55] <infinity> Stale caches can do horrible things to apt-like clients.
[22:56] <infinity> (Not that debootstrap is apt, but it still verifies signatures and hashes, which means cache coherency (or no cache) is required)
[22:56] <rbasak> preseed: http://paste.ubuntu.com/823207/ - it's got a proxy in there you might want to change
[22:56] <rbasak> yeah but the previous and following installs work OK, so it can't be a stale cache problem
[22:56] <infinity> Sure it can.
[22:57] <infinity> If the timeouts are staggered enough, you'd have what appears to be a consistent mirror, followed by inconsistent, followed by consistent.
[22:57] <GrueMaster> That is more than likely the issue.  I see issues occasionally here, and just rekick after my mirror update runs (every 2h).
[22:57] <infinity> Assuming a mirror pulse in the middle, and getting one caches result and one fresh.
[22:57] <infinity> s/caches/cached/
[22:58] <rbasak> so we can't reliably run a netinst over a proxy cache? that sounds like an issue to me.
[22:58] <rbasak> (I have Packages.gz etc. configured to be refreshed every time)
[22:59] <infinity> And Release*?
[22:59] <rbasak> refresh_pattern \/(Packages|Sources)(|\.bz2|\.gz)$ 0 0% 0
[22:59] <rbasak> refresh_pattern \/Release(|\.gpg)$ 0 0% 0
[22:59] <infinity> On a stable release, it's much less of an issue, since we don't change the release pocket.
[22:59] <infinity> But yeah, 99% of issues like this are usually a proxy's fault.
[23:00] <infinity> The other 1% are actual broken mirrors.
[23:03] <rbasak> thanks
[23:08] <GrueMaster> I see it usually when installing at the same time my mirror is updating packages and hasn't finished updating all of the Packages.[gz|bz2] files.
[23:08] <GrueMaster> So not as often.