[02:31] <lifeless> hmm, running out of yak shaving time
[02:31] <lifeless> Anyone care to land an approved branch for me ?
[02:38] <lifeless> StevenK: ping
[02:41] <poolie> i got a tcp timeout connecting to bugs.edge...
[02:42] <lifeless> !
[02:43] <poolie> just once
[02:43] <poolie> no other pages failed
[02:43] <poolie> bug 600000
[02:43] <_mup_> Bug #600000: missing dependency on Bazaar <hitchhiker (Ubuntu):Fix Released> <hitchhiker (Debian):New> <https://launchpad.net/bugs/600000>
[02:43] <poolie> big round numbers yay :)
[02:43] <lifeless> thats really weird as the front end is all load balanced etc
[02:43] <poolie> exactly
[02:53] <poolie> lifeless: i realize we can redirect but i wonder if we want to
[02:53] <poolie> probably
[03:07] <lifeless> http://www.paulhammond.org/2010/06/trunk/ <- relevant to lp
[03:07] <lifeless> (mailing the list now)
[04:44] <lifeless> StevenK: ping
[06:07] <StevenK> lifeless: pong
[06:22] <lifeless> StevenK: hi
[06:22] <lifeless> StevenK: I have two patches I would like to land
[06:22] <lifeless> but I'm not setup for ec2
[06:23] <lifeless> StevenK: I'm hioping you can help me
[06:25] <StevenK> lifeless: Okay, we can either setup ec2, or I can throw them at ec2
[06:26] <lifeless> please toss em :)
[06:26] <lifeless> https://code.edge.launchpad.net/~lifeless/launchpad/lsprof/+merge/28583 is one
[06:26] <lifeless> and https://code.edge.launchpad.net/~lifeless/launchpad/lognamer
[06:26] <lifeless> sorry
[06:27] <lifeless> https://code.edge.launchpad.net/~lifeless/launchpad/lognamer/+merge/28574
[06:27] <lifeless> the lognamer one should go first
[06:31] <StevenK> lifeless: You should also fix your e-mail address for bzr, it's 'robertc@lpdev'
[06:36] <lifeless> ugh
[06:36] <lifeless> danke
[06:37] <lifeless> I'll add that to the VM set info
[06:38] <lifeless> fixed for future work
[06:39] <lifeless> and fixed on the wiki
[07:23] <adeuring> good morning
[07:26] <StevenK> lifeless: I finally have your lognamer branch, can you set a commit message in the MP?
[07:29] <lifeless> done
[08:01] <lifeless> StevenK: thanks
[08:01] <lifeless> StevenK: I'll be online later.
[11:02] <deryck> Morning, all.
[12:44] <jml> writing about code makes me want to write code instead :(
[12:45] <lifeless> :)
[12:45] <lifeless> jml: I've had that intensely this week
[12:46] <lifeless> jml: though I've also closed off a bunch of bzrloom things, so not as badly as I expect you're going through
[12:46] <jml> heh.
[12:46] <jml> my top priority out-of-work hacking task is releasing Twisted
[12:46] <lifeless> \o/
[12:46] <jml> which doesn't involve coding
[12:47] <lifeless> does it have the fixed issue with subunit and fake errors ?
[12:47] <lifeless> you could release testtools if you want
[12:47] <lifeless> oh right, coding
[12:48] <jml> 10.1 has the subunit fix, yes.
[12:49] <lifeless> what would you like to write code on
[12:52] <jml> lots of LP stuff; twisted release automation; a couple of testtools fixes I have in mind; some tweaks for my graphing thing
[13:00] <lifeless> cool
[13:09] <lifeless> ngight all
[13:19] <bigjools> jml: don't know if you saw my message yesterday, at least I don't remember seeing a reply.  Are you going to be able to look at those buildd-manager changes?
[13:19] <jml> not soon, no.
[13:40] <mwhudson> bigjools: is this twisted-y stuff?
[13:40] <bigjools> mwhudson: very much so
[13:41] <mwhudson> bigjools: i might be able to have a look, although my brain is made of cotton wool today
[13:42] <bigjools> mwhudson: it's best if I take you through it, the buildd-manager is a, err, special piece of code
[13:43] <bigjools> but it'll have to wait until next week if that's ok?
[13:43] <mwhudson> bigjools: next week should be fine
[13:43] <mwhudson> and yes, i've looked at buildd-manager before
[13:43]  * mwhudson rubs the mental scar tissue
[13:44] <bigjools> I still have bits of fingernail in my eyes
[13:45] <bigjools> it was only after I started re-writing bits of code that I realised a lot of the crap in there is explicitly for tests
[13:48] <mwhudson> bigjools: what are you working on?  just generally improving the sanity level?
[13:49] <bigjools> mwhudson: when it was developed its design was influenced too much by the old scanner than did one massive scan over the whole farm.  I changed the behaviour so that I've got separate Deferred threads for each builder in the farm, so that when the scan fails it doesn't blow out the scan of the whole farm.
[13:50] <bigjools> and it's a lot faster generally with that approach as it can do more stuff in parallel
[13:50] <mwhudson> bigjools: sounds good
[13:50] <bigjools> however, this has completely broken the existing tests of course :)  I need advice on how to write some sane tests.
[13:50] <mwhudson> although 'developed' is perhaps an insufficiently perjorative term? :)
[13:51] <bigjools> you are indeed the master of understatement
[13:52] <bigjools> mwhudson: if you want to take an advanced look, the branch is here:   https://code.edge.launchpad.net/~julian-edwards/launchpad/buildd-manager-parallel-scan
[13:52] <bigjools> now, I need fud
[15:27] <jtv> danilos: you may still be too busy for this, but I made a few tweaks to the decision matrix we worked out for setCurrentTranslation.
[15:29] <danilos> jtv, it's wrong, totally wroooong!
[15:29] <jtv> uh-oh
[15:29] <danilos> jtv, I'll take a look
[15:30] <jtv> and _then_ tell me it's all wroooong.  :-)
[15:47] <danilos> jtv, btw, I should look at the wiki page or code?
[15:47] <jtv> danilos: wiki page would be easier I think, though the code should match it pretty closely
[17:33] <leonardr> salgado-lunch or flacoste_afk, i have a launchpad/web service problem that you might be able to help with when you return
[18:17] <salgado> hi leonardr
[18:17] <james_w> hmm, got an ec2 run that is failing every test
[18:17] <james_w> "Warning: 'with' will become a reserved keyword in Python 2.6"
[18:17] <james_w> and then failing with syntax error when it tries to use "with"
[18:17] <leonardr> salgado: this problem has to do with navigation
[18:17] <james_w> running with 2.4 python?
[18:18] <jml> james_w, is the test failing locally?
[18:18] <leonardr> i am publishing ~{user}/oauth_access_tokens as a collection of IOauthAccessToken objects
[18:18] <james_w> jml: no
[18:18] <james_w> jml: *every* test is failing in ec2
[18:18] <leonardr> the problem is that IOAuthAccessToken objects are not currently published on the website. so they have no canonical_url and there is no way to navigate to them
[18:18] <jml> james_w, oh.
[18:18] <leonardr> i hacked in a canonical_url but i can't figure out how to make navigation work
[18:19] <leonardr> is this something you can help with?
[18:19] <jml> james_w, I saw a patch for something similar sounding fly by today
[18:19] <james_w> jml: ah yeah, thanks, I'll try merging that
[18:21] <leonardr> salgado: once i get the navigation working there is another problem with permissions and oauth access levels but we'll deal with that later
[18:22] <salgado> leonardr, IIUC, what you want is a traversal so that you can get to the OAuth token?
[18:22] <leonardr> salgado: right
[18:22] <leonardr> i was trying to make /~leonardr/oauth_access_tokens/{key} work, but that wasn't working
[18:23] <leonardr> i looked at other deeply-nested objects like bug messages, and i didn't see any way of recreating their complex navigation code for something that was 1. part of the main application rather than malone, and 2. published only in the web service
[18:23] <salgado> leonardr, so, something similar to what we do for email addresses?
[18:24] <salgado>     @stepthrough('+email')
[18:24] <salgado>     def traverse_email(self, email):
[18:24] <salgado>         """Traverse to this person's emails on the webservice layer."""
[18:24] <salgado>         email = getUtility(IEmailAddressSet).getByEmail(email)
[18:24] <salgado>         if email is None or email.personID != self.context.id:
[18:24] <salgado>             return None
[18:24] <salgado>         return email
[18:24] <leonardr> that is promising! where's that code?
[18:24] <salgado> lib/lp/registry/browser/person.py
[18:24] <jml> leonardr, salgado: not necessary, but it would be nice to have a short howto / checklist put up somewhere as a result of this conversation.
[18:24] <leonardr> jml: yeah, i know it's come up before
[18:25] <salgado> indeed
[18:26] <jml> glad you agree :)
[18:27] <salgado> leonardr, note you'll have to use a different path segment than the one you use for the collection (e.g. +oauth-access-tokens)
[18:27] <leonardr> right
[18:27] <leonardr> should it be singular or plural? i see singulars here
[18:27] <salgado> singular
[18:28] <james_w> https://dev.launchpad.net/Web/URLTraversal
[18:29] <jml> oh look there's a thing :)
[18:29] <jml> james_w, thanks.
[18:29] <james_w> np
[18:31] <salgado> leonardr, you might want to give that wiki page a try and update it in case you find anything else
[18:36] <leonardr> salgado: "Traverse to this person's emails on the webservice layer." is that "webservice layer" part enforced at all?
[18:36] <salgado> leonardr, I don't think so
[18:37] <leonardr> ok
[18:37] <salgado> it's not indeed -- one can traverse to an email address on the web app
[18:38] <sinzui> oh sweet
[18:39] <sinzui> I can do the same searching /people/ by email address, but that is kind of secret and definitely slower than API
[19:05] <james_w> jml: may I move FileIsADirectory from lp.codehosting.sftp to lp.services.sshserver?
[19:05] <james_w> jml: or a better place?
[19:24] <leonardr> salgado: now that we've resolved that, i'd like your advice on implementing a new OAuth access level and the permissions that go with it
[19:24] <leonardr> http://pastebin.ubuntu.com/457940/
[19:25] <leonardr> i can create the access level itself easily enough (#1) but i'm not sure how the very specific permission control we need for it can work given our existing permission system
[19:36] <salgado> leonardr, I think you'll need to special case IOAuth* objects in LaunchpadSecurityPolicy.checkPermission() because the security adapters don't have access to the oauth token used to authenticate, so they can't see if the access level is GRANT_PERMISSIONS or not
[19:36] <salgado> leonardr, but you should talk to gary/flacoste before going forward with that, because it's a bit of a hack
[19:37] <leonardr> salgado: agreed. this design is one i came up with with gary, but i don't know if he knows about that implication
[19:37] <salgado> leonardr, another (even more hacky, although less intrusive) option would be to use get_current_browser_request() in your security adapter to have access to the oauth token
[19:38] <leonardr> salgado: security adapter for IOAuthAccessToken? can you point me to a similar example?
[19:38] <salgado> leonardr, lib/canonical/launchpad/security.py
[19:39] <salgado> leonardr, these are called by LaunchpadSecurityPolicy.checkPermission(), but they're only given the logged in user and the object to check permission on
[19:40] <leonardr> i think that might be a better solution
[19:54] <salgado> leonardr, btw, do you have a few minutes to help me with lazr.restful?
[19:54] <leonardr> salgado, sure
[19:56] <salgado> leonardr, AIUI, the way lazr.restful exports things is by annotating the interfaces and their methods/attributes and later scanning them to generate the wadl to describe the service. is that correct?
[19:56] <leonardr> salgado: yes
[19:58] <salgado> leonardr, and how does the web app maps the requests back to say, method calls, later?
[19:59] <leonardr> salgado: the scanning process actually generates a set of adapter classes (adapting the various data model classes to IEntry)
[19:59] <leonardr> those adapter classes are used to generate the wadl and also to turn http requests into operations on the data model objects
[19:59] <salgado> oh, right, I'd forgotten about the adapters
[20:02] <salgado> leonardr, cool, I think I know enough to move forward now.  I'm doing a proof of concept for exporting things that are not directly provided by a given class but can be provided through an adapter (like what james_w described in that Adapters & API thread
[21:58] <thumper> morning
[22:02] <lifeless> hiya


[03:33] <bigjools> jtv: may I avail myself of your reviewing powers please https://code.launchpad.net/~julian-edwards/maas/timer-commands/+merge/233296
[03:33] <jtv> *trumpet music blares briefly*
[03:34] <bigjools> is that like the reaping music in Hunger Games?
[03:47] <jtv> Can't discuss that here.  Probably illegal.
[03:47] <jtv> Anyway, your review is done.
[03:49] <bigjools> thanks
[05:09] <newell> Hola all
[08:11] <jtv> Controlling the power on our NUCs would be so much easier if amttool supported IPv6...
[08:26] <jtv> Bah.  Doesn't look as if wsman supports IPv6 either.  :(
[10:10] <rvba> allenap: it seems we've got many different ways to test methods that call the RPC stuff in the code base… I assume this is due to the fact that you're refined it recently… can you point me to the most up-to-example version?
[10:12] <allenap> rvba: It depends on what you want to do :) call_responder is best when you’re testing a single RPC method directly.
[10:13] <rvba> allenap: I want to test this: a RPC method should be called as a side-effect of changing a node's status.
[10:13] <allenap> rvba: Mock(Live)?(ClusterToRegion|RegionToCluster)Fixture are best when testing code that uses RPC. The Live variants are best when there isn’t an opportunity to pump IO in the test, by hand as it were.
[10:14] <rvba> allenap: okay, thanks; that's what I started using.  There are places in the code that use pure mocking instead of this.
[10:15] <allenap> rvba: Personally I would be tempted to write a helper in maasserver.clusterrpc somewhere, test that on its own, then use patch_autospec to test that *that* is called when changing a node’s status.
[10:16] <rvba> allenap: I don't understand… what would that helper do?
[10:22] <rvba> allenap: couldn't we get MockRegionToClusterRPCFixture to use patch_autospec under the hood to create "valid" mocks for all the registered methods?
[10:39] <allenap> rvba: We’re actually getting something similar because all calls are being validated against the RPC schema.
[10:39] <rvba> allenap: ah, okay.
[10:39] <rvba> allenap: still, it's not exactly the same thing as having mocks already setup.
[10:40] <allenap> rvba: The helper would be a thin wrapper around getting a client and making the remote call. It’s a conveniently small thing to test, but also provides a good point at which to mock.
[10:40] <allenap> rvba: What kind of mocks do you want? When running the pserv tests I don’t really want to bring up the database and Django.
[10:41] <rvba> allenap: well, just mock objects;  and then you can configure them if you want.  I don't see how that's related to Django at all but I must be missing something.
[10:48] <allenap> rvba: If you’re using addEventLoop (from the cluster) or addCluster (from the region) with the end-to-end fixtures, then you can specify which calls to mock, and it does provide stubs for you to customise. It’s hard to customise those to have some default behaviour when that behaviour is defined elsewhere (e.g. provisioningserver shouldn’t import
[10:48] <allenap> maasserver, and that’s where Django comes in) and might require a database with sample data. I also don’t think that would be a good way to write unit tests.
[10:49] <rvba> allenap: fair enough.
[14:18] <gQuigs> ~$ maas maas-mini-test maas get-config maas_name=unicode
[14:18] <gQuigs> No provided name!
[14:18]  * gQuigs doesn't understand how to query get-config
[14:19] <gQuigs> ideally, I'd like to be able to just get all the config back
[15:04] <rvba> allenap: I'm still not completely satisfied with the explanation you gave me on ~allenap/maas/rpc-start-nodes-extra… why were we excluding nodes with MACs?  If this is still a requirement, why aren't you changing all the call sites to eliminate the nodes with MACs before calling start_nodes.  And if you think start_nodes is the wrong place to do this, why did you do something very similar in stop_nodes?
[15:05] <rvba> allenap: sorry, lots of questions :)
[15:08] <allenap> rvba: I honestly don’t know why we were excluding nodes without MACs.
[15:09] <allenap> It seems bizarre to make that decision then. Worse yet to exclude them without warning, just silently drop them.
[15:10] <allenap> rvba: I’m not sure the call sites need changing… well, I don’t know. How do we get to a point where we have a node without a MAC address?
[15:11] <rvba> allenap: the only explanation I can see is that for some reason we know we can't power them up.  In which case it's logical to exclude them.
[15:11] <rvba> allenap: yeah, I know, that's why the whole thing is weird.
[15:11] <allenap> rvba: stop_nodes() doesn’t exclude nodes without MACs, only those where the power_info tuple has can_be_stopped=False.
[15:12] <rvba> allenap: right.
[15:12] <rvba> allenap: I'm temped to agree with you and get rid of it… but because I don't understand why we were doing this in the first place I'm a bit confused…
[15:12] <allenap> rvba: On one hand I want to remove it and see if anything happens.
[15:13] <rvba> gQuigs:  ~$ maas maas-mini-test maas get-config name=myconfig
[15:14] <gQuigs> rvba: oh, wow..  thanks!
[15:18] <rvba> allenap: I think we did this because get_primary_mac is used by get_effective_power_parameters
[15:19] <rvba> allenap: but there is support for when get_primary_mac return None
[15:19] <rvba> allenap: okay, let's get rid of it.
[15:21] <allenap> rvba: Cool.
[15:21] <allenap> rvba: Thanks, by the way. It’s good to have these kinds of discussions :)
[15:23] <rvba> allenap: heh, you're welcome :)
[15:34] <roaksoax> rvba: isn't the primary mac also for networking?
[15:35] <roaksoax> rvba: we only do mapping for primary mac
[15:35] <roaksoax> for DNS
[15:39] <rvba> roaksoax: no, we populate the DNS with what's in the staticIP table. And this is, in turn, uses the MAC on the managed interface.
[16:02] <roaksoax> rvba: ok


[18:38] <scottbomb> Question for anyone here. I am testing the Xubuntu 13.04 ISO. I tested 2 random languages, Armenian and Bangla. I logged out and back in with each and nothing is translated. Does this mean that no one has done the translation or should I file a bug? If it's a bug, against what package do I file it?
[18:58] <scottbomb> Nevermind


[00:17] <ScottK> It would be lovely if someone could review/accept the taglib update.   That's needed to fix one of the KDE build failures we had.
[00:22] <stgraber> ScottK: looking
[00:22] <ScottK> Thanks.
[00:23] <stgraber> well, once LP gives me a diff :)
[00:23] <ScottK> http://paste.ubuntu.com/1257087/
[00:24] <stgraber> I guess that wasn't a case where you could get away with a generic usr/include/taglib/*.h?
[00:26] <stgraber> anyway, accepted
[00:45] <jbicha> ^ I guess that needs at least a verbal FFe since it adds a new (renamed) package but there aren't any rdepends
[00:47] <jbicha> it won't build anyway until webkit makes it to quantal
[00:47] <balloons> can anyone tell me if I'm doing something wrong -- I'm trying to launch ubiquity from my quantal box, but it only wants to run the kubuntu installer
[00:48] <ScottK> stgraber: Thanks.
[00:48] <balloons> ubiquity gtk_ui crashes, with no frontend available
[00:51] <balloons> ahh.. I solved it, but it's odd you get the kde version by default
[00:51] <balloons> why isn't ubiquity-frontend-gtk installed by default?
[01:37] <micahg> debfx: Laney: qtwebkit isn't supposed to be built from the qt4-x11 source since maverick, but from qtwebkit-source
[02:25] <ScottK> would someone please rescore taglib.  There's stuff in proposed that needs it to build.
[02:27] <stgraber> ScottK: rescored
[02:28] <ScottK> stgraber: Thanks.
[04:47] <NCommander> jbicha, ping
[04:47] <NCommander> I don't see a bug/reason for the telepathy-farstream sync.
[04:48] <jbicha> NCommander: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686564
[04:48] <ubot2> Debian bug 686564 in libtelepathy-farstream2 "Breaks theora video calling" [Grave,Fixed]
[04:49] <NCommander> jbicha, thanks,accepted
[04:50] <NCommander> (Its an annoying PITA to look at sync changelogs since Launchpad doesn't give me a handy link like it does with uploads)
[07:18] <cjwatson> balloons: it'll be random.  I see no need to explicitly prefer any particular frontend since we always select a particular one during live fs building
[07:19] <cjwatson> balloons: and really, REALLY don't run ubiquity on your regular system.  it is not even slightly a good idea ...
[07:20] <cjwatson> (it will at the very least feel free to make configuration changes to the running system and is not at all guaranteed to put things back the way they were later)
[08:43] <cjwatson> Laney: ignore the mail about my mistaken copy of make-dfsg to quantal-updates rather than quantal - I deleted that again
[08:46] <debfx> micahg: it's a bit more complicated than that
[08:47] <Laney> cjwatson: righto. You got in before I saw it
[09:24] <cjwatson> Riddell: ^- no Replaces: field?
[09:25] <Riddell> cjwatson: is that needed in -proposed?
[09:25] <Riddell> surely -proposed is for people who do testing?
[09:27] <cjwatson> There's no harm in adding Replaces, and it may help
[09:27] <cjwatson> So why not?
[09:27] <Riddell> ok dokay
[09:28] <cjwatson> If it gets rid of even a handful of confused bug reports it's worth it
[11:00] <cjwatson> Could somebody review ubiquity in unapproved, please?
[11:52] <cjwatson> In fact if somebody other than me could do any queue review that would be pretty nice. :-)
[11:52] <smartboyhw> :P
[11:54] <Laney> I'll do some in a bit.
[11:54] <Laney> post lunch
[11:54] <cjwatson> Thanks
[11:55] <Laney> 283 results :(
[11:55] <Laney> oh, langpacks
[11:55] <cjwatson> Huh
[11:55] <cjwatson> I can deal with those ...
[12:05] <cjwatson> Flushed.
[12:06] <Laney> how do you deal with those? do you just accept them?
[12:06] <cjwatson> Yeah
[12:06] <cjwatson> Well I spot-checked one that it looked vaguely reasonable
[12:06] <cjwatson> But I'm not going to review them all :-)
[12:06]  * xnox ponders why is it source package per lang, instead of singe source package with binary package per lang.
[12:07] <cjwatson> They don't *always* get uploaded in a giant block
[12:07] <xnox> ok then
[12:08] <cjwatson> Just often
[12:08] <cjwatson> I expect I have some status quo bias; I think I'm happier with fewer ginormous source packages though
[12:15] <xnox> some of them are very small like 9kB src & 3kB binary....
[12:16] <xnox> gnome and kde-base are big.
[12:16]  * xnox meh...
[12:16] <cjwatson> the non-base ones alternate between tiny and huge
[12:29] <tumbleweed> meep, I should also do a queue pass. I haven't been doing much recently
[12:29]  * smartboyhw wonders why everyone suddenly caught up with queue passing today:P
[12:30] <tumbleweed> urgh, I need to catch up on FFe bugs first
[12:31] <Daviey> I don't think they are overwhelming tumbleweed
[12:31] <tumbleweed> no, but tehy're in a busy inbox
[12:31] <Daviey> tumbleweed: yeah, inbox traffic has indeed been high
[12:33] <seb128> Daviey, thanks for geary!
[12:34] <Daviey> seb128: np
[13:20] <hallyn> hi - IIRC when I asked beofre, for bug 1056381, it was said an FFE for spice isn't needed since it's needed for a qxl bugfix?
[13:20] <ubot2> Launchpad bug 1056381 in xserver-xorg-video-qxl "[FFe: spice] error on x startup" [High,Confirmed] https://launchpad.net/bugs/1056381
[13:20] <hallyn> but, better safe than sorry :)
[13:24] <stgraber> hallyn: can we get a changelog for all those packages? that'd make it easier to figure out whether there are any feature changes that'd indeed require an FFe
[13:26] <hallyn> stgraber: quoted into the bug you mean?
[13:27] <stgraber> hallyn: yes, please
[13:28] <hallyn> ok
[13:40] <stgraber> rejected wakeup as it's a feature change without a FFe or even a bug (re-adding evolution plugin)
[14:01] <hallyn> stgraber: (posted to the bug)
[14:02] <stgraber> hallyn: yep and I added the upstream changelogs for each now
[14:02] <balloons> cjwatson, ahh, so no running of ubiquity to install to another target eh? Guess I can close my own bug found then :-)
[14:04] <xnox> balloons: already won't fixed it. =) ubiquity more-or-less copies the whole system it's booted of (the live-cd) + does cleanup. And since installed systems != livecd special built the results are unexpected =)
[14:32] <cjwatson> balloons: Yeah, that's explicitly unsupported
[15:18] <plars> popey: so should I use ppa:unity-team/ppa then? I looked at unity-team/release and it doesn't appear to be set to build for arm at all
[15:18] <popey> yes plars
[15:18] <plars> popey: ok, I had the wrong one yesterday it seems, it looks like arm still isn't build though so I'll check back later today
[15:19] <popey> thanks plars
[17:04]  * iulian wonders why spice is sitting in the queue if its FFe hasn't been approved yet.
[17:04] <iulian> stgraber: Are you looking at spice?
[17:07] <stgraber> iulian: I can review it later today but I wouldn't mind another review of the FFe by someone who knows a bit more about spice. I'm just the original reporter of the bug as I tried using spice a couple of weeks ago and noticed that X wouldn't start in my VM.
[17:08] <iulian> stgraber: I have no experience with spice at all and thus I shall leave it to someone else.
[17:15] <infinity> stgraber: It sounds like you have as much experience as anyone, given that you've, I dunno, used it. :P
[17:16] <stgraber> hmm, then I'll give it another look and if I don't spot anything that looks scary I'll accept the FFe. Current state is that X doesn't start, so can't get much worse than that I guess
[19:05] <plars> popey: hey, it finally built, and seems to work here :)
[19:05] <popey> woooooot
[19:06] <popey> plars, so can you open music with a right click and then play preview from the store?
[19:06]  * popey crosses fingers
[19:07] <plars> popey: right click, yes - from the main results this time too (not just music)
[19:07] <popey> excellent, thanks plars, much appreciated, could you please leave a comment on bug 1055684 ?
[19:07] <ubot2> Launchpad bug 1055684 in unity-lens-shopping "[FFE] Use music lens details page for music store results" [High,In progress] https://launchpad.net/bugs/1055684
[19:08] <plars> popey: I think I'm missing the bits I need to playback the preview... let me install that
[19:11] <Laney> https://launchpad.net/ubuntu/+source/qt4-x11/4:4.8.3+dfsg-0ubuntu3/+build/3871112
[20:16] <infinity> I'm rejecting eglibc, since I plan to do an upload today, and it'll be a waste of buildd time to build both, I'll make sure the one in the queue is included in mine.
[20:17] <mdeslaur> infinity: cool, thanks
[20:18] <infinity> mdeslaur: NP, happy to reject more security uploads!
[20:18] <mdeslaur> lol :)
[20:18] <mdeslaur> stupid security updates wasting all the CPU time :)
[20:19] <infinity> mdeslaur: I'm still bitter about the security update to precise that wiped out two weeks of testing on my eglibc SRU. :/
[20:20] <infinity> mdeslaur: (Reeeeeally would have been nice if someone had at least tried to contact me and coordinate that)
[20:21]  * NCommander sits down and deals with the unapproved queue
[20:21] <micahg> infinity: I thought about mentioning it but figured you would see it in backscroll, will highlight next time
[20:21] <mdeslaur> infinity: yeah, it sucks when that happens. sorry about that....I believe it got started a while ago
[20:21] <infinity> micahg: Erm, hilighting me after it's uploaded would have been a bit too late anyway.
[20:22] <infinity> mdeslaur: The annoyance is that I could have finished off the SRU testing pretty quickly, and we could have pushed the security update on top.
[20:22] <micahg> infinity: they discussed it a bit first :)
[20:22] <infinity> micahg: But not with me, nor with regard to the SRU, that's the bit that's annoying me.
[20:22] <infinity> micahg: And it's pretty non-obvious to people who aren't paying really close attention when their SRU just disappears.
[20:23] <micahg> infinity: oh, I thought you meant the devel upload, yeah, I wasn't around for the security update in stable
[20:23] <infinity> micahg: Oh, no, the devel upload is fine.  I just rejected it to avoid wasting resources.
[20:23] <infinity> micahg: This is entirely about the precise upload.
[20:24] <infinity> micahg: Which, along with resetting my SRU timer, also broke a whole class of users who had been happily using the one in -proposed. :/
[20:28] <mdeslaur> infinity: we'll make it up to you with some security team beer at uds ;P
[20:28] <infinity> mdeslaur: But.  But.  You guys aren't half as fun as the kernel team.
[20:29] <infinity> mdeslaur: You can always stop by their table and buy us a round. :)
[20:29] <mdeslaur> infinity: oh, we go to the Kernel Team Variety Show too!
[20:42] <NCommander> seb128, ping, I see an entire set of indicator-* packages in the queue with no attached bug.
[20:42] <NCommander> What changes are they making?
[20:42] <ScottK> NCommander: There's no requirement for a bug.  Read the diff.
[20:42] <NCommander> (I see new upstream version released)
[20:42] <NCommander> ScottK, I did, the diff just says new upstrema version with no reason
[20:43] <ScottK> As long as the new version is bugfix only, that's sufficient.
[20:43] <seb128> NCommander, #ps is just rolling stable tarballs for release, translation updates, minor cleanups
[20:43] <NCommander> seb128, thanks
[20:43] <NCommander> ScottK, I'm aware of that, but I do like to verify $WORLD :-). Call it insanity/pendaticness
[20:43] <NCommander> seb128, I'll release the entire set now
[20:44] <seb128> NCommander, thanks
[21:21] <ogasawara> infinity: could I get those linux and linux-meta uploads approved?  It should be our last before kernel freeze tomorrow.  it's an ABI bumper too.
[21:22] <infinity> ogasawara: Yeahp, can do.
[21:23] <ogasawara> infinity: thanks, you're the best
[21:23] <infinity> ogasawara: Aww, I'm blushing.
[21:32] <plars> popey: ok, I can confirm that preview works too, sorry for the delay
[21:32] <popey> plars, no need to apologise, I really appreciate you taking the time to test it, thanks!
[21:32] <Daviey> infinity: are you handling d-i uploads?
[21:33] <infinity> Daviey: I will in ~8h, yeah.
[21:33] <Daviey> rocking banana !
[21:33] <infinity> (When the kernel builds are all done and such)
[21:51] <stgraber> if someone wonders, I've tested most of the changes in that casper upload. I couldn't really test the RAID stuff, but my guess is that it can't be much worse than what they have now (failure to boot)
[21:51] <stgraber> the various persistence changes have been tested and so has the username/userfullname/hostname override
[21:52] <stgraber> The network changes have been tested from busybox (to check that the syntax is fine) but I don't have a netboot environment here to test that it actually works at runtime (but the code is so similar that it really should)
[21:52] <infinity> stgraber: Tested "most" is really giving me confidence. ;)
[21:53] <stgraber> infinity: it's casper we're talking about ;) testing all the possible paths in that thing would take years...
[22:38] <ScottK> kde-baseapps is me trying to salvage some binaries.
[23:02] <infinity> ScottK: Was there a double-override-loss-of-binaries oops?
[23:07] <infinity> apw: Danke.
[23:08] <apw> infinity, np
[23:11] <wgrant> infinity: No, there was a copy-from-proposed-before-armhf-built oops
[23:11] <infinity> wgrant: Ahh.  Oops indeed.
[23:11] <wgrant> infinity: ScottK and I are poking to copy them across
[23:11] <infinity> wgrant: Thanks for helping.
[23:11] <wgrant> Using the same binary recovery method that's never been used on the primary archive before
[23:11] <wgrant> And running into some issues
[23:12] <wgrant> But I think we'll have it sorted out once he's back to rerun the copy
[23:12] <wgrant> And then we'll know this works and can use it properly in future
[23:14] <wgrant> The latest trick is that copyPackage doesn't let you specify a custom source pocket, instead just picking the latest publication with that (archive, name, version)
[23:15] <wgrant> So asking it to copy that version picks the release publication, not the proposed one, so it doesn't grab the missing binaries
[23:15] <wgrant> But if we copy it back to proposed, then from proposed back to release, it will grab the missing binaries, and all will be good in the world.
[23:15] <infinity> Yeah, I've used THAT copy trick before.
[23:15] <infinity> updates -> proposed -> updates
[23:15] <wgrant> Right
[23:16] <infinity> It's from a pocket to itself that's the curiously bizarre use-case.
[23:17] <wgrant> And the non-deterministic override selection issue is a bit problematic, but relatively easily fixable.