[00:17] <kees> does anyone know how ppc64el handles CONFIG_COMPAT? it seems to have the ability to handle 32-bit syscalls, but I see no mention of CONFIG_COMPAT in defconfigs
[00:19] <kees> oh, but it's in the Kconfig. nevermind!
[14:00] <infinity> zequence: LP: #1427850 <--- That time again.
[14:01] <infinity> zequence: Oh, and you've already done it.
[14:01] <infinity> zequence: Way to be proactive; ignore me.
[14:32] <MegaBrutal> Hello! When will 3.16.0-32-generic be released?
[15:23] <bjf> MegaBrutal, it will hit -updates in approx. 2 weeks
[15:25] <bjf> MegaBrutal, it will be in -proposed sometime today
[15:26] <MegaBrutal> bjf: 2 weeks? Why does it take so long? Can you link some info about the Ubuntu kernel release cycle? (I was searching the Ubuntu wikis, but didn't find a table about the planned release dates or so.)
[15:27] <bjf> MegaBrutal, it goes through testing and bug verification before -updates
[15:28] <MegaBrutal> Can I help with that somehow?
[15:28] <bjf> MegaBrutal, you can install the kernel when it hits -proposed and if there are any regressions file bugs against it
[15:30] <bjf> MegaBrutal, https://wiki.ubuntu.com/Kernel/Handbook
[15:30] <bjf> MegaBrutal, i haven't read that for some time so i'm not sure exactly what you are looking for is in there
[15:31] <MegaBrutal> bjf: Actually, I expect it to fix Launchpad 1396889. This commit will do the magic: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-utopic.git;a=commitdiff;h=665cd5467479366d98930108db392a0785bf765a;hp=ce1161dde994bafe05f749f64c31904699239889 - but it will only appear in 3.16.0-32-generic, if I'm correct.
[15:32] <MegaBrutal> bjf: Btw, thanks for all the info! :)
[15:37] <bjf> MegaBrutal, i'm looking but i don't see that fix in our utopic tree
[15:37] <bjf> MegaBrutal, oh, one sec ... let me refresh my git tree
[15:39] <bjf> MegaBrutal, the commit you reference in that bug has been in the Utopic kernel since the first 3.16.0-22.29 (and earlier)
[15:40] <bjf> MegaBrutal, ignore me ... i'm still not awake
[15:41] <MegaBrutal> bjf: Which commit? The one which introduces the bug, or the one which fixes it?
[15:41] <bjf> MegaBrutal, yeah, i was looking at the bad commit not the fix
[15:41] <bjf> MegaBrutal, so i'm on the same page now
[15:42] <bjf> MegaBrutal, when the kernel hits -proposed the associated bug, which you created, will get "spammed" with a request to test and verify the fix. we expect you to do that.
[15:43] <bjf> MegaBrutal, so, like i said it should hit -proposed today and you can test tomorrow and then follow the directions in the bug on how to mark it "verified"
[15:47] <MegaBrutal> bjf: OK. But how Launchpad (or the team) will know that -32 will fix my bug? Sorry if it's a silly question, but the fix was merged under an entirely different LP report, and I don't see a connection. It seems like the fix was merged completely unrelated to my record.
[15:51] <bjf> MegaBrutal, ah! in came in via a stable release. i should have noticed that. in that case there is nothing for you to do. if it fixes your problem then you can just mark the bug as "Fix Released" or ping me and i'll do it
[15:51] <bjf> MegaBrutal, however, if you still have problems come back here and ping me or someone else on the kernel team and we'll look into it more
[15:52] <zequence> infinity: Sometimes it happens
[15:52] <MegaBrutal> bjf: Anyway, could you help me to triage 1423796? (Not sure it you're in charge for it, since it's not a kernel issue.)
[15:53] <MegaBrutal> Why doesn't the bot look up the number? Simon says Launchpad 1423796!
[15:53] <MegaBrutal> Nah! :)
[15:54] <bjf> MegaBrutal, if you had put "bug " or "lp " and then the bug #, the bot would have detected it
[15:55] <bjf> apw, ^ that bug looks interesting
[15:57] <apw> bjf, yeah, that deffo needs kernel side config for the initramfs changes, and likely initramfs-tools change for the other
[15:57] <apw> as i am about to do the merge for that ... i'll poke it
[15:58] <bjf> MegaBrutal, ^ there you go :-)
[16:02] <MegaBrutal> bjf, apw: Wow, thank you! :)
[16:14] <MegaBrutal> bjf, apw: Sorry for my lots of questions, but do you know what is Canonical IS department? In bug 1376088, I've been informed, they've opened a ticket there, and nothing has happened since then.
[16:16] <apw> MegaBrutal, yep that really is the ops people for the ubuntu.com department, that is being referred to
[16:17] <apw> MegaBrutal, do you have a special need for that service over ipv6?  as they are slowly over time adding ipv6 in general to external services
[16:18] <didrocks> hey apw, I have an overlayfs question for you (probably a stupid one)
[16:19] <didrocks> remember the "is_path_is_mountpoint()" for systemd?
[16:19] <didrocks> so, I'm trying to special case overlayfs for the simple use case I have as we discussed
[16:19] <didrocks> meaning, I need to know if this path is referencing a file on overlayfs
[16:20] <didrocks> I'm getting the file fd, then fstat it, -> st_dev -> getting the fspath with blkid -> probe -> get "TYPE" value through blkid
[16:20] <didrocks> this all works well on most of file systems
[16:20] <didrocks> but blkid_devno_to_devname(st.st_dev); return nothing on overlayfs
[16:20] <MegaBrutal> apw: It is not very critical for me... but imho it really wouldn't take so much for such a great company to add an AAAA record to that address. (Most Ubuntu services have IPv6 connectivity already.) Currently, an IPv6-only Ubuntu host can't do a release upgrade without an AAAA record for changelogs.ubuntu.com.
[16:21] <didrocks> am I doing false track and there is a magical way easier way to detect (and so special case) it?
[16:21] <didrocks> going*
[16:28] <apw> MegaBrutal, that it didn't get an address when archive.ubuntu.com did implies it is somewhere that doesn't have ipv6 currently
[16:30] <apw> didrocks, i find it peculiar that we don't use /proc/mounts or something to work out if something is a mount point
[16:32] <apw> MegaBrutal, but i do know the intent is to spread ipv6 around everything
[16:32] <MegaBrutal> apw: archive.ubuntu.com has 2 addresses within 2001:67c:1360:8c01::/64. The upgrader first checks changelogs.ubuntu.com to verify whether there is an upgrade. Only then it turns to archive.ubuntu.com to actually download packages. So changelogs.ubuntu.com not having an IPv6 address is a single point of failure in a release upgrade.
[16:33] <apw> MegaBrutal, i am not disputing that it is needed for ipv6 only systems, not that it is likely these things will be common at the current time
[16:33] <didrocks> apw: so, you would just map if the file is a mount point matching the path to /proc/mounts?
[16:34] <apw> didrocks, i am trying to work out why that isn't appropriate
[16:34] <didrocks> apw: yeah, I have no idea, apart from perfs maybe…
[16:35] <apw> i guess you could fall back to that slow path when the normal one says it is a mountpoint
[16:35] <MegaBrutal> apw: OK-OK. Anyway, you could also check LP 1396213 and LP 1391429 too. If you found the lvmcache stuff interesting, you'll probably like these too. :)
[16:36] <didrocks> apw: or maybe fallbacking if parent dir major is 0?
[16:36] <apw> didrocks, yeah
[16:36] <didrocks> sounds sane enough, I'll give it a try, thanks for the advice apw :)