| === Flannel is now known as esck | ||
| === esck is now known as Flannel | ||
| === Cimi_ is now known as cimi | ||
| === akxwi-dave_ is now known as akxwi-dave | ||
| hyperair | ScottK: thoughts on https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1519331? if nobody's working on it, i could provide a debdiff | 08:55 |
|---|---|---|
| ubottu | Launchpad bug 1519331 in postfix (Ubuntu) "Postfix cannot resolve DNS if network was unavailable when it was started, such as on a laptop" [Low,Confirmed] | 08:55 |
| rbasak | hyperair: please get that fix into Debian. With no delta against Debian in postfix, I'd rather not have to maintain a delta for that bug. | 08:59 |
| hyperair | oh right | 08:59 |
| hyperair | rbasak: what about stable releases though? | 08:59 |
| hyperair | (after getting it into debian, of course) | 09:00 |
| rbasak | No objection, as long as it's OK under normal SRU policy, etc. | 09:00 |
| hyperair | right | 09:03 |
| hyperair | okay, actually taking a closer look, postfix does already does drop a script into /etc/network/if-up.d | 09:03 |
| hyperair | odd | 09:03 |
| cpaelzer | hi, anybody an idea of a meta package I could depend upon which gives me /vmlinuz cross arch for Debian&Ubuntu? | 11:34 |
| cpaelzer | haven't seen a linux-generic in Debian - is there an equivalent? | 11:35 |
| fossfreedom | sil2100: on the off-chance you haven't broken up for the holiday season (!) ... have you found any time to look at the lp:ubuntu-cdimage merge request? TIA | 12:06 |
| sil2100 | fossfreedom: hey! Not yet, got a bit preempted last week - let me deal with it in a minute | 12:10 |
| ScottK | hyperair: I have a theory about it. It's on my list for this week. | 12:17 |
| === alan_g is now known as alan_g|lunch | ||
| hyperair | ScottK: oh okay | 13:05 |
| rbasak | infinity: may I have your opinion on https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1176046/comments/38 please? | 13:36 |
| ubottu | Launchpad bug 1176046 in isc-dhcp (Ubuntu Trusty) "isc-dhcp dhclient listens on extra random ports" [Medium,In progress] | 13:36 |
| === alan_g|lunch is now known as alan_g | ||
| === jgrimm-out is now known as jgrimm | ||
| rbasak | smoser, lamont: let's coordinate here. | 14:46 |
| lamont | ok | 14:47 |
| rbasak | I'm not sure what to do about bug 1642679. If nobody affected can be bothered to test, maybe it's better not to disrupt others who might be relying on the current code path but don't know about the bug and push a revert through. I don't know. | 14:47 |
| ubottu | bug 1642679 in cloud-init (Ubuntu Yakkety) "The OpenStack network_config.json implementation fails on Hyper-V compute nodes" [Medium,Confirmed] https://launchpad.net/bugs/1642679 | 14:47 |
| rbasak | But let me see if that's the only blocker. | 14:47 |
| rbasak | smoser: maybe put a second call for testing in the bug, at least? | 14:48 |
| smoser | rbasak, i'm typing some stuff there now. | 14:48 |
| smoser | and have irc-pinged a contact who is involved in the hyperv-nova work also | 14:49 |
| rbasak | lamont: can I check I'm not missing anything? What's the full set of packages you need releasing? | 14:51 |
| lamont | open-iscsi, isc-dhcp, initramfs-tools, cloud-init, cloud-initramfs-tools, ifupdown | 14:55 |
| smoser | rbasak, gsamfira responded to me and he says he will test. | 14:55 |
| rbasak | lamont: can you comment in bug 1629972 explaining on what basis it's verification-done please? That is: have you tested it specifically, or are you relying on the test case somewhere else? What about the test case documented in that bug itself? | 14:58 |
| ubottu | bug 1629972 in MAAS "networking stop incorrectly disconnects from (network) root filesystem" [Undecided,Triaged] https://launchpad.net/bugs/1629972 | 14:58 |
| rbasak | lamont: thank you for the list | 14:59 |
| rbasak | smoser: great, thanks! | 14:59 |
| lamont | rbasak: doh. added. | 15:01 |
| lamont | the lxc test case in the bug was actually the simplified version of what I tested. | 15:02 |
| === scottt is now known as Guest63900 | ||
| === gpiccoli2 is now known as gpiccoli | ||
| sil2100 | Is there any archive admin around to do a preNEW review in Bileto for a new source package? https://bileto.ubuntu.com/#/ticket/2278 | 15:47 |
| sil2100 | In theory this should go to the NEW queue normally (Bileto doesn't go around the source NEW queue), but I remember we had this practice of gettin a pre-ACK beforehand | 15:48 |
| sil2100 | And besides, this will go straight to the overlay for xenial | 15:48 |
| smoser | rbasak, gsamfira updated https://bugs.launchpad.net/cloud-init/+bug/1642679 | 15:52 |
| ubottu | Launchpad bug 1642679 in cloud-init (Ubuntu Yakkety) "The OpenStack network_config.json implementation fails on Hyper-V compute nodes" [Medium,Confirmed] | 15:52 |
| rbasak | Thanks! | 15:53 |
| lamont | smoser: bug 1611074 needs yakkety verrification, it would seem | 16:28 |
| ubottu | bug 1611074 in cloud-init "Reformatting of ephemeral drive fails on resize of Azure VM" [High,Fix committed] https://launchpad.net/bugs/1611074 | 16:28 |
| lamont | smoser: ditto bug 1626243 | 16:28 |
| ubottu | bug 1626243 in cloud-init (Ubuntu Yakkety) "Cloud-init fails to write ext4 filesystem to Azure Ephemeral Drive" [Medium,Fix committed] https://launchpad.net/bugs/1626243 | 16:28 |
| infinity | rbasak: Added my two cents. | 16:34 |
| rbasak | infinity: thanks! | 16:36 |
| smoser | lamont, hm.. | 16:37 |
| rbasak | infinity: in general I agree with you, but here specifically there's one additional thing, which is that dhclient can grab a UDP port that later userspace then can't grab. So I think the bug is that it is (effectively) impossible to host a UDP service on a static port when using DHCP. | 16:38 |
| * lamont has looked around and found zero asure ephemeral drives. :/ | 16:38 | |
| infinity | rbasak: Yes, and the bug was reported 3.5 years ago, trusty was released 2.5 years ago, and we now have a new LTS. | 16:38 |
| infinity | rbasak: If we'd fixed it 3 years ago, fine, yay, but we didn't, and there were really very few complaints. | 16:39 |
| infinity | rbasak: Is there an internal motivation for this that has escalated it, or did the itch just land on someone who found the old bug and decided it was suddenly dire? | 16:39 |
| rbasak | infinity: AIUI, someone new got hit and raised it with Canonical. So new motivation arrived. | 16:40 |
| slashd | infinity, UA customer filed a bug about it, but I do agree with upgrading to Xenial, this is what I told him at the first place, and then I start a discussion with caribou and rbasak if we could do more or not | 16:40 |
| slashd | infinity, rbasak, so final position is upgrade to Xenial and nothing more ? | 16:41 |
| nacc | rbasak: caribou: ack on the bug filed re: usd tag, i forgot to update documentation (for now, run `usd tag --format='logical/<explicit version>' | 16:41 |
| rbasak | infinity: IMHO, the point in having an EOL is that we fix things before EOL is reached. So I'm not convinced "there's a new LTS out" should be a reason. | 16:41 |
| infinity | slashd: HEY YOU. | 16:41 |
| infinity | slashd: You owe me a bug verification on debian-installer in xenial. | 16:41 |
| infinity | rbasak: We don't fix ALL things. | 16:41 |
| rbasak | infinity: but, if that's a -1, I think it carries more weight that my +1 on the principle (but not the method). | 16:41 |
| rbasak | than my | 16:42 |
| slashd | infinity, I know I change the tag to verification-done and update the lp bu about d-i | 16:42 |
| infinity | rbasak: There's a bar for what is and isn't appropriate to fix in an SRU. This is pretty borderline. | 16:42 |
| rbasak | infinity: I agree it's borderline, but the observation that it makes it impossible to reliably run a UDP static port service swung it for me. | 16:42 |
| infinity | slashd: Oh, so you did. Thanks. | 16:42 |
| nacc | rbasak: caribou: re: LP: #1651113 that is | 16:42 |
| ubottu | Launchpad bug 1651113 in usd-importer ""usd tag" cannot tag logical tags" [High,Triaged] https://launchpad.net/bugs/1651113 | 16:42 |
| slashd | infinity, tks for sending me a reminder | 16:42 |
| infinity | rbasak: I don't particularly love the behaviour, but I love any potential solution less. | 16:43 |
| nacc | rbasak: do you want to sit down today or tmrw and prioritize the (now many) importer issues? | 16:43 |
| rbasak | nacc: sure. Let me figure out when is best. | 16:44 |
| infinity | rbasak: Anything that involves package splitting or environment-driven behaviour or, really, anything that says "trusty now supports two behaviours" will imply supporting a smooth upgrade path to same. | 16:44 |
| infinity | rbasak: Which means isc-dchp upgrade suddenly doing the opposite of what they do today, or similar issues. | 16:44 |
| rbasak | infinity: I think the current proposal resolves that. No unexpected change in behaviour for anyone. The ugliness is in having to do an SRU to Xenial to ensure that. | 16:45 |
| infinity | The use-case that leads to the misfeature being a "bug" is clearly not a common one, or we'd have a ton of angry bugs about it. So I really think "upgrade to Xenial" is the saner answer. | 16:45 |
| infinity | rbasak: Nope, the current proposal doesn't address the upgrade path. | 16:46 |
| rbasak | infinity: how so? | 16:46 |
| infinity | rbasak: Once you split to "foo" and "foo-nofeature", you're saying "installing foo gets you feature". And then we can't have it both ways. Either the upgrade needs to start including feature, which will make current users grumpy, or it needs to not, which breaks that implied contract. | 16:46 |
| infinity | The current proposal says "all upgrades get you nofeature". | 16:47 |
| infinity | Which is certainly the path of least surprise for me. But not for someone who read "apt-cache show foo" and "apt-cache show foo-nofeature" in a post-SRU world and installed "foo" on purpose. | 16:47 |
| rbasak | you're saying...> I'm not sure I agree. We could make that clear in the package descriptions. I don't think anyone would be surprised by this any more than they are surprised today that "feature" disappears on upgrade to Xenial, which already happens. | 16:48 |
| rbasak | I'm just surprised that you object on the principle of the thing rather than the mechanism. | 16:50 |
| infinity | Alright, that's a reasonable fair argument. If you take your proposal, and add "due to this package split being a late addition to trusty, upgrades to xenial will require manually installing foo-feature if you wanted feature" might work. | 16:50 |
| infinity | I still disagree with the principle. :P | 16:50 |
| infinity | It's a feature, not a bug. It's a crap feature to have installed on basically all machines, but that still doesn't make it a bug. | 16:50 |
| infinity | If the behaviour were itself deemed buggy and incorrect, we'd remove foo-feature from xenial, not split it. :P | 16:51 |
| persia | Just as a note: if only one person is complaining, can they just have a package that works for them? I like everything being in the distro, but some things are disruptive. | 16:51 |
| rbasak | infinity: well, there are always going to be cases where users depend on one aspect of a particular feature but another aspect is a bug and should be fixed, but that would disrupt the first because SRU patches can't read minds. | 16:52 |
| infinity | persia: People like me have given Canonical support a pretty strong mandate to *not* build one-off packages for customer bugfixes unless there's literally no other way to address something, because, well, that's super distro-unfriendly and just leads to chaos and extra maintenance burden. | 16:52 |
| infinity | persia: Also hi. | 16:53 |
| rbasak | infinity: I expect there are other less borderline cases where we'd have to do something similar. But I accept this this case is so borderline, the same reasoning can tip it over the edge to "no". | 16:53 |
| persia | infinity: Hi. People like me tend to deliver working packages and work with distro if that won't break distro, but I strongly support your base position and apologise for complicating it. | 16:53 |
| infinity | rbasak: Anyhow, I'm not going to be the one to block it or not. I was offering a "this really doesn't need fixing at all, maybe you should just tell the customer to upgrade" option because, well, I feel that's the sane option. | 16:54 |
| persia | (and, to be fair, I'm not much of a person-like-me in the sense above these days) | 16:54 |
| rbasak | infinity: so now we have two indecisions :-) | 16:55 |
| infinity | persia: Yeah, were I an independent contractor, I'd provide fixes today, push to distro tomorrow, and if distro rejects, I'd figure out how to charge the client for ongoing maintenance of the forked package I just gave them. :P | 16:55 |
| infinity | persia: Canonical's pricing structure for baseline support definitely doesn't support the latter part of that sentence, so letting our support guys back themselves into that corner is very bad. ;) | 16:55 |
| caribou | infinity: rbasak: slashd: wouldn't a backport of the Xenial bits to the backport archive sufficient for this single occurence ? | 16:56 |
| persia | infinity: Understood, and thank you for formally describing "people-like-me" in that context. | 16:56 |
| infinity | Thus, it should be "in the distro for everyone", "no bugfix for you", or "this customer pays us way more". | 16:56 |
| infinity | caribou: Perhaps, but that's an ongoing maintenance burden too. | 16:57 |
| rbasak | caribou: that feels like it ships in a behaviour change in through the back door. I'm not sure backports is really intended for that, but I suppose that depends on backports policy. | 16:57 |
| infinity | caribou: isc-dhcp doesn't have a perfect security record, by any stretch, so a backport as a bugfix would also mean needing to keep backports up to date. | 16:57 |
| caribou | infinity: we do not propose maintenance for the backports archive | 16:57 |
| rbasak | Certainly with users opting in it's not so bad from that perspective. | 16:57 |
| rbasak | caribou: might as well just use a PPA then? | 16:58 |
| infinity | caribou: Err. You can't have it both ways. If this is proposed as a bugfix, the fix can't be something buggier. :) | 16:58 |
| caribou | rbasak: PPA is a one-off in that sense and, like infinity, is strongly against them | 16:58 |
| infinity | And "here's a version frozen in time with no upgdates because we don't wanna" is buggier. | 16:58 |
| rbasak | caribou: at least a PPA makes it clear though. | 16:59 |
| infinity | No, please don't. | 16:59 |
| caribou | rbasak: then let's teach them how to build their own PPA & let _them_ maintain it | 16:59 |
| infinity | If the motivation is strong enough to put work in on this, do it right. | 16:59 |
| rbasak | I'm not sure backports should be a place to fire-and-forget in changes you don't want to maintain. | 16:59 |
| slashd | rbasak, won't be supported if they have other issue as per UA policy, they will need to go back to the pkg in -update if they want more support on the pkg , sec update, etc ... | 16:59 |
| slashd | rbasak, about the PPA ^ | 17:00 |
| rbasak | So, as I see it, neither infinity nor I are prepared to commit to a +1, but won't block it either. So we're effectively at 0 from an SRU perspective. Ubuntu governance requires us to be decisive. So we can extend to the rest of ~ubuntu-sru to decide, or ask the TB. That's our path to a decision if you want one. | 17:01 |
| infinity | Doesn't need a TB decision. | 17:01 |
| rbasak | I suggest that in this case if we remain at 0 then the status quo should remain. | 17:01 |
| rbasak | infinity: we can ask the TB if ~ubuntu-sru can't decide, AIUI. | 17:02 |
| infinity | If the isc-dhcp-client desciption is amended with a note about the split being post-release and upgrades downgrading the feature again, I'm fine with rbasak's plan otherwise. I don't love it, but I can get over it. But it better be deemed worth the effort by the people putting in the time on this. :P | 17:02 |
| infinity | (hint, hint) | 17:02 |
| rbasak | Well, then I guess it's fine to do if slashd prepares it all. Because infinity said it's OK :-P | 17:03 |
| rbasak | nacc: got time for a hangout now? | 17:05 |
| rbasak | I have a hard stop in 55 minutes though. | 17:05 |
| slashd | rbasak, infinity, so it's a +1 for my -noddns proposal, even if I totally agree that ideally, upgrading to xenial the favourite solution. | 17:06 |
| rbasak | slashd: that's my understanding, yes. But see infinity's requirement above, and I also want the dpkg-divert clashing path I identified in comment 38 checked carefully. | 17:07 |
| caribou | nacc: ack on usd tag btw | 17:07 |
| rbasak | slashd: as well as the use cases we already identified, all being checked as part of SRU verification please. | 17:07 |
| slashd | rbasak, sure, will you be amenable to sponsor it once completed since you are aware of everything since almost day 1 ? | 17:08 |
| rbasak | slashd: I can't sponsor as I'll need to be available to provide the ~ubuntu-sru review, and I can't do both. | 17:08 |
| slashd | rbasak, make sense, ok will find another sponsor, no worries | 17:08 |
| rbasak | slashd: basically you need two reviews - one from me, and one from another person who can upload the package. | 17:08 |
| infinity | rbasak: If you sponsor, you can annoy me until I review. | 17:09 |
| slashd | rbasak, ack | 17:09 |
| rbasak | slashd: oh, you have a volunteer :-) | 17:09 |
| infinity | If both our waffling asses agree it's okay, that closes that hole. :P | 17:09 |
| caribou | infinity: rbasak: I'll sponsor it, that's not an issue | 17:09 |
| slashd | tks caribou | 17:09 |
| slashd | tks infinty and rbasak | 17:09 |
| slashd | infinity ^ | 17:10 |
| infinity | caribou: I expect you to take your sponsorship duties very seriously and review like you hate the uploader, then. ;) | 17:10 |
| infinity | (Pretending to hate the uploader/committer is my default review strategy) | 17:10 |
| caribou | infinity: I'll try to do as well as you did for me ;) | 17:10 |
| caribou | infinity: ah, now I get it :-p | 17:10 |
| infinity | "THIS GUY VOTED WRONG, KICKS PUPPIES, AND DOESN'T UNDERSTAND HOW BREAKS WORKS, ARGH." | 17:11 |
| infinity | Oh, wait, no, just the dpkg thing. But still valid! | 17:11 |
| slashd | infinity, 2 quebecers can't hate each other, it will be hard to caribou to hate me ;) lol | 17:12 |
| xnox | persia, can you vote in US elections and who did you vote for? | 17:12 |
| infinity | slashd: Maybe have a debate about separation, and if you both agree (which you probably do), one of you can play devil's advocate until the other is seething with rage. | 17:13 |
| slashd | infinity, lol as long as I have poutine, I don't mind being in Canada ;) | 17:14 |
| xnox | wales would be happy to become Quebec's overseas territory. | 17:14 |
| infinity | slashd: A solid position. | 17:14 |
| caribou | infinity: pls don't get me into that; I fleed to France to avoid those | 17:15 |
| infinity | slashd: I'm considering running for federal office to proposed poutine and maple syrup transfer payments. That is, every time Quebec is net negative on the other type of transfer payments, they need to send a few thousand tonnes of squeaky cheese and a few thousand litres of maple syrup out west to say "thanks". | 17:17 |
| infinity | slashd: Sadly, as the oil industry self-destructs, this seems less likely to work in the future. :P | 17:17 |
| slashd | infinity ;p | 17:17 |
| persia | xnox: I don't generally believe democracy is a good model, but one of my favorite parts of how it works in the US is the double-blind system for matching whether one voted and how one voted. | 17:18 |
| nacc | rbasak: sorry, was afk -- i can talk for a few now, or we could try tmrw? | 17:32 |
| rbasak | nacc: short chat now? | 17:32 |
| nacc | rbasak: sounds good | 17:33 |
| smoser | lamont, all the cloud-init yakkety are now verification-done | 18:09 |
| lamont | rbasak: ^^ I think that's everything for yakkety to land | 18:09 |
| smoser | rbasak, i just saw your comment on https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1633479 wrt git noise on precise. | 18:13 |
| ubottu | Launchpad bug 1633479 in isc-dhcp (Ubuntu Yakkety) "dhclient does not wait for ipv6 dad (duplicate address detection)" [Medium,Fix committed] | 18:13 |
| nacc | cyphermox: you asked for some input from submitter in LP: #1634689 but a different user responded (and did't change the bug state). Can you take a look at your convenience? | 19:40 |
| ubottu | Launchpad bug 1634689 in openvpn (Ubuntu) "DNS leak after upgrade to 16.10" [Undecided,Incomplete] https://launchpad.net/bugs/1634689 | 19:40 |
| nacc | hallyn: would you be able to comment if the suggested fix in LP: #1618899 is appropriate? | 19:52 |
| ubottu | Launchpad bug 1618899 in vm-builder (Ubuntu) "vmbuilder fails with dist-upgrade with release xenial" [Low,Triaged] https://launchpad.net/bugs/1618899 | 19:52 |
| infinity | nacc: Who/what is changing sudoers? | 19:55 |
| nacc | infinity: a fair question! i'll ask in the bug, it does seem like there must be some local modification to get that prompt | 19:58 |
| infinity | nacc: Commented. | 19:59 |
| infinity | See stuff in the vm-builder source like: | 19:59 |
| infinity | logging.info("Running ec2 postinstall") | 19:59 |
| infinity | self.install_from_template('/etc/ec2_version', 'ec2_version', { 'version' : self.context.ec2 | 19:59 |
| infinity | _version } ) | 19:59 |
| infinity | self.install_from_template('/etc/ssh/sshd_config', 'sshd_config') | 20:00 |
| infinity | self.install_from_template('/etc/sudoers', 'sudoers') | 20:00 |
| nacc | infinity: thanks! | 20:00 |
| nacc | yep | 20:00 |
| infinity | nacc: If vm-builder is altering conffiles (ick), then dist-upgrading over those altered conffiles won't exactly make things better. | 20:00 |
| nacc | infinity: absolutely agreed. Will see what the originator(s) say | 20:00 |
| infinity | nacc: In this case, what they say isn't super meaningful. ;) | 20:01 |
| nacc | infinity: yeah, i suppose that's true :) | 20:02 |
| infinity | nacc: You can see the templates in the source, and what they alter. In the sudoers case, it's adding ubuntu=NOPASSWD, which should be a sudoers.d snippet instead. | 20:02 |
| infinity | nacc: In the sshd_config case, it's just gross. Lots of changes, and no way to do that without mangling a conffile. | 20:02 |
| infinity | nacc: So, maybe the answer is to mangle conffiles *after* the dist-upgrade step, not before. But even then, you're leaving end-users of the image with something that will prompt on upgrade, which sucks. | 20:03 |
| infinity | But, that bug seems to have existed pretty much forever, so meh. | 20:04 |
| nacc | right, it seems like the 'correct' fix to just the sudoer issue is probably sudoers.d? | 20:05 |
| infinity | Yeah. But sshd_config will have exactly the same issue. | 20:05 |
| infinity | Oh, no it won't. | 20:05 |
| infinity | sshd_config isn't a conffile. | 20:05 |
| infinity | Handy. | 20:06 |
| nacc | heh | 20:06 |
| infinity | So, yeah. Fixing the sudoers thing by slapping a snipper in .d would fix this bug. | 20:06 |
| infinity | snippet* | 20:06 |
| nacc | infinity: thanks for the help! | 20:06 |
| hallyn | nacc: fwiw the cloud image team are the ones afaik still using vmbuilder. pushing gaughen to have her team maintain vmbuilder would seem prudent :) | 20:07 |
| hallyn | me, i tried to drop it for 14.04, but adt was at the time still using it. presumably by now it has stopped. | 20:07 |
| nacc | hallyn: thanks! that was the context I was lacking (and poked you as the 'maintainer' in the package) | 20:08 |
| infinity | nacc: As an added bonus, it would modernize the sudoers in vm-builder images, which seem to have a template forked from forever ago. | 20:08 |
| infinity | hallyn: Do they, though? All new releases at least use live-build/livecd-rootfs. | 20:09 |
| hallyn | infinity: last i knew yeah they were using it for something | 20:09 |
| === dax is now known as ro | ||
| nacc | gaughen --^ ? | 20:09 |
| gaughen | nacc, hallyn, infinity we are moving away from it | 20:09 |
| nacc | ok :) | 20:09 |
| gaughen | and the vmbuilder that is used is a rather old fork | 20:09 |
| hallyn | gaughen: toward livebuild? | 20:09 |
| hallyn | gaughen: there are no newer forks afaik :) | 20:10 |
| hallyn | nacc: so you could start with doing a fresh reverse depds check on vmbuilder, | 20:10 |
| hallyn | on the one hand it was a pretty clean solutoin and one day i think we'll want it back, | 20:10 |
| infinity | Well, even if we remove it from zesty, this bug is in xenial and trusty and needs fixing. | 20:10 |
| hallyn | but otoh it's unmaintained atm and (obviously) out of date | 20:10 |
| * infinity wonders if trusty's sudo speaks sudoers.d | 20:11 | |
| hallyn | ok | 20:11 |
| hallyn | like i say i think we'll want it back someday (when cloud-images stop being a thing) :-) | 20:11 |
| infinity | It does. Handy. | 20:11 |
| infinity | hallyn: Err, why would either of those things happen? | 20:12 |
| hallyn | i dunno, why would ubuntuone storage go away | 20:12 |
| infinity | Anyhow, I disagree heartily. | 20:12 |
| hallyn | we went from something the community could generate to something where community depends on someone else, | 20:12 |
| * nacc backs away slowly... | 20:12 | |
| nacc | hallyn: infinity: gaughen: thanks for the help on this bug! | 20:12 |
| infinity | Even if we stopped producing the one thing that makes us more money than anything else, we'll be in a position to give people a way to do it "the way we did the official ones". | 20:12 |
| infinity | hallyn: Work is in place to make it a 1-command no-brainer to emulate our infra. | 20:13 |
| hallyn | agreed it seems unlikely, but the way we do the official ones is afaik secret sauce | 20:13 |
| hallyn | oh that'd be awesome | 20:13 |
| hallyn | no wait | 20:13 |
| hallyn | is it based on snappy? | 20:13 |
| infinity | No. | 20:13 |
| infinity | I mean, there will be snap-based images too, but that's not what I was refering to. | 20:14 |
| hallyn | cool, that'll be awesome to see | 20:14 |
| hallyn | then all the more reason i should offer nacc: hey nacc, if you manage to drop vmbuilder from the archive before feb, and if you're in bruseels for fosdem, i'll buy you a beer and a waffle. | 20:15 |
| infinity | nacc: So, anyway, short story from my investigation: sudoers.tmpl in vm-builder is wildly out of date anyway, and sudo in both trusty and xenial supports sudoers.d, so drop the sudoers templates, add a template for /etc/sudoers.d/ubuntu that includes just the bottom bit of the template, test, win. | 20:15 |
| sarnold | a beer -and- a waffle? nice | 20:16 |
| infinity | nacc: And by all means, also file a removal request for vm-builder from zesty if no one cares to maintain it and gaughen is sure it's not being used in zesty. | 20:16 |
| gaughen | nacc, we can double check with Odd_Bloke so we're 200% sure | 20:16 |
| gaughen | nacc, will send a note and cc you. | 20:43 |
| nacc | hallyn: infinity: gaughen: ack on all that, thanks! | 21:20 |
| === nacc_ is now known as nacc | ||
| nacc | so is it just me, or is the current assignee of LP: #1299186 spam? | 23:24 |
| ubottu | Launchpad bug 1299186 in samba (Ubuntu) "Creating a Samba Share is not possible because "'net usershare' returned error 255: net usershare add: cannot convert name "Everyone" to a SID. Access denied."" [High,Confirmed] https://launchpad.net/bugs/1299186 | 23:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!