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