[01:10] <thumper> mwhudson: I'm back now.  When do you want to talk about recipies?
[01:10] <mwhudson> thumper: i haven't really started anything after my lunch break so now ish is good
[01:11] <mwhudson> thumper: gimme a minute to fetch a drink
[01:11] <thumper> mwhudson: ok, let me grab a glass of water and I'll call you
[01:13] <mwhudson> thumper: ready now
[01:18] <dhillon-v10> mwhudson: ping :)
[01:52] <mwhudson> http://people.canonical.com/~michaeln/bfb/build_now_overlay_v2-expanded.png
[03:29]  * thumper off to take advantage of sunshine, back later
[07:32] <noodles775> G'day all
[07:37] <noodles775> lifeless: Hi, will you have a chance to look at bug 509370 solution before I get it reviewed and landed?
[07:37] <mup> Bug #509370: PPA access granted for XXXX mail does not identify the PPA. <email> <ppa> <trivial> <Soyuz:In Progress by michael.nelson> <https://launchpad.net/bugs/509370>
[07:37] <noodles775> s/at/at the
[07:39] <NCommander_> hey noodles775
[07:39] <wgrant> Morning.
[07:41] <lifeless> noodles775: I'm sure you understood the issue, so whatever you've done should be fine
[07:41] <lifeless> noodles775: if you have some reason to think it won't be, I can make time to look at it.
[07:42] <NCommander_> noodles775: do you know if there are any Soyuz specs to implement binary rebuilds?
[07:44] <noodles775> lifeless: ok, I was slightly confused about it, as it is a private PPA that the subscriber doesn't actually have access to, but I've just added the actual PPA name (as opposed to the displayname) and included the description in the email. Thanks.
[07:46] <noodles775> NCommander_: hi, it seems to be currently without priority - mentioned at https://dev.launchpad.net/Soyuz/WantedFeatureList with the relevant bug.
[07:47] <NCommander_> noodles775: I was hoping there were some design docs or spec on the topic
[07:47] <noodles775> Evening wgrant.
[07:49] <lifeless> noodles775: the key thing I'd want to see is the ppa: url
[07:49] <lifeless> noodles775: which is perhaps what you mean by 'actual PPA name'
[07:49] <lifeless> noodles775: the problem being that many many people have a PPA called 'releases' :)
[07:50] <noodles775> lifeless: by 'actual PPA name' I mean the IArchive.name property which is what is used in the URL. Including the URL has a few issues, the main being that the user *doesn't* have access to view the URL.
[07:51] <noodles775> (and won't even when they are subscribed - they can download software, but not see the details of uploads etc.
[07:52] <lifeless> noodles775: I don't understand the issue: the URL is what they add to add-apt-repository etc - its the unique key for the thing.
[07:52] <lifeless> noodles775: I don't know what IArchive.name property /means/
[07:52] <noodles775> lifeless: ah, the apt url - right, I thought you meant the LP url.
[07:52] <lifeless> noodles775: but here is my test: If I can be confused because someone else has a similarly named PPA, then the bug won't be fixed.
[07:53] <wgrant> The URL, or ppa:wgrant/ppa?
[07:56] <noodles775> wgrant: right - As long as owner ? ppa name is there it's sufficient to uniquely identify it. Currently the email includes the name, but not the owner (instead displaying info about the person who subscribed you, which won't always be the same)
[07:56] <lifeless> wgrant: so, ppa:wgrant/ppa, and https://launchpad.net/~wgrant/+archive/ppa - either would be fine for me
[07:57] <noodles775> Neither of those are actually accessible, but yes, the unique info is contained there.
[07:57] <lifeless> and I don't want to pin noodles775 down to doing something that doesn't make sense, which is why I'm trying to keep it high level - that both the owner and url element, not the visible description, need to be visible.
[07:57] <lifeless> noodles775: great, I shall be happy then
[07:58] <noodles775> Yep, that's great. Thanks.
[08:46] <adeuring> good morning
[08:49] <maxb> What is the ettiquette for submitting branches to devel, which you know will cause a conflict in the stable->db-devel automerge?
[08:50] <maxb> (It's just an unfortunately clashing import change)
[08:58] <thumper> maxb: propose for devel, and land
[08:58] <thumper> maxb: once in devel, merge into db-devel
[08:58] <thumper> maxb: when the automatic merge from stable -> db-devel happens, it is a no-op
[08:58] <mrevell> Hi.
[08:58] <thumper> hi mrevell
[09:00] <maxb> Thanks
[09:04] <maxb> gmb: When you have time, could I trouble you for review of the additional unreviewed changeset in https://code.edge.launchpad.net/~maxb/launchpad/use-hashlib/+merge/18894 ? - thanks
[09:10] <lifeless> hi jml
[09:14] <jml> lifeless, hi
[09:20] <jml> jelmer, hi
[09:43] <gmb> maxb: Sure, I'll look now. Sorry, I forgot all about that yesterday
[09:45] <gmb> maxb: Looks good.
[09:45] <gmb> maxb: Want me to ec2  it ?
[09:45] <maxb> Excellent ... yes please
[09:46] <gmb> It's on its way.
[10:41] <jelmer> jml, 'morning
[10:42] <nigelb> any launchpad devs around? I have a feature request and want to know if it is technically feasible before requesting
[10:42] <nigelb> Recently, we've been having quite a large amount of spam, is it possible to revert all the changes made by a user in this case?
[10:43] <nigelb> now, we are manually having to change it.  That comes to modifying around 40 or so bugs
[10:52] <jelmer> nigelb: The required information is present to do something like that, but I have no hard it would be to implement.
[10:52] <jelmer> nigelb: please file a wishlist bug against Launchpad
[10:52] <nigelb> jelmer, so shall I log a bug and hope for the best that it would be tried at some point?
[10:53] <nigelb> oh, great. thanks
[10:53] <wgrant> jelmer: It's not necessarily all present, sadly.
[10:53] <wgrant> The activity log isn't perfect.
[10:53] <wgrant> Although it's much better than it was a few months ago.
[11:43] <nigel_nb> jelmer, bug 520413 opened in LP :)
[11:43] <mup> Bug #520413: All changes by user must be revertable <Launchpad Bugs:New> <https://launchpad.net/bugs/520413>
[11:44] <jelmer> nigel_nb, thanks :-)
[11:45] <nigel_nb> could you please set that to wishlist?
[12:41] <sinzui> nigel_nb: we do not use wishlist (we should remove that status). We use the feature tag and usually mark it as low. Low mean it will be fixed opportunistically, but the feature tag means we need a blueprint for it
[12:42] <nigel_nb> sinzui, and the blueprint would be made at your end ?
[12:42] <nigel_nb> i.e., anything nothing more I can do?
[12:43] <sinzui> nigel_nb: not necessarily us. anyone may, and any feature should have one.
[12:43] <nigel_nb> sinzui, so can I write (or get help from some one to write) one and add a feature tag?
[12:44] <sinzui> nigel_nb: We only commit to working on high priority work. The priority is determined by our goals, oops, and some bugs. contributors can and do work on low priority features to improve launchpad for their community.
[12:45] <sinzui> nigel_nb: I added that tag before you asked to have it set to wishlist :)
[12:46] <nigel_nb> sinzui, well, I'm not a dev at all.  But I can create a feature spec if someone wants to work on it :)
[12:46] <nigel_nb> I'm afraid this *could* potentially be high priority later on
[12:48] <sinzui> nigel_nb: I think we really want to understand what needs to be accomplished and why. A spec implies we know that. We may want to change ACLs and that will make the suggested solution moot.
[12:48] <nigel_nb> sinzui, um, what are ACLs?
[12:49] <sinzui> access control list. If the the untrusted user could not make the change, there would have been no request to rollback the data.
[12:52] <nigel_nb> sinzui, ah, well that makes sense too!  Either ways, it has become insane the last week rolling back changes
[12:56] <wgrant> I think it's just been a particularly bad week.
[12:56] <wgrant> Most weeks have no idiots. The last week had two.
[12:57] <nigel_nb> True.  But it would be nice to have a fail-safe
[13:33] <sinzui> jpds: ping
[13:36] <jpds> sinzui: Pong.
[13:38] <sinzui> jpds: my test for your api changes never enters the loop: http://pastebin.ubuntu.com/373951/ can you hit me with a clue-by-four so that I can test  the api changes?
[13:40] <wgrant> Is that the broken unauthenticated launchpad.View adapter problem?
[13:40] <thekorn> I think so
[13:41] <sinzui> yes it is
[13:41] <sinzui> thank you everyone.
[13:41] <thekorn> bug 515761
[13:41] <mup> Bug #515761: Anonymous API access to some collections returns nothing <qa-ok> <Launchpad Foundations:Fix Committed by jamalta> <https://launchpad.net/bugs/515761>
[13:41] <sinzui> ...I should not have cargo-culted my anonymous test for this test
[13:41] <wgrant> You should have.
[13:41] <wgrant> It exposed another bug.
[13:46] <intellectronica> thekorn: thanks for the work on the iperson_ihasbugs branch. the branch looks in good shape now. set the commit message and i'll land it for you
[13:47] <thekorn> intellectronica, super, thanks. will set this message in a bit
[13:52] <jpds> sinzui: I just mirror = ubuntu.getMirrorByName(name="releases.ubuntu.com") personally.
[13:54] <sinzui> jpds: yes that works, but as wgrant and thekorn rightly noted, there is another bug. I tested it as anonymous and I could not get the mirrors. I am looking for the bad interface
[13:54] <jpds> Groovy.
[13:54] <wgrant> There is no launchpad.View for mirrors.
[13:54] <wgrant> There needs to be, for other reasons, which will fix this.
[13:57] <thekorn> intellectronica, I added a commit message
[13:58] <intellectronica> thekorn: lovely, thanks.
[15:32] <maxb> What's PQM up to, and is lp:~maxb/launchpad/use-hashlib coming up soon?
[15:49] <bigjools> maxb: should have gone through now, the queue is empty
[15:51] <maxb> Something's eaten my branch :-(
[15:51] <maxb> I have a test results email confirming ec2 success
[15:59] <maxb> Well, if it's not in devel and its not in PQM, could someone resubmit it directly to PQM for me?
[15:59] <maxb> lp:~maxb/launchpad/use-hashlib  -> devel
[15:59] <maxb> "[r=gmb][ui=none] Switch from using sha and md5 to hashlib. Also use hashlib.sha256 instead of the python-apt implementation."
[16:19] <bigjools> it's in testfix mode :/
[16:58] <thekorn> allenap, thanks for your comments ;)
[16:59] <thekorn> allenap, ...and your patch
[17:00] <allenap> thekorn: Cool, no worries. Thank you for doing the branch :)
[17:01] <thekorn> allenap, I promise, future branches will have smaller diffs :)
[17:02] <allenap> thekorn: It grew naturally, so no complaints here.
[17:03] <thekorn> yeah that's exactly the problem here
[17:15] <thekorn> allenap, when I move get_related_bugtasks_search_params() to bugs.model.bugtask should this IllegalRelatedBugTasksParams exception stay in registry.interfaces.person or can this exception be moved somewhere to bugs.*
[17:15] <leonardr> flacoste: do you have time for a quick pre-impl chat?
[17:16] <leonardr> the bug is https://bugs.edge.launchpad.net/lazr.restful/+bug/520542
[17:16] <mup> Bug #520542: confusing latest_version_uri_prefix should be merged into active_versions <lazr.restful:New> <https://launchpad.net/bugs/520542>
[17:16] <leonardr> basically, people who encounter latest_version_uri_prefix are confused
[17:17] <leonardr> my plan is to not spell that our separately, just have it be the last version mentioned in active_versions
[17:17] <leonardr> the underlying implementation would be the same
[17:17] <leonardr> the only downside i can think of is it might be confusing to always have 'devel' or 'trunk' at the end of the list, and to slip versions into the list near the end instead of adding them at the end
[17:18] <leonardr> but i think on balance it's better without latest_version_uri_prefix
[17:18] <leonardr> let mek now if you agree
[17:20] <flacoste> leonardr: agreed
[17:23] <allenap> thekorn: Good question. lp.bugs.interfaces.bugtask seems likely, but I'll check.
[17:24] <allenap> thekorn: Yeah, that's the place.
[17:25] <thekorn> okidoki,moving it there, thanks
[17:25] <kfogel> jml: thanks for the quick re-review
[17:49] <salgado> deryck, around? is bug 520584 known?
[17:49] <mup> Bug #520584: Person (assignee) picker is broken on +filebug <Launchpad Bugs:New> <https://launchpad.net/bugs/520584>
[17:50] <deryck> salgado, yes.  I thought there was a bug for that already.
[17:50] <salgado> I couldn't find one
[17:51]  * deryck looks
[17:55] <deryck> very aggravating.  I know I've seen a bug for this before.
[17:56] <jtv> I'm tired of writing one-liner stub methods in my tests.  Unless something *simple* already exists, I'm introducing a helper class FakeMethod that gives you a stub for any function or method and counts the invocations.
[17:59] <deryck> salgado, found it.  and marked yours accordingly.
[17:59] <deryck> salgado, thanks for the heads up, though.
[17:59] <salgado> thanks deryck
[18:03] <mrevell> night
[18:07] <jml> g'night all.
[18:20] <thekorn> allenap, still around?
[18:25] <kfogel> jml: g'night
[18:26] <kfogel> deryck: any idea what's going on here?  http://paste.ubuntu.com/374133/   (i.e., why are there instances of "\n\t" in the submit message that PQM is quoting back to me, when they're not in the original?)  I don't see why we'd be in testfix mode...
[18:26]  * deryck looks
[18:27] <deryck> kfogel, we must be in testfix.  Checking builders now...
[18:27] <deryck> kfogel, db_lp is in testfix
[18:28] <kfogel> deryck: "db_lp" means db-devel or something else?
[18:28] <deryck> kfogel, yeah, the db-devel builder.
[18:28] <kfogel> deryck: hm, but this submission is to devel
[18:29] <deryck> kfogel, yeah, but if either buildbot is broken we go into testfix mode.
[18:30] <kfogel> deryck: oh, I didn't know that.  Okay, thanks.
[18:30] <maxb> Is anyone working on un-testfixing?
[18:31] <deryck> I seem to recall something about db devel in email this morning.
[19:29] <mwhudson> good morning
[19:35] <maxb> Are we un-testfixed now? If so, please could someone do a PQM submit for me?
[20:11] <mwhudson> barry: ping?
[20:11] <barry> mwhudson: pong
[20:11] <mwhudson> barry: do you know anything about getting the magic gdbinit file to work with python2.5?
[20:12] <mwhudson> maxb: yes, untestfixed it seems
[20:12] <barry> mwhudson: i wasn't aware that it didn't work, but it's been a long time since i tried.
 lp:~maxb/launchpad/use-hashlib  -> devel
 "[r=gmb][ui=none] Switch from using sha and md5 to hashlib. Also use hashlib.sha256 instead of the python-apt implementation."
[20:13] <maxb> That got ec2tested OK but apparently dropped on the floor presumably due to testfix
[20:13] <barry> mwhudson: which gdbinit file are you using?
[20:13] <mwhudson> i think it'll be ok with a non-debug build, but too much seems to get inlined into PyEval_EvalFrameEx in the release build
[20:13] <mwhudson> man gdb's command language sucks
[20:14] <bdmurray> where do the losa's hide out?
[20:14] <mwhudson> bdmurray: here, among other places
[20:15] <mwhudson> barry: i'm using the one from the release2.5-maint branch currently
[20:15] <bdmurray> I'd like a Launchpad account suspended.
[20:16] <mwhudson> aaaah
[20:17] <mwhudson> gdb has an embedded python interpreter now
[20:17] <barry> BOGGLE
[20:18] <mwhudson> OH MAN
[20:18] <mwhudson> ACTUAL PROGRAMMING WOO
[20:22] <maxb> Sorry to nag, but as my message is vanishing up in the scrollback: Would someone be able to do a PQM resubmit for me?
[20:22] <mwhudson> maxb: i guess i'm not very trusting, but i'd like confirmation that it passed ec2 from somewhere
[20:23] <mwhudson> did gmb try to land it?
[20:23] <maxb> quite understandable. Shall I forward the ec2test email to mwh@canonical?
[20:24] <mwhudson> maxb: that'd be good
[20:24]  * mwhudson grrs at gdb's python thing
[20:24] <mwhudson> close but no cigar
[20:27] <maxb> sent
[20:28] <mwhudson> ok, got
[20:39] <mwhudson> maxb: in pqm
[20:39] <maxb> \o/
[21:40] <wgrant> jelmer: I notice that your sync-source.py fix tests for lzma tarballs, which are not supported by dak or LP.
[22:36] <EdwinGrubbs> maxb: ping
[22:37] <maxb> EdwinGrubbs: pong
[22:38] <EdwinGrubbs> maxb: I saw your email. I wasn't sure if that was something you were planning to work on, or if I should plan on doing it.
[22:38] <maxb> This is about PIL 1.1.7, right?
[22:39] <EdwinGrubbs> maxb: right
[22:40] <maxb> The relevant change to debian/control is a mere 10 characters or so. I figured I'd leave it to you, as you can better explain why we need 1.1.7
[22:40] <EdwinGrubbs> ok, cool
[23:41]  * mwhudson lunches
[23:42] <maxb> Hrm
[23:42] <maxb> launchpad-database-dependencies is no longer installable on lucid, because postgresql-8.3-slony1 has been dropped
[23:42] <wgrant> Oops.
[23:42] <wgrant> Rebuild rebuild rebuild?
[23:43] <wgrant> Or convince stub to fix 8.4..
[23:43] <wgrant> maxb: Do you have any ideas on the lucid python-setuptools incompatibility?
[23:43] <maxb> I've not looked at the slony1 source package, but adapting it to build for multiple postgresql versions doesn't sound all that fun
[23:44] <maxb> wgrant: I've not examined it - I've literally just upgraded my desktop to lucid now, so I've been focussing on karmic+2.6 up til now
[23:44] <wgrant> maxb: Ah, right.
[23:44] <wgrant> Well, you'll probably need to download python-setuptools and python-pkg-resources to their karmic versions, because of the migration to distribute.
[23:45] <wgrant> I must file a bug on that.
[23:45] <maxb> Oh, the setuptools guys are starting to think about fixing the bug that stops us using pytz source#
[23:45] <maxb> I need to get back to them about that, actually
[23:45] <wgrant> Ah, good.
[23:50]  * maxb wonders what the lp buildbot is up to
[23:51] <maxb> 6 more revs in devel over stable seems high
[23:52] <wgrant> It should be just a few minutes off merging.
[23:53] <wgrant> (I'd guess < 10)
[23:55] <maxb> I wonder if slony1 is actually needed for launchpad development environments
[23:57]  * maxb ponders the idea of a slony1pg83 renamed source package that only builds the postgresql-8.3-slony1 binary (slony1-bin and slony1-doc unbuilt and coming from the lucid archive)