[00:07] <infinity> wgrant: Sounds reasonable, assuming "arbitrary" is a predictable precedence selection.
[00:07] <infinity> As much as I want random arch-indep builds, I'm not sure today is the day. ;)
[00:08] <wgrant> infinity: Well, I don't really have much to go on there.
[00:09] <wgrant> The Architecture field could be specified as negative wildcards, for example.
[00:09] <wgrant> Unless I use like DAS.id or something arbitrary but stable.
[00:10] <infinity> wgrant: Well, you know which builds you're going to create.
[00:10] <wgrant> infinity: Right, but what defines the order of the DASes?
[00:10] <infinity> wgrant: So, a precedence list of "if I'm not creating it, try the next instead" would work, with an order of amd64 > i386 > misc
[00:11] <infinity> Not sure the misc matters. :P
[00:11] <infinity> Just that i386 should be preferred over randomly picking the armhf build.
[00:11] <infinity> If for no other reason than CPU time.
[00:11] <wgrant> It's probably sufficiently rare that it doesn't really matter. I don't reallllly want to hardcode i386.
[00:12] <wgrant> Though I guess this is technically temporary, since Debian might eventually define the affinity field.
[00:12] <infinity> wgrant: This should be temporary.  But you could also just pull the arches in order from the DB, and try/pass until you hit a match.
[00:12] <infinity> wgrant: Since, I think, x86 comes first by PK ordering.
[00:12] <infinity> Though powerpc is right up there somewhere.
[00:13] <wgrant> Heh, no
[00:13] <wgrant> Oh, i386 is the first Processor.
[00:13] <wgrant> That might work
[00:13] <wgrant> But arm64 is the first DAS atm.
[00:19] <infinity> wgrant: Yeah, DAS creation is probably close to random, I meant the Processor table, which is static.
[00:19] <infinity> rsalveti: So, it sounds like, from the above, William will have a solution for you "i386 all" issue soon, and you can just ignore it. :P
[00:20] <infinity> rsalveti: A fresh upload to vivid after it's fixed will be needed to make it DTRT, but that's it.
[00:21] <wgrant> Yep
[00:21] <rsalveti> awesome :-)
[00:22]  * infinity needs to run out shopping, back soon.
[00:56] <skellat> Is there no backports suite for utopic?  Nothing is showing up for it on packages.ubuntu.com though rmadison says there is stuff there.
[01:02] <skellat> For example, rmadison pumpa and http://packages.ubuntu.com/pumpa show differing output
[02:19] <infinity> skellat: packages.u.c isn't authoritative, what rmadison is telling you is correct.
[03:19] <wgrant> rmadison also isn't authoritative :)
[03:19] <wgrant> Though usually correct.
[03:21] <skellat> What's the most authoritative answer then?
[03:22] <wgrant> skellat: https://launchpad.net/ubuntu/+source/pumpa
[03:23] <skellat> wgrant: Thank you
[04:45] <infinity> wgrant: I's argue that from a "what users see" perspective, rmadison is more authoritative than LP. :P
[04:45] <infinity> wgrant: Since LP is telling you what SHOULD be on disk, rmadison is telling you what IS.
[04:45] <infinity> (And we really hope the two match)
[04:46] <wgrant> Perhaps.
[04:46] <wgrant> Also rmadison is seriously slow.
[04:46] <wgrant> When LP is faster than something else, the something else has a serious problem :P
[04:46] <infinity> Yeah, I keep wondering if I have the round tuits to fix that.
[04:46] <infinity> There's no reason rmadison needs to be slow.
[04:46] <infinity> It just is.
[04:46] <wgrant> Indeed.
[04:47]  * skellat is just learning how to use the tools...the hard way...
[04:48] <infinity> The hard way is often the right way.
[05:15] <wgrant> Right, new arch-indep logic works, yay.
[05:16] <wgrant> Implementing an arch-indep affinity field should now be roughly two lines of code, too.
[05:23] <stgraber> infinity: dump a couple of ssds into snakefruit => problem solved?
[05:24] <stgraber> or spend a while trying to get index lookups to not be nearly as slow, but ssds for the indices seems easier :)
[05:26] <infinity> stgraber: apt-cache implies that index lookups don't have to be slow.  madison-lite could just use a bit more smart.
[05:28] <wgrant> infinity: https://code.launchpad.net/~wgrant/launchpad/bug-1350208/+merge/240808 if you care/understand
[05:32] <infinity> + # XXX wgrant 2014-11-06: The fact that production's
[05:32] <infinity> 156	+ # Processor 1 is i386, a good arch-indep candidate, is a
[05:32] <infinity> 157	+ # total coincidence and this isn't a hack. I promise.
[05:32] <infinity> Heh.
[09:23] <tjaalton> please drop xserver-xorg-video-intel 2:2.99.910-0ubuntu1.3 from the upload queue, I'll add one critical patch to it
[09:24] <tjaalton> unrelated to the ones on it now, but critical for broadwell
[10:05] <wgrant> Currently deploying the complete rewrite of the Soyuz build creation logic. If anything seems weird, it probably is, so let me know.
[15:43] <rbasak> bdmurray: if you're wearing your SRU team hat today, please can I poke you about reviewing juju-core in the Trusty queue? I'd like to get it pushed through soon if we can, so that upstream can QA on Ubuntu's proposed binary before they release upstream.
[15:46] <bdmurray> rbasak: I'll be putting that hat on in a bit after my morning meetings.
[15:46] <rbasak> OK, thanks!
[18:34] <balloons> stgraber, someone; can you make sure Upgrade Ubuntu Gnome amd64 and Upgrade Ubuntu Gnome i386 get added to the script for weekly upgrade builds?
[18:35] <stgraber> let me check what that script does exactly, I somehow doubt it contains an hardcoded list
[18:35] <balloons> hehe.. yea, probably just grabs the family
[18:35] <balloons> in which case it's all set
[18:36] <stgraber> so it iterates through the ones that are already on the daily milestone and bump them all
[18:36] <stgraber> so if you do the first entry by hand, it'll pick it up from there
[18:36] <balloons> yep, done.. ty stgraber
[19:05] <bdmurray> How do you add an extra space there? https://launchpadlibrarian.net/189391989/xserver-xorg-video-intel_2%3A2.99.910-0ubuntu1.2_2%3A2.99.910-0ubuntu1.3.diff.gz
[19:22] <tjaalton> bdmurray: is the newer upload of -intel for trusty still on the queue?
[19:24] <tjaalton> same version number..
[19:24] <bdmurray> tjaalton: yes, its still there
[19:24] <tjaalton> not for too long I hope ;)
[19:29] <bdmurray> cjwatson: Could you do the -proposed cleanup?
[20:27] <infinity> bdmurray: I've got that (proposed cleanup).
[20:37] <ogra_> i disabled system-image auto-importing for a bit to coordinate a device tarball landing with a silo
[20:57] <bdmurray> infinity: okay, thanks
[21:24] <bdmurray> tjaalton: the -intel upload has a reference to a patch not included in it
[21:24] <bdmurray> +  * Prevent crash when using SNA with fglrx.
[21:24] <bdmurray> +    - disable-outputs-when-slaved.patch
[21:27] <tjaalton> bdmurray: seems to me that it's there..
[21:28] <bdmurray> I don't see it in the series file
[21:29] <tjaalton> +disable-outputs-when-slaved.patch
[21:29] <ogra_> system-image auto-importer back on
[21:30] <tjaalton> bdmurray: there were quite a few patches added after that
[21:31] <bdmurray> tjaalton: I'm looking at this diff - https://launchpadlibrarian.net/189391989/xserver-xorg-video-intel_2%3A2.99.910-0ubuntu1.2_2%3A2.99.910-0ubuntu1.3.diff.gz
[21:32] <tjaalton> well boo then, it was added in 1.2
[21:33] <tjaalton> bad mlankhorst :)
[21:34] <tjaalton> or actually it's just the changelog entry that's confusing and duplicat
[21:34] <tjaalton> e
[21:36] <tjaalton> but I can fix that
[21:36] <tjaalton> and upload again
[21:36] <bdmurray> tjaalton: that'd be great, then I'll get it approved today
[21:39] <tjaalton> done
[21:41] <brainwash> please move thunar from utopic-proposed to -updates
[21:41] <brainwash> bug 1382977
[21:41] <ubot2> bug 1382977 in thunar (Ubuntu Utopic) "[SRU] Thunar open default not respecting mimetype" [Undecided,Fix committed] https://launchpad.net/bugs/1382977
[21:55] <bdmurray> brainwash: we wait for packages to live in -proposed for 7 days
[21:56] <brainwash> bdmurray: even if several people confirmed that the package has fixed the issue? ok then I guess
[21:58] <bdmurray> brainwash: 7 days is the policy https://wiki.ubuntu.com/StableReleaseUpdates/#Procedure
[21:59] <bdmurray> brainwash: we can waive that sometimes is the bug critical?
[22:01] <brainwash> bdmurray: no, it cannot be labeled as critical or even high. we are just trying to get the fix out asap, because it's the no.1 issue in xubuntu 14.10
[22:02] <brainwash> but the 7 days aging time makes sense, so we'll wait some more days
[22:03] <bdmurray> brainwash: feel free to ping an SRU team member on the 11th then (I'll be out that day)
[22:03] <brainwash> I will, thanks :)
[22:03] <infinity> Or just assume that we'll get to it.
[22:03] <infinity> If the bugs are all verified.
[22:53] <wgrant> infinity: Nothing seemed weird build-wise overnight?
[22:55] <infinity> wgrant: Should it have?  I was indisposed.
[22:57] <wgrant> infinity: Well, a lot of very crufty evolved code was rewritten, so it's not inconceivable that something might be broken.
[22:57] <wgrant> But everything looks fine, which is nice.
[22:58] <wgrant> Which means it should be safe to run add-missing-builds, but I might test it on dogfood first.
[22:58] <wgrant> Also rsalveti's android should build in vivid now.
[22:58] <rsalveti> great
[22:59] <infinity> rsalveti: That'll need a no-change upload to prompt it to create the build records in a sensible fashion.