| * smb grumbles about unhelpful service providers | 07:58 | |
| === FreezingCold is now known as Richsoft | ||
| === Richsoft is now known as FreezingCold | ||
| cking | smb, still no luck? | 09:15 |
|---|---|---|
| smb | cking, nope (except tethering) | 09:16 |
| cking | smb, did they give you any idea when you would get it fixed? | 09:16 |
| 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:17 |
| 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 | 09:18 |
| === fmasi_afk is now known as fmasi | ||
| === fmasi is now known as fmasi_afk | ||
| cking | smb, quality service provision :-/ | 09:32 |
| === fmasi_afk is now known as fmasi | ||
| smb | cking, Yeah, probably even ISO certified (keep technical staff firewalled behind a call center) | 09:39 |
| 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. | 10:32 |
| xnox | v41: https://launchpad.net/ubuntu/+source/linux/3.11.0-13.20 lists a few bug fixes for btrfs. | 11:10 |
| 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:13 |
| 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 :) | 11:17 |
| * ppisati -> out for lunch | 12:59 | |
| === fmasi is now known as fmasi_afk | ||
| === fmasi_afk is now known as fmasi | ||
| 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:26 |
| ppisati | stgraber: nope, is off now | 15:28 |
| 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:29 |
| rtg | stgraber, IIRC there is a firmware udeb where the DTBs sholdgo. | 15:36 |
| rtg | should go* | 15:36 |
| stgraber | rtg: so all the current ones appear to be in the kernel-image udeb | 15:42 |
| stgraber | rtg: I can't find a generic firmware udeb, the only ones I see come from the linux-firmware source | 15:43 |
| rtg | stgraber, which kind of makes sense (that they are in the kernel image udeb). lemme refresh my memory about firmware. | 15:44 |
| 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:27 |
| 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:29 |
| jsalisbury | jodh, cool, thanks. Just like to have to bug reporter test to confirm it fixes the problem. | 16:31 |
| === 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 | ||
| 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:38 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| infinity | stgraber: Selfish. ;) | 18:53 |
| rtg | stgraber, uploaded trusty with your DTB patch (somewhat modified) | 20:08 |
| stgraber | rtg: thanks! | 20:09 |
| stgraber | rtg: oh I see, I guess it works better when applied to the right place ;) | 20:11 |
| rtg | stgraber, yup | 20:11 |
| infinity | CONFIG_OABI_COMPAT=n | 20:18 |
| infinity | That was seriously not set before? | 20:18 |
| rtg | infinity, nope, kees pointed it out | 20:19 |
| 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:20 |
| rtg | there are a zillion config options. I'm not surprised we missed this one for awhile | 20:21 |
| 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:23 |
| rtg | I likely inherited it from somewhere and didn't notice. | 20:24 |
| 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:40 |
| rtg | kees, confused for a sec. I was still thinking CONFIG_HAVE_ARCH_SECCOMP_FILTER=y | 21:41 |
| infinity | kees: Yeah, it should definitely default to n, given the lack of userspace support these days. | 21:42 |
| kees | rtg: ah, yeah, no, I meant CONFIG_OABI_COMPAT. :) | 22:02 |
| 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:03 |
| kees | rtg: np, sorry for wasting a build :( | 22:08 |
| rtg | kees, make M=kernel takes very little time | 22:09 |
| kees | heh, okay, whew :) | 22:09 |
| 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:10 |
| kees | ah! okay. | 22:11 |
| === fmasi is now known as fmasi_afk | ||
| * rtg -> EOW | 23:07 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!