=== X-Rob_ is now known as X-Rob === dpawlik_ is now known as dpawlik [09:33] coreycb: https://etherpad.openstack.org/p/stein-rc1-ubuntu-packaging [12:09] jamespage: ohh etherpad, good idea [12:09] jamespage: i'll take a scan through and pick up on anything new [12:12] jamespage: i'm going to order those alphabetically === Guest12731 is now known as logan- === v12aml_ is now known as v12aml === cryptodan_d is now known as cryptodan === andol_ is now known as andol [13:31] coreycb: +1 - my list was a dump from my inbox so mainly in arrival order! [13:31] coreycb: does your upstream vs distro version report still run somewhere? === pedro__ is now known as DodgeThis [14:18] rbasak: I think cpaelzer__ is EOD, could you please review this small mp? I would like to upload it before the monday freeze: https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/364923 [14:18] the description is large because it includes test instructions [14:19] ack [14:20] thx! [14:23] Lunch is beeping [14:23] I'll come back to it. [14:23] What's this /run thing? Seems odd. [14:23] * rbasak will look later [14:26] coreycb: I'm going to ping an email to ubuntu-release with current status - we have a few MIR's blocking proposed migration and at least one package in the NEW queue. [14:26] coreycb: is masakari-monitors in disco yet? [14:26] jamespage: no that's also still in the NEW queue [14:27] jamespage: thank you [14:28] coreycb: if masakari does not make it to main this cycle I'm not worried tbh [14:28] based on converstations with gnuoy I think we can describe that feature as 'preview' for general consumption [14:29] jamespage: agreed [14:29] jamespage: i believe i have them both seeded correctly but i'm going to double check that it's all in tact [14:32] coreycb: I think they are on the component mismatches report - we might want to drop them from the seed for now [14:33] jamespage: ok i can do that and add a note to re-add them early next release [14:33] well note to self [14:54] jamespage: looks like we're all caught up on RC1s etc [15:01] coreycb: yep! [15:30] hrm, I have Landscape On Prem installed on in an 18.04 container, and now all of a sudden it says it is unsupported. [15:30] LDS 19.01, that is. === runelind_q_ is now known as runelind_q [15:33] jamespage: masakari seeds dropped [15:48] ahasenack: I'm back did you get all the MP reviews you need? === cpaelzer__ is now known as cpaelzer [16:11] cpaelzer: I pinged rbasak about libnfsidmap [16:11] cpaelzer: I mean, the other one [16:11] nfs-utils [16:11] and pushed libnfsidmap again to the right place, if you want to take another look, but I was going to upload [16:17] ahasenack: I already re-reviewed libnfsidmap [16:17] abotu 15 minutes ago [16:17] it is good to go [16:18] k [16:31] ahasenack: SRU template? This is for DIsco right? [16:31] rbasak: disco first, yes [16:31] no sru template yet [16:31] rbasak: have to find an easy way to test this [16:31] for people to test it, I mean [16:31] ah, wait [16:31] I'm mixing both bugs [16:32] rbasak: so yes, this one will get the sru template once it is in disco, and the testing instructions will be the same [16:32] the other one (libnfsidmap) is more complicated to test with just one vm, and it won't work in containers, that's the one I have to think a bit more about testing instructions [16:32] but cpaelzer approved that one already [16:32] rbasak: ^ [16:33] I'm only looking at nfs-utils I think? [16:33] yes [16:33] please, only that one :) [16:33] And only for Disco currently? [16:34] I'm not sure about breaking existing uses in an SRU [16:34] For Disco it's fine in this case IMHO [16:34] users [16:34] it's for disco, but there should be an sru [16:35] there is no way for people to pass options to rpc-svcgssd without this, the content from /etc/default/nfs-kernel-server won't be seen by the systemd service file [16:35] For an SRU I'm thinking perhaps accept either variable name but fail hrad if both are set and are different. [16:35] both cannot be set, that's done in the wrapper script [16:35] The wrapper script could examine both and make a decision couldn't it? [16:35] even if users change the var name in the default file, that won't be seen by the nfs-utils_env.sh script and will be ignored [16:36] I mean that users who have fixed this locally, that fix was not about changing the var name in the default file [16:36] it would have most likely been in the service file [16:36] systemd service file [16:36] that's what all the bugs were pointing out: "variable name in service file is wrong" [16:36] Let's talk about the SRU later [16:36] did you see my update with cases (a), (b) and (c)? [16:37] As I'm not sure we're on the same page right now about the appropriate fix, but we can defer that conversation [16:37] Yes [16:37] ok [16:37] that var gets mangled twice :/ [16:37] RPCSVCGSSDOPTS -> RPCSVCGSSDARGS -> SVCGSSDARGS [16:38] (default file -> wrapper -> systemd service file) [16:40] Do you know why the wrapper is even necessary? [16:40] The whole system seems insane to me. [16:40] And this bug demonstrates why [16:40] Not that this should preclude your fix of course. [16:40] But perhaps a Debian bug asking for an end to this might be appropriate [16:43] rbasak: I don't know why the wrapper was introduced [16:44] * Add debian/nfs-utils_env.sh: Translate our /etc/default files into runtime [16:44] configuration for nfs-config.service. [16:44] by pitti [16:44] in 2016 [16:44] 2015, actually [16:45] debian adopted it in 2016 [16:45] via pitti as well :) [16:47] * rbasak is still looking at it [17:12] ahasenack: I don't follow why you're choosing to alter the wrapper and not the service definition [17:12] If you alter the service, then surely users who have local overrides are in the same position anyway? [17:12] rbasak: the systemd service file comes from upstream, and the wrapper is ours [17:12] Oh, I see. [17:13] I could have made that comment right after I said "the wrapper is the best place for the fix", sorry [17:13] I was trying to think of the possibilities in case Debian end up fixing the problem in a different way, combined with us taking on a delta, later dropping it, combined with the different way existing users might have worked around. [17:13] Too many possibilities; I gave up :-/ [17:13] yeah, this is the second time I try to fix this bug [17:13] the first time I had also given up [17:14] I think I'd prefer an NMU to Debian to fix this bug there. [17:14] That would eliminate one set of possibilities caused by Debian implementing a different fix. [17:14] But we'd miss Disco then. [17:15] However, is that a big deal? We'd have to SRU Bionic; on top of that Disco doesn't seem so bad; it'd be the same patch and test case, right? [17:15] I'm fine with waiting and seeing if debian will take it [17:15] Debian seems to be inactive on this package. [17:15] want me to make a pr in salsa? [17:15] Multiple NMUs in so far. [17:15] yeah [17:15] oh, I see [17:15] I think it'll have to be another one. [17:15] I hadn't checked that [17:16] let me see if it's in salsa [17:16] in ubuntu nfs isn't that much better [17:16] lots of bugs filed, with no resposes [17:16] responses* [17:16] I see https://salsa.debian.org/debian/nfs-utils (last commit 3 months ago) [17:16] and https://salsa.debian.org/kernel-team/nfs-utils (2 years ago for the last commit) [17:20] I suspect this fix won't qualify under the current buster freeze, but I'd have to check the rules. [17:22] how about I add a NEWS bit, so apt listchanges will show it? [17:23] that being said, normally you wouldn't need to add options to this service in particular [17:23] what I wanted to add was -v, when debugging why it wasn't working [17:24] NEWS is a pain - it'll vanish on next sync! [17:24] There really is no good answer. [17:24] hah [17:24] I'm proposing to await Debian (and/or drive in Debian with an NMU) to avoid extra complications [17:25] waiting I think won't work [17:25] That is also a bad answer in that it delays a fix, including to Bionic. [17:25] bug is old [17:25] Yeah [17:25] That was my thought. [17:25] Also a workaround is readily available. [17:25] I suggest a systemd override file in /etc, but perhaps that needs thinking about. [17:25] and the changelog entry points at the bug, people can see what changed [17:25] your suggestion for users without the fix? [17:26] Perhaps we could publish (in the bug) our recommended workaround, and make sure that a future fix won't break _that_ workaround. [17:26] (which means we should think about the workaround we choose to suggest) [17:26] I can do option (b) [17:26] export both varis [17:26] vars* [17:26] so people with overrides will also have it still work [17:27] But will that encourage more users to use a name that we will eventually break? [17:27] the name in /etc/default/ isn't the issue [17:27] the issue is that our wrapper exported the wrong name, it's like an internal ipc [17:28] Ah [17:28] Sorry. This is confusing :-/ [17:28] our wrapper, which connects /etc/default to the systemd service file, made a typo [17:30] option (b) is to have the wrapper keep exporting the wrong name, to cope with users who have changed the systemd service file [17:30] and export the correct name, for users who haven't done a thing [17:30] AFAICT that would work. [17:30] If Debian adopts that fix then great. [17:31] and I can add a comment to the wrapper right where this is being done, explaining why [17:31] If Debian doesn't retain the old name export in the wrapper, then that breakage would have to happen on a future sync for us anyway. [17:31] ok, so try (b), submit to salsa, wait a bit? [17:32] I think I'm also OK with an Ubuntu upload for (b) [17:32] ok, let me prep that [17:32] thanks for the review, you did great for your first time with this bub :) [17:32] bug* [17:32] ugh [17:33] As well as Salsa, please post the patch to the existing Debian bug, so it will have followed the long standing advance notice exactly for a future NMU [17:33] Thanks :) [17:33] ok [17:35] https://release.debian.org/buster/freeze_policy.html [17:35] My reading of that is that a fix in Debian for this would be inappropriate for buster. [17:37] it's full freeze now, right? [17:43] rbasak: how about this: https://pastebin.ubuntu.com/p/2nf4gjr9y5/ [17:43] not committed yet, just looking for feedback on the message/text [17:45] ahasenack: the wording looks good. [17:45] ok [17:45] ahasenack: I might amend s/changing/overriding/ and s/systemd service file/systemd service/ but that's up to you. [17:45] sure === lotuspsychje_ is now known as lotuspsychje [17:45] (to cover both changing /lib/systemd/system/... and the two override mechanisms in /etc) [17:46] the former wouldn't break [17:46] it's not a config file, we would just write the good one over it [17:46] Good point [17:46] I need to run, but consider this to be my +1 [17:46] rbasak: for ubuntu upload? AFter I file a salsa mp [17:46] Yes [17:46] ok, thanks [17:47] But yeah, please do file the salsa MP and attach the patch to Debian BTS. [17:47] yep [17:48] Sorry for being reluctant before. It's complicated :-/ [17:48] But you convinced me it's OK. [17:49] what? No [17:49] it's great [17:49] really [17:49] I had that in place, in fact, in the first iteration of this MP :) [17:49] I abandoned the idea because the systemd file in /lib would be overwritten, I hadn't thought about actual overrides in /etc [17:49] so review++ [17:50] The outcome is good. Peer review is good. I just felt like I was dragging my heels there. Turns out because I didn't fully understand the consequences.