=== dax is now known as housecat
[02:39] <themill> What's the oldest currently supported ubuntu release and what version of Python 3 does it have? I'm wondering what level of legacy cruft can be ditched from python-debian now.
[02:47] <fo0bar> themill: for mainline support: https://packages.ubuntu.com/search?keywords=python3 -- though trusty (3.4.0) is in paid ESM
[02:52] <themill> thanks; I think 3.4 is the newest version for which we have explicit compat code in there, so being able to set python 3.5 as the lowest limit would be reasonable from an Ubuntu perspective and would also allow lots of cleanup
[08:36] <cjwatson> themill: I mean we aren't going to upgrade trusty to newer python-debian anyway ...
[08:39] <Unit193> I'm perhaps a bit lax, but trimming up to Bionic seems pretty fine to me.
[08:47] <cjwatson> Unit193: Selfishly, Launchpad runs on xenial and we often want to upgrade python-debian there (it's installed in a virtualenv)
[08:47] <cjwatson> Though hopefully that'll be bionic in the near future
[08:49] <cjwatson> (Python 2 on xenial, too, so upgrading to newer upstreams is getting more difficult in general anyway)
[08:50] <Unit193> That would be rather rough.  Another Ubuntu server I know of is on Trusty..Doubtful ESM.
[08:55] <cjwatson> We've been scrabbling to get things a bit more current but it is a lot of work.
[09:04] <Unit193> IIRC you've said i386 too, with that and py2 it seems you'll be having a lot of that in the future. :/
[09:16] <cjwatson> Unit193: I use i386 for my local test containers to save memory, but production is amd64
[09:16] <Unit193> Ahh, OK.
[09:16] <cjwatson> (And memory is probably less of an issue nowadays anyway, but old habits)
[09:18] <cjwatson> https://git.launchpad.net/~cjwatson/launchpad/log/?h=py3 is a (non-fast-forwarding) Launchpad branch with various fixes to improve Python 3 support from which I've been landing various bits and pieces over time
[09:18] <cjwatson> But it's at the stage of "you can start the test suite and it at least runs even though it produces a bazillion test failures"
[11:08] <wgrant> doko, mwhudson: https://launchpad.net/~wgrant/+archive/ubuntu/nonvirt/+build/19151918 <- a riscv64 golang-1.14 if you want it
[13:09] <doko> wgrant: but that doesn't build with the current golang-defaults, does it? for that we need to update golang-defaults to 1.4
[15:54] <fo0bar> wgrant: you mentioned in your README that sshd wasn't included in the riscv64 image, but FWIW, I wasn't able to get openssh-server workin at all.  connections would always freeze during preauth
[15:54] <fo0bar> dropbear works fine though, so I'm just pretending this is a consumer router :)
=== hggdh is now known as hggdh-msft
[15:57] <fo0bar> when the system is under load, htop works for literally a second then will exit "Success".  and in general, I've noticed things like to ENOMEM even when they're plenty of free memory
[15:57] <fo0bar> "besides that, Mrs. Lincoln..."
[15:57] <fo0bar> would these be useful reporting anywhere?
[15:59]  * fo0bar notices even more typing mistakes than usual above, and decides he should get coffee first
=== rick_h_ is now known as rick_h
[18:31] <cjwatson> fo0bar: Can you get anything from /var/log/auth.log?
[18:31] <cjwatson> (for sshd)
[18:32] <cjwatson> Or ssh -vvv
[18:42] <fo0bar> cjwatson: https://pastebin.ubuntu.com/p/QDfyfcTSHk/
[18:43] <fo0bar> stock server config except LogLevel DEBUG.  trying to do password auth to 127.0.0.1 results in basically the same thing
[18:45] <fo0bar> speaking of syslog, I have syslog-ng installed because it looks like rsyslog isn't in yet.  is there a riscv64-specific ftbfs tracking page somewhere?
[19:38] <cjwatson> Hm, sorry, not obvious without significantly more digging.  An strace might be worthwhile I guess
[19:49] <fo0bar> ... and strace isn't in riscv64 yet :)  no worries, thanks
[19:50] <fo0bar> interestingly, load doesn't go up during those two minutes, so it's not spinning per se
[19:50] <cjwatson> I wondered if it might be a seccomp filter bug, but just a guess
[22:54] <xnox> there appears to be a lot of linux-signed* handling in ubiquity & base-installer, which was just left there. Despite us stopping to use linux-signed
[22:55] <xnox> also we have many different flavours now that one can use, yet somehow baseinstaller lists never got updated. I wonder how our kernel flavour selection works now.
[23:36] <wgrant> fo0bar: I'd try with the old qemu if you can. The sshd hang, though, might be due to lack of entropy, so a virtio-rng might be an idea
[23:36] <wgrant> qemu 4.2 made things very unstable. I've no idea why yet
=== hggdh-msft is now known as hggdh