[07:43] <dholbach> good morning
[09:02] <Silverlion> good morning everyone
[19:52] <kevouze> Hi everyone,
[19:52] <kevouze> I am currently running a survey about new contributor experience in the following projects: Debian, GNOME, Gentoo, KDE, Mozilla, Ubuntu, NetBSD, or OpenSUSE.
[19:52] <kevouze> I have been talking to Daniel Holbach and Bhavani Shankar, who are supportive of the project.
[19:52] <kevouze> Bhavani recommended me to talk to you here to ask you whether you can help advertise the survey.
[19:54] <holstein> kevouze: can you hang here? it should be easy to get that linked as news
[19:55] <kevouze> that'd be nice.
[19:55] <kevouze> I can also write some post if you want. I'd be happy to do that. Or else I have a number of posts online already.
[20:00] <holstein> kevouze: cool! that is helpful!
[20:01] <kevouze> Shall I write a post and send it? or do you want the list of the other posts? I guess, a specific post for Ubuntu shall be more efficient
[20:08] <holstein> kevouze: i would hang here til you catch pleia2 or one of the other higherups
[20:08] <holstein> kevouze: you can check the topic though and add it in if you'd like
[20:10] <kevouze> ok, shall I send a message on the news ml also?
[20:10] <holstein> kevouze: sure
[20:11] <kevouze> I have also talked to Jono about it, he knows about the project
[20:13] <holstein> kevouze: thanks for being willing to write it up
[20:13] <kevouze> happy to do anything that would help out. this is my final PhD survey, 3 years of work! :)
[20:13] <holstein> congrats!
[20:14] <kevouze> let's wait until I get the results! Still a bit stressed out to get enoufg responses.
[20:54] <kevouze> holstein, question. If I attach the post to the email to news ml, will people get the attached document?
[21:14] <kevouze> Hi, I have just sent an email to the ubuntu news ml asking to help out, but the email was rejected
[23:16] <pleia2> kevouze: can you just send a link to the mailing list? We'll review for inclusion it in the Ubuntu Weekly Newsletter :)
[23:16] <pleia2> (not an attachment)
[23:18] <kevouze> thanks! you mean link to the survey or the blog post for Ubuntu?
[23:20] <pleia2> kevouze: do you have a blog where you posted the survey?
[23:21] <kevouze> yes, http://kevincarillo.org/survey-invitation/
[23:21] <kevouze> I have also a blog post ready for you about how the survey will help Ubuntu, if you think it could be posted
[23:21] <pleia2> great, I'll just include this link :) no need to email
[23:21] <kevouze> thanks!
[23:22] <kevouze> any chance to mention the survey on the g+/facebook ubuntu pages? any help will be super welcome
[23:26] <pleia2> we don't handle the Ubuntu accounts there, you'll need to talk to dholbach (someone on the Canonical community team has access, not sure who)
[23:26] <pleia2> he would know though :)
[23:31] <kevouze> ok, he knows already about the project and is supportive. I am sure he is overwhelmed with his post-UDS email backlog :)
[23:31] <kevouze> Thanks for your help, pleia2!
[23:32] <pleia2> sure, good luck with your survey
[23:33] <pleia2> (and retweeted personally)
[23:34] <kevouze> thanks, appreciated.
[23:34] <kevouze> fingers crossed.
[23:35] <kevouze> do you have any other suggestion to help spread the word within Ubuntu?
[23:39] <pleia2> might contact one of the ubuntu news sites, ubuntuvibes, omgubuntu.co.uk, muktware.com...
[23:39] <pleia2> or all of them :)
[23:46] <kevouze> thanks, will do right now.
[23:46] <kevouze> can I mention you in the emails?
[23:47] <pleia2> sure
[23:47] <kevouze> cool! thanks for all. :)
[23:51] <kevouze> by the way, when is the next newsletter issued?
[23:51] <pleia2> they're weekly, released each Monday
[23:53] <kevouze> ok, perfect.
[23:55] <cprofitt> kevouze: very easy to get involved... and rewarding too.
[23:56] <bkerensa> pleia2: contact omg?
[23:56] <bkerensa> :)
[23:56] <bkerensa> were right here
[23:56] <bkerensa> ;p
[23:56] <pleia2> well, there you go :)
[23:57] <kevouze> cprofitt: the survey involves Ubuntu and 7 other large projects. I am meeting quite a lot of cool people. it's awesome
[23:57]  * pleia2 heads out to dinner
[23:57] <kevouze> have already sent an email to joey 3 days back, still waiitng for an answer
[23:57] <cprofitt> meeting cool people is always awesome
[23:57] <bkerensa> kevouze: what is it your trying to get covered? Joey is a busy guy :)
[23:57] <cprofitt> it will be interesting to see how your survey turns out
[23:58] <kevouze> I have had more negative experiences sometimes also on irc :)
[23:58] <kevouze> can give you the numbers for now, if you are curious
[23:58] <kevouze> it has been 24 horus
[23:58] <bkerensa> kevouze: I actually completed that survey just a couple days ago
[23:59] <bkerensa> I will blog about it on OMG tonight
[23:59] <bkerensa> :)
[23:59] <kevouze> bkerensa: Cool!
[23:59] <kevouze> I actually written a blog post for Ubuntu, saying how the survey will help Ubuntu
[23:59] <kevouze> it is not published anywhere yet,


[01:38] <thumper> lifeless: was there a bug about the +activereviews fubar?
[01:38] <thumper> lifeless: FWIW I've found the bug and fixing it
[01:42] <lifeless> thumper: I think it was lp death spiraling
[01:42] <thumper> lifeless: no, it wasn't
[01:42] <lifeless> thumper: and no, we didn't file a bug
[01:42]  * thumper files one
[01:42] <lifeless> thanks for fixing it.
[02:04] <thumper> every time I think of the question I need to talk to gary about, it is my afternoon and he is away :(
[02:08] <wgrant> LP doesn't work on Lucid :(
[02:08] <wgrant> Should I upload fixes to my own PPA, and get somebody to copy them in?
[02:13] <lifeless> wgrant: yes
[02:23] <ajmitch> wgrant: I hope it's mostly due to python 2.5 support going away, and nothing more major
[02:24] <wgrant> ajmitch: That's right.
[04:13] <mwhudson> wow typing out model code is boring
[04:42]  * wgrant yearns for bug tag editing in bug listings.
[04:49] <lifeless> mwhudson: model code?
[04:49] <wgrant> How do I create a WIP MP?
[04:50] <mwhudson> lifeless: the python code that reflects the database tables
[04:50] <mwhudson> wgrant: you create a ready for review one and change the status i think
[04:50] <wgrant> mwhudson: Ah. That's a bit crap.
[04:50] <mwhudson> (or "use the api", maybe)
[04:50] <mwhudson> wgrant: yes
[07:17] <thumper> wgrant: you used to be able to ..
[07:17] <thumper> wgrant: but the option got removed for simplicity
[07:17] <thumper> wgrant: I want to add an "Extra options" area like bugs
[07:17] <thumper> wgrant: and bring it back
[08:00] <thumper> AAARRRGGGHHHH!!!!!!!!!!!!!!!!!
[08:00] <thumper> ✁☹
[08:01]  * thumper files a bug
[08:04]  * thumper doesn't file a bug, but just fixes the damn problem
[08:11] <adeuring> good morning
[08:22] <jelmer> 'morning
[08:22] <noodles775> Morning jelmer :-D
[08:26] <thumper> jelmer: hi, starting officially today?
[08:26] <jelmer> thumper: hi - yep
[08:26] <thumper> jelmer: welcome and congratulations
[08:27] <bigjools> good morning jelmer
[08:28] <jelmer> thumper: Thanks :-)
[08:34] <wgrant> Morning.
[08:35] <noodles775> Hi wgrant
[08:35] <wgrant> bigjools: Did you get around to uploading that dpkg? My connection has returned to full speed, so I can do it if needed.
[08:35] <bigjools> wgrant: not yet, I was half-way through editing the changelog
[08:36] <bigjools> wgrant: I was trying to think of an appropriate version :)
[08:37] <wgrant> bigjools: Some use the CAT version, others use ~launchpad1...
[08:37] <bigjools> yeah I was going with the latter
[08:41]  * wgrant prepares a lucid Launchpad PPA.
[08:52] <bigjools> wgrant: it's uploading now
[08:53] <wgrant> bigjools: Thanks
[08:53] <wgrant> bigjools: Now I guess somebody needs to poke $LOSA and $EC2TEST_AMI_UPDATING_PERSON...
[08:54] <bigjools> yarp
[08:54] <bigjools> when the package is built I'll do that
[08:54] <wgrant> Thanks.
[08:54] <bigjools> wgrant: it was buildbot and ... ?
[08:55] <wgrant> bigjools: ec2test images
[08:56] <bigjools> that's the same thing in my head
[08:56] <wgrant> bigjools: (and cocoplum and germanium and iron... how are those RTs going?)
[08:56] <wgrant> They're different images.
[08:56] <bigjools> can you tell I don't use ec2? :)
[08:56] <wgrant> :(
[08:58] <bigjools> wgrant: https://edge.launchpad.net/~launchpad/+archive/ppa/+build/1374027
[08:59] <bigjools> balls
[08:59] <wgrant> Um.
[08:59] <wgrant> That's odd.
[08:59]  * wgrant looks.
[08:59] <bigjools> debhelper(inst 6.0.4ubuntu1 ! >= wanted 6.0.7)
[09:00] <mwhudson> i can rebuild the images for ec2 test
[09:00] <bigjools> cool thanks.  I'd like to get the package built first :)
[09:00] <mwhudson> just drop me a mail when the ~launchpad ppa has the new hotness
[09:00] <bigjools> yarp
[09:00]  * mwhudson shouldn't be at the computer any more...
[09:00] <mwhudson> running away now
[09:00] <jml> flee
[09:00] <wgrant> bigjools: Let me check how my PPA managed to build it.
[09:01] <wgrant> Ah, of course, it's not exactly the same.
[09:01] <wgrant> mine's an older version.
[09:02] <wgrant> You could use debhelper from hardy-backports, or ask cjwatson how he did it...
[09:06] <wgrant> bigjools: You retried it?
[09:07] <bigjools> no
[09:07] <bigjools> wtf
[09:07] <thumper> jml: please QA your bits :)
[09:07]  * thumper runs away too
[09:07] <wgrant> bigjools: The depwait giver-back is being rather too lenient, then?
[09:08] <bigjools> yes
[09:08] <bigjools> I thought it waited longer
[09:08] <bigjools> I will copy the hardy-backports dpkg
[09:08] <bigjools> s/dpkg/debhelper/
[09:09] <wgrant> bigjools: Using the forbidden UI?
[09:09] <bigjools> shhh
[09:09] <wgrant> It is handy for that.
[09:09] <bigjools> I don't mind making it more public if we can force people to specify package names up front
[09:10] <wgrant> Right.
[09:11] <wgrant> Although I don't see why it has to time out while listing them all.
[09:11] <wgrant> Rebuild archives manage to list their packages.
[09:13] <bigjools> yeah we can possible make the same optimisations
[09:13] <bigjools> possibly*
[09:14]  * bigjools stabs intel xorg
[09:14] <jml> thumper, !
[09:14] <wgrant> bigjools: Still broken, even on Karmic?
[09:14] <bigjools> yes
[09:14] <wgrant> bigjools: What's wrong with it?
[09:14] <bigjools> z-order is totally borked sometimes, you get the wrong windows half-painted over the top of the one that has focus
[09:15] <wgrant> I see that sometimes during Compiz transitions, but never otherwise.
[09:15] <wgrant> (well, except for Firefox, but that's Mozilla)
[09:16] <wgrant> bigjools: You didn't just retry it before it was published, did you?
[09:16] <bigjools> I didn't
[09:16] <wgrant> Or was that the depwait giver-back thing again?
[09:16] <wgrant> Ah.
[09:16] <bigjools> yes :/
[09:16] <jml> if a revision broke the test suite because it was actually behaving badly, how should that be marked on the QA plan?
[09:17] <bigjools> jml: BAD
[09:17] <jml> bigjools, thanks.
[09:17] <jml> I did some refactoring on the upload permission stuff
[09:17] <jml> how should I QA that?
[09:18] <bigjools> jml: ?? (untestable)
[09:19] <jml> bigjools, is there some way to at least smoke test it?
[09:19] <jml> make sure that people can still upload to their PPAs & what-not.
[09:19] <bigjools> jml: yeah you can use dogfood if it was up :(
[09:19] <jml> bigjools, hmm. ok.
[09:19] <wgrant> bigjools: Still updating?
[09:19] <wgrant> *restoring
[09:20]  * jml writes a launchpadlib script to test the final QA item
[09:21]  * wgrant tracks down the retry-depwait bug.
[09:21]  * bigjools tries to get into dogfood
[09:22] <wgrant> Well, it doesn't take pockets into account.
[09:22] <wgrant> That would do it.
[09:22] <bigjools> that's.... suboptimal
[09:24] <bigjools> ooo nice race condition
[09:24] <bigjools> retry build, click rescore, then see if you can beat it getting dispatched
[09:25] <bigjools> if not, OOPS!
[09:29] <wgrant> bigjools: Oh, do you want to review my gina 3.0 branch?
[09:29] <bigjools> wgrant: I can, stick it in my queue
[09:30] <bigjools> wgrant: it built \o/
[09:30] <wgrant> bigjools: Excellent.
[09:31] <mrevell> morning
[09:31]  * bigjools retries other arches
[09:46] <lifeless> random question
[09:46] <lifeless> arch all packages
[09:47] <lifeless> what controls what queue they go to? Is it code, or a db entry?
[09:47] <wgrant> distroseries.nominatedarchindep
[09:47] <wgrant> It's in the DB.
[09:47] <lifeless> I was wondering, if we could just make it roundrobin through some  sort of hack
[09:48] <wgrant> Sort of.
[09:48] <wgrant> Bug #285206 is better.
[09:48] <lifeless> just putting the idea out there.
[09:48] <mup> Bug #285206: builddmaster needs to be able to deal with "random arch" buildds <oem-services> <soyuz-build> <Soyuz:Triaged> <https://launchpad.net/bugs/285206>
[09:49]  * bigjools would love it if lifeless fixed that :)
[09:49] <wgrant> It should be nearly free after BFB, I think.
[09:49] <wgrant> The main problem is queueing.
[09:49] <bigjools> yeah
[09:49] <wgrant> s/queueing/ordering/
[09:54] <jml> if I have a python dictionary corresponding to the JSON dict of a launchpad rest resource, can I somehow bless it into an actual launchpadlib object?
[09:54] <jml> (also, is the rest service _slower_ than the rest of Launchpad?)
[09:56]  * jml discovers launchpadlib.uris. Is happy.
[09:59] <jml> hmm. http://paste.ubuntu.com/332235/
[10:01] <jml> you know, if that got split out into a method that took 'representation' as a parameter, unit testing would be much easier, and I'd be able to do what I want.
[10:03] <lifeless> jml: you should do that :)
[10:03] <jml> lifeless, I should do a lot of things.
[10:04] <jml> I need help dealing with a bad QA item. Who do I talk to?
[10:09] <lifeless> whats bad about it
[10:14] <lifeless> jml: I need a quick review (real quick): https://code.edge.launchpad.net/~lifeless/testtools/meta/+merge/15479
[10:16] <jml> lifeless, done
[10:16] <lifeless> thanks
[10:44] <maxb> Hmm. Launchpad is confused. It has sent me a mail claiming "You are receiving this email because you are the uploader of the above PPA package." for bigjools upload of dpkg to launchpad PPA
[10:44] <bigjools> !
[10:45] <bigjools> that's special
[10:45] <bigjools> maxb: ah I know why
[10:45] <bigjools> it's because you're listed as a separately permissioned uploader
[10:46] <bigjools> it's deliberate
[10:46] <bigjools> but the email template is wrong of course
[10:46] <maxb> It's still wrong :-)
[10:46] <bigjools> yeah :(
[10:47] <bigjools> it was done for our OEM team so they get all upload notifications sent to a list
[10:47] <maxb> In a perfect world we'd extend the concept of subscriptions to PPAs
[10:47] <bigjools> yes, that's the eventual plan
[10:47] <bigjools> then we can remove the emails that go to the owner's address
[10:53] <wgrant> Hm.
[10:53] <wgrant> I note a lack of lpia Lucid PPA builds
[10:53] <wgrant> Has the chroot been removed, but not yet the DAS?
[10:53] <bigjools> yes
[10:53] <wgrant> Ah.
[14:53] <asabil> hi all
[14:53] <asabil> is it possible to configure launchpad not to use subdomains ?
[15:00] <jml> no, not really.
[15:03] <asabil> ok
[15:21] <jml> barry, hey, you know 'make run_all'?
[15:47] <jml> barry, can we stop it from doing that mailman spew?
[15:47] <barry> jml: it should only spew if something earlier up fails
[15:47] <jml> <IP_ADDRESS> - "" "xmlrpc-private.launchpad.dev:8087" [1/Dec/2009:15:22:07 +0100] "POST /mailinglists HTTP/1.0" 200 392 4 0.135702133179 46 47 "Anonymous" "MailingListApplication:MailingListAPIView" "" "xmlrpclib.py/1.0.1 (by www.pythonware.com)"
[15:47] <jml> <IP_ADDRESS> - "" "xmlrpc-private.launchpad.dev:8087" [1/Dec/2009:15:22:08 +0100] "POST /mailinglists HTTP/1.0" 200 392 3 0.0679800510406 25 36 "Anonymous" "MailingListApplication:MailingListAPIView" "" "xmlrpclib.py/1.0.1 (by www.pythonware.com)"
[15:47] <jml> <IP_ADDRESS> - "" "xmlrpc-private.launchpad.dev:8087" [1/Dec/2009:15:22:13 +0100] "POST /mailinglists HTTP/1.0" 200 392 4 0.0281419754028 20 46 "Anonymous" "MailingListApplication:MailingListAPIView" "" "xmlrpclib.py/1.0.1 (by www.pythonware.com)"
[15:47] <jml> barry, I mean that spew.
[15:48] <barry> jml: oh
[15:48] <barry> jml: well, i guess shut off logging in the xmlrpc server?
[15:48] <jml> barry, what's making the requests?
[15:49] <allenap> mars: I'm about to look at bug 489342, but I wondered if you know if anyone else has already done some work on it?
[15:49] <mup> Bug #489342: "'display_name' is undefined" JavaScript error on development <javascript> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/489342>
[15:49] <barry> jml: it's the mailman xmlrpc queue runner.  it polls launchpad.dev every so often
[15:50] <jml> barry, hmm.
[15:50] <mars> allenap, jml and I looked into it on Friday.  We thought it may have been a change in the last week, but I was able to reproduce on an old branch of db-devel.
[15:51] <mars> allenap, I'm really puzzled by the bug's absence on staging and edge.
[15:51] <jml> barry, I think what I might do is abandon 'make run_all'
[15:51] <barry> jml: unless you really need the other services, that's the best advice i can give
[15:51] <jml> mars, out of curiosity, have you diffed the various outputs?
[15:52] <mars> jml, the on-page outputs?  No, good idea though.
[15:52] <mars> allenap, ^
[15:52] <jml> mars, yeah, that's what I meant: js, css & html.
[15:52] <jml> mars, it might not locate the problem, but you might find out what's different about edge & staging.
[15:52] <allenap> mars: Okay, I have no idea what that refers to yet, but I'll take a look :)
[15:53] <jml> barry, codehosting needs the private XML-RPC service
[15:54] <barry> jml: iirc, there are ways to start services selectively.  i don't remember the details, but you should be able to make run_all and not start mailman.  read the Makefile for details (there's a make variable)
[15:54] <jml> barry, hmm. thanks.
[15:54] <mars> allenap, details are in the bug description.  The bug doesn't show up in production, only on devel.  By capturing and diffing the output of a real page, we might be able to narrow down what is different between production and devel.
[15:54] <jml> barry, even if there's a variable, I might make a helper though. It's _really_ useful to be able to fire up codehosting without thinking too much.
[15:57] <jml> barry, even if there's a variable, I might make a helper though. It's _really_ useful to be able to fire up codehosting without thinking too much.
[15:58] <barry> jml: copy the run_all target and remove mailman from the bin/run -r option
[15:58] <jml> ok. I'll do that.
[15:58] <jml> although, it's week 4
[15:58] <jml> why are we even talking about making small improvements to increase developer speed :(
[15:59] <barry> jml: exactly. jfdi
[15:59] <jml> barry, I can't!
[15:59] <jml> barry, week 4 means I can't.
[16:00] <barry> jml: so now you've started to find the root cause.  rinse and repeat :)
[16:02] <jml> barry, well, there's already some interest in thawing during week 4
[16:02] <barry> jml: that would rock
[16:17] <allenap> gmb: Have you got 10 minutes to talk about bug 489342? I think it's related to the async subscriber portlet work.
[16:17] <mup> Bug #489342: "'display_name' is undefined" JavaScript error on development <javascript> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/489342>
[16:17] <gmb> Oy.
[16:17] <gmb> allenap: Sure.
[16:17] <gmb> Skype?
[16:17] <allenap> gmb: Cool, Skype? Ready? :)
[17:22] <EdwinGrubbs> bac: ping
[17:29] <jml> is there a PPA with all of the latest launchpadlib stuff in it?
[17:29] <bigjools> jml: I hear we have this great search thing in LP ...
[17:30] <cody-somerville> I heard its crap
[17:31]  * bigjools takes cody-somerville off his xmas list
[17:31] <cody-somerville> :-(
[17:31] <bigjools> jml: also see the cool expander at the bottom of here https://edge.launchpad.net/ubuntu/+source/python-launchpadlib
[17:31] <jml> bigjools, you know what, I tried searching for 'launchpadlib ppa' and I found a broken link to one of your PPAs at item eight or so
[17:32] <bigjools> jml: or you can go to https://edge.launchpad.net/ubuntu/+ppas :)
[17:32] <bigjools> umm ew, broken icons
[17:34] <jml> hmm. no one seems to have packaged the latest release
[17:39] <mars> beuno, ^ looks like more sprites are broken, this time on https://edge.launchpad.net/ubuntu/+ppas
[17:40] <beuno> hrm
[17:40] <mars> same problem, the sprites have been applied to a block-display <li> tag
[17:41] <beuno> yeah
[17:41] <beuno> they need to be applied to a span
[17:42] <jml> anyway, where was I.
[17:43] <jml> one of my QA items is bad. An API I added doesn't behave as advertised. Instead of returning a dict mapping URLs to branch objects, it returns a dict mapping URLs to branch json dicts.
[18:07] <jml> how can I tell what db queries are used to load a person via the API?
[18:08] <mars> jml, is there a way to tell which queries are used on a regular launchpad page?
[18:09] <mars> versus the API
[18:10] <jml> mars, yes. you can add ++oops++ as the suffix of the URL to generate an oops report
[18:10] <mars> jml, oh, neat.  I assume you tried that with the API URL?  Might work, depending on how the publisher machinery views the request.
[18:11] <sinzui> have I mentioned how much I hate ZCML recently? Well I still do.
[18:11] <jml> well, I tried entering an API url into my browser. All I get is "Unknown consumer (None)."
[18:11] <mars> sinzui, hehe
[18:11] <jml> mars, whether I use the suffix or not
[18:11] <jml> mars, https://dev.launchpad.net/Debugging was where I got the ++oops++ trick from, btw
[18:11] <mars> jml, try it via the launchpad.net/api/ URL
[18:12] <mars> jml, the url that the JS uses
[18:13] <jml> no joy
[18:13] <jml> different stuff, no oops love.
[18:16] <bac> EdwinGrubbs: hi
[18:30] <mars> jml, wow, thanks for the debugging page link.  That is useful!
[18:32] <jml> mars, np. please update it as you think of stuff.
[18:33] <mars> jml, just tried it myself, and you're right.  No oops for API ++oops++ urls.  darnit.
[18:34] <jml> '* * * * *' means "run every minute" in cron, right?
[18:36] <jml> hmm.
[18:36] <jml> can 'links' log in to Launchpad, I wonder.
[18:37] <mars> jml, on devel, tried "$ LP_DEBUG_SQL=1 make run"
[18:38] <mars> it doesn't return too much
[18:38] <mars> I wish I could tell were the session and auth SQL statments begin and end though
[18:40] <mars> also works in curl: $ curl -k https://bugs.launchpad.dev/api/beta/~name12
[18:41] <jml> mars, not quite as convenient as being able to generate an OOPS, sadly.
[18:42]  * jml starts gathering data on how long it takes to do a named get for a particular api
[18:45] <EdwinGrubbs> bac: I had some questions about private teams and vocabularies. I see that you currently allow private teams in the ValidTeam vocabulary if the user is a participant of the team, but a private-membership team is never in the vocab.
[18:46] <bac> EdwinGrubbs: yes as PMTs can never be used for anything
[18:47] <sinzui> EdwinGrubbs: we are trying to remove them because they really cannot be used for anything
[18:49] <EdwinGrubbs> bac: currently, if a form field uses PublicPersonChoice with the ValidTeamVocabulary, it displays "Invalid value" for non-members trying to enter in a form and hides it from the picker. However, for members of the private team, the form displays "Constraint not satisifed" since PublicPersonChoice rejects it although it actually shows up in the vocabulary for members. This also means that the picker allows you to select a team t
[18:50] <jml> hmm. something is going on that I don't understand
[18:51] <jml> it looks like the first time I hit a bug via wget it takes a while to load, and then following hits take less time: http://paste.ubuntu.com/332535/
[18:51] <bac> EdwinGrubbs: your last sentence got truncated.
[18:52] <EdwinGrubbs>  bac:... This also means that the picker allows you to select a team that can't be used.
[18:52] <bac> EdwinGrubbs: that indeed sounds like a problem.
[18:53] <EdwinGrubbs> bac: so, I'm wondering whether the security measure should be primarily handled by the vocabulary or by the *PersonChoice. I can explain the pros and cons.
[18:53] <bac> EdwinGrubbs: perhaps we need two vocabularies
[18:54] <bac> EdwinGrubbs: one vocab to use with PublicPersonChoice and one to use with ParticipatingPersonChoice
[18:54] <Ursinha> danilos, here is better, I guess :)
[18:54] <Ursinha> or danilo_
[18:55] <danilo_> Ursinha, hi, yes :)
[18:55] <Ursinha> danilo_, rite :P
[18:56] <danilos> Ursinha, so, what test is bothering you? :)
[18:56] <Ursinha> danilos, lp.translations.browser.tests.test_product_view.TestProduct.test_primary_translatable_with_package_link failed
[18:56] <Ursinha> danilos, I went to the test to see why, and it
[18:56] <Ursinha> grrr
[18:56] <bac> mthaddon: ping
[18:56] <Ursinha> it's testing a behavior I wasn't expecting
[18:57] <danilos> Ursinha, right, let me take a look
[18:57] <Ursinha> danilos, the way I implemented, primary_translatable is or the translation focus or the development focus
[18:57] <EdwinGrubbs> bac: the advantage of the vocabulary is that it does all the work, however, if you are allowed to pass in any vocab to PublicPersonChoice, etc., then you can confuse the programmer.
[18:58] <Ursinha> that test expects that if the devel focus has a link to a package, we should return nothing
[18:58] <Ursinha> danilos, ^
[18:59] <danilos> Ursinha, well, it expects that for a reason, let me take a closer look :)
[18:59] <Ursinha> danilos, I couldn't find an explanation where that properties were defined, so thanks for looking :P
[19:00] <EdwinGrubbs> bac: Either, the PublicPersonChoice has to duplicate the privacy check in case an inappropriate vocab is used, or it has to restrict which vocabs are allowed, or we could have one Choice class per relevant vocab: PublicPersonOrTeamChoice, PublicTeamChoice, etc.
[19:01] <danilos> Ursinha, did you change in any way how development_focus is used as primary_translatable other than giving precedence to translation_focus?
[19:01] <Ursinha> danilos, I'm pretty sure I didn't, but I'll double check
[19:01] <danilos> Ursinha, because, I don't see how your code would have broken the test since the test itself doesn't set the translation_focus
[19:02] <Ursinha> danilos, indeed
[19:04] <danilos> Ursinha, where's your branch so I can see how the test is failing as well :)
[19:04] <bac> EdwinGrubbs: and we are currently doing #1, correct?
[19:04] <EdwinGrubbs> bac: The advantage of putting the restriction only in the Choice classes instead of the vocabulary is that it prevents creating new two vocabs when we have orthoganol search criteria. For example, you could use PublicPersonChoice(vocab=ValidTeamOwner) or ParticipatingPersonChoice(vocab=ValidTeamOwner) instead of having two separate vocabs.
[19:05] <Ursinha> danilos, https://code.edge.launchpad.net/~ursinha/launchpad/add-translation-focus/
[19:05] <bac> EdwinGrubbs: at the expense of doing more in python than in SQL
[19:05] <EdwinGrubbs> bac: actually, we are currently checking the value in both places.
[19:06] <EdwinGrubbs> bac: although, you only have to check one value in python, which is not really as expensive as checking all the possible values in SQL.
[19:07] <EdwinGrubbs> bac: for the picker search that is.
[19:07] <EdwinGrubbs> bac: actually, nevermind that last point, since it only makes sense for private-membership teams which are going away.
[19:07] <bac> EdwinGrubbs: if the constraint only lives in the Choice won't we get more situations where an inappropriate team is presented only to be rejected by the constraint?
[19:08] <Ursinha> danilos, I think I know what I did wrong
[19:08]  * jml now gathering data on how long stuff I care about takes
[19:08] <danilos> Ursinha, cool
[19:08] <EdwinGrubbs> bac: yes, but this does have the advantage of providing the user a clear error as to why the team can't be used, so they don't think the picker is broken when it can't find a team they know exists.
[19:09] <sinzui> How do I clearsign the new COC for sample person?
[19:09] <Ursinha> danilos, hm, no, false alarm :(
[19:09] <bac> EdwinGrubbs: and what will that error look like?  something better than "Constraint not satisfied"?
[19:10] <sinzui> dholbach provided a branch to update the COC, but we need a signed version by name12 to pass the test
[19:10] <EdwinGrubbs> bac: I remember beuno mentioning at some point that it would be nice if unselectable items showed up in the picker, but it didn't let you click on them, but vocabularies don't really have a system for that built-in.
[19:11] <EdwinGrubbs> bac: Yes, I was thinking of "Private teams are not allowed." for users that can see the team, but it will automatically default to "Invalid value" for other users.
[19:13] <EdwinGrubbs> bac: The vocab would still filter out teams based on the user's ability to see them, but the Choice would handle whether a private team is an appropriate value for a given field.
[19:13] <bac> EdwinGrubbs: I think what you describe sounds well thought-out and a simplification.
[19:14] <EdwinGrubbs> bac: cool, so I didn't just waist a bunch of time staring at zope code for no reason.
[19:14] <bac> EdwinGrubbs: that would never be wasted time.  well...
[19:21] <Ursinha> danilos, it seems I created a translation_focus property to translations and it wasn't needed :) I guess I complicated what was simple
[19:21] <danilos> Ursinha, could be, I tried playing with your branch and hit some issues with my LP tree
[19:23] <Ursinha> danilos, well, fixed, pushed, running tests again
[19:31] <mars> jml, check that the subsequent wgets are not returning a 304: Unchanged HTTP status code
[19:31]  * mars <- back to lunch
[19:33] <mrevell> night all :)
[19:37] <EdwinGrubbs> bac: I see that ParticipatingPersonChoice only allows private teams and not public or private-membership, however, the docstring says it allows any non-private-membership team.
[19:43] <mwhudson> good morning
[19:44] <jelmer> hey mwhudson
[19:44] <mwhudson> jelmer: https://code.edge.launchpad.net/~mwhudson/launchpad/code-import-paranoia/+merge/15467 btw
[19:45] <mwhudson> jelmer: do you manage to test RemoteGitBzrDirFormat at all in bzr-git's tests?
[19:46] <bac> EdwinGrubbs: that doesn't sound right
[19:46] <EdwinGrubbs> bac: can you look at lib/canonical/launchpad/fields/__init__.py for me?
[19:46] <bac> EdwinGrubbs: what you said is not correct
[19:47] <bac> EdwinGrubbs: ParticipatingPersonChoice constraint is *not* of is_private_membership
[19:47] <jelmer> mwhudson, yes, you're right - it's not tested
[19:47] <bac> EdwinGrubbs: so it allows private and public
[19:47] <jelmer> mwhudson: We need more test infrastructure for that
[19:47] <jelmer> mwhudson, most of the underlying infrastructure is
[19:48] <bac> barry: ping
[19:48] <mwhudson> jelmer: did you see the thread about file:/// urls in the database on launchpad-dev?
[19:48] <mwhudson> it's somewhat related
[19:48] <jelmer> mwhudson, no, where was that? launchpad-dev?
[19:48] <EdwinGrubbs> bac: sorry, I confused myself. It makes sense now.
[19:49] <mwhudson> jelmer: yes
[19:49] <bac> EdwinGrubbs: understandable
[19:49] <mwhudson> jelmer: i guess automatically testing bzr-svn over http is pretty challenging :-)
[19:49] <mwhudson> create an apache config file, run it, test, tear down the server
[19:49] <mwhudson> but blearg
[19:50] <mwhudson> jelmer: https://lists.launchpad.net/launchpad-dev/msg01828.html
[19:52] <jml> mwhudson, hello
[19:52] <mwhudson> jml: hello
[19:52] <jml> mwhudson, mthaddon was asking today about memory problems we're having on bazaar.lp.net
[19:53] <jelmer> mwhudson, I've just replied
[19:53] <jelmer> mwhudson: bzr-local-test-server provides some help there
[19:53] <jelmer> but it's far from trivial
[19:53] <mwhudson> jelmer: i see
[19:54] <mwhudson> jml: do we know what was using the memory?
[19:54] <jml> mwhudson, lots of bzr processes.
[19:55] <jml> mwhudson, some of them are hours old, which makes mthaddon suspect that bug 260171 has reared its head again
[19:55]  * mwhudson waits for mup
[19:55] <jml> 'Codehosting server used a lot of memory and not releasing "old" processes'
[19:55] <jml> https://bugs.edge.launchpad.net/launchpad-code/+bug/260171
[19:56] <jml> for some reason it's private
[19:56] <mwhudson> jml: well afaict nothing has changed here
[19:57] <jml> mwhudson, yeah, that's what I was thinking.
[19:58] <jml> mwhudson, which means we still don't know why the memory usage is so high.
[20:00] <jml> mwhudson, or what to do in a situation where we're running dangerously low on memory
[20:00] <mwhudson> jml: yes, i don't have a good answer for that last point
[20:02] <maxb> wgrant: You seem to have mislanded a local change into     lp:~launchpad-committers/ubuntu/lucid/python-defaults/ubuntu-unofficial. Mind if I push --overwrite it?
[20:08]  * maxb checks you have the revision in another branch, and does it
[20:17] <mars> anyone able to help spot the problem with the following pqm-submit command?  It says I'm "Not authorized to commit to branch": http://paste.ubuntu.com/332582/
[20:17] <mars> And I included the trailing slash on the --submit-branch this time.
[20:18] <sinzui> bac: EdwinGrubbs: I am looking at bug 490224. I recall some decision a long time ago that affected the content-type of downloads, but I do not know the rules.
[20:18] <mup> Bug #490224: .tar.bz2 download has wrong Content-Type <Launchpad Registry:New> <https://launchpad.net/bugs/490224>
[20:18] <salgado> mars, can you do a --dry-run and paste the output?
[20:18] <mars> sure
[20:20] <mars> salgado, http://paste.ubuntu.com/332588/
[20:21] <salgado> mars, I think what you want is to remove the trailing slash
[20:21] <mars> alright
[20:22] <bac> sinzui: looking
[20:24] <EdwinGrubbs> sinzui: I can't remember any possible root cause for the wrong content-type. What doe
[20:25] <EdwinGrubbs> sinzui: oops, I was going to ask what does the db row for that file say the content-type is?
[20:26] <sinzui> EdwinGrubbs: I do not know
[20:26] <bac> EdwinGrubbs, sinzui: we are using mimetypes.guess_type to figure out the content type
[20:27] <bac> sinzui, EdwinGrubbs: for "*.bz2" it returns (None, None) so we default to "text/plain"
[20:27] <sinzui> ha ha
[20:27] <bac> sinzui: it is in ProductReleaseEditView
[20:28] <sinzui> that sounds familiar. Did we have some hacks to second guess other types?
[20:28] <bac> sinzui: sorry, ProductReleaseAddDownloadFileVIew
[20:28] <bac> sinzui: if we did we don't now
[20:28] <EdwinGrubbs> sinzui, bac: it also seems bad that it returns Content-Encoding:gzip when it is already compressed with bz2.
[20:28] <bac> but i don't think we did
[20:29] <wgrant> maxb: Argh, damn, sorry. Must have checked that out rather than branched it.
[20:29] <bac> EdwinGrubbs: using 'wget -S' i don't see that Content-Encoding
[20:30] <maxb> I guess we should start populating the PPA for lucid :-)
[20:30] <wgrant> maxb: Right, I've mostly done it in https://launchpad.net/~wgrant/+archive/launchpad
[20:31] <wgrant> maxb: But lucid's pylint is currently uninstallable, and I decided that merging logilab-common at 1am was inadvisable.
[20:31] <bac> sinzui, EdwinGrubbs: the mimetypes package for python2.6 returns (None, 'bzip2')
[20:31] <maxb> joy
[20:33] <bac> EdwinGrubbs: you have an XXX note about using python-magic.  Was any progress made on that?
[20:33] <sinzui> bac: did you init()
[20:33] <bac> sinzui: i don't understand?
[20:33] <EdwinGrubbs> bac: in which file is the XXX?
[20:34] <sinzui> bac:
[20:34] <sinzui> >>> mimetypes.init()
[20:34] <sinzui> >>> mimetypes.guess_type('file.tar.bz2')
[20:34] <sinzui> ('application/x-tar', 'bzip2')
[20:34] <bac> sinzui: no i did not
[20:34] <EdwinGrubbs> bac, sinzui: btw, the odd Content-Encoding:gzip only occurs on HEAD requests, so it is irrelevant.
[20:35] <bac> sinzui: but if i do "init()" i get the same results of (None, None)
[20:35] <sinzui> oops. We do not call init in the class
[20:35] <bac> sinzui: you sure you're using 2.5?
[20:35] <bac> EdwinGrubbs: browser/productrelease.py
[20:35] <sinzui> I am using 2.6, but the mimetype.init() requirement is ages old.
[20:35] <maxb> wgrant: In order to point out that it's being worked on already, shall I copy your python-{defaults,support} into the launchpad PPA?
[20:35] <bac> sinzui: it does not seem to change the results on 2.5
[20:36] <sinzui> I see 2.5 is buggered
[20:36]  * sinzui checks 2.4
[20:37] <sinzui> Well that's below average
[20:37] <bac> sinzui: calling init is not required. it looks like guess_types calls it if not done yet
[20:38] <sinzui> I see it has an inited attr
[20:39] <wgrant> maxb: That's probably a good idea.
[20:41] <sinzui> bac: in any case, we either need to update to python 2.6, or hack the Finder and ProductReleaseAddDownloadFileView classes. In all cases we need a db update
[20:41] <bac> sinzui: why a db update?
[20:41] <maxb> done. I'll ignore the no-change rebuilds for now
[20:42] <maxb> unless you think otherwise
[20:42] <sinzui> because all the bz2 files uploaded via the View are the wrong content type
[20:42] <sinzui> bac: Finder defaults to application/octet-stream
[20:43] <bac> sinzui: ah, you mean we need to update the data we've stored.  right.
[20:43] <bac> sinzui: can we install a mimetypes file that includes knowledge of .bz2 and use it when we init mimetypes?
[20:44] <bac> sinzui: or just provide a wrapper around it that knows about .bz2
[20:48] <sinzui> bac: I am not sure what to do.
[20:50] <bac> sinzui: perhaps look at the diff in the mimetypes.py from 2.5 and 2.6 and see if we can hack the difference
[20:50] <sinzui> We are close to getting to 2.6
[20:51] <sinzui> gary_poster: barry: was there an estimate of effort or time needed to get to 2.6?
[20:52] <barry> sinzui: at the time we thought maybe another week or two
[20:52] <bac> sinzui: it looks like they just add new entries into suffix_map and encodings_map
[20:52] <barry> sinzui: it kind of depends on the dependencies
[20:52] <bac> sinzui: i think mimetypes provides means to do that cleanly
[20:53] <gary_poster> sinzui: we don't plan to move to 2.6 until Lucid unless there is something really compelling
[20:57] <sinzui> bac: the easiest is to make the Finder and AddDownloadFile agree that the default is application/octet-stream
[20:58] <bac> sinzui: why not x-tar?
[20:58] <bac> sinzui: look at the comment in /etc/mime.types
[20:59] <bac> sinzui: recall .bz2 and .gz are compression not encodings, so we need to figure out what has been compressed
[20:59] <maxb> I was planning to start getting in the residual changes from the python-migration2.6 branch this week, but then I noticed it was week 4, so I figured I might as well do it next week instead
[20:59] <sinzui> bac: yes, I agree with you
[21:01] <sinzui> bz2 appears to be the only broken type of the common types. I think we can add a rule to set the type to application/x-tar for bz2
[21:04] <sinzui> barry: mwhudson: I vaguely recall that we could drop our hacks to urlsplit, urlparse, and safe_hasattr when we switched to python 2.5.
[21:04] <barry> sinzui: i think that's right.  i don't remember the details though
[21:05]  * mwhudson doesn't remember anything about this sorry
[21:06] <sinzui> bac: I loath to do extensive hacking to fix mimetypes since we will toss it out when we get to 2.6
[21:06] <bac> sinzui: i agree.  it just depends on the window...
[21:07] <bac> sinzui: but will there be others we discover?
[21:07] <sinzui> If we add up the time to add and remove 2.6 hacks, we may just find that we would save time helping launchpad get to 2.6
[21:08] <bac> sinzui: probably.  but i still wonder if our users won't always be ahead of the mimetypes package so having the infrastructure in place to update it might be useful.
[21:09] <bac> sinzui: BjornT_ would probably know about urlsplit, etc
[21:10] <sinzui> bac: excellent argument. We know the ones we must support. we can call init(mimetypes.knownfiles + ['launchpad,mimetypes']) to ensure we do not get regressions
[21:11] <BjornT_> bac: i just confirmed that urlparse and friends are fixed in both 2.5.4 and 2.5.2, so we should be able to remove our versions
[21:11] <sinzui> \o/
[22:52] <wgrant> Can anyone think why bootstrapping LP on lucid would be attempting to grab 'distribute'? I didn't think LP used it at all.
[22:53] <wgrant> My upgraded installation works fine, but bootstrapping a new one fails.
[22:54]  * mwhudson also wonders why launchpad-dependencies doesn't want to install on hardy
[22:54] <wgrant> mwhudson: What does it whine about?
[22:55] <wgrant> Hmm, new dpkg-dev not liking old devscripts, maybe?
[22:55] <mwhudson> wgrant: http://pastebin.ubuntu.com/332660/
[22:55] <wgrant> There was something like that in my previous experiments, but it didn't appear to be a problem here.
[22:55] <mwhudson> wgrant: yes, something very much like that
[22:56] <wgrant> mwhudson: Try devscripts from hardy-backports.
[22:56]  * mwhudson wonders if hardy-backports is enabled...
[22:56] <wgrant> Not by default.
[22:56] <wgrant> Ah, EC2. Inconvenient.
[22:57] <mwhudson> i guess there's no wonderful "sudo enable-backports" command?
[22:58] <wgrant> mwhudson: Not beyond 'echo "deb http://archive.ubuntu.com/ubuntu hardy-backports main restricted universe multiverse" >> /etc/apt/sources.list'
[22:59] <mwhudson> wgrant: i guess i'll do something like that then
[23:00] <wgrant> mwhudson: The devscripts from hardy-backports is indeed new enough to not fall afoul of the new dpkg-dev.
[23:00] <mwhudson> yes, this seems to be Doing Stuff
[23:01] <wgrant> mwhudson: If that works, just copy 2.10.39ubuntu2~hardy1 from https://edge.launchpad.net/ubuntu/+archive/primary/+copy-packages?field.name_filter=devscripts&field.status_filter=published&field.series_filter=hardy
[23:03] <mwhudson> wgrant: "copy existing binaries" ?
[23:03] <wgrant> mwhudson: Yes.
[23:03] <mwhudson> hm
[23:03] <mwhudson> i wonder if this is going to time out
[23:04] <mwhudson> yes
[23:04] <wgrant> It didn't when I tried it last week :(
[23:04] <wgrant> Ah, looks like I didn't copy binaries.
[23:05]  * mwhudson confuzzed
[23:05] <wgrant> Anyway, I have a train to catch.
[23:05] <mwhudson> now i get The following source cannot be copied:
[23:05] <mwhudson>     * devscripts 2.10.39ubuntu2~hardy1 in hardy (same version already building in the destination archive for Hardy)
[23:05] <mwhudson> wgrant: thanks for the hints so far
[23:05] <wgrant> Um.
[23:05] <wgrant> Odd.
[23:06] <wgrant> Oh.
[23:06] <mwhudson> so it looks like the copy was actually ok and the time out was rendering the resulting page
[23:06] <mwhudson> maybe
[23:06] <wgrant> Did it maybe time out while trying to render +copy-packages again?
[23:06] <wgrant> Right.
[23:06] <wgrant> Yeah, it copied fine.
[23:06] <wgrant> Anyway, /me leaves.
[23:07] <mwhudson> so i just have to wait until it's published and then we'll be happy
[23:19] <EdwinGrubbs> sinzui: I sent my response to your review. I could work on an oops bug tonight, if there is something you would like fixed before the rollout.
[23:24]  * sinzui looks.
[23:25]  * maxb wishes LP defaulted to "copy binaries". Deciding to rebuilt already built source ought to be a deliberate choice
[23:29] <sinzui> EdwinGrubbs: We do not have any RC candidates. I see two bugs Bug #230801 and Bug #406751 that I think are short
[23:29] <mup> Bug #230801: AssertionError triggered renewing team membership <oops> <registry> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/230801>
[23:29] <mup> Bug #406751: misprint in title of "/@@/maybe" image  <trivial> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/406751>
[23:29] <sinzui> EdwinGrubbs: neither needs to be done this week
[23:36]  * mwhudson watches x11 being installed on the ec2 image
[23:36] <mwhudson> that's a little odd
[23:36] <mwhudson> hm, only x11-common
[23:45] <EdwinGrubbs> sinzui: I'll look into the first one
[23:49]  * mwhudson lunches


[07:10] <flocculant> bluesabre: when I boot pc - pa-plugin is grey till it gets clicked > https://i.imgur.com/r81yEQU.png
[07:10] <flocculant> and ack parole
[11:49] <bluesabre> flocculant: that's weird
[11:50] <bluesabre> flocculant: when you boot, can you restart the panel before clicking on it to see if it is grey even after a panel restart?
[11:51] <bluesabre> if yes, build with --prefix=/usr --enable-debug=full
[11:51] <bluesabre> and then kill the panel and run it with
[11:51] <bluesabre> PANEL_DEBUG=all xfce4-panel
[11:52] <bluesabre> and send me the output from that after a few seconds (long enough for everything to load and then some)
[12:09] <flocculant> ack - doing that now then
[12:17] <flocculant> bluesabre: ok - so grey after panel restart, rebuilding it, went belly up, no plugin to add to panel > http://paste.ubuntu.com/26094953/
[12:20] <flocculant> guess something not liking debug=full
[12:20] <flocculant> in and out today
[13:36] <bluesabre> flocculant: that makes no sense, good job!
[13:46] <flocculant> :p
[14:22] <flocculant> bluesabre: obviously I have all the ppas
[14:22] <flocculant> anyway - bbl - probably