[07:20] <jtaylor> bigon: I got mozilla to change their firefox optimization default :D
[07:21] <bigon> yeah \o/
[07:21] <bigon> you have a bug#?
[07:24] <jtaylor> https://hg.mozilla.org/integration/autoland/rev/8fdb9e30b6a7
[11:59] <abeato> infinity, hey, I registered a bug in debian for klibc: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863761
[11:59] <abeato> ogra_, ^^
[12:03] <ogra_> wheee!
[12:41] <Laney> slangasek: fixed
[14:16] <slangasek> Laney: cheers :)
[15:18] <bigon> jtaylor: "
[15:18] <bigon> We however keep -Os as default for debug builds for now, because -O2
[15:18] <bigon> triggers -Werror=strict-overflow failures somehow. "
[15:18] <bigon> shouldn't that be -Og for easier debugging?
[15:18] <bigon> or no -O option at all?
[15:18] <jtaylor> probably compatibility with older gccs
[15:18] <jtaylor> and Og is not very good
[15:19] <jtaylor> though probably not worse than Os
[15:19] <bigon> do you know in which version that patch will land?
[15:20] <jtaylor> version 55
[15:23] <bigon> thx
[15:26] <pdeee> rbasak, bmw I've drafted an SRU justification for Certbot 0.14.0, and a template for future SRUs
[16:13] <jamespage> slangasek: hi!
[16:14] <jamespage> slangasek: so... what's the position on a package electing to not support 32bit architectures?  ceph as a project are not actively testing 32 on arm or i386
[16:48] <nacc> cjwatson: perhaps you would have the context, is it appropriate to drop the same changes you did in LP: #1334916 for consolekit, in trusty?
[16:50] <slangasek> jamespage: for future releases, it's ok to drop the package; for existing releases, we would want to continue providing the package if at all possible despite upstream not testing
[16:50] <slangasek> jamespage: do we have autopkgtests?
[16:51] <cjwatson> nacc: I'm afraid I don't have the context for that any more - it would involve working out whether the desktop uses consolekit, and whether e.g. you can ssh to a trusty desktop without that patch and with X forwarding and run programs that do policykit checks that the user is an admin
[16:51] <cjwatson> (which IIRC was the original use case)
[16:51] <nacc> cjwatson: ok, I'll put it on the backlog then :)
[17:12] <nacc> mdeslaur: there might be a security regression in LP: #1690380 -- upstream adjusted the change they did (with the commits mentioned in my last comment)
[17:15] <mdeslaur> nacc: thanks, I'll look on mondayt
[17:16] <nacc> mdeslaur: thanks!
[17:54] <Unit193> nacc: Did you get a chance to look at parsedatetime?
[17:55] <nacc> Unit193: argh, sorry! doing it now
[17:55] <Unit193> Thanks.
[20:04] <jamespage> slangasek: limited - however it is possible to test i386 with the charms for ceph
[20:05] <jamespage> slangasek: we're ok for 10.2.x (current stable); next stable (12.0.3) is not so 32bit friendly - that said it is probably fixable
[20:05] <jamespage> slangasek: so this is >= artful only
[20:07] <slangasek> jamespage: right, it's perfectly fine to drop architecture support for a package between releases
[20:08] <jamespage> slangasek: ok I've raised on the upstream ML - lets see if users are actually using armhf or i386 :-)
[20:08] <slangasek> I mean, we want to support packages on every architecture we can, but you're not expected to make a herculean effort to support something that upstream doesn't
[20:15] <infinity> I think we're approaching the point where we need to have a large public discussion about possibly dropping armhf and i386 entirely (post-18.04, perhaps).
[20:15] <infinity> Though I might prefer pre-18.04, it's perhaps a bit late to suggest that.
[20:18] <jbicha> I don't think we have to provide installers for i386 and armhf for 18.04 LTS
[20:19] <mardy> Mirv: hi! At ubports there's an ongoing discussion on whether to move to qt 5.9. Do you have any wise things to say? :-)
[20:19] <jbicha> a compromise idea: what about restricing support lifetime for i386 and armhf to 3 years to match 16.04 LTS?
[20:19] <sarnold> i386 I think you're right, but arm still has a huge amount of enthusiasm from hobbyists
[20:19] <sarnold> i386 feels like it only exists at this point to cause guitarpro6 users insane amounts of trouble with their sudo packages
[20:19] <mardy> Mirv: like, do you know if Debian or KUbuntu will package it?
[20:20] <Unit193> sarnold: My netbook doesn't do amd64 either though. :/
[20:22] <jbicha> mardy: part of Qt 5.9 is in Debian exp.
[20:23] <mardy> jbicha: mmm... good to know, thanks!
[20:23] <jbicha> mardy: I thought ubports was only working on vivid and xenial?
[20:23] <sarnold> Unit193: oh :(
[20:24] <infinity> jbicha, sarnold: We already don't provide any non-d-i images for armhf, turning off d-i images would be trivial, but probably also pointless.
[20:24] <infinity> jbicha: Agree with dropping i386 ISOs, though.
[20:24] <sarnold> infinity: the usual debian/ubuntu problem of you only see the installer once and just upgrade for the next twenty years? :)
[20:25] <mardy> jbicha: correct, but we are discussing which qt version to use. If debian has already packages for qt 5.9, building them on a PPA for xenial will be easier (than do the whole packaging ourselves)
[20:26] <infinity> sarnold: Right, while dropping an installer image will remove some new users, I'd argue that i386/armhf really aren't seeing a mess of new users anyway (ubuntu-core and rpi2 might be a sticky "but" there), it's old users we need to eventually convince to throw away their hardware or reinstall lm-compatible hardware with amd64.
[20:26] <mardy> jbicha: looks like qtbase and qtdeclarative are there at least! That's plenty to work with :-)
[20:26] <jbicha> mardy: are you saying that ubports does not use the Ubuntu archive version of Qt?
[20:27] <sarnold> infinity: I swear I'm going to upgrade my pandaboard to trusty one of these days. honest.
[20:28] <infinity> sarnold: Pandaboards are pretty aerodynamic.
[20:28] <infinity> sarnold: Just sayin'.
[20:28] <mardy> jbicha: it does for now, but xenial has Qt 5.5, which is rather old
[20:28] <sarnold> infinity: hehehe
[20:28] <mardy> jbicha: in case you are interested: https://forums.ubports.com/topic/273/june-1-2017-app-developer-os-developer-meeting/6
[20:29] <infinity> sarnold: I have a whole graveyard of ARM dev boards here that I have no idea what to do with.
[20:30] <jbicha> mardy: I believe mitya57 would definitely appreciate some help in getting Qt 5.9 into Ubuntu, updating qt-creator, etc.
[20:35] <jbicha> mardy: I don't want to speak for Mirv but maybe he's not currently working on Qt in Ubuntu?
[20:36] <mardy> jbicha: I'm afraid you are right; I just thought that he might know better. But I'm happy to bother mitya57 as well ;-)
[21:24] <cjwatson> infinity: or sidegrade, for the smart/adventurous/mad ones
[21:25] <cjwatson> i386> I'll still campaign for keeping it in the archive, for the usual reason William and I quote (i.e. containers running a half-million lines of Python take noticeably less memory that way)
[21:31] <sarnold> do they still run a useful load with only ~2.5 gigs address space per process?
[21:32] <cjwatson> they run the LP test suite just fine
[21:32] <sarnold> aha :)
[23:05] <Unit193> mwhudson: Right, so Debian 863998 was just filed (Linking to https://github.com/golang/go/issues/13191), which looks like Debian 849662 but yet I believe it still doesn't compile on arm?