[00:46] -queuebot:#ubuntu-release- Unapproved: iproute2 (xenial-proposed/main) [4.3.0-1ubuntu3 => 4.3.0-1ubuntu3.16.04.1] (core)
[00:49] -queuebot:#ubuntu-release- Unapproved: iproute2 (yakkety-proposed/main) [4.3.0-1ubuntu3 => 4.3.0-1ubuntu3.16.10.1] (core)
[01:37] <superm1> AA's: fwupdate and fwupdate-signed don't seem to be migrating from proposed, i think some manual prodding might be needed.
[01:42] <infinity> superm1: That would be because they're not built.
[01:43] <infinity> Well, in upapproved.
[01:43]  * infinity goes to fix that.
[01:44] -queuebot:#ubuntu-release- Unapproved: accepted fwupdate [amd64] (zesty-proposed) [9-1]
[01:44] -queuebot:#ubuntu-release- Unapproved: accepted fwupdate [armhf] (zesty-proposed) [9-1]
[01:44] -queuebot:#ubuntu-release- Unapproved: accepted fwupdate [arm64] (zesty-proposed) [9-1]
[01:44] -queuebot:#ubuntu-release- Unapproved: accepted fwupdate [i386] (zesty-proposed) [9-1]
[02:53] -queuebot:#ubuntu-release- Unapproved: snapd (trusty-updates/universe) [2.23.1~14.04 => 2.22.6~14.04] (no packageset) (sync)
[02:53] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-updates/main) [2.23.1 => 2.22.6] (desktop-core, ubuntu-server) (sync)
[02:54] -queuebot:#ubuntu-release- Unapproved: snapd (yakkety-updates/main) [2.23.1+16.10 => 2.22.6+16.10] (desktop-core, ubuntu-server) (sync)
[02:55] -queuebot:#ubuntu-release- Unapproved: accepted snapd [sync] (trusty-updates) [2.22.6~14.04]
[02:55] -queuebot:#ubuntu-release- Unapproved: accepted snapd [sync] (xenial-updates) [2.22.6]
[02:55] -queuebot:#ubuntu-release- Unapproved: accepted snapd [sync] (yakkety-updates) [2.22.6+16.10]
=== RAOF1 is now known as RAOF
[07:34] <handsome_feng> Good Morning! Everyone! Could anyone help to approve the UKUI packages? Thank you! bug: #1663477
[07:34] <ubot5> bug 1663477 in Ubuntu "[FFe] UKUI desktop environment" [Wishlist,In progress] https://launchpad.net/bugs/1663477
[08:51] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (xenial-proposed) [1.0+16.04ubuntu1]
[08:52] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (yakkety-proposed) [1.0+16.10ubuntu1]
[09:32]  * smb wonders whether he can find a daring sru team member for approving Xen fun into T/X/Y
[09:40] <acheronuk> apw: would you be able to look at bug #1673394
[09:40] <ubot5> bug 1673394 in kde-l10n-engb (Ubuntu) "[FFe] upgrade KDE localisations/transations for KDE to 16.12" [Undecided,New] https://launchpad.net/bugs/1673394
[09:41] <acheronuk> really want those in for the beat for wider testing ^^^
[09:43] <acheronuk> *beta
[10:36] -queuebot:#ubuntu-release- Unapproved: accepted pepperflashplugin-nonfree [source] (yakkety-proposed) [1.8.2+nmu1ubuntu1.1]
[10:38] -queuebot:#ubuntu-release- Unapproved: accepted pepperflashplugin-nonfree [source] (xenial-proposed) [1.8.2ubuntu1.1]
[10:41] -queuebot:#ubuntu-release- Unapproved: accepted pepperflashplugin-nonfree [source] (trusty-proposed) [1.3ubuntu1.1]
[10:47] <acheronuk> apw: also bug #1672672 thanks :)
[10:47] <ubot5> bug 1672672 in krita (Ubuntu) "[FFe] Krita 3.1.2.1 for zesty" [Undecided,Confirmed] https://launchpad.net/bugs/1672672
[11:19] <wgrant> I've just reverted 16 kernel metapackages across {trusty,xenial,yakkety}-{updates,security} to avoid apt removal carnage from the snapd SRU reversion (https://launchpad.net/bugs/1673247). It's all published and my test systems are healthy, but let me know if anything looks awry.
[11:19] <ubot5> Ubuntu bug 1673247 in snapd (Ubuntu) "package snapd 2.23.1 failed to install/upgrade: trying to overwrite '/etc/apparmor.d/usr.lib.snapd.snap-confine', which is also in package snap-confine 2.23.1" [Critical,Confirmed]
[11:49] <tsimonq2> AAs (cc infinity, slangasek): What is your stance regarding allowing packages with the Cat Supremacy License into the archive?
[11:53] <tsimonq2> Debian says no, because "cats aren't superior" ^_^
[11:57] <apw> wgrant: thanks for handling that for me ... appreciated
[11:57] <acheronuk> tsimonq2: braillegraph 0.1?
[11:58] <wgrant> apw: np
[12:06] <cjwatson> "Cat Supremacy License"  no relevant hits on ddg that I can see
[12:09] <acheronuk> after a little searching.... https://github.com/kilobyte/braillegraph/commit/a535c2d818bb8b60a80c53e527861c779611350b
[12:10] <acheronuk> I guess that is what debian failed to agree with ;)
[12:11] <cjwatson> the addition of the second para means that it's effectively just a simple permissive licence and should be fine, though I'd like to deprecate silly novelty licences in general
[12:13] <tsimonq2> cjwatson: They rejected it on the basis that they can't print it if they don't love cats :P
[12:13] <cjwatson> that's a clear misreading
[12:13] <tsimonq2> acheronuk: You are correct
[12:14] <cjwatson> given that the second para says they have the same rights "albeit grudgingly"
[12:14] <cjwatson> anyway, stupid licence, just use the next version along with a more standard one
[12:15] <tsimonq2> http://www.mail-archive.com/debian-curiosa@lists.debian.org/msg05476.html
[12:15] <tsimonq2> cjwatson: I was thinking of using it, that's why I was asking :P
[12:15] <cjwatson> in fact I'm not totally sure why you care about this given that the licence change was committed before any release was tagged.
[12:15] <cjwatson> even 0.1 has the replaced licence shown in the commit above.
[12:16] <tsimonq2> It just caught my eye when reading LWN *shrug*
[12:16] <cjwatson> honestly this is time-wasting :P
[12:25] <tsimonq2> cjwatson: Thank you for your value input, and praise The Superior Species \,o/
[12:25] <tsimonq2> o/
[12:26] <cjwatson> I mean, sure, I like cats, I have two, but. :-)
[12:26] <cjwatson> (admittedly this is largely due to accident: one turned up and adopted us, then had kittens before we got round to neutering her)
[12:28] <tsimonq2> <3
[12:51] <jbicha> hi, could an AA allow steam to migrate to zesty? it intentionally introduces an arch:all that depends on an arch:i386
[12:53] <jbicha> because steam itself is i386 only so it was unavailable to install in gnome-software (on especialy amd64) without this new arch:all package
[14:15] <jbicha> pixfrogger is an example of another Debian/Ubuntu pkg that has this same arch:all to arch:i386 dependency
[14:21] <xnox> wine does that too
[14:21] <xnox> i think
[14:24] <jbicha> it looks like wine64 only recommends wine32 now
[16:02] <infinity> jbicha: We trick britney into doing that.
[16:06] <infinity> jbicha: Fixed.  Maybe.
[16:28] <jbicha> infinity: is that a permanent trick? or will that have to be manually done every time there's a new steam upload?
[16:32] <infinity> jbicha: It's permanent.
[16:45] <infinity> jbicha: Erm, oh.  But there's an added bit of broken here, you can't depend on "steam:i386", you just want to depend on "steam" and trust that'll grab the i386 package, since that's the only one that exists.
[16:45] <infinity> jbicha: With my fix to britney, changing that dep will also fix you.
[16:45] <jbicha> ok, I'll do that, thanks
[17:02] -queuebot:#ubuntu-release- New sync: qtubuntu-print (zesty-proposed/primary) [0.1+17.04.20170301.2-0ubuntu1]
[17:02] -queuebot:#ubuntu-release- New sync: ubuntu-printing-app (zesty-proposed/primary) [0.1+17.04.20170308-0ubuntu1]
[17:11] -queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (yakkety-proposed) [1.36.1-0ubuntu2.1]
[17:12] -queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (xenial-proposed) [1.34.0-0ubuntu8.3]
[17:14] -queuebot:#ubuntu-release- Unapproved: accepted pam-mysql [source] (xenial-proposed) [0.7~RC1-4ubuntu2.1]
[17:19] -queuebot:#ubuntu-release- Unapproved: accepted pam-mysql [source] (yakkety-proposed) [0.7~RC1-4.1ubuntu1.1]
[17:26] -queuebot:#ubuntu-release- Unapproved: accepted xen [source] (yakkety-proposed) [4.7.2-0ubuntu1]
[17:32] -queuebot:#ubuntu-release- Unapproved: accepted ltt-control [source] (yakkety-proposed) [2.8.1-1ubuntu1]
[17:42] <infinity> jbicha: FWIW, discussed it with guillem.  While a dep on "steam:i386" is valid from dpkg's POV, it's probably saner and more future-proof to have the unqualified dep anyway, as today it means the same thing (only i386 exists), and if tomorrow an amd64 build of steam shows up, it would DTRT and install that instead.
[17:42] <infinity> jbicha: So pushing that fix back to Debian would be correct, IMO.
[17:42] <infinity> (But we should probably also teach our tools to cope with the explicit dep for when someone comes up with a use-case where it makes sense)
[17:43] <jbicha> maybe we'll see steam:amd64 around the same time as halflife3
[17:43] <infinity> Heh.
[17:43] <infinity> I imagine we'll see it around the same time as major distros decide to drop 32-bit support.
[17:43] <infinity> Which I'd like to do in Ubuntu post-18.04, personally.
[17:44] <wxl> :(
[17:44] <infinity> 18.04 will be supported until 2023, if people are still using i386 CPUs after 2023, my sympathy for them isn't high.
[17:45] <infinity> The harder argument will be armhf, because I'd like to drop *all* 32-bit support, not just x86.
[17:45] <wxl> it's hard to say how far people will take lubuntu's aim of targetting old hardware
[17:45] <infinity> But maybe the world will be sufficiently arm64 by then (at least, for platforms we care about).
[17:46] <wxl> i guess we'll just have to see what happens
[17:46] <infinity> wxl: Hey, I still run a machine from 1997 here (PowerMac G3), but we just dropped support for that (powerpc), and I'll live, somehow.
[17:47] <infinity> wxl: Eventually, the cost of maintenance and electricity doesn't outweigh the percieved savings, IMO.
[17:47] <wxl> eventually
[17:47] <infinity> The only reason this one wasn't a huge burden on my electric bill was because I managed to replace the original CPU with a low power mobile part.
[17:48] <wxl> but if, in the sense of a school system, the electricity is perhaps a given regardless of how it fluctuates (i'm not sure about this), then reusing old hardware might still be a good budget saving venture
[17:48] <wxl> i think that's the main audience i'm concerned about rather than the casual user
[17:48] <wxl> and if we're going with the flow of the rest of the linux world, then oh well
[17:48] <infinity> wxl: But, realistically, x86 CPUs have been defaulting to amd64 for more than a decade (and almost two decades by 2023), so I don't think supporting 20 year old machines is a reasonable goal.
[17:48] <wxl> i just don't want to be the snowflake
[17:49] <infinity> But I won't be making the decision alone here, either.  I'm sure lots of people will object.  We need to sort out if the objections are based on statistical fact or passion, and go from there.
[17:49] <wxl> yeah
[17:49] <wxl> might be wise to collect the age of the machines of our users
[17:49] <infinity> The biggest potential issue, IMO, isn't "old hardware", but 3rd party software.
[17:50] <wxl> right
[17:50] <infinity> But much like Flash didn't die until Apple refused to support it, we might just have to lead here and force the rebuilds.  We'll see.
[17:50] <wxl> i think that's the least likely issue
[17:50] <infinity> User metrics would also be handy.
[17:50] <wxl> since mostly what people are trying to do is simple tasks like browsing and such
[17:51] <infinity> bdmurray: Does errors.ubuntu.com collect enough data to determine what CPUs people are using?  So we can see how many i386 users *can* run amd64 but aren't?
[17:51] <wxl> that's a really good idea
[17:52] <wxl> we'd need flags from procinfo tho
[17:52] <infinity> We might collect cpuinfo.  I don't recall.
[17:52] <wxl> cpuinfo, sorry :)
[17:52] <infinity> Though, I think we went through a similar dance when trying to decide the impact of dropping non-pae support.
[17:53] <wxl> i don't think i was involved enough in those discussions to know how that was resolved
[17:53] <infinity> Oh, which is also a valid data point.  The number of machines that support PAE but not amd64 isn't actually huge.
[17:54] <infinity> As in, we dropped most i386 users with the PAE change already.  There's only a short gap of a few years' worth of hardware that supports PAE and not 64-bit.
[17:54] <wxl> right
[17:54] <wxl> admittedly we have instructions on dealing with that
[17:55] <wxl> so if we had a similar solution for i386
[17:55] <infinity> Do the instructions involve a custom kernel?
[17:55] <wxl> !pae
[17:55] <ubot5> Ubuntu provides only PAE-enabled kernels for 32-bit systems now. Some older CPUs may have issues with it. For more info and troubleshooting, see https://help.ubuntu.com/community/PAE
[17:55] <wxl> no apparently
[17:55] <infinity> So, that's not the hardware I mean. :P
[17:55] <infinity> Yes, some PentiumM and CeleronM machines *do* support PAE but misreport it.  Those are fixed by those workarounds.
[17:56] <infinity> Anything older, however, just plain doesn't support it.
[17:56] <wxl> ah
[17:56] <infinity> And won't boot.
[17:56] <infinity> (Well, except for the original Pentium Pro, but anyone running one of those is very much not a user we target)
[17:58] <wxl> admittedly we get very few people asking about it
[17:58] <infinity> Anyhow, it's a talk I imagine we'll have a few times leading up to 18.04, and I think all involved have already agreed that we'll keep 32-bit *for* 18.04, so it'll at least live until 2023.
[17:58] <wxl> it's pretty much become a bit of a non-issue
[17:58] <wxl> that seems logic
[17:58] <wxl> al
[17:59] <infinity> Dropping 32-bit will solve some goldfish issues with software getting so fat that 32-bit machines can't be self-hosting anymore without tricks, which sucks.
[17:59] <wxl> it would also be nice to know about those flags
[17:59] <wxl> i have a 64-capable machine running i386
[17:59] <infinity> (For instance, without some hackery, most webkit-based projects can't actually build *for* 32-bit *on* 32-bit)
[17:59] <wxl> i would hate that to show up as a datapoint suggesting keeping i386
[17:59] <wxl> (yes, i've been lazy about dealing with it)
[18:00] <infinity> Plus, there's the impending doom of the 2038 epoch that we'd entirely side-step by just not having any supported series on 32-bit by then.
[18:00] <infinity> 2038 used to seem very far in the future.  It really doesn't anymore.
[18:00] <wxl> it will also allow users to use chrome proper, which is not an uncommon request
[18:00] <wxl> good point
[18:01] <cjwatson> i386> I still like being able to run Launchpad tests in an i386 chroot, because it makes a fairly big difference to memory usage.
[18:01] <bdmurray> infinity: cpuinfo?
[18:01] <cjwatson> er s/chroot/container/ but whatever
[18:01] <infinity> cjwatson: If only x32 had been a thing from day 1. :/
[18:01] <cjwatson> Yeah, x32 would be nice if we actually did the port.
[18:01] <wxl> @bdmurray: /proc/cpuinfo
[18:02] <cjwatson> But we can't be the only ones for whom userspace memory usage still matters at least a bit.
[18:02] <infinity> cjwatson: So, I live in the same world as you, and I think, for instance, people running m.small AWS instances should all run i386 images.  Usage statistics, however, show that very few people think like you and I.
[18:03] <infinity> Where "very few" is a number approaching 0.
[18:03] <wxl> bdmurray: more specifically the flag "lm"
[18:03] <bdmurray> It looks like only the cheese package hook collect cpuinfo and that looks broken, so no not in errors.
[18:04] <infinity> bdmurray: Dang.  Maybe we should change that soonish, so we can collect some solid data over the next 6-12 months.
[18:04] <infinity> bdmurray: Knowing the host CPU is sometimes handy for debugging too, but very handy for this sort of data mining.
[18:04] <bdmurray> works for me
[18:05] <wxl> i guess an alternative solution for 3rd party stuff is using an old distro in a virtual machine
[18:05] <wxl> or a 32 bit chroot, as you guys were discussing
[18:06] <wxl> but that's probably not a realistic sustainable solution
[18:07] <infinity> No.  It needs to be supportable.
[18:08] <infinity> I might talk with RH toolchain guys about this too.
[18:08] <infinity> If RH can be talked into dropping 32-bit support along with us, 3rd parties will pretty much have no choice but to catch up, instead of just naming us the odd ones out.
[18:08] <wxl> rh?
[18:08] <wxl> oh
[18:09] <wxl> derp nevermind :)
[18:09] <bdmurray> infinity: I reported 1673557 re apport
[18:10] <infinity> I certainly wouldn't mind if the advice for RH/Ubuntu was "if you need to run old, broken crap, use a Fedora/Debian chroot", though in an ideal world, F/D would also drop 32-bit. :P
[18:10] <infinity> bdmurray: Huzzah.
[18:10] <wxl> infinity: i thought at least Debian has been discussing this as well? or maybe i'm just hoping.
[18:10] <infinity> It comes up from time to time, yes.
[18:11] <infinity> I expect we'll lead on it, though.
[18:11]  * wxl sighs
[18:11] <infinity> If they drop support before us, it'll be a no-brainer for us, IMO.  We don't want to be responsible for all the potential issues.
[18:12] <wxl> right. in an ideal world, that would be the sequence of events
[18:12] <wxl> as with systemd
[18:12] <wxl> and ppc
[18:13] <infinity> systemd was a unique snowflake there, to be fair.  Because we'd already "led" with upstart.
[18:13] <infinity> Had we not done that, we'd have moved to systemd while Debian was still discussing it.
[18:13] <bdmurray> infinity: is there someway to shorten cpuinfo?
[18:14] <infinity> bdmurray: In what sense?  To inline it?  I think we'd rather have it as a block, like we do with /proc/environ
[18:14] <acheronuk> infinity: is there any chance you would have time to look at: bug #1673394 ?
[18:14] <ubot5> bug 1673394 in kde-l10n-engb (Ubuntu) "[FFe] upgrade KDE localisations/translations for KDE to 16.12" [Undecided,Confirmed] https://launchpad.net/bugs/1673394
[18:15] <bdmurray> infinity: at least on my cpu a lot of it seems redundant. all the processors are the same.
[18:15] <infinity> acheronuk: If, as the bug title implies, it's just translations and docstrings, that freeze isn't until the 30th, and you need no exception.
[18:15] <infinity> bdmurray: Oh, I see what you mean.
[18:16] <acheronuk> infinity: ah. I thought that was just for ubuntu derived packages reading the wiki. thanks for the clarification :)
[18:17] -queuebot:#ubuntu-release- Unapproved: accepted xen [source] (xenial-proposed) [4.6.5-0ubuntu1]
[18:17] <infinity> bdmurray: One could perhaps employ some shell sort hackery to collapse all the same lines down.  On most systems, I'm not sure it matters, but I suppose on a 160-thread machine, it starts getting ugly.
[18:18] <wxl> you could use awk for sure
[18:18] <bdmurray> wxl: well if you are feeling clever feel free to add it to the bug.
[18:19] -queuebot:#ubuntu-release- Unapproved: accepted ltt-control [source] (xenial-proposed) [2.7.1-2ubuntu1]
[18:20] <wxl> or you could grep for the number of lines, too
[18:20] <wxl> they should be static, no?
[18:21] <wxl> er head
[18:21] -queuebot:#ubuntu-release- Unapproved: accepted supervisor [source] (xenial-proposed) [3.2.0-2ubuntu0.1]
[18:22] <infinity> bdmurray: lscpu might be more pleasant for this.  Need to confirm it DTRT on all platforms.
[18:22] <cyphermox> bdmurray: lscpu
[18:22] <wxl> head -n 26 does the trick here
[18:23] <wxl> no flags, tho
[18:23] <infinity> wxl: Cutting won't cut it, every CPU reports different numbers of lines (drastically so on other platforms).
[18:23] <wxl> although i guess op mode should give you what's needed
[18:24] <wxl> @infinity: really? given the fact there are null rows, i'm surprised
[18:24] <infinity> lscpu is a bit underwhelming on ppc.
[18:24] <infinity> wxl: It's not a machine-readable format, it changes a lot from machine to machine.
[18:24] <wxl> bah
[18:24] <cyphermox> infinity: aside from say, "CPU(s):                160"
[18:25] <infinity> cyphermox: Missing clock, which is irksome.  But not the end of the world.
[18:25] <infinity> cyphermox: Oh, also missing a proper model.
[18:25] <cyphermox> yeah, I noticed that
[18:25] -queuebot:#ubuntu-release- Unapproved: accepted thermald [source] (xenial-proposed) [1.5-2ubuntu3]
[18:25] <cyphermox> clock is there, but not very helpful
[18:25] <infinity> cyphermox: http://paste.ubuntu.com/24190287/
[18:26] <infinity> cyphermox: Though, that's trusty, maybe the machine you're using is less crap?
[18:26] <cyphermox> we're not looking at the same system
[18:26] <infinity> No, indeed we're not. :P
[18:27] <cyphermox> http://paste.ubuntu.com/24190297/
[18:27] <infinity> But my two complaints on the one I'm looking are are lack of clock (meh), and Model reporting machine model, but no CPU model.
[18:27] <cyphermox> still missing model
[18:27] <cyphermox> yep
[18:27] <infinity> Ahh, no.  That has the info I'd want.
[18:27] <infinity> Model name:            POWER8E (raw), altivec supported
[18:27] <cyphermox> ah
[18:27] <infinity> Is that xenial or zesty?
[18:27] <cyphermox> I thought you wanted things like PowerNV
[18:27] <wxl> sed -n '/./,/^$/{/^$/q; p}' will give you what's above the blank line
[18:28] <wxl> i.e. tne 0th processor
[18:28] <cyphermox> xenial
[18:28] <wxl> ^^ on cpuinfo
[18:28] <infinity> cyphermox: That does tell me it's PowerNV, if you read between the lines.
[18:28] <cyphermox> infinity: I don't have your intimate knowledge of Power.
[18:28] <infinity> cyphermox: "Model: 2.0 (pvr 004b 0200)"
[18:28] <infinity> cyphermox: If it was a qemu machine, it would say "IBM pSeries (emulated by qemu)"
[18:29] <cyphermox> oh, I suppose you're right
[18:29] <infinity> wxl: Trust me, not helpful, every platform is different.
[18:29] <cyphermox> well, I know ;D
[18:29] <infinity> bdmurray: lscpu is the answer here.
[18:29] <wxl> infinity: all it does is look for ANY character up until a newline. you mean to tell me some of them don't separate by newlines?
[18:29] <infinity> wxl: Not in the same ways.  *and* I want the stuff after the newline.
[18:30] <wxl> oh well then have fun XD
[18:30] <bdmurray> infinity: cool, nothing collects that either yet. :-(
[18:30] <cyphermox> ah, is that for apport?
[18:30] <infinity> cyphermox: Yeah.
[18:30] <cyphermox> wee
[18:31] <infinity> lscpu on aarch64 is awful too.  No flags.
[18:32] <infinity> I hate software.
[18:32] <infinity> cpuinfo really would be better, but collapsing it on large machines would be nice.
[18:34] <cyphermox> cpuinfo is already grabbed by apport sometimes
[18:34] <infinity> Only by some hooks, apparently.
[18:34] <infinity> Or so Brian says.
[18:34] -queuebot:#ubuntu-release- Unapproved: accepted xen [source] (trusty-proposed) [4.4.2-0ubuntu0.14.04.10]
[18:35] <cyphermox> yeah, well, those where we thought it mattered, so d-i and linux for sure.
[18:35] <infinity> So, while format of cpuinfo isn't guaranteed, the platforms *we* care about seem to at least have paragraphs starting with "processor", and then sometimes a trailing one that doesn't.
[18:35] <cyphermox> does it matter everywhere now?
[18:35] <bdmurray> cyphermox: I didn't see any indication they collect that.
[18:35] <infinity> So we could take the first of the former, append the latter, and call it good.
[18:36] <cyphermox> bdmurray: data/package-hooks/source_linux.py:    apport.hookutils.attach_hardware(report)
[18:36] <cyphermox> I might not be looking at the right thing though
[18:36] <infinity> cyphermox: I want it everywhere for (a) some more useful debugging info and (b) installation metrics (ie: the above dicsussion about "how many people run i386 on amd64-capable CPUs")
[18:37] <cyphermox> infinity: that's not my call. If you think it should be everywhere, it becomes easy to fix for all apport hooks
[18:37] <infinity> Not everyone reports bugs on linux, but over the course a year, a very large subset of users will sumit *some* report to errors.u.c
[18:37] <cyphermox> right
[18:38] <cyphermox> I'll go back to my livefs now
[18:38] <bdmurray> oh, I missed the attach_hardware function. its alot more than just linux - cups, bluez, x stuff, d-i
[18:39] <infinity> bdmurray: I'm going back on my "use lscpu" comment. cpuinfo is indeed still better.
[18:40] <infinity> bdmurray: And it looks like we already do it for a lot of stuff, as pointed out.  So maybe we should just do it for everything.
[18:40] <infinity> bdmurray: And worry about collapsing it later. :P
[18:40] <cyphermox> infinity: wouldn't it be pretty simple to fix lscpu for aarch64?
[18:40] <cjwatson> base-installer has some per-arch cpuinfo scanning support IIRC
[18:40] <infinity> cyphermox: lscpu is kinda still crap for a lot of arches, IMO.  Only x86 shows flags, for instance.
[18:41] <cjwatson> maybe not on all arches though
[18:41] <infinity> But, more to the point, apport already does cpuinfo, so doing it *more* isn't a big change here.
[18:41] <cyphermox> infinity: sure, but what I mean is if x86 shows flags, the others could
[18:41] <bdmurray> infinity: I don't think its actually made into the error tracker because its greater than 1k - we'd need to whitelist it.
[18:41] <infinity> Making it better can be a secondary goal.
[18:41] <cjwatson> yeah, doesn't look like it ever needed to be especially complete, so ignore me
[18:42] <infinity> cyphermox: Not suggesting util-linux couldn't do with some patches to make lscpu less crap, just suggesting that's not a thing that matters to me today when cpuinfo has what I need.
[18:42] <cyphermox> yeah, I understand
[18:43] <infinity> I'm not sure lscpu's non-machine formats are really something people care about.
[18:43] <infinity> 'lscpu -e' is the useful switch (and not at all useful for what we're doing)
[18:44] <cyphermox> you're talking to someone who never uses lscpu
[18:44] <cyphermox> oh, I think I maybe did patch that to work correctly on ppc64el though
[18:45] <infinity> cyphermox: Heh.  Yeah.  I think the default of "vomit unformatted crap" should never have existed, -e and -p are the useful modes.
[18:46] <infinity> e for humans, p for computers.
[18:46] <infinity> bdmurray: So, whitelisting it would be nice.  Should I work on collapsing N cores down to 1 before you allow that?
[18:47] <bdmurray> infinity: collapsing it might make less than 1k right?
[18:47] <bdmurray> if that happened we wouldn't need to change whoopsie
[18:47] <bdmurray> otherwise its a whoopsie and apport change
[18:47] <infinity> bdmurray: In many/most cases.  In some x86 cases, it might still be larger (the flags line can get pretty huge).
[18:48] <infinity> bdmurray: In fact, yes.  Isolating one CPU core here is 1063 bytes.  So, just over. :P
[18:49] <infinity> Thanks, Intel.
[18:49] <bdmurray> I don't know how we are doing on db storage but it'd be best if we collapsed it.
[18:49] <infinity> bdmurray: Right.  I'll brush off my awk.  It should be a short 1-liner, I just need to remember how to live in 1979.
[19:03] <bdmurray> Is there anybody actually reviewing stuff in the queue for -backports?
[19:07] <bdmurray> caribou: bug 1342580 is missing Impact and Regression Potential, I see a test case in your reproducer comment.
[19:07] <ubot5> bug 1342580 in tftp-hpa (Ubuntu Yakkety) "tftpd-hpa doesn't start on boot" [Medium,Confirmed] https://launchpad.net/bugs/1342580
[19:10] <bdmurray> slangasek: When did the armhf autopkgtest infrastructure change? http://autopkgtest.ubuntu.com/packages/p/pbuilder/xenial/armhf
[19:11] <slangasek> bdmurray: I think it was sometime last summer
[19:11] <slangasek> bdmurray: so May-October 2016 would certainly cover the range
[19:13] <bdmurray> great
[19:13] <infinity> That error, on the other hand, seems pretty suspect.
[19:15] <infinity> Especially given that s390x and armhf should, in theory, be similar setups.
[19:16] <infinity> slangasek: Did pitti leave us with docs on how to get into those machines, or is this a "Laney and one or two other know and have access" thing?
[19:16] <infinity> s/other/others/
[19:17] <slangasek> infinity: there are docs of a sort; last time I tried to connect to them I was apparently going one proxy too deep
[19:17] <infinity> My proxy depth is just right.
[19:17] <infinity> At least, that's what Goldilocks told me.
[19:18] <slangasek> mknod in a container, I'm surprised that works in s390x either?
[19:18] <infinity> Well, that's my point.  It should either not work on s390x or it should work on armhf.  The disparity smells funny.
[19:19] <infinity> xor, for the pedantic.
[19:21] <infinity> (Weird side note: does anyone read a natural language 'or' as a logical 'or', or do we all read it as a logical 'xor'?)
[19:21] <infinity> I tend to lean to the latter.
[19:21] <infinity> In fact, I did so in my question. :P
[19:22] <slangasek> you're right; this is inconsistent.  We should rename 'or' to 'bor' for 'boolean or', and 'xor' can be 'or'
[19:24] <infinity> slangasek: Maybe we need an Si OiR.
[19:25] <infinity> It's fun to say out loud.
[19:27] <infinity> I think it's time to go install a shawarma in my face.
[19:31] <jgrimm> howdy, can a release team member take a look at this FFe for ack or nack: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1668940
[19:31] <ubot5> Ubuntu bug 1668940 in samba (Ubuntu) "[FFe] samba-vfs-modules misses ceph vfs module" [Medium,New]
[19:32] <jgrimm> nacc, ^^ fyi
[19:50] <infinity> jgrimm: Commented.
[19:53] <infinity> jgrimm: The comment probably should have been split into "with a release team hat on" and "with an SRU team hat on", but I suspect readers can sort that out. :P
[19:53] <acheronuk> infinity: could you maybe also have a look at https://bugs.launchpad.net/ubuntu/+source/krita/+bug/1672672
[19:53] <ubot5> Ubuntu bug 1672672 in krita (Ubuntu) "[FFe] Krita 3.1.2.1 for zesty" [Undecided,Confirmed]
[19:57] <infinity> acheronuk: The only major feature change there (other than some knew knobs, and better mouse handling) seems to be removing PDF export support.  Which kinda sucks, but if upstream won't support it, I don't think we should either, so +1.
[19:58] <acheronuk> infinity: thank you :)
[20:00] <jgrimm> thanks infinity +1 to your recommendation
[20:03] <infinity> "knew knobs"?  What were my fingers smoking?
[20:03] <jgrimm> infinity, can you change 1668940 to 'triaged' to seal your ACK?
[20:03] <infinity> Okay, really shawarma time.  Maybe I'll learn how to spell "new" when I'm out.
[20:04] <infinity> jgrimm: That's not generally part of my FFe workflow, but if it matters to you, go nuts and change it. :P
[20:04] <jgrimm> cool, just following the wiki. :)
[20:04] <infinity> Oh, we document these things?  Fancy.
[20:05] <infinity> You'll note that my "workflow" often consists of people pinging me on IRC and copy/pasting my response into the bug, cause I can't be bothered to respond twice. :P
[20:06] <jgrimm> heh, oh i'd noticed.. there is wiki process, and then how things really work. ;-P
[20:06]  * acheronuk was about to do just that ^^^^ :P
[20:06] <acheronuk> copy/paste infinity's response I mean
[20:07] <infinity> acheronuk: Complete with my creative spelling of "new", no doubt.
[20:07] <acheronuk> knobs included. sorry :P
[20:07] <acheronuk> *knew knobs
[20:08] <infinity> Future generations deserve to datamine my derp.  It's all good.
[20:45] <nacc> jgrimm: thanks
[20:46] <jgrimm> nacc.. as you'll see in backscroll,  you may want to ping here if you have other languishing FFes you'd like to nudge forward
[20:46] <nacc> jgrimm: yep
[23:48] <xnox> infinity, slangasek: armhf and s390x are different runners in adt; one is lxc1 the other one is lxd
[23:49] <xnox> one is less secure than the other. I believe s390x is the lax one.
[23:49] <tsimonq2> Ooh, Release Team, Final Beta coming up fast. Freeze on Monday!
[23:50] <tsimonq2> (or Tuesday, but you probably get the point in me saying that...)
[23:59] <slangasek> xnox: huh, why the laxity?