[09:02] <smb> ppisati, Is any Arm we care about caring about acorn partition type? Just asking because I am looking at that SRU patch that wants to disable it for V and W. Personally I would not miss that type, I guess.
[09:02] <ppisati> smb: acorn is dead in the water, no one cares about it
[09:03] <smb> ppisati, Ok, cool. cheers
[09:03] <ppisati> smb: except for people who had/still have an acorn system and want to move their data around
[09:04] <smb> I guess we will then hear from them sooner or later. Likely later when things move out of proposed. :-P
[16:08] <rtg> jsalisbury, could you build a test kernel for bug #1471029 with b51621abbcb4694b8d2842ce3a66006a60bba6e5 reverted in Vivid ?
[16:08] <ubot5> bug 1471029 in libxslt (Ubuntu) "ELF programs with R_386_RELATIVE blocks are badly mapped into memory" [Undecided,Triaged] https://launchpad.net/bugs/1471029
[18:29] <pkern> Hi. Could someone nominate https://bugs.launchpad.net/fedora/+bug/1124250 for Precise?
[18:29] <ubot5> Ubuntu bug 1124250 in linux (Ubuntu Utopic) "Partially incorrect uid mapping with nfs4/idmapd/ldap-auth" [Low,Fix released]
[18:45] <infinity> pkern: Some of the comments claim 3.2 is fine...
[18:45] <rtg> infinity, was just reading the comments after the fix was supposedly implemented. it doesn' look like the patch fixed their problem
[18:46] <infinity> Oh.  And it seems to mention userspace issues.
[18:46] <rtg> might get arges and chiluk to have another look
[18:46] <infinity> Probably needs someone to sort out what package the bug is actually in before opening tasks willy-nilly.
[18:46] <rtg> yep
[18:48] <chiluk> rtg sorry switched machines and lost backscrolll what bug are we talking about?
[18:50] <infinity> chiluk: LP: #1124250
[18:50] <ubot5> Launchpad bug 1124250 in linux (Ubuntu Utopic) "Partially incorrect uid mapping with nfs4/idmapd/ldap-auth" [Low,Fix released] https://launchpad.net/bugs/1124250
[18:52] <rtg> jsalisbury, did you see my note about bug #1471029 ?
[18:52] <ubot5> bug 1471029 in libxslt (Ubuntu) "ELF programs with R_386_RELATIVE blocks are badly mapped into memory" [Undecided,Triaged] https://launchpad.net/bugs/1471029
[19:03] <chiluk> infinity, rtg .. dgadomski is on vacation till Monday iirc.
[19:03] <chiluk> I wouldn't pull the patch until he has a chance to weigh in on it.
[19:03] <chiluk> iirc there were two separate keys stores depending on the security protocols, but I could be recalling that wrong.  He may have only fixed one of them.
[19:04] <rtg> chiwill you make sure it gets on his TODO list ?
[19:04] <rtg> chiluk, will*
[19:08] <jsalisbury> rtg, I'll take a look now
[19:10] <jsalisbury> rtg, I don't see a note in the bug, where can I find it?
[19:11] <pkern> infinity: You are right. It should be a task for linux-lts-trusty on precise.
[19:11] <infinity> chiluk: ^
[19:11] <pkern> infinity: That or the userland. But I suppose it's hard to support both.
[19:11] <rtg> jsalisbury, in the scroll back for this channel. I asked if you could revert b51621abbcb4694b8d2842ce3a66006a60bba6e5 and build a test kernel
[19:11] <pkern> infinity: Unless the kernel tries to be compatible.
[19:11] <pkern> marga: ^^
[19:11] <rtg> jsalisbury, you might end up having to revert a couple of patches
[19:12] <jsalisbury> rtg, sorry I must have missed it. Had to reboot a few times today.  I'll build the test kernel
[19:12] <rtg> jsalisbury, thanks
[19:12] <infinity> pkern: If you guys can figure out what you think the correct behaviour for both 3.2+userland and 3.13+userland on precise should be, that might help chiluk's team sort out WTF actually needs fixing. ;)
[19:12] <infinity> pkern: I'm not sure I have an opinion on the matter, other than "it should probably work".
[19:13] <chiluk> infinity, I haven't looked at that issue for months.. and even then I didn't look at it too thoroughly
[19:20] <marga> infinity, the problem happens with the -lts-trusty kernel
[19:20] <marga> on precise.  That is a supported usecase, right?
[19:20] <infinity> marga: Right, so then the question becomes "should the lts-trusty kernel attempt to be compatible with the precise userspace, or should the precise userspace be made compatible with both 3.2 and 3.13?"
[19:21] <infinity> I guess the end result is the same, but whee.
[19:21] <marga> maybe we can have -lts userspace?
[19:21] <infinity> marga: Absolutely a supported usecase, yes.  Just need to sort out the facts of the situation and then how to solve it.
[19:21] <marga> like with xserver-xorg
[19:21] <infinity> Forking lts-foo userspace stuff should be a last resort thing.
[19:22] <infinity> The reason it's done for X is the same as for the kernel: to get more hardware support.
[19:22] <infinity> For other userspace bits, we should either be making the kernel side or the userspace side compatible, not introducing new packages no one will find on their own.
[19:22] <infinity> (ie: we could ship nfs-utils-lts-trusty or whatever, but who would know it existed and install it?)
[19:23] <marga> I was not able to get it to renew the keys as it's supposed to do. Installing keyutils, libkeyutils, libnfsidmap from trusty + copying /usr/sbin/nfsidmap & /etc/request.keys.d/* from nfs-common from trusty, made the keys become permanent.
[19:23] <marga> I'm not sure if I can provide anything else that helps
[19:24] <infinity> marga: Kay.  The bug is a bit of a mess.  Can you try to clarify in a comment which combinations of userspace+kernel do work, and which combinations don't, and hopefully chiluk's minions can go from there to try to figure out which side should be fixed to be compatible.
[19:24] <infinity> ie: if precise + 3.2 works, trusty + 3.13 works, and precise + 3.13 doesn't, or whatever.
[19:24] <infinity> Which is, I think, what you just said.
[19:25] <marga> Yeah. Although I don't know for sure if trusty + 3.13 leads to permanent keys or renewed keys
[19:26] <marga> But I'll clarify in the bug
[19:26] <infinity> Ta.
[19:27] <jsalisbury> rtg, it appears bug 1471029 is fixed in mainline 4.2-rc3.  I tried a revert of a87938b2 in Wily and Utopic, but the revert requires a backport.  Do you thinks its better to backport the revert or work with the bug reporter to perform a reverse bisect and find the upstream fix?  Or I guess I can do both in parallel.
[19:27] <ubot5> bug 1471029 in linux (Ubuntu) "ELF programs with R_386_RELATIVE blocks are badly mapped into memory" [Medium,Triaged] https://launchpad.net/bugs/1471029
[19:27] <infinity> bjf: ^-- This probably points to a need for more extensive and creative userspace testing, too.  If we can figure out without a bug report that userspace nfs or cifs or whatever bits don't work with an LTS backport (or even a new non-lts-backport), that would be nice.
[19:28] <infinity> bjf: Sounds like something cking would be all over if you mentioned it in casual conversation. :P
[19:28] <cking> i didn't hear that
[19:29] <infinity> cking: Heh.  Aren't you usually EOD and offline by now?
[19:29] <cking> infinity, possibly.. actually just faffing with some packaging while I'm entertaining my kids
[19:29] <rtg> jsalisbury, it could be a combination of patches, including the 2 that we've already applied.
[19:30] <jsalisbury> rtg, got it.  I'll dig into it deeper
[19:30] <cking> infinity, bjf, I don't mind looking at that tomorrow at some point
[19:41] <bjf> cking, it's all yours
[19:41] <cking> ta