[14:27] <rbasak> xnox: please could you look at bug 1798786? Claimed to be a regression caused by libssl bump.
[14:28]  * rbasak doesn't see how that's "In progress"
[14:29] <rbasak> ahasenack: ^ ah, just noticed the timing of your comment
[14:29] <rbasak> I added the regression-update tag.
[14:29] <ahasenack> yep, uploading to the sru queue as we speak
[14:29] <ahasenack> meant to ping xnox just to let him know
[14:29] <rbasak> Because I feel this should feed back to the SRU team on regression considerations for the SSL work.
[14:30] <rbasak> Ah. Thanks!
[14:30] <xnox> rbasak:  SNI is real, one must send SNI. SO that sru should ship, if it hasn't yet - https://code.launchpad.net/~ahasenack/ubuntu/+source/fetchmail/+git/fetchmail/+merge/368713
[14:30] <ahasenack> doing it right now
[14:30] <ahasenack> just checking the version number, I might have made a mistake there
[14:31] <ahasenack> ah, yeah
[14:31] <ahasenack> 6.3.26-3build1    | bionic
[14:31] <ahasenack> 6.3.26-3ubuntu0.1 | cosmic-updates
[14:31] <rbasak> xnox: sure. No objection to the SRU. I just mean that for the libssl work, it's "Regression Potential" that might have been missed.
[14:31] <rbasak> (this could be a class of bugs and not just one)
[14:32] <ahasenack> what version can I use for bionic in this case? Cosmic has the fix already
[14:32] <rbasak> xnox: do we need to actively look for others, for example, to make sure that we haven't created other regressions?
[14:32] <ahasenack> I need something between 3build1 and 3ubuntu0.1
[14:32] <ahasenack> 3ubuntu0.1~18.04.1?
[14:32] <rbasak> ahasenack: +1
[14:32] <rbasak> Interesting odd case :)
[14:33] <xnox> rbasak:  we have fixed half-a-dozen of these SNI things in all the things already. all of those SRUs landed in bionic, prior to landing 1.1.1 sru.
[14:33] <xnox> but obviously missed fetchmail
[14:34] <rbasak> xnox: ack. I was just asking if it needs to be thought about, not knowing what had already been considered.
[14:35] <xnox> rbasak:  all good. SNI was called out as Regression Potential in the openssl 1.1.1 sru.... =)
[14:35] <xnox> we did anticipate, plan, fix things for it.
[14:35] <rbasak> Ah, OK :)
[14:36] <rbasak> ahasenack: when you upload, do you want a fast review for that? Seems appropriate.
[14:36] <ahasenack> sure
[14:36] <ahasenack> rbasak: mp is/was https://code.launchpad.net/~ahasenack/ubuntu/+source/fetchmail/+git/fetchmail/+merge/368713
[14:36] <ahasenack> I'll just have to update the version number, then maybe you can take a quick look, since cpaelzer's +1 was for the former?
[14:37] <rbasak> Possibly warrants an aging period ignore too, given that it's a regression and the fix is well tested in other series.
[14:37] <rbasak> Sure
[14:38] <cpaelzer> yep
[14:38] <cpaelzer> ahasenack: did you push a new version number to not collide?
[14:38] <ahasenack> cpaelzer: rbasak: just now
[14:43] <rbasak> ahasenack: +1. Sorry I think I stole the wrong review slot.
[14:43] <rbasak> (there are no longer any team ones)
[14:44] <rbasak> ahasenack: (please upload)
[14:45] <ahasenack> rbasak: done
[14:50] <rbasak> Does anyone think that a quick verification and release into -updates immediately is a bad idea for this one?
[14:51] <rbasak> The source is identical to what is in Cosmic now anyway, sans changelog
[14:51] <ahasenack> it's even the same version from cosmic
[14:51] <ahasenack> yeah
[14:51] <ahasenack> the test is super easy, I can do it as soon as it's available
[14:51] <rbasak> So only risk is of the rebuild environment being different (which, to be fair, we know it is, because of so much work in Bionic)
[14:51] <ahasenack> rbasak: well there is a new ssl being picked up this time :)
[14:51] <rbasak> :)
[15:30] <ahasenack> rbasak: fetchmail verification done
[15:32] <rbasak> ahasenack: thanks!
[15:33] <rbasak> vorlon: your comment introduces some doubt. Do you think I should wait before releasing?
[15:33] <rbasak> xnox: do you think you could help with vorlon's question in bug 1798786 please? I don't see you subscribed.
[15:36] <xnox> rbasak:  vorlon: https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1798786/comments/27
[15:37] <rbasak> xnox: sounds like you're confident - are you happy for me to release?
[15:37] <vorlon> rbasak, xnox: thanks
[15:41] <xnox> rbasak:  yes.
[15:41] <rbasak> Done. Thanks!
[15:41] <rbasak> (and to Andreas)
[15:42] <rbasak> (and Christian, and Steve!)
[18:45] <TJ-> is there a way to auto-generate an initial man-page for a built binary from its --help prior to custom editing it?
[19:28] <ahasenack> TJ-: I used txt2man in the past to bootstrap a new manpage
[19:32] <bryce> +1 to txt2man
[19:33] <bryce> (if the tool's --help is sensibly formatted)
[19:52] <TJ-> ahasenack: thanks! I ended up doing it manually. I'm packaging dmzadm (for dm-zoned) SMR drive management etc
[19:53] <ahasenack> good luck, and thanks for thinking about the manpages :)
[19:58] <TJ-> ahasenack: I live in man-pages; couldn't be without :)
[19:58] <ahasenack> :)
[20:07] <TJ-> am I correct in thinking, for the version, if I publish initially in a PPA that -0ubuntu1-xxxx (so that there's no Debian version number) is the way to go?
[20:09] <TJ-> hmmm that should be -0ubuntu1~xxxx "~" of course
[20:09] <ahasenack> ~, yes
[20:09] <ahasenack> I use ~ppaN
[20:41] <TJ-> I'm doing (test) builds for 18.04>19.10 so I add ~YYMM[.minor]
[21:48] <TJ-> In case anyone wants to test dmzadm with the dm_zoned device-mapper module, for SMR ZAC/ZBC (host managed) shingled drives, https://launchpad.net/~tj/+archive/ubuntu/ppa/
[21:50] <Unit193> txt2man?  Seems like you mean help2man.