[00:36] <mwhudson> uhh
[00:36] <mwhudson> is ssh-import-id just broken on focal?
[00:36] <mwhudson> mwhudson@anduril:~$ ssh-import-id lp:mwhudson
[00:36] <mwhudson> 2020-02-24 13:36:25,093 ERROR module 'platform' has no attribute 'dist'
[00:36] <mwhudson> looks like a python 3.8 thing
[00:37] <cjwatson> Easy fix is to port it to the distro module
[00:37] <cjwatson> (Not in the standard library, but it's more or less a drop-in replacement)
[00:39] <cjwatson> https://pypi.org/project/distro/
[00:39] <mwhudson> ah https://bugs.launchpad.net/ubuntu/+source/ssh-import-id/+bug/1864107
[00:40] <mwhudson> and https://code.launchpad.net/~waveform/ssh-import-id/+git/ssh-import-id/+merge/379351
[00:40] <mwhudson> now where was i in this mountain of yaks
[07:02] <cpaelzer> vorlon: doko: I see you have restarted tests related to the new procps upload that is breaking postgresl-common autopkgtests - is there an analysis/bug for that already?
[07:57] <cpaelzer> vorlon: was bug 1864424 intentional to bring in mouse=a for 20.04?
[08:33] <ackk> hi, is it expected for focal not to have the nice boot screen & password prompt for encrypted volumes yet?
[08:44] <mwhudson> ackk: works for me
[08:44] <mwhudson> ackk: or to more directly ask, no i don't think that is expected
[08:44] <ackk> mwhudson, did you upgade or run a fresh install?
[08:45] <mwhudson> ackk: upgrade
[08:45] <ackk> ok, mine was a fresh install. it also seems it takes a looong time until the password prompt, and then until gdm login
[08:45] <ackk> also, after install, I didn't have any snap installed nor I could install them
[08:46] <ackk> snap reports that the system is not yet seeded
[08:47] <mwhudson> ah now that sounds like a reported bug
[08:47] <ackk> mwhudson, FWIW even during the boot of the installer I didn't get the nice spash screen
[08:47] <ackk> I only had a purple text screen with an off-centered "Ubuntu 20.04" text
[08:49] <ackk> mwhudson, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1864230 maybe?
[08:50] <mwhudson> ackk: yeah
[08:50] <mwhudson> ackk: https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1864252 might be the fix?
[08:51] <ackk> mwhudson, ah, nice
[08:51] <mwhudson> ackk: cat /var/log/installer/media-info?
[08:52] <ackk> mwhudson, Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200220)
[08:53] <mwhudson> ackk: so before that livecd-rootfs fix landed
[08:55] <ackk> mwhudson, do I need to reinstall?
[08:57] <mwhudson> ackk: hm, don't know
[08:57] <mwhudson> ackk: you can probably fix it by messing around in /var/lib/snapd and rebooting
[08:57] <mwhudson> ackk: but reinstalling is probably easier...
[08:58] <mwhudson> ackk: you could ask #snappy about the seeding issues
[09:32] <ackk> mwhudson, thanks
[09:33] <mwhudson> ackk: seems Laney has found some problems with the fix, but things are in progress at least
[09:34] <Laney> :'(
[09:43] <doko> cpaelzer: no analysis done yet
[09:44] <doko> oSoMoN: marcustomlinson: could you have a look at the lo arm64 autopkg test failure?
[09:51] <marcustomlinson> doko: If I don’t get to it I’ll let hellsworth know
[09:52] <cpaelzer> doko: vorlon: ok I have started in https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1864423
[09:55] <doko> cjwatson: openssh gained some new dependencies on universe packages. do we need to promote those, or should we build without those?
[10:12] <cjwatson> doko: we should really MIR and promote libfido2 - the new version of openssh uses it for U2F (universal second-factor token) support, which is the headline feature in openssh 8.2 and I want it in focal
[10:14] <cjwatson> doko: (ref. https://www.openssh.com/txt/release-8.2 under "Changes since OpenSSH 8.1")
[10:14] <cjwatson> I think we'll also need to add libfido2 to the i386 whitelist
[10:22] <doko> cjwatson: that includes libcbor and mathjax
[10:23] <doko> filing a MIR
[10:24] <cjwatson> Thanks
[10:25] <cjwatson> doko: Wait, why mathjax?
[10:28] <doko> cjwatson: libcbor-doc depends on it. so we should blacklist that one
[10:35] <cjwatson> doko: Might be simplest
[13:17] <ahasenack> Skuggen: hi, mysql8 question
[13:18] <ahasenack> Skuggen: password() was removed/deprecated, right
[13:18] <ahasenack> Skuggen: I'm looking at a patch where someone changed password("%s") to
[13:19] <ahasenack> CONCAT('*',UPPER(SHA1(UNHEX(SHA1('%s')))))
[13:19] <ahasenack> is that the right thing to do?
[13:19] <ahasenack> rbasak: if you have seen that before^
[13:20] <rbasak> I've not seen that before
[13:21] <rbasak> Looks like someone is constructing their own KDF
[13:21] <rbasak> (badly)
[13:26] <ahasenack> we might be better off going with a new upstream release for this one
[13:26] <ahasenack> ahead of debian
[13:26] <ahasenack> the new release works with mysql8 (allegedly)
[13:26] <ahasenack> and doesn't do this with the password
[13:32] <ahasenack> hm, the new version pulled in a lot of crypto/hash functions
[13:32] <ahasenack> is doing the hash client side and then comparing
[13:45] <Skuggen> Yeah, that looks kind of horrible :)
[13:48] <ahasenack> Skuggen: suggestions? :)
[13:49] <Skuggen> Which package is this?
[13:49] <ahasenack> zoneminder
[13:49] <ahasenack> that change came from an attached patch, to the bug
[13:49] <ahasenack> Skuggen: this bug: https://bugs.launchpad.net/ubuntu/+source/zoneminder/+bug/1859295working
[13:50] <ahasenack> the other changes are basically quoting new reserved keywords in mysql8
[13:50] <ahasenack> like Groups, Function
[13:50] <ahasenack> and match what upstream did
[13:50] <Skuggen> Right
[13:53] <Skuggen> I don't really understand what it's doing, but is that meant to work with mysql_native_password, or caching_sha2_password?
[13:54] <ahasenack> I'm not sure either, it looks like it has its own user db, and is doing a simple string comparison to authenticate someone
[13:54] <ahasenack> or find someone in the db
[13:54] <ahasenack> the new upstream code does just this query in the beginning:
[13:55] <ahasenack>       "SELECT `Id`, `Username`, `Password`, `Enabled`, `Stream`+0, `Events`+0, `Control`+0, `Monitors`+0, `System`+0, `MonitorIds`"
[13:55] <ahasenack>       " FROM `Users` WHERE `Username` = '%s' AND `Enabled` = 1", safer_username);
[13:55] <ahasenack> (it dropped Password = )
[13:55] <Skuggen> There's some functionality for setting password there, which should probably just be replaced with the standard user management
[13:55] <ahasenack> but does this new thing later:
[13:55] <ahasenack>   if ( verifyPassword(username, password, user->getPassword()) ) {
[13:55] <ahasenack> and that verifyPassword() function does the hashing now
[13:55] <ahasenack> manipulating SHA_CTX and whatnot via openssl
[13:56] <ahasenack> with checks like
[13:56] <ahasenack>   if ( db_password_hash[0] == '*' ) {
[13:56] <ahasenack>     // MYSQL PASSWORD
[13:56] <ahasenack> ....
[13:57] <ahasenack> funny that they *moved* to SHA1
[13:57] <Skuggen> Where is the code for creating users?
[13:58] <Skuggen> Maybe they set them to use mysql_native_password
[13:59] <ahasenack> don't know yet, https://github.com/ZoneMinder/zoneminder/tree/master/src is what I'm looking at, but that's the new upstream version
[13:59] <Skuggen> Yeah, I'm looking there too
[13:59] <ahasenack> current code in focal (well, my branch on top of focal) is https://code.launchpad.net/~ahasenack/ubuntu/+source/zoneminder/+git/zoneminder/+ref/focal-zoneminder-mysql8
[14:00] <Skuggen> But it doesn't really seem like upstream's code is less hacky about this than that patch :)
[14:00] <Skuggen> It's just that it doesn't seem to me it should work if the users are set to caching_sha2
[14:00] <ahasenack> https://github.com/ZoneMinder/zoneminder/tree/1.32.3/src is what is in focal
[14:01] <ahasenack> based on tag and version number, that is
[14:03] <Skuggen> Oh, wait!
[14:03] <Skuggen> I've misunderstood completely. These aren't mysql users :P
[14:03] <ahasenack> no
[14:04] <ahasenack> its their own, and they just happened to use mysql's password() function for convenience is my guess
[14:04] <Skuggen> Yeah
[14:04] <Skuggen> It's just that the password() function was a sha1 function
[14:05] <Skuggen> So it's "fine".
[14:05] <ahasenack> so they do a query for where user=foo, pass=bar, and if that query fails, say that authentication failed
[14:05] <rbasak> If it was, then perhaps it's no loss to reimplement as the replacement that ahasenack originally suggested?
[14:05] <rbasak> Even if that is bad, that is what they were doing before
[14:05] <Skuggen> Yeah
[14:06] <ahasenack> ok
[14:06] <rbasak> Meanwhile, clickhouse is taking forever to build :-(
[14:07] <ahasenack> rbasak: yeah, last good build was recorded at 1h in LP
[14:07] <ahasenack> rbasak: did you look at that removal bug? Just in case this is a waste of time (trying to get it to build)
[14:08] <Skuggen> One possible concern for ZM is the way the hashing is done, though; Is it correct, i.e. as secure as it was before?
[14:10] <rbasak> ahasenack: it looks like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950983 is the same issue and proposes a trivial patch, so I'm trying that
[14:10] <rbasak> Reproducing the failure first though
[14:10] <rbasak> (locally)
[14:11] <rbasak> Skuggen: if it's wrong, hashes will mismatch and nobody will be able to log in
[14:11] <rbasak> (until individual passwords are reset)
[14:11] <rbasak> Who wrote that replacement?
[14:12] <ahasenack> rbasak: https://bugs.launchpad.net/ubuntu/+source/zoneminder/+bug/1859295/comments/1 the person who opened the bug
[14:12] <ahasenack> https://launchpad.net/~joe-yasi
[14:13] <Skuggen> Maybe ask if he's tested with an upgrade scenario?
[14:15] <ahasenack> I think I'll upload the ftbfs fix first
[14:16] <ahasenack> I thought tackling this runtime bug would be quicker (as I was just seeing those quoting changes), but then I stumbled on this
[14:26] <Skuggen> Hehe
[15:05] <vorlon> cpaelzer: mouse=a> no; there was a change upstream of us that I thought I saw had made the mouse=a behavior conditional on OS, but apparently I misread. I'll restore the patch
[15:05] <cpaelzer> thanks vorlon
[15:06] <cpaelzer> in that case I'm glad I filed the bug and asked about it
[15:06] <vorlon> ah maybe I was led astray by "can be reverse-applied" :P
[15:06] <vorlon> but reverse-applying a deletion, well..
[15:10] <vorlon> cpaelzer: ah new procps is breaking it because the new Debian version is setting fs.protected_regular=2 (debian/protect-links.conf)
[15:11] <vorlon> cpaelzer: so this is related to https://lists.ubuntu.com/archives/ubuntu-devel/2020-February/040904.html etc
[15:11] <cpaelzer> vorlon: is that what you get out of the debug into I put into the postgresql-common bug?
[15:11] <vorlon> yes
[15:12] <cpaelzer> oh I have read that thread, but not mapped the two into one
[15:12] <vorlon> systemd was setting fs.protected_regular=1, and that caused some problems
[15:12] <vorlon> procps is setting f.sprotected_regular=2, which causes more problems
[15:12] <vorlon> kees: ^^ hey there's your =2
[15:13] <vorlon> so, changing postgresql-common is for the good to make it more portable; but we may want to revert this procps change
[15:16] <cpaelzer> ack
[16:20] <rbasak> xnox: o/ are you working on the new clickhouse FTBFS?
[16:50] <rcj> Could I get a sponsor to upload livecd-rootfs for the MPs in bug #1864252 ?
[16:50] <rcj> Eoan builds are blocked on this bug
[16:53] <rbasak> PSA: the DMB election has closed and the results are available directly from CIVS. I am clearing up a minor administrative matter before I send the announcement, so it may not be today.
[16:53] <rbasak> teward: FYI ^
[16:53] <teward> thanks rbasak
[16:53] <rbasak> We do have a DMB meeting scheduled today
[16:53] <rbasak> I'm not sure who is in the DMB currently!
[16:55] <Laney> only 31% turnout? :(
[16:55] <Laney> but well done to the (eventual) new members :>
[16:56] <teward> yeah i noticed that too :P
[17:02] <teward> rbasak: i just took a look at the agenda it doesn't look like there's any pressing matters that need attention today from the DMB just the regular holdovers.
[17:02] <teward> so given that it might just be prudent to skip the meeting today
[17:02] <ahasenack> xnox: hi, your clickhouse upload is failing to build on arm64 and s390x, and I see you included a fix for https://bugs.launchpad.net/ubuntu/+source/clickhouse/+bug/1863026
[17:03] <rbasak> teward: that might be a good idea.
[17:03] <teward> rbasak: there is something that needs attention on the 9th but that's not today's meeting so :P
[17:08] <ahasenack> xnox: I marked the clickhouse task in that bug I linked as "fix committed"
[18:12] <ricotz> ahasenack, hi, I assume this needs a i386 exception https://launchpad.net/ubuntu/+source/bind9-libs/1:9.11.16+dfsg-3~build1
[18:14] <ahasenack> ricotz: indeed, since bind9 had it
[18:50] <xnox> rbasak:  ahasenack: in theory, yes, in practice i'm not sure what the test regressions on arm64/s390x are yet. I did fix the failure to build, it *just* now fails to pass compile time test
[19:04] <ahasenack> rbasak: Skuggen: https://pastebin.ubuntu.com/p/b2yw9hv28p/
[19:04] <ahasenack> rbasak: Skuggen: output is always the same (this is mysql 5.7)
[19:04] <ahasenack> I checked 5.7's source, and that's exactly what PASSWORD() did back then
[19:04] <ahasenack> double sha1(), display as hex
[19:05] <ahasenack> no salt, nothing else
[19:08] <rbasak> Looks good!
[19:17] <Skuggen> Yup
[19:25] <bryce> xnox, although php7.4 is still in proposed due to icu, I'd like to go ahead and kick off the php 7.4 transition today by uploading the new php-defaults, if that won't cause any troubles for you with the icu transition?
[19:28] <xnox> bryce:  well arm64 instances fail to boot at the moment, thus icu is stuck behind libreoffice
[19:33] <bryce> xnox, yeah it sounds like you may need some time for getting icu sorted.  I want to get php at least started before FF, but only if it won't impact your work negatively.  I don't think it will but wanted to doublecheck with you first.
[19:37] <xnox> bryce:  ah.... you are not on #ubuntu-release
[19:37] <xnox> bryce:  vorlon might try to make icu transition regardless libreoffice.
[19:38] <bryce> xnox, ok so you'd advise to hold off for now?
[19:39] <xnox> bryce:  "<vorlon>	and no we shouldn't be uploading any packages currently tangled in icu for the php transition until icu is done"
[19:39] <xnox> bryce:  please don't upload php-defaults just yet
[19:39] <bryce> xnox, alright, thanks
[19:41] <xnox> bryce:  also join #ubuntu-release for transitions coordination
[19:42] <xnox> with the release team
[19:43] <vorlon> no
[19:43] <vorlon> php-defaults is not dependent on icu
[19:43] <vorlon> and he can upload that just fine
[19:43] <vorlon> (as I said on Friday)
[19:44] <vorlon> but things currently in -proposed which depend on icu should not be reuploaded for new php until after icu migrates
[19:46] <bryce> I think only php7.4 itself is dependent on icu (it's the only package I've noticed this so far, anyway).  I wasn't needing to alter php7.4 though, and it's fine if the remaining php bits stay in proposed as a result, until icu is migrated.
[19:46] <vorlon> bryce: ^^
[19:46] <vorlon> right
[19:46] <vorlon> so, since bryce has already coordinated with the release team on this... :)
[19:48] <bryce> vorlon, xnox, thanks.
[19:49] <xnox> ah, ok, now i understand what you mean
[20:32] <mwhudson> good morning
[20:35] <sarnold> welcome back mwhudson :)
[21:51] <bdmurray> Does anybody know if there is a bug report about my T450s keyboard light keeps turning on?
[23:33] <CarlFK> Feb 24 23:05:25 main-menu[367]: (process:3286): dpkg-divert: warning: diverting file '/sbin/start-stop-daemon' from an Essential package with rename is dangerous, use --no-rename  http://paste.ubuntu.com/p/GYF4sbXDkJ/
[23:35] <CarlFK> pxe + preseed.cfg di/key/value file from bionic.