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