| === X-Rob_ is now known as X-Rob | ||
| === dpawlik_ is now known as dpawlik | ||
| jamespage | coreycb: https://etherpad.openstack.org/p/stein-rc1-ubuntu-packaging | 09:33 |
|---|---|---|
| coreycb | jamespage: ohh etherpad, good idea | 12:09 |
| coreycb | jamespage: i'll take a scan through and pick up on anything new | 12:09 |
| coreycb | jamespage: i'm going to order those alphabetically | 12:12 |
| === 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 | ||
| 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? | 13:31 |
| === pedro__ is now known as DodgeThis | ||
| 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:18 |
| rbasak | ack | 14:19 |
| ahasenack | thx! | 14:20 |
| 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:23 | |
| 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:26 |
| coreycb | jamespage: thank you | 14:27 |
| 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:28 |
| 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:29 |
| jamespage | coreycb: I think they are on the component mismatches report - we might want to drop them from the seed for now | 14:32 |
| 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:33 |
| coreycb | jamespage: looks like we're all caught up on RC1s etc | 14:54 |
| jamespage | coreycb: yep! | 15:01 |
| 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:30 |
| === runelind_q_ is now known as runelind_q | ||
| coreycb | jamespage: masakari seeds dropped | 15:33 |
| cpaelzer__ | ahasenack: I'm back did you get all the MP reviews you need? | 15:48 |
| === cpaelzer__ is now known as cpaelzer | ||
| 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:11 |
| cpaelzer | ahasenack: I already re-reviewed libnfsidmap | 16:17 |
| cpaelzer | abotu 15 minutes ago | 16:17 |
| cpaelzer | it is good to go | 16:17 |
| ahasenack | k | 16:18 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| ahasenack | (default file -> wrapper -> systemd service file) | 16:38 |
| 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:40 |
| ahasenack | rbasak: I don't know why the wrapper was introduced | 16:43 |
| 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:44 |
| ahasenack | debian adopted it in 2016 | 16:45 |
| ahasenack | via pitti as well :) | 16:45 |
| * rbasak is still looking at it | 16:47 | |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| rbasak | I suspect this fix won't qualify under the current buster freeze, but I'd have to check the rules. | 17:20 |
| ahasenack | how about I add a NEWS bit, so apt listchanges will show it? | 17:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:35 |
| ahasenack | it's full freeze now, right? | 17:37 |
| 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:43 |
| 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 |
| === lotuspsychje_ is now known as lotuspsychje | ||
| rbasak | (to cover both changing /lib/systemd/system/... and the two override mechanisms in /etc) | 17:45 |
| 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:46 |
| rbasak | But yeah, please do file the salsa MP and attach the patch to Debian BTS. | 17:47 |
| ahasenack | yep | 17:47 |
| rbasak | Sorry for being reluctant before. It's complicated :-/ | 17:48 |
| rbasak | But you convinced me it's OK. | 17:48 |
| 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:49 |
| 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. | 17:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!