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:02 |
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:03 |
smb | I guess we will then hear from them sooner or later. Likely later when things move out of proposed. :-P | 09:04 |
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 | 16:08 |
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:29 |
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:45 |
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:46 |
chiluk | rtg sorry switched machines and lost backscrolll what bug are we talking about? | 18:48 |
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:50 |
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 | 18:52 |
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:03 |
rtg | chiwill you make sure it gets on his TODO list ? | 19:04 |
rtg | chiluk, will* | 19:04 |
jsalisbury | rtg, I'll take a look now | 19:08 |
jsalisbury | rtg, I don't see a note in the bug, where can I find it? | 19:10 |
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:11 |
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:12 |
chiluk | infinity, I haven't looked at that issue for months.. and even then I didn't look at it too thoroughly | 19:13 |
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:20 |
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:21 |
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:22 |
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:23 |
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:24 |
marga | Yeah. Although I don't know for sure if trusty + 3.13 leads to permanent keys or renewed keys | 19:25 |
marga | But I'll clarify in the bug | 19:26 |
infinity | Ta. | 19:26 |
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:27 |
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:28 |
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:29 |
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:30 |
bjf | cking, it's all yours | 19:41 |
cking | ta | 19:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!