[00:17]  * mwhudson nom nom nom
=== mbarnett changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 4 of 3.1.12 | PQM is closed; RC only (https://dev.launchpad.net/CurrentRolloutBlockers, RM: danilos) | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes
[00:39] <wgrant> So, the source format 3.0 code is there now. But do the Soyuz machines have the new dpkg, and are the buildds running lp-buildd 54?
[00:40] <bigjools-afk> wgrant: no and yes
[00:40] <wgrant> bigjools-afk: Argh and yay.
[00:41] <bigjools-afk> it will happen in due course then we can turn on the wotsit selection
[00:41] <wgrant> Right.
[00:48] <bigjools-afk> bedtime, g'night
[00:48] <wgrant> Night.
[01:09] <thumper> mwhudson: so... when are we going to flick the switch on the "never succeeded" svn branches?
[01:31] <jml> mwhudson, where is your pyflakes branch that makes working with lazy imports not be terrible?
[01:31] <jml> mwhudson, and would you like me to land it to trunk for you?
[01:33] <mwhudson> thumper: i guess there's little harm in flicking the switch now
[01:33] <mwhudson> thumper: we shouldn't mass retry them all
[01:33] <thumper> mwhudson: limit 5 each time?
[01:33] <thumper> mwhudson: how many where there?
[01:33] <mwhudson> jml: https://code.edge.launchpad.net/~mwhudson/pyflakes/support-lazy-imports
[01:34] <jml> mwhudson, thank you.
[01:34] <mwhudson> jml: if you like; i've never proposed it as it seems very bzrlib specific
[01:34] <thumper> jml: want a quick chat now? or after you have lunch?
[01:34] <jml> thumper, I just had lunch.
[01:34] <jml> thumper, it's all I can do to prevent my parent's from serving it before breakfast.
[01:34] <mwhudson> thumper: well, by flicking the switch i meant "update codeimport set rcstype = ..."
[01:34] <jml> s/'//
[01:35] <thumper> mwhudson: yeah, that's what I was thinking too
[01:35] <thumper> mwhudson: add a "limit 5" on the end of the query
[01:35] <mwhudson> thumper: not sure off hand about how to retry them with straight sql
[01:35] <mwhudson> thumper: most of the never-succeeded ones are marked FAILED, they won't be retried without intervention
[01:35] <thumper> mwhudson: set the status to reviewed
[01:35] <thumper> mwhudson: ah, bugger
[01:35] <thumper> mwhudson: the code adds the job when it becomes reviewed
[01:36] <mwhudson> thumper: yeah
[01:36] <thumper> mwhudson: so direct editing of reviewed would be a 'bad idea'
[01:36] <mwhudson> i think it's probably just "insert into codeimport where ..." but yeah
[01:36] <mwhudson> *into codeimportjob rather
[01:36] <mwhudson> "some care required"
=== mwhudson_ is now known as mwhudson
[03:02] <jtv> hi mwhudson!  you've been working on the recipe builds, right?
[03:03] <spm> jtv: howdy! no long no see!
[03:03] <jtv> spm: g'day!
[03:03] <jtv> spm: how's life?  drop bear attacks not too bad?
[03:04] <jtv> spm: I've been doing some traveling...  no mobile coverage most of the time, let alone internet.  feel like a different person
[03:04] <spm> heh
[03:08] <mwhudson> jtv: i have, for my sins
[03:08]  * jtv resists to urge to ask about those :)
[03:09] <jtv> mwhudson: I was wondering... how does one go about writing tests for that sort of thing?
[03:09] <mwhudson> jtv: i don't really know, i haven't got to that point yet
[03:09] <mwhudson> jtv: just bashing out the content class code and tests for same
[03:10] <jtv> mwhudson: in our case we separated the "set up an execution environment" work from the "build the payload" work, so I'm facing that part a bit earlier
[03:11] <mwhudson> jtv: well, i guess the interface to between the build and the master is xml-rpc
[03:12] <mwhudson> jtv: so you don't need to run the build inside a vm to be able to test that...
[03:13] <jtv> the last time I did anything with xmlrpc it was to protect against a virus that exploited a PHP implementation... then told the inventor of xml that it was all his fault.
[03:13] <jtv> but the principle sounds sensible :)
[03:14] <jtv> mwhudson: that's another part I couldn't figure out easily: where does the payload fit in?  I saw mention of a build() method on the slave, but couldn't quite match it up to an implementation
[03:15] <mwhudson> jtv: what do you mean by payload?
[03:15] <jtv> the actual work that we want to do on the slave
[03:15] <jtv> i.e. our own equivalent of "build the package"
[03:15] <mwhudson> jtv: code or data?
[03:15] <jtv> oh, our "build" is a pure data thing
[03:16] <jtv> very simple compared to the other stuff
[03:16] <jtv> compared to the other forms of build, I mean
[03:17] <mwhudson> jtv: so there are two ways you can get data onto a build machine
[03:17] <mwhudson> (currently)
[03:17] <jtv> I think we'll be wanting to add a third: check out a publicly available branch
[03:17] <mwhudson> jtv: as an argument to an xmlrpc method, and a file from the librarian
[03:17] <mwhudson> jtv: yes indeed
[03:18] <jtv> I think you're talking about the "cacheFileOnSlave" stuff, right?
[03:18] <mwhudson> (and ultimately, check out a non-public branch too)
[03:18] <mwhudson> jtv: yeah
[03:18] <jtv> for the files that aren't on the public librarian
[03:18] <mwhudson> jtv: i think "cacheFileOnSlave" applies to the public librarian doesn't it?
[03:19] <mwhudson> jtv: public librarian files are accessed by sha1sum, restricted librarian files by url which has credentials embedded in it
[03:19] <jtv> mwhudson: I could easily be wrong, but the buildfarmjobbehavior code I looked at said it was going to the trouble to deal with private files
[03:19] <mwhudson> jtv: wgrant knows far more than me about this sort of thing btw :-)
[03:19]  * wgrant looks.
[03:20] <jtv> I guess the Pacific side of the planet is the place to be for these things  :-)
[03:20] <jtv> hi wgrant!
[03:21] <mwhudson> jtv: which code are you looking at?
[03:22] <jtv> mwhudson: I'm not looking at code now but IIRC there is one existing concrete implementation of IBuildFarmJobBehavior; it has a private method with a name like _cacheFilesOnSlave that does this stuff
[03:22]  * wgrant tries to work out how this new split works.
[03:23] <mwhudson> jtv: i haven't looked at this since the soyuz guys moved all the code around
[03:23] <wgrant> jtv: YOou mean BinaryPackageBuildBehaviour._cachePrivateSourceOnSlave?
[03:24] <jtv> wgrant: that's our baby
[03:24] <jtv> but I don't care too much about this part anyway because what I need to do is pass the branch URL to the slave, then have the slave check out the branch
[03:25] <mwhudson> jtv: in builder.py, i reckon self.slave.ensurepresent is calling some xmlrpc method
[03:25] <jtv> I see now that we've been talking at cross purposes
[03:25] <wgrant> mwhudson: It is.
[03:26] <wgrant> jtv: lib/canonical/buildd/slave.py, def ensurepresent
[03:26] <wgrant> Er, mwhudson ^^
[03:26] <mwhudson> wgrant: right
[03:26] <jtv> ahhhh, and all this time I was looking only in lib/lp/buildmaster and lib/lp/soyuz
[03:27] <wgrant> jtv: And you should stay there until you really have to leave.
[03:27] <mwhudson> jtv: oh, you hadn't had the delight of lib/canonical/buildd yet?
[03:27] <wgrant> lp-buildd is *not* pretty.
[03:27]  * mwhudson goes away until the screaming becomes loud enough to disturb him again
[03:27]  * jtv looks worried and puzzled at the contrast between wgrant's and mwhudson's take
[03:28] <mwhudson> jtv: basically, i guess we'll need to add an xmlrpc method "getbranch" or something
[03:28] <wgrant> mwhudson: But you're going to be using bzr-builder to grab the branches, aren't you?
[03:29] <mwhudson> wgrant: *I* am i expect, yes
[03:29] <jtv> mwhudson: you've been adding slave-side stuff... have you been doing that by extending this part, or by adding new classes somewhere?
[03:29] <wgrant> So it may prove better to just let the Translations code inside the builder take a branch path in extra_args, check it out itself.
[03:29] <mwhudson> jtv: i haven't added slave side stuff yet
[03:30] <jtv> what's bzr-builder btw?
[03:30] <mwhudson> jtv: wgrant has a point here
[03:30] <jtv> it rings a bell
[03:30] <mwhudson> jtv: slave.py defines an abstract class BuildManager
[03:30] <mwhudson> jtv: debian.py in the same directory defines a subclass DebianBuildManager
[03:31] <jtv> wgrant: that's what I had in mind, yes...  it'll mean some IS changes, but it's by far the "narrowest" channel I think
[03:31] <mwhudson> jtv: we'll both be wanting to define new subclasses i think
[03:31] <jtv> ah, buildmanager was that thing that sounded like it lived master-side but actually managed the build client-side?
[03:31] <jtv> I mean, slave-side?
[03:31] <wgrant> jtv: No, no.
[03:31] <mwhudson> hee hee
[03:31] <wgrant> There is buildmanager, and buildd-manager.
[03:31] <wgrant> And slave-scanner, and builddmaster.
[03:31] <mwhudson> there is buildd-manager an
[03:32] <jtv> "oh of course, how could I be so _stupid_?"  :-)
[03:32] <wgrant> buildd-manager and slave-scanner are both instances of this 'builddmaster' concept.
[03:32] <wgrant> They live on the master. There is only one of them.
[03:32] <wgrant> buildmanager is part of lp-buildd, and lives on the slave.
[03:32] <jtv> lp-buildd?  I don't think I've been introduced to that one
[03:33] <wgrant> jtv: launchpad-buildd is the thing that lurks in lib/canonical/buildd
[03:33] <mwhudson> jtv: the stuff in lib/canonical/buildd is turned into a debian package called launchpad-buildd (?) which is installed on the build machines
[03:33] <jtv> but this _does_ sound like buildmanager is the one that sounds like it runs on the master but actually runs on the client, just like I said, no?
[03:33] <wgrant> It's self-contained, except for tac-related stuff.
[03:34] <mwhudson> jtv: yeah
[03:34] <jtv> tactical air command?
[03:34] <jtv> type approval code?
[03:34] <wgrant> jtv: Nasty Twisted thing.
[03:34] <mwhudson> twisted application configuration
[03:34] <jtv> thrust asymmetry compensation?
[03:34] <wgrant> Ahh.
[03:34] <mwhudson> wgrant: better than taps!
[03:34] <wgrant> mwhudson: Yeeeees.
[03:37] <jtv> coffee's ready
[03:37] <jtv> coming back from Laos with a few bags of the stuff was the perfect excuse to get a proper machine
[03:37] <jtv> hang on
[03:38] <jtv> ahhh
[03:39] <jtv> with that taken care of, back to that code :-)
[03:42] <wgrant> How scheduled is this work?
[03:43] <wgrant> (ie. do we know what people will be doing in Wellington?)
[03:43] <jtv> wgrant: still a big unknown afaik
[03:43] <mwhudson> wgrant: this is exactly what we'll be working on in wellington
[03:43] <wgrant> mwhudson: 'this' is a very big domain.
[03:43] <mwhudson> what precisely we will do depends on what we get done between now and then i guess
[03:43] <mwhudson> wgrant: well yes
[03:44] <jtv> wgrant: hence our different answers :)
[03:44] <mwhudson> aiui, the plan is "find something to do.  do it"
[03:44] <wgrant> But I guess it is closer than I had previously thought, what with Christmas in the way.
[03:45] <jtv> mwhudson: would "clean up l/c/buildd a bit" be a good point for the agenda there?
[03:45] <mwhudson> one of the goals on the internal wiki page for the sprint is "# Hack on code like crazed bunnies "
[03:45] <wgrant> mwhudson: Heh.
[03:45] <wgrant> jtv: That code is normally hacked by infinity/lamont/whoeveritisnow
[03:45] <wgrant> But I suspect a lot will need to be done in Wellington.
[03:46] <jtv> what ever happened to "everyone owns all code"?  :-)
[03:46] <jtv> getting fresh, freshly-frustrated eyes on code is often what drives good cleanup
[03:46] <wgrant> jtv: This code primarily lives in a tree outside LP.
[03:46] <wgrant> Occasionally getting copied back in.
[03:46] <wgrant> Although that appears to have changed in the past few weeks :D
[03:47]  * jtv hates hidden dependencies between projects
[03:48] <mwhudson> jtv: part of it (i guess) is that this code has to run on architectures that launchpad probably doesn't run on
[03:48] <mwhudson> like hppa
[03:50] <jtv> fair enough, but does that mean that I'll have to go to this other source tree when I need to work on slave-side code?
[03:51] <mwhudson> i don't think that's completely settled, but i'd lean to "yes"
[03:51] <wgrant> lamont was last week doing the latest lp-buildd changes in a normal Launchpad branch, so the days of the separate tree may be over.
[03:53] <mwhudson> i think that more or less has to happen
[03:58] <mwhudson> wow, the hotel we're staying in in wellington doesn't get very good reviews on tripadvisor
[03:58] <mwhudson> (but i think it'll be fine for us actually)
[03:59] <jtv> mwhudson: the cynic in me is tempted to say "maybe there's just 1 competing hotel and they like to review each other"
[03:59] <mwhudson> jtv: new zealand is a small country, but there's more than one hotel in it's capital :-)
[03:59] <mwhudson> or two
[04:00] <jtv> mwhudson: "oh you're from New Zealand?  Do you know Gerald?"
[04:00] <wgrant> I presume the sprint itself will be somewhere in the hotel too?
[04:00] <jml> you presume too much sir!
[04:01]  * jml goes back to his box
[04:02] <mwhudson> wgrant: yeah
[04:03] <wgrant> Oh good, their website wants me to install QuickTime.
[04:37] <mwhudson> thumper: did you want to talk today?  i guess it's getting late
[04:37] <thumper> mwhudson: I think tomorrow is better
[04:37] <thumper> mwhudson: I'm about to make hamburgers for dinner :)
[04:37] <mwhudson> thumper: ok
[04:38] <mwhudson> thumper: have fun :)
[05:32] <jml> wuuu
[05:32] <jml> adsl2
[05:42] <mwhudson> jml: feel the bits!
[05:43] <mwhudson> "DownStream Connection Speed 9829 kbps"
[05:52] <jml> mwhudson, heh
[05:52] <mwhudson> i think i'm on adsl2, but on the other hand i'm also in new zealand
[05:53] <jml> mwhudson, speedtest says 17.5 Mbps
[05:53] <mwhudson> jml: that's pretty fast
[05:53] <jml> 0.83 up.
[05:53] <jml> mwhudson, I may be the only person on this exchange with adsl2
[05:54] <jml> mwhudson, given that the town has 1,700 people.
[05:55] <wgrant> Which ISP was crazy enough to put an ADSL2 DSLAM down there?
[05:55] <spm> internode probably
[05:56] <jml> yep
[05:56] <spm> despite being in canberra, I support the fact that they put dslams in remote SA towns. big +1 from me.
[05:56] <jml> spm, SA?
[05:56] <wgrant> TAS, wasn't it?
[05:56] <spm> South Aust
[05:56] <jml> spm, I'm in even _southier_ Australia
[05:57] <spm> jml: I know, but they really focus on SA - in particular. for a small company, that's impressive
[05:57] <jml> spm, oh, right.
[05:59] <spm> heh. was funny at one event Simon was talking, one of their network ops was seeing all sorts of funky stuff from telstra. just before T went to full ADSL1. was like random testing of lines and stuff.
[06:00] <jml> in some ways, I'm glad the government didn't split telstra up before privatizing
[06:00] <jml> every story needs a bad guy.
[06:01] <spm> :-)
[07:15] <jml> abentley, with ampoule jobs, what happens if a process dies due to an unexpected error?
=== joey is now known as Guest18577
[10:06] <bigjools> mwhudson: around?
[10:06] <bigjools> or thumper?
[10:35] <maxb> I think bug 316192 has regressed, should I reopen it or file a new one?
[10:35] <mup> Bug #316192: bzrlib.plugin.load_plugins() loads system plugins even for non-system bzrlib <Bazaar:Fix Released by vila> <Launchpad Bazaar Integration:Fix Released by thumper> <https://launchpad.net/bugs/316192>
[10:35] <maxb> I got test failures because LP's 2.1b3 bzr egg doesn't like my bzr-gtk (from .deb) or bzr-rebase (in ~/.bazaar/plugins/)
=== jelmer__ is now known as jelmer
=== jelmer is now known as Guest85315
=== Guest85315 is now known as jelmer
=== salgado-afk is now known as salgado
[11:32] <adiroiban> hi. I'm having some problems with xpath trying to get the row (tr) element hosting a link. I'm using //table[@id='languagestats']/descendant::a[text()='French']/parent::td/parent::tr
[11:32] <adiroiban> but it's not getting the right row
[11:57] <BjornT> maxb: opening a new bug is usually best. it's easier to keep track of things that way. there's value in seeing that this issue was fixed once before.
[11:57] <maxb> I wondered. OK.
[14:19] <leonardr> james_w, i'd like to talk to you about your lazr.restfulclient branch
[14:19] <leonardr> https://code.edge.launchpad.net/~james-w/lazr.restfulclient/fix-caching/+merge/15635
[14:19] <james_w> hi leonardr
[14:19] <leonardr> the branch itself looks fine, but i think the process is broken, because it hasn't been landed for a week
[14:20] <leonardr> and i only noticed it because jml was complaining about a launchpadlib backlog
[14:20] <leonardr> so: what did you expect would happen after the branch was approved?
[14:20] <james_w> ah, I can't land it, so abel said that he would
[14:20] <leonardr> aha
[14:20] <james_w> it obviously slipped his mind
[14:21] <james_w> or got rejected or something
[14:21] <leonardr> it wouldn't have been rejected, it's not pqm-managed
[14:21] <james_w> this was on IRC, so it's not recorded in the MP
[14:22] <leonardr> all right. the simplest way to solve the problem would be for me to monitor the review list and push branches that are stuck in the process
=== Guest18577 is now known as joey
[14:44] <KLondenberg> Hi all .
[14:46] <KLondenberg> Short question: I'm currently trying to get my private copy auf Launchpad working, including Codehosting and so on. Everything except codehosting seems to work fine. But when I try to push to a lp://dev/  repository, the repository gets created in the root folder (/) of the server launchpad is running on. It fails, even, if this is not done with root rights (for obvious reasons). Any clue...
[14:46] <KLondenberg> ...what might be wrong, or where I should start looking into ?
[14:47] <KLondenberg> Apart from that, pushes to that repository don't get picked up by the webapp, even if I "make sync_branches"
[14:55] <sinzui> Chex: Can you merge lp:~sinzui/launchpad/spam-eggs-bug-495250 on staging? We want to verify this branch for a CP to hinder spammers
[14:59] <Chex> sinzui: sure, hang on
[15:00] <Chex> updown is down
[15:00] <Chex> erf misfire
[15:03] <intellectronica> andrea-bs: ok, i know why you're getting the cofiguration conflicts
[15:03] <andrea-bs> intellectronica, great
[15:03] <intellectronica> andrea-bs: in line 159, you allow everything in ISpecification
[15:04] <intellectronica> andrea-bs: then in line 188 you try to require permissions for newMessage and setCommentVisibility
[15:05] <intellectronica> andrea-bs: zope doesn't like that. you can't override attribute configuration, it has to be given only once, and a catch-all allow for an interface counts as all its attributes already configured
[15:05] <intellectronica> it's a PITA!
[15:07] <intellectronica> andrea-bs: the obvious (and somewhat unpleasant) solution is to change the allow declaration to use attribute names instead of the interface, and include only those attributes that you really want to allow
[15:07] <intellectronica> andrea-bs: let me see if there's a better solution i can think of, but it may be that you simply have to do the above
[15:09] <intellectronica> andrea-bs: as you can see, that's how we do it for IBug too
[15:09] <Chex> sinzui: the staging tree already has a bunch of stuff cowboyed in, won't let me pull in your branch.. should I do a revert and try again?
=== salgado is now known as salgado-lunch
[15:10] <sinzui> Chex: Yes, I think staging should be reverted since we released code
[15:11] <andrea-bs> intellectronica, thanks. I'm allowing all ISpecification's attributes (except newMessage & friends) by hand. I think this will require some time :)
[15:13] <intellectronica> andrea-bs: i know. it's no fun. sorry :(
=== jamalta_ is now known as jamalta
[15:18] <leonardr> james_w: sorry, i have more questions about https://code.edge.launchpad.net/~james-w/lazr.restfulclient/fix-caching/+merge/15635
[15:18] <leonardr> i'm trying to see how difficult it would be to write a test for the branch
[15:19] <leonardr> and whether it will really help you
[15:19] <leonardr> what named operation are you calling that's not being cached, that you think should be cached?
[15:19] <james_w> I saw it with lots of things
[15:19] <james_w> distro_series.getSourcePackage for instance
[15:20] <leonardr> were these all named operations that returned specific objects?
[15:20] <leonardr> rather than collections?
[15:21] <leonardr> and when you made the change locally, did you see that the cache was actually being used?
[15:21] <leonardr> i wouldn't expect it to be used because right now launchpad doesn't serve caching directives
[15:22] <james_w> maybe that's the cause then
[15:22] <james_w> while looking in to it I discovered that it wasn't actually the lack of caching that was the limiting factor in the script
[15:23] <james_w> so I eyeballed the bug and submitted the change before moving on to fix the other issue
[15:23] <james_w> it's not just caching though
[15:23] <leonardr> all right
[15:23] <leonardr> i'm going to land the branch because it makes sense and will help us in the future
[15:23] <james_w> httplib skips all the stuff it normally does on GET
[15:23] <leonardr> but i don't expect it to improve performance immediately, if it only affects named operations
[15:25] <leonardr> actually there might be a way to test it regardless...
[15:33] <Ursinha> Chex, gary_poster, rockstar, bigjools, danilos, sinzui, allenap: production meeting in 28 mins @ #launchpad-meeting
[15:33] <bigjools> Ursinha: al-maisan is covering for me today
[15:33]  * al-maisan waves
[15:33] <Chex> sinzui: sorry for the delay, all set now with that lp branch on staging
[15:34] <Ursinha> oi, thanks bigjools and hi al-maisan :)
[15:34] <Ursinha> s/oi/ok/
[15:34] <al-maisan> hellau Ursinha :)
[15:55] <Ursinha> stub, Chex, gary_poster, rockstar, al-maisan, danilos, sinzui, allenap: production meeting in 5 mins @ #launchpad-meeting
[16:01] <Ursinha> stub, Chex, gary_poster, rockstar, al-maisan, danilos, sinzui, allenap: production meeting now @ #launchpad-meeting
[16:02] <sinzui> bac: danilo: I think the webkit CSS problem is related to: http://pastebin.ubuntu.com/343618/
=== salgado-lunch is now known as salgado
[16:03] <sinzui> bac: danilo: We can put some of these rules back, but we should not use ids
[16:07] <sinzui> bac: danilos: The first  rule and the second rule in the removed CSS are the most likely causes.
[16:07] <danilos> sinzui, the only thing that was not old CSS but what I introduced as a bug fix 2 months back was #maincontent { clear: both; }, and that's the first thing I'd add back
[16:08] <danilos> sinzui, margin-right: -25% probably helped with other issues people are seeing
[16:36] <bac> danilos: i'm confused about the CSS problem.  for me it is only appearing on staging not edge.  is that consistent with what others are seeing?
[16:36] <danilos> bac, not that I know, it appears on everything now that we've rolled it out
[16:37] <bac> danilos:  very odd.  on my webkit browser edge looks fine
[16:37] <danilos> bac, what is it that you are seeing? is main content indented for the logo width?
[16:38] <bac> danilos: no.  on a team page the portlets that should be top right are bottom left, below the map.
[16:39] <danilos> bac, right, so that's one part of the problem... if you reduce the font size, does the main content get indented (i.e. floats around the top-left logo)
[16:39] <bac> no
[16:40] <danilos> bac, see bug #493518
[16:40] <mup> Bug #493518: Side portlet moved again below the main content on wide-screen displays (1920x1200) <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/493518>
[16:41] <danilos> bac, ok, so you are being bitten by only part of the bug :)
[16:44] <danilos> bac, I am bitten by both parts, and first one is that I get https://devpad.canonical.com/~danilo/screenshots/css-issues.png
[16:46] <bac> danilos: i've added a comment and two screenshots to that bug
[16:46] <danilos> bac, cool, thanks
[16:46] <bac> danilos: note that i'm seeing the portlets on the bottom LEFT, not the same as emmet's screenshot where they are just pushed down
[16:48] <danilos> bac, right, everybody else sees them at bottom right, so it's interesting to note
[17:22] <salgado> BjornT, around?
[17:23] <salgado> bac, is that on staging?
[17:24] <salgado> bac, staging's currently broken; we need to 'make clean' there
[17:24] <salgado> mbarnett, can you revert pending merges on staging and do a 'make clean' there?
[17:27] <mbarnett> salgado: sure
=== fjlacoste is now known as flacoste
[17:43] <sinzui> salgado: mbarnett: We need to QA my spam branch on staging. It is a CP/reroll candidate. When can we remerge my branch?
[17:46] <mbarnett> sinzui: ok, it sounds like thre is some contention over staging...
[17:46] <mbarnett> salgado: things have been reverted and the appserver restarted.
[17:46] <salgado> mbarnett, thanks!
[17:47] <mbarnett> sinzui: whenever is fine by me, it just depends on what is going on with other devs on staging
[17:48] <sinzui> salgado: are you testing anything on staging?
[17:48] <salgado> sinzui, not anymore
[17:48] <al-maisan> Is there a need to declare on the LP API the return type of a method that returns a string?
[17:49] <sinzui> mbarnett: can you merge this branch into staging and restart it: lp:~sinzui/launchpad/spam-eggs-bug-495250
[17:49] <mbarnett> sinzui: i believe salgado is currently running some tests.  is that true salgado?
[17:50] <salgado> mbarnett, nope, I'm finished
[17:50] <mbarnett> salgado: ok, great.  thanks
[17:50] <mbarnett> sinzui: ok, give me a few (on a phone call), then i will merge that in for you
[18:39] <EdwinGrubbs> sinzui: ping
[18:42] <sinzui> Hi EdwinGrubbs
[18:44] <EdwinGrubbs> sinzui: I have a new idea for solving the addMember() status confusion. Salgado had added a True/False return value just for the REST API, but it would be better to return the actual status. Then, the UI can do the right thing no matter what the model decides to do.
[18:44] <sinzui> EdwinGrubbs: That is a great idea. I agree we should do it
[18:54] <bac> salgado: great, the problem i saw on staging is gone
[18:55] <bac> danilos:
[18:55] <bac> danilos: ^^
[19:06] <danilos> bac, thanks
[19:46] <mars> sinzui, ping
[19:46] <mwhudson> bigjools: here now...
[19:47] <bigjools> mwhudson: I am not :)
[19:47] <mwhudson> bigjools: congrats
[19:47] <bigjools> I just wanted to catch up about how you're doing
[19:47] <bigjools> but it's late, I'm tired, and fed up with 12+ hour days
[19:50] <mwhudson> bigjools: i finally got something reviewable yesterday, thudding my way along i guess
[19:52] <sinzui> hi mars
[19:57] <bigjools> mwhudson: \o/
=== salgado is now known as salgado-afk
[22:15] <EsatYuce> Who knows about GPG key?
[23:43] <thumper> EsatYuce: many people who have stopped working for the day
[23:43] <EsatYuce> thumper, : but i haven't done