[07:58]  * smb grumbles about unhelpful service providers
=== FreezingCold is now known as Richsoft
=== Richsoft is now known as FreezingCold
[09:15] <cking> smb, still no luck?
[09:16] <smb> cking, nope (except tethering)
[09:16] <cking> smb, did they give you any idea when you would get it fixed?
[09:17] <smb> cking, No, that would be far too helpful. Things change between, this can take days to we don't think we have an issue
[09:18] <cking> sigh
[09:18] <cking> that's really awful
[09:18] <smb> One of the main issues is that it is *impossible* to actually talk to any technical staff
=== fmasi_afk is now known as fmasi
=== fmasi is now known as fmasi_afk
[09:32] <cking> smb, quality service provision :-/
=== fmasi_afk is now known as fmasi
[09:39] <smb> cking, Yeah, probably even ISO certified (keep technical staff firewalled behind a call center)
[10:32] <v41> Is the linux-generic-lts-saucy package (version 3.11.0.13.12) based upon mainline kernel 3.11.3 or 3.11.5+ ? The reason for asking is that some critical btrfs filesystem bugs in 3.11.3 have been fixed in 3.11.5 .  I checked the ubuntu-to-mainline-kernel-version-mapping-page, but it doesn't list version 3.11.0.13.12.
[11:10] <xnox> v41: https://launchpad.net/ubuntu/+source/linux/3.11.0-13.20 lists a few bug fixes for btrfs.
[11:13] <smb> IF it is that linux-image version it should be based on 3.11.6
[11:13] <v41> xnox:  yes, the kernel-version-mapping page shows that 3.11.0-13.20 is based upon 3.11.6, so it contains the btrfs fixes.  But linux-generic-lts-saucy is based upon an earlier version, 3.11.0.13.12
[11:13] <smb> That version number looks like the one from a meta package
[11:17] <v41> smb:  Thankyou, that clears up the problem.  As you suggested, the meta package depends upon linux-image version 3.11.0-13.20 .   I ought to have checked this before asking the question.  (Headslap).
[11:17] <smb> -> 3.11.0-13.20~precise2
[11:17] <smb> linux-image-3.11.0-13-generic
[11:17] <smb> Right :)
[12:59]  * ppisati -> out for lunch
=== fmasi is now known as fmasi_afk
=== fmasi_afk is now known as fmasi
[15:26] <stgraber> apw: around?
[15:26] <stgraber> apw: I'm looking at tweaking our d-i armhf images a bit and one thing that'd help quite a bit there is for all the existing .dtb to be shipped in the udeb
[15:28] <ppisati> stgraber: nope, is off now
[15:29] <stgraber> ppisati: ok, anyway, I think I've got a patch that should do the trick, I'll send that to the list asking if there may also be a way to avoid having those hardcoded in two places
[15:29] <stgraber> ppisati: as apparently just having the dtb enabled in the kernel config isn't enough, they also need to be added to rules.d/armhf.mk to actually show up in the udeb
[15:36] <rtg> stgraber, IIRC there is a firmware udeb where the DTBs sholdgo.
[15:36] <rtg> should go*
[15:42] <stgraber> rtg: so all the current ones appear to be in the kernel-image udeb
[15:43] <stgraber> rtg: I can't find a generic firmware udeb, the only ones I see come from the linux-firmware source
[15:44] <rtg> stgraber, which kind of makes sense (that they are in the kernel image udeb). lemme refresh my memory about firmware.
[16:27] <jsalisbury> jodh, Hey James, when you have a chance, can you test the kernel posted in bug 1247769 I can send that patch to the mailing list if you confirm it fixes the bug.
[16:27] <ubot2> Launchpad bug 1247769 in linux (Ubuntu Trusty) "kernel headers do not define OVERLAYFS_SUPER_MAGIC " [Medium,In progress] https://launchpad.net/bugs/1247769
[16:29] <jodh> jsalisbury: currently working on a release (I can look on Monday), but can't that just be tested by someone simply grepping for OVERLAYFS_SUPER_MAGIC in the appropriate header?
[16:31] <jsalisbury> jodh, cool, thanks.  Just like to have to bug reporter test to confirm it fixes the problem.
=== fmasi is now known as fmasi_afk
=== smb` is now known as smb
=== fmasi_afk is now known as fmasi
=== cnd` is now known as cnd
[18:38] <ppisati> either i'm doing somthing wrong or upstream u-boot is broken WRT omap3/am335x
[18:38] <ppisati> and with that said, /me call it a day/week
[18:38] <ppisati> EOW
[18:44] <stgraber> rtg: any idea when these two extra dtb will land in the archive? It's currently blocking a d-i change I'm preparing.
[18:45] <rtg> stgraber, I assume you're targeting trusty ? noly one of them is supported for Saucy.
[18:45] <rtg> only*
[18:45] <stgraber> rtg: yeah, I only care about trusty
[18:45] <rtg> stgraber, gimme a bit. I can get it uploaded today.
[18:45] <stgraber> rtg: I'm reworking the way we generate armhf d-i images to be much faster and use the upstream u-boot with the generic kernel for all boards using device-tree
[18:45] <stgraber> rtg: awesome, thanks!
[18:46] <rtg> stgraber, I was messing with generating the udeb from the DTB list, but I'll just postpone that for now
[18:46] <rtg> too many distractions right now
[18:47] <stgraber> yeah, I think it'd be good to get there eventually so adding support for extra boards isn't nearly as painful, but for now I mostly care about getting my wandboard be installable ;)
[18:53] <infinity> stgraber: Selfish. ;)
[20:08] <rtg> stgraber, uploaded trusty with your DTB patch (somewhat modified)
[20:09] <stgraber> rtg: thanks!
[20:11] <stgraber> rtg: oh I see, I guess it works better when applied to the right place ;)
[20:11] <rtg> stgraber, yup
[20:18] <infinity> CONFIG_OABI_COMPAT=n
[20:18] <infinity> That was seriously not set before?
[20:19] <rtg> infinity, nope, kees pointed it out
[20:20] <rtg> I hate xchat
[20:20] <infinity> rtg: I mean, it's mostly a no-op on the userspace side, since we tore OABI (completely) out of glibc a couple of releases back.
[20:20] <infinity> But still.  Wha?
[20:21] <rtg> there are a zillion config options. I'm not surprised we missed this one for awhile
[20:23] <infinity> rtg: Yeah, I'm just surprised it was ever on in the first place, since our userspace has been EABI from day one.
[20:23] <infinity> Though, maybe someone made an argument for the compat long ago.
[20:24] <rtg> I likely inherited it from somewhere and didn't notice.
[21:40] <kees> infinity, rtg: it's been "default y" in mainline, so that's probably why. it does add syscall overhead to have built in. anyway, I sent a patch to "default n" it in mainline...
[21:41] <rtg> kees, confused for a sec. I was still thinking CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
[21:42] <infinity> kees: Yeah, it should definitely default to n, given the lack of userspace support these days.
[22:02] <kees> rtg: ah, yeah, no, I meant CONFIG_OABI_COMPAT. :)
[22:03] <kees> rtg: and sorry about the glitch on the seccomp patch. It seems I totally screwed up my "master" checkout months ago and didn't notice "git pull" was doing merges :(
[22:03] <kees> rtg: I've sent a pull request now with the two missing upstream patches too.
[22:03] <rtg> kees, cool
[22:03] <rtg> thanks
[22:08] <kees> rtg: np, sorry for wasting a build :(
[22:09] <rtg> kees, make M=kernel takes very little time
[22:09] <kees> heh, okay, whew :)
[22:10] <kees> I've also forgotten the joys of 64-way builds. first world problem of now having ONLY 32-way :)
[22:10] <rtg> kees, oh, I'm doing this on a Calxeda. I wanted to make sure the cross compile wasn't the issue.
[22:11] <kees> ah! okay.
=== fmasi is now known as fmasi_afk
[23:07]  * rtg -> EOW