[07:49] <cpaelzer> can I have some opinions on https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1822370/comments/9
[07:49] <ubottu> Launchpad bug 1822370 in openssh (Ubuntu) "19.04 beta openssh-client broken pipe" [Critical,Triaged]
[07:49] <cpaelzer> cjwatson: as it is openssh your opinion would be expecially great to ahve
[07:50] <cjwatson> cpaelzer: did you look through Debian bugs?  it has certainly been reported there.
[07:50] <cjwatson> I consider this a VMware bug and if anyone is pushing for this we need to put pressure on VMware to fix it.
[07:50] <cpaelzer> not yet, I was collecting through vmware and fedora references so far
[07:51] <cpaelzer> I consider this a VMWare bug as well
[07:51] <cpaelzer> may question is if we should avoid putting it on our users due to the upcoming release
[07:51] <cjwatson> I don't want to revert this as that just takes the pressure off.
[07:51] <cjwatson> It's not an LTS after all
[07:51] <cpaelzer> ok, I'd be happy if you could state so in the bug
[07:52] <cpaelzer> I have a call today with VMWare anyway and can make sure this is really seen on their side
[07:52] <cjwatson> done
[07:52] <cpaelzer> thanks
[07:53] <cjwatson> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923879 is a more persuasive reason to possibly revert
[07:53] <ubottu> Debian bug 923879 in openssh-client "ssh: IPQoS defaults change interacts badly with iptables -m tos" [Normal,Open]
[07:53] <cjwatson> but I haven't had time to independently research that
=== ricab is now known as ricab|lunch
=== ricab|lunch is now known as ricab
[16:56] <bdmurray> seb128: Do you know if anything is happening with bug 1807900?
[16:56] <ubottu> bug 1807900 in update-manager (Ubuntu Bionic) "update-manager suggests to use Livepatch, which is not available" [High,Triaged] https://launchpad.net/bugs/1807900
[17:01] <Laney> rbasak: you have ~ubuntu-developer-members available, FWIW (re: devel-permissions@)
[17:01] <Laney> (specifically your last paragraph)
[17:04] <rbasak> Laney: thanks! I was going to ask you for input, as a person who comes to mind who understands how it's all put together :)
[17:04] <Laney> It's the not-very-used DMB-as-a-membership-board procedure
[17:04] <rbasak> Laney: would ~ubuntu-dev be better to retain voting rights though?
[17:05] <rbasak> Assuming the DMB is happy to do that, which I suppose is a separate decision.
[17:05] <rbasak> As we don't have any documented emeritus process AFAICT.
[17:05] <Laney> I'm not sure that there's precedent for ~ubuntu-dev without any upload rights
[17:05] <Laney> So you'd be inventing a new thing there AFAIK
[17:05] <rbasak> I agree it'd be a new thing.
[17:05] <rbasak> Seems to be that we should have an emeritus process, or at least know what to do.
[17:06] <Laney> Makes sense
[17:06] <Laney> I think not retaining voting rights would be more usual (but haven't given it a whole lot of thought)
[17:06] <rbasak> It also seems to me that as leaving ~ubuntu-core-dev is effectively voluntary, but a good thing (on a security basis), it should be possible to do so without being forced to lose other rights, eg. voting.
[17:07] <Laney> Something like - if you're not participating in the community then you don't have as good a context or "skin in the game" relating to its governance
[17:07] <Laney> But it'd be more proper for you in the DMB to work that up and maybe ask the CC
[17:07] <rbasak> Yes, but then that needs to be enforced, rather than having the obvious workaround to be click a button every two years.
[17:10] <Laney> Not sure about "needs", but it would be valid to scope the problem wide enough to cover this
=== Erich is now known as Eickmeyer
[17:18] <rbasak> Perhaps I can create an ~ubuntu-dev-emeritus team and leave it as a member of ~ubuntu-developer-members for now.
[17:19] <rbasak> Then we could decide where to move it later.
[18:05] <seb128> bdmurray, I don't know off hand, need to check with andyrock
[18:11] <seb128> bdmurray, he's going to look at it
[18:14] <bdmurray> seb128: okay, I wasn't sure if we should defer it to EE
[18:15] <seb128> bdmurray, it probably doesn't matter much for disco since livepatch doesn't exist on that serie
[18:26] <teward> seb128: bdmurray: we see questions occasionally on Ask Ubuntu about livepatch on the interim releases between LTSes
[18:27] <teward> so if we're going to 'fix' this I'd target EE for fixing it since users otherwise will get the wrong ideas about Livepatch service
[18:27] <teward> (just my two cents, sorry I just saw yuor messages in scrollback thought I'd give my thoughts)
[18:28] <bdmurray> teward: iirc it works but checking to see if you are running an LTS so its moot
[18:28] <teward> bdmurray: good point, but that's where the questions come in at :P  In either case I'd rather the system not even suggest it when Livepatch isn't an option in that release :P
[18:28] <teward> but you're not wrong.
[18:29] <teward> the only system I use livepatching on is this laptop but that's for reasons - sometimes I go a few weeks without applying kernel updates :P
[18:29] <bdmurray> teward: It shouldn't suggest it is my point.
[18:29] <teward> bdmurray: right, i agree with you
[18:29] <bdmurray> teward: I mean that it already shouldn't / that was fixed.
[18:32] <bdmurray> teward: https://bazaar.launchpad.net/~ubuntu-core-dev/update-manager/main/view/head:/UpdateManager/Dialogs.py#L151
[18:37] <teward> ah
[18:37] <teward> not sure why people were still using it then :P
[19:09] <seb128> teward, it should already not show on non LTS series, that bugfix is about not displaying the control on the LTS if the UI is not available which is a specific fix
[20:15] <infinity> bdmurray: My only nitpick on this apport is that if "whoopsie-preferences is needed to store preferences", that seems more like a Recommends than a Suggests?
[20:15] <infinity> bdmurray: Unless you don't view preferences as a meaningfully core functionality.
[20:32] <bdmurray> infinity: it'd end up pulling whoopsie-preferences into cloud-image then. although looking at the original MP it's only apport-gtk which makes the gdbus call - https://code.launchpad.net/~didrocks/apport/whoopsie-auto-ui/+merge/348479
[20:33] <infinity> bdmurray: So maybe it's apport-gtk that wants it as a recommends (or even depends)?
[20:34] <infinity> bdmurray: That said, nothing in whoopsie-preferences or its deps looks inappropriate for a CLI system, if the CLI apport had a way to save prefs.
[20:34] <infinity> Depends: libc6 (>= 2.4), libglib2.0-0 (>= 2.30.0), libpolkit-gobject-1-0 (>= 0.99), libwhoopsie-preferences0 (= 20), libwhoopsie0 (>= 0.2.48)
[20:35] <bdmurray> infinity: The cli apport doesn't have a way to save preferences
[20:35] <infinity> bdmurray: Kay, so maybe this dep should move to -gtk and be upgraded to rec/dep (your call)
[20:36] <bdmurray> infinity: that sounds like a good idea
[20:41] <infinity> bdmurray: I can haz an upload that does that, then?  (And if it's a recommends, I assume you already had code that conditionally uses this, rather than crashes when it's not there?)
[20:42] <bdmurray> infinity: I'll upload for disco and it'll be a depends fwiw I'm fixing somebody else's bug here.
[20:43] <infinity> Of course. :)
[21:17] <bdmurray> coreycb: I feel like your comment is missing something in the url https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-auth-mellon/+bug/1820279/comments/3
[21:18] <ubottu> Launchpad bug 1820279 in libapache2-mod-auth-mellon (Ubuntu Cosmic) "[FFe] [SRU] build mellon with --enable-diagnostics to ease up SSO debugging" [High,Triaged]
=== smow is now known as Guest92455
=== pfsmorigo is now known as Guest7369
=== BenderRodriguez is now known as Stalin
=== Stalin is now known as BenderRodriguez