[12:25] <lifeless> if you want to have the batch size, add &batch=50, not ?batch=50
[12:25] <lifeless> as salgado said, doh.
[02:08] <ddaa> lifeless: I was about to go to bed
[02:08] <ddaa> when I found this
[02:08] <ddaa> http://groups.google.com/group/comp.lang.python/browse_thread/thread/2478cc7e5bcc6c30/
[02:08] <ddaa> makes import statements redundant :)
[02:09] <ddaa> also provide lazy importing of selected modules
[04:26] <pablof> hello, somebody help me  ?
[04:27] <pablof> how can i change the Translation Group of a product ?
[04:30] <pablof> thanks
[05:56] <jamesh> lifeless: could you try doing the bzr-0.11-support merge to rocketfuel again?
[06:15] <Ubugtu> New bug: #63898 in launchpad "kill canonical.foaf package" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63898
[07:25] <SteveA> morning
[08:14] <SteveA> jamesh: how's the bzr-0.11 thing going?
[08:15] <jamesh> SteveA: yesterday's merge failed, and lifeless said he'd try it again today (I fixed the cscvs test failures I missed before).  I pinged him a few hours ago, but haven't got a response
[08:17] <jamesh> as far as I can tell, it should successfully merge this time.
[08:25] <SteveA> ok
[08:34] <carlos> morning
[08:51] <sabdfl> morning all
[08:51] <fabbione> hey sabdfl 
[08:54] <jamesh> sabdfl: with a patch we rolled out yesterday, you can do "bzr branch https://launchpad.net/products/bzr" and get a branch of bzr
[08:55] <jamesh> not quite lp: URLs, but it is close
[09:32] <_thumper_> morning
[10:04] <sivang> morning
[10:18] <sabdfl> jamesh: very very cool! i wonder, were we getting any 404's suggesting people were doing that instinctively?
[10:18] <sabdfl> hey fabbione! you hanging out in our part of town too?
[10:19] <fabbione> sabdfl: have been doing it for a long time :)
[10:19] <jamesh> sabdfl: a few, yes.
[10:20] <SteveA> jamesh: does it do a redirect to do that?
[10:21] <jamesh> SteveA: it creates a bzr branch reference (the same kind of pointer you get in a lightweight checkout)
[10:22] <jamesh> SteveA: so it pulls all the branch data directly from http://bazaar.launchpad.net/ (and records the bazaar.launchpad.net URL as the parent)
[10:23] <SteveA> wow
[10:25] <jordi> heya
[11:26] <carlos> jordi: hi
[11:26] <carlos> so, did you send that email?
[11:26] <jordi> carlos: no, I have to ammend according to kiko's comments, and I left LliureX at 20:30 last night.
[11:27] <jordi> I'm doing rosetta this evening
[11:27] <carlos> I think mpt did those changes based on kiko's input
[11:27] <carlos> anyway, don't worry until this evening
[11:27] <jordi> oh really?
[11:27] <carlos> I think so
[11:27] <jordi> ok, I can send early in the evening though
[11:27] <jordi> maybe in a while if I can find the time
[11:27] <carlos> I've incorporated your points while copyediting the page.
[11:27] <carlos> Cheers
[11:27] <carlos> --
[11:27] <carlos> Matthew Paul Thomas
[11:27] <carlos> http://mpt.net.nz/
[11:36] <AlinuxOS> carlos, is it possible in this precise moment translate official gnome in rosetta ?
[11:36] <carlos> no, because we don't have a way to sync automatically from GNOME's CVS
[11:44] <carlos> danilos: ping
[11:44] <danilos> carlos: pong
[11:46] <AlinuxOS> carlos, it's only for the moment ? or it's future project ?
[11:46] <AlinuxOS> Entrans is still crappy and buggy to use.
[11:46] <AlinuxOS> danilos, privet ;)
[11:46] <danilos> AlinuxOS: hi ;)
[11:46] <carlos> it's a future project
[11:46] <AlinuxOS> carlos, very future ? :)
[11:46] <carlos> it's not a high priority right now
[11:47] <carlos> and we don't have time to schedule it yet
[11:47] <carlos> we have something started by zyga thought
[11:47] <carlos> but he ran out of time
[11:47] <AlinuxOS> and search inside a module ?
[11:47] <carlos> that's high priority once we finish our current tasks
[11:47] <carlos> danilo will do it
[11:48] <AlinuxOS> for example I need to search a phrase inside debian-installer ..or I remember a string number :)
[11:48] <AlinuxOS> danilos, wow :) good.
[11:48] <danilos> AlinuxOS: bug 44
[11:48] <Ubugtu> Malone bug 44 in rosetta "Translations should be searchable" [High,Confirmed]  http://launchpad.net/bugs/44
[11:48] <danilos> AlinuxOS: btw, the workaround people use now is to download a PO file and look for the string there
[11:49] <AlinuxOS> guys can I see entire list of high priority bug of rosetta ?
[11:50] <AlinuxOS> danilos, me too :)
[11:50] <AlinuxOS> but it's not so fast.
[11:52] <AlinuxOS> and great thing may be... if you have a possibility to search a phrase in original (unicode) language and in english too, not only in a single .po filke but in entire language (Ex: Georgian) project.
[11:52] <carlos> AlinuxOS: https://launchpad.net/products/rosetta/+specs
[11:53] <carlos> AlinuxOS: that's the way we are going to implement it, search for translations and english strings
[11:53] <carlos> AlinuxOS: our current top priority ones are https://launchpad.net/products/rosetta/1.0
[11:53] <AlinuxOS> carlos, thanks...
[11:53] <AlinuxOS> Great Job! ;)
[11:53] <carlos> AlinuxOS: https://features.launchpad.net/products/rosetta/1.0/+specs <- This is the right link
[11:54] <sabdfl> shouldn't need the last +specs
[11:54] <sabdfl> (and won't need the /products soon either
[11:55] <AlinuxOS> sabdfl, hello ;)
[11:55] <sabdfl> privet :-)
[11:56] <AlinuxOS> sabdfl, no in Georgian:  (gamarjoba).
[11:56] <carlos> sabdfl: well, that's a bug in our navigation links ;-)
[11:56] <AlinuxOS> privet = russian ;)
[11:58] <AlinuxOS> sabdfl, I knew about your response to a letter from Ministry of Instruction of Georgia, they are going to use Kubuntu in Georgian schools and that's great!
[11:59] <AlinuxOS> (sorry for offtopic launchpaders)
[11:59] <jamesh> it is unfortunate that we need to keep the /+spec/ bit in the features.launchpad.net URLs if we want to include product series URLs
[12:00] <jamesh> be nice to have https://features.launchpad.net/rosetta/spec-name
[12:00] <AlinuxOS> I'm just proud of Ubuntu/Launchpad & Co ;)
[12:02] <lifeless> SteveA: can we do a voice call ?
[12:03] <SteveA> lifeless: I'm in a conf call now
[12:03] <lifeless> SteveA: ok, well ping me when you are free. its 2000 here for reference
[12:03] <jamesh> lifeless: have a chance to try the bzr-0.11-support merge again?
[12:03] <lifeless> jamesh: just about to as it happens
[12:04] <jamesh> thanks
[12:04] <lifeless> jamesh: we have j-a-meinel here so have been sprinting all day
[12:05] <lifeless> pqm is down for manual merge
[01:08] <lifeless> spiv: zope has a wsgi module too
[01:10] <lifeless> jamesh: passed
[01:10] <jamesh> lifeless: great.
[01:12] <lifeless> its only lp, cscvs and bzr to update right ?
[01:13] <lifeless> and what commit message do you want ? '[r=lifeless]  Update to bzr 0.11' ?
[01:13] <jamesh> yeah
[01:13] <jamesh> that sounds good
[01:18] <SteveA> BjornT: ping
[01:18] <BjornT> SteveA: pong
[01:18] <SteveA> did we arrange to have lunch today?
[01:18] <BjornT> no, tomorrow.
[01:20] <SteveA> ok, thanks
[01:23] <SteveA> BjornT: late lunch, after lp meeting?
[01:24] <SteveA> lifeless: ping
[01:24] <ddaa> good morning
[01:24] <lifeless> SteveA: pong
[01:24] <SteveA> lifeless: want that voice call?
[01:25] <lifeless> please
[01:25] <lifeless> in 5 minutes ?
[01:25] <SteveA> ok, call me when you are ready
[01:25] <lifeless> skype ?
[01:25] <SteveA> oh, sure.  i'll run it
[01:25] <lifeless> whats the account name to call ?
[01:25] <SteveA> implied
[01:27] <lifeless> jamesh: all done. Can you do submit a merge to dists to remove the bzrtools from the configs ?
[01:30] <BjornT> SteveA: sure, late lunch is ok.
[01:34] <sabdfl> AlinuxOS: very happy to hear that!
[01:35] <ddaa> _thumper_: hello, how's it going today?
[01:35] <_thumper_> ddaa: good, mostly reading today
[01:36] <_thumper_> wiki pages on launchpad mostly
[01:36] <_thumper_> but just looking at launchpad.conf now
[01:36] <ddaa> launchpad.conf does not make very interesting reading
[01:36] <_thumper_> not overly
[01:36] <_thumper_> but started with the makefile
[01:37] <AlinuxOS> sabdfl, ;)
[01:37] <ddaa> Did someone suggested that you read launchpad.conf?
[01:37] <_thumper_> no
[01:37] <_thumper_> just looking
[01:37] <_thumper_> ddaa: where is the initial entry point for lp?
[01:38] <_thumper_> the display thereof
[01:38] <ddaa> initial entry point?
[01:38] <_thumper_> what gets displayed when you hit launchpad.dev
[01:38] <ddaa> well... it's built on zope, so if you want to go top down like that it's going to take... a long time...
[01:39] <_thumper_> the executive summary should be find
[01:39] <_thumper_> s/find/fine
[01:39] <_thumper_> I worked on a plone zope2 site before
[01:39] <_thumper_> with a big zodb
[01:39] <_thumper_> which launchpad doesn't have
[01:40] <ddaa> Okay, so in my perception, when you got a page and you want to know what produces it...
[01:40] <ddaa> You start by figuring out what content object this page is displaying.
[01:40] <_thumper_> yeah, the object and its view I gess
[01:40] <ddaa> Consider https://launchpad.net/people/ddaa/+branch/bzrk/dev
[01:41] <ddaa> it's displaying a branch
[01:41] <ddaa> actually, it's the index page for the branch
[01:41] <ddaa> that is it is an alias for https://launchpad.net/people/ddaa/+branch/bzrk/dev/+index
[01:41] <ddaa> so you look in lib/canonical/launchpad/zcml/branch.zcml
[01:42] <_thumper_> ok
[01:42] <ddaa> here you'll find an entry for +index with for="IBranch" (or something close to that)
[01:42] <ddaa> this element will tell you which template is used for this page, with which view class
[01:42] <_thumper_> yep, see it
[01:43] <ddaa> the templates are all in lib/canonical/launchpad/templates
[01:43] <ddaa> and the view classes are all in lib/canonical/launchpad/browser
[01:44] <_thumper_> ok
[01:44] <ddaa> the view class whatever it needs to do, but eventually it ends up talking with content classes
[01:44] <ddaa> the content classes are all in lib/canonical/launchpad/database
[01:44] <ddaa> however, the browser classes only talk to content classes through zope security proxies
[01:45] <ddaa> that enforce permissions and stuff like that
[01:45] <sivang> ddaa: those proxies are actually factories ?
[01:45] <ddaa> sivang: ask someone who actually understand that stuff, will you :)
[01:45] <sivang> hehe
[01:46] <ddaa> the security proxing is done with two important bits of code, the zope interface(s) for the content class
[01:46] <ddaa> all zope interfaces are in lib/canonical/launchpad/interfaces
[01:47] <_thumper_> what is the facet attribute of <browser:page> ?
[01:47] <ddaa> and the permission policies, which are all in lib/canonical/launchpad/security.py
[01:48] <ddaa> facet is one of overview/bugs/branches/specification/etc.
[01:48] <ddaa> it's essentially the class of the pillar of the page
[01:48] <_thumper_> is it used for anything interesting or just grouping
[01:49] <ddaa> it's quite essential to the structure of the site, it's used to generate the action menu and the location portlet
[01:49] <_thumper_> getting back to the initial page, what is the root object?
[01:49] <ddaa> the two portlets you find on almost every page in the top left
[01:50] <ddaa> root?
[01:50] <_thumper_> the one that the initial page view is off
[01:50] <_thumper_> http://launchpad.dev/ is a view on something, what?
[01:50] <ddaa> ha
[01:50] <ddaa> the home pages are special
[01:51] <_thumper_> ok...
[01:51] <_thumper_> zcml?
[01:51] <ddaa> for example the /bazaar page is defined with the bazaar.zcml
[01:51] <ddaa> I'd expect the root page to be somewhere in launchpad.zcml
[01:51] <ddaa> these are so called application pages
[01:52] <ddaa> because they do not have a real database content object to back them
[01:52] <_thumper_> makes sense
[01:53] <ddaa> also, in the near future, the facet will determine the primary vhost from which the page is served
[01:54] <_thumper_> I read a spec about that work
[01:54] <ddaa> I do not really know the details of the vhostization plan, though
[01:55] <ddaa> _thumper_: if you want to read some boring stuff, I'd like if you had read all the open bugs and specs on the launchpad-bazaar product before the sprint
[01:55] <_thumper_> ddaa: will it put me to sleep?
[01:56] <ddaa> depends on how strong is your coffee
[01:56] <_thumper_> v.strong
[01:56] <_thumper_> ddaa: I will read
[01:56] <ddaa> that should be okay then. None of us has learned writing at MS documentation dept.
[01:57] <sivang> ddaa: you should have tried readin some VB manuals, they take it all, trust me :)
[01:58] <ddaa> _thumper_: some bugs and specs tend to be quite high context, so do not hesitate to ask for explanations
[01:58] <_thumper_> ddaa: no problems there
[01:58] <ddaa> oh, btw, there's some documentation about the various launchpad-bazaar systems I wrote some months ago
[01:59] <ddaa> it's obsolete of course, but will give you an idea
[02:00] <ddaa> go to doc/bazaar
[02:00] <ddaa> and "make"
[02:00] <ddaa> you'll need xsltproc and dia installed
[02:01] <ddaa> that will produce a bazaar.html page and the associated png files
[02:01] <_thumper_> I installed those this morning after reading the README
[02:04] <_thumper_> doc made, and will read after lunch
[02:08] <_thumper_> ddaa: I must be missing something - what is HCT?
[02:11] <ddaa> The Hypothetical Changeset Tool
[02:11] <ddaa> I mean, that's a VERY good question
[02:13] <_thumper_> Hmm, just checking launchpad to see if a person with a particular id existed, and it oopsed
[02:13] <ddaa> That is a not-yet-implemented (long story there) tool to version-control distro packages as a collection of branches.
[02:13] <_thumper_> I don't think it should do that
[02:13] <ddaa> _thumper_: there's a couple of bugs open about that
[02:13] <_thumper_> ok
[02:13] <ddaa> for one thing the 404 page should look more like a 404 and less like a crash
[02:13] <matsubara> _thumper_: which OOPS number?
[02:13] <ddaa> and then, when looking for objects like that, it should do a search and give close matches
[02:14] <_thumper_> OOPS-277B290
[02:14] <Ubugtu> https://devpad.canonical.com/~jamesh/oops.cgi/277B290
[02:14] <_thumper_> ddaa: makes sense
[02:15] <_thumper_> ddaa: do you know if I can change my short name that is currently registered with launchpad?
[02:15] <ddaa> _thumper_: so, in HCT, a source package would be represented as a collection of branches, which have a common base in the upstream source code. Merging all those branches produces the final source package tree.
[02:15] <ddaa> there would be one branch for each distro patch
[02:15] <ddaa> and one branch for the distro-specific data
[02:23] <lifeless> _thumper_: yes you can
[02:25] <_thumper_> lifeless: don't you ever get away from the computer?
[02:25] <lifeless> yes :)
[02:25] <ddaa> when he hears beer
[02:25] <ddaa> or smell meat
[02:27] <ddaa> _thumper_: when we have HCT, we will have a branches facet on distro objects, like sourcepackages
[02:27] <ddaa> mh... actually, strike what I said before
[02:27] <ddaa> facet and pillar are different
[02:28] <ddaa> the facet indentify the launchpad sub-application a page belongs to
[02:28] <ddaa> distro is a pillar
[02:28] <matsubara> _thumper_: https://launchpad.net/people/$yourlaunchpadname/+edit
[02:28] <_thumper_> ddaa: not too worried about it yet
[02:28] <_thumper_> matsubara: thanks
[02:29] <_thumper_> matsubara: unfortunately the id I want is owned by someone who is not an active launchpad user :(
[02:29] <ddaa> that can probably be arranged
[02:30] <ddaa> ask a launchpad admin to rename the offender
[02:30] <_thumper_> :)
[02:31] <_thumper_> is there an email address for that or channel?
[02:31] <ddaa> ask people here
[02:32] <ddaa> anybody in the admin team
[02:32] <_thumper_> ok
[02:37] <salgado> stub, is staging being rebuilt daily?
[02:38] <stub> salgado: No - it is still running Brads branch from two weeks ago. If this is a problem, we can sort it out with Brad.
[02:40] <salgado> stub, I'd like to do some testing now that person-creation-rationale has landed. hasn't bradb's branch landed already? would it be possible to have staging rebuilt this week?
[02:41] <stub> salgado: I don't know if brad's branch has landed. Can you confirm?
[02:42] <salgado> sure
[02:42] <salgado> bradb, around?
[02:42] <bradb> RM isn't in prod
[02:42] <bradb> won't be for a bit yet
[02:43] <stub> bradb: Can we remove the branch from staging for a while? We can revert in a few days if you still need it, but salgado is the second person to have asked about staging in the last day or so.
[02:43] <salgado> bradb, well, I was asking if it has landed in rocketfuel
[02:43] <bradb> salgado: sorry, not in rf either
[02:44] <bradb> stub: if you can put it back in a few days, it's okay to remove it for now, i think
[02:44] <stub> bradb: ta.
[02:44] <stub> salgado: I'll update staging now with fresh code, and we will get a fresh db dump tomorrow.
[02:45] <salgado> stub, cool. can you also get the guess-person-creation-rationale.py script running? :)
[03:09] <ddaa> hey, what do I need to do to get notified about all spec changes in a given product?
[03:09] <ddaa> specifically, I want to be told if anybody does any spec work in launchpad-bazaar
[03:09] <ddaa> to avoid being caught by surprise when somebody tells me "there's a spec about that, it's random-name"
[03:18] <cprov> stub: ping
[03:18] <stub> cprov: pong
[03:19] <cprov> stub: hi, do you have any rescent production DB snapshot ? we need a new copy in mawson. 
[03:19] <BjornT> ddaa: i'm quite sure it's not possible to do that today, but there's a bug open for it i think.
[03:19] <stub> cprov: I'll push a fresh one out now
[03:20] <ddaa> BjornT: maybe if I make myself the driver of bazaar-launchpad?
[03:20] <cprov> stub: thank you !
[03:21] <BjornT> ddaa: no. spec notifications get sent only to people directly related to the spec. there's not even a 'new spec' notification.
[03:21] <ddaa> Crapity crap :(
[03:23] <Keybuk> stub: I don't have permission to change one of my own products (grepmap)
[03:25] <stub> Keybuk: file a bug, and if necessary me or any of the other launchpad administrators should be able to make the change for you
[03:28] <kiko> morning
[03:28] <matsubara> Keybuk: any of the Registry Admin would be able to transfer ownership to you
[03:28] <matsubara> s/Admin/Admins/
[03:28] <kiko> I am one
[03:29] <Keybuk> what should I file the bug on?
[03:30] <Keybuk> products/launchpad ?
[03:30] <matsubara> kiko: no, you're not, but you're a lp admin. :)
[03:30] <stub> ahh... I assumed 'own product' meant you where the owner in the launchpad sense
[03:30] <stub> Do we have a claim product feature request open already?
[03:30] <Keybuk> well, I'm sure I registered it originally
[03:30] <Keybuk> but somebody went through in SQL and reassigned everything I registered to registry admins once
[03:31] <Keybuk> I just noticed this one
[03:31] <stub> Keybuk: I've set you back as the owner anyway
[03:31] <Keybuk> ok, bug #63963
[03:31] <Ubugtu> Malone bug 63963 in launchpad "No permission to edit my own product" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63963
[03:31] <matsubara> Keybuk: file a support ticket
[03:31] <matsubara> hmm too late
[03:31] <Keybuk> thanks
[03:33] <matsubara> the fastest "fix released" bug ever!
[03:37] <salgado> flacoste, ping?
[03:38] <flacoste> salgado: pong
[03:40] <Ubugtu> New bug: #63963 in launchpad "No permission to edit my own product" [Undecided,Fix released]  http://launchpad.net/bugs/63963
[03:41] <salgado> flacoste, I'm writing the UI to chose the language when searching for a ticket, and since one of the radio buttons will have to have some text and a link (that I can't store in a vocabulary) right beside it, I'm thinking that it may be better to manually craft the HTML and stuff instead of using a Choice field and a vocabulary
[03:41] <salgado> unless there's a easy way to achieve that with a Choice and a vocab
[03:42] <BjornT> salgado: what kind of value does the text represent?
[03:43] <flacoste> salgado: you could create a custom widget, but it may not be worth the trouble
[03:43] <salgado> BjornT, one of the radio buttons will be labeled "My preferred languages" and then right beside it I need to list the user's preferred languages and provide a link for the user to change the preferred languages
[03:44] <salgado> flacoste, yeah, that's what I thought
[03:45] <BjornT> salgado: so, what value would it have in the widget? if it's None, then you can easily change the _messageNoValue attribute in the widget.
[03:47] <BjornT> salgado: another option is to create a custom vocabulary, which would contain your new value, as well as the original vocabulary items.
[03:48] <salgado> BjornT, the value is not None, so I don't think I can use the former
[03:48] <salgado> BjornT, for the latter, you mean make the vocabulary include the preferred languages and the link?
[03:49] <flacoste> BjornT: the actual vocabulary contain three values: English, PreferredLanguages, All
[03:49] <BjornT> salgado: yeah. it depends on what other items you have in the radio widget.
[03:50] <flacoste> BjornT: and salgado wants to display a link to change the preferred languages alonside that option (and display the currently selected preferred languages)
[03:50] <flacoste> flacoste: but the vocabulary contains basically three values
[03:50] <flacoste> BjornT: ^^^
[03:51] <BjornT> if it's only three values, it's probably easiest to simply construct the vocabulary on the fly, or something like that.
[03:53] <salgado> BjornT, something like constructing the DBSchema on the fly and feeding it to vocab_factory?
[03:54] <flacoste> salgado: no, simply create a vocabulary using SimpleVocabulary
[03:54] <flacoste> flacoste: for validation purpose, but you'll have to code the UI by hand (or in a widget, but no point in writing a widget for only one use)
[03:55] <BjornT> yeah, i was referring to using SimpleVocabulary
[03:55] <BjornT> flacoste: how will the UI look like?
[03:55] <salgado> ( ) English
[03:55] <salgado> ( ) My preferred Languages
[03:55] <salgado> ( ) Any language
[03:56] <BjornT> why would that have to be coded by hand, rather than using RadioWidget?
[03:57] <flacoste> salgado: actually you said the second one would look like: ( ) My preferred languages (Portuguese, Spanis) Click here to change your preferred languages
[03:57] <flacoste> BjornT: ^^^
[03:57] <salgado> yeah, I forgot that
[03:57] <BjornT> flacoste: it's possible to include links in vocabuarly term labels
[03:57] <salgado> that's the main reason why we're having this discussion. :)
[03:58] <salgado> BjornT, but we can't include the user's preferred languages, can we?
[03:58] <flacoste> BjornT: you mean, include the HTML in the vocabulary label?
[03:58] <flacoste> salgado: we can if you build the vocabulary yourself dynamically
[03:58] <BjornT> salgado: well, that was why i suggested constructing vocabuarly on the fly
[03:58] <BjornT> flacoste: yeah, HTML
[03:59] <flacoste> BjornT: won't it get escaped?
[03:59] <salgado> right, I thought you were suggesting that we shouldn't need to build the vocab on the fly
[03:59] <salgado> looks like there's an example on browser/bugtask.py
[04:00] <salgado> a SimpleTerm whose label contains a hyperlink
[04:00] <flacoste> then it should work
[04:02] <flacoste> so simplest thing is to build the vocabulary at run time
[04:03] <flacoste> you can either register your vocabulary by name or use a IContextSourceBinder to create it using a SimpleVocabulary
[04:04] <flacoste> (you can find a IContextSourceBinder example in interfaces/buglinktarget_browser.py)
[04:04] <bradb> jamesh: When I move an @action into a base class and inherit from that in my view, rendering that @action breaks with an error like "TraversalError: (<zope.formlib.form.Actions object at 0x338c5430>, 'field.actions.submit_bug')". Any idea why actions seem not to work with inheritance?
[04:05] <flacoste> bradb: it's because you defined other actions in your descending class?
[04:05] <salgado> flacoste, I'll do that
[04:05] <salgado> flacoste, BjornT, thanks a lot. I'll pester you guys again if I have any problems. :)
[04:05] <flacoste> bradb: and the @action decorator doesn't cooperate well across classes
[04:05] <bradb> ah
[04:05] <flacoste> bradb: that's should probably considered a bug
[04:06] <flacoste> bradb: there is probably a workaround, hold on
[04:06] <bradb> flacoste: is this the code that breaks it?
[04:06] <bradb>         caller_locals = sys._getframe(1).f_locals
[04:06] <bradb>         if actions is None:
[04:06] <bradb>             actions = caller_locals.get('actions')
[04:06] <bradb>         if actions is None:
[04:06] <bradb>             actions = caller_locals['actions']  = Actions()
[04:06] <flacoste> bradb: yep
[04:06] <flacoste> well, probably
[04:07] <flacoste> you could try declaring actions yourself in the base class:
[04:07] <flacoste> class Base:
[04:07] <flacoste>     actions = Actions
[04:07] <flacoste> that might work
[04:07] <flacoste> actualy, actions = Actions()
[04:07] <flacoste> hmm, no
[04:07] <bradb> hm hm hm
[04:07] <flacoste> that won't work
[04:08] <flacoste> the problem is that it is trying to find the actions for the lexical scope and not from the instance
[04:08] <flacoste> jamesh suggested that should be rewritten to use class advisor
[04:09] <flacoste> the @action works that way is because the class doesn't yet exit when it does it's job
[04:09] <flacoste> s/exit/exists/
[04:09] <bradb> flacoste: so the lex scope of a decorator is the stuff inside the class statement, before the decorator?
[04:09] <flacoste> bradb: yep
[04:09] <flacoste> o!
[04:10] <flacoste> you could probably do in your subclass: actions = BaseClass.actions
[04:10] <flacoste> and stuff would automagically work
[04:10] <bradb> ah, hm hm
[04:10] <bradb> I wonder if it would have that attr at that point. /me tries.
[04:11] <SteveA>  +1 for rewriting using a class advisor
[04:12] <SteveA> any workaround should be marked with an XXX
[04:12] <SteveA> so it can be removed later
[04:12] <bradb> oh yeah. neon sign on this hack.
[04:12] <bradb> i think it's working, but i'm testing it a bit more
[04:13] <bradb> flacoste: seems to work, thanks
[04:31] <elmo> is the fact that LP redirects-of-death if you paste a leading # into the "Jump to a bug" button, known?
[04:32] <kiko> elmo, no, it's a bug. can you file it and assigne it to me?
[04:40] <matsubara> elmo: fwiw, bug 44390; it's not the same issue though
[04:40] <Ubugtu> Malone bug 44390 in malone "Bug number entries should allow "#n"" [Medium,Confirmed]  http://launchpad.net/bugs/44390
[04:42] <salgado> flacoste, to get the browser languages I need the request... is it possible to get it from my vocabulary factory which implements IContextSourceBinder?
[04:43] <flacoste> salgado: hmm, not really, IContextSourecBinder takes only a context argument
[04:45] <flacoste> salgado: and it's the same thing for the Vocabulary, its factory only takes a context object 
[04:45] <salgado> flacoste, yeah... would it be possible to construct the field on the fly, using a LaunchpadFormView?
[04:46] <flacoste> probably in setupFields()
[04:46] <kristog> what is the best way for ask a feature?
[04:47] <flacoste> salgado: and modify the vocabulary attribute of the Choice field there
[04:47] <flacoste> unless that's a read-only attribute...
[04:47] <kristog> open a bug on LP?
[04:48] <carlos> kristog: yeah, that's a good way
[04:48] <matid> Hello. I've got a question regarding the preferred email address in Launchpad. I know that all email coming to launchpad-id@ubuntu.com are delivered to your preferred address. How does Launchpad handle it if you set your preferred address to launchpad-id@ubuntu.com ?
[04:49] <carlos> matid: I guess you will stop getting email
[04:49] <matid> carlos: Really? I don't think so. There are some people with @ubuntu.com email set as their primary one
[04:49] <flacoste> salgado: no, you can probably override the vocabulary in setupFields by storing it in the schema Choice 
[04:50] <flacoste> salgado: kind of hacking to modify the schema at runtime, but an XXX will do :-)
[04:50] <carlos> matid: you will need to check that with elmo or Znarl (our admins) but that would be just canonical people, I'm not sure whether it's handled the same way in that case
[04:51] <carlos> perhaps their sync script detects it and the email alias is not changed
[04:51] <matid> carlos: Ok, thanks
[04:51] <matid> carlos: I'll make sure to contact one of the guys
[04:51] <salgado> flacoste, so, I overwrite setUpFields(), call the parent's setUpFields() and then change the vocabulary of the field I want?
[04:52] <BjornT> flacoste, salgado: i think creating a new Choice field in setupFields would be better.
[04:52] <flacoste> salgado: you should change the schema before calling the parent setupFields
[04:52] <salgado> yeah, that's what I had in mind
[04:52] <doko_> kiko: I rejected jerichorivera from a group in LP, because I didn't know him, and I couldn't send him an email. would it be possibe to get his email address somehow?
[04:52] <flacoste> salgado: because, the parent uses the schema to create the fields
[04:52] <kristog> carlos: thank you.
[04:53] <kristog> bye ;)
[04:53] <salgado> flacoste, ah, right.  what do you think about BjornT's suggestion?
[04:53] <BjornT> salgado: how many fields will there be in the schema?
[04:54] <salgado> BjornT, 4
[04:54] <elmo> matid: if you set your preferred email to be ubuntu.com, your @ubuntu.com email will disappear
[04:54] <flacoste> salgado: creating a new CHoice instead of setting the vocabulary attribute, yeah, that's more obvious
[04:55] <matid> elmo: So people with @ubuntu.com emails as their preferred ones are the ones with ubuntu.com mailboxes?
[04:55] <matid> elmo: I can list dholbach as the example
[04:56] <elmo> matid: this only applies to community people
[04:57] <matid> elmo: Ok, thanks. I guess I'll have to revert the changes I've just made
[04:57] <elmo> matid: this is how it works:  any ubuntu member who has signed the CoC and has a preferred email gets launchpadid@ubuntu.com
[04:58] <elmo> there are a couple of exceptions: (1) if their launchpadid is inappopriate in someway (e.g. 'root' or something), it'll be ignored.  (2) if their preferred email would create a loop in any way (e.g. is launchpadid@ubuntu.com), it'll be ignored
[05:01] <matid> elmo: Ok, thanks for explaining it
[05:01] <matid> elmo: I guess I have to do my best to become Canonical's employee to get the @ubuntu.com mailbox, not an alias :)
[05:08] <elmo> matid: you absolutely can get an @ubuntu.com forwarding address, your launchpad preferred email just has to be something else
[05:09] <tepsipakki> carlos: hi! gnome-screensaver is not set up for accepting translations in LP
[05:09] <matid> I know, I already have the alias
[05:09] <matid> I was just joking that I have to be an ubuntu employee to set it as preferred ;)
[05:10] <carlos> tepsipakki: yes, it is....
[05:10] <carlos> tepsipakki: https://launchpad.net/distros/ubuntu/edgy/+source/gnome-screensaver/+pots/gnome-screensaver
[05:10] <tepsipakki> hmm..
[05:10] <tepsipakki> ok, I went via g-s product page
[05:11] <carlos> tepsipakki: the links between products and distro packages are not always up to date
[05:20] <kiko> carlos, but people can add them!
[05:21] <carlos> kiko: right, but you cannot remove them....
[05:21] <carlos> I think that feature sucks right now..
[05:21] <salgado> flacoste, I'm guessing I need to add a new Choice field to self.schema on setUpFields(). is that right?
[05:22] <flacoste> salgado: hmm, there is a kind of problem with that
[05:22] <flacoste> salgado: because a schema is a global object
[05:22] <flacoste> salgado: so in theory we could get problems if two clients accessed that same code path at the same time
[05:23] <salgado> ahhh, I see
[05:23] <flacoste> salgado: better would be to create a new schema altogether
[05:23] <flacoste> salgado: probably by exending the base schema which would define the common fields
[05:24] <flacoste> salgado: something along: self.schema = type('randomname', bases=(BaseSchema,), choice_field=dynamic_choice)
[05:25] <flacoste> actually, that third parameter should be a dict: type(randomname, (BaseSchema,), dict(choice_field=dynamic_choice))
[05:26] <salgado> flacoste, ah, cool! I'll try that
[05:28] <_thumper_> ddaa: ping
[05:29] <flacoste> BjornT: looks like you're the poor^W lucky fellow who's been assigned to review my big tt-workflow branch
[05:31] <_thumper_> ddaa: going through launchpad-bazaar features - what is importd?
[05:31] <jamesh> _thumper_: ther system used to import CVS and Subversion branches into Bazaar (using cscvs)
[05:31] <salgado> flacoste, hmmm. looks like I got a metatype conflict. :-(TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases)
[05:32] <_thumper_> jamesh: thanks
[05:32] <_thumper_> jamesh: so cscvs does svn and cvs?
[05:32] <jamesh> _thumper_: yes
[05:32] <flacoste> salgado: hmm
[05:32] <_thumper_> what does it stand for?
[05:33] <jamesh> _thumper_: "change set cvs", iirc
[05:33] <_thumper_> jamesh: ok, thanks
[05:33] <flacoste> salgado: what did you use exactly?
[05:33] <salgado> self.schema = type('foo', (self.schema,), dict(languages=languages_field))
[05:34] <jamesh> it originally only handled CVS, and let you group the commits into tree wide change sets (rather than revisions to individual files)
[05:35] <flacoste> salgado: a ok
[05:36] <flacoste> salgado: self.schema metatype is zope.interface.interface.InterfaceClass
[05:36] <flacoste> salgado: so you probably need to create the class using that instead of type()
[05:37] <flacoste> salgado: yep, self.schema = zope.interface.interface.InterfaceClass('foo', (self.schema,), {...}) should do the trick
[05:38] <salgado> yay. it works
[05:38] <salgado> thanks again, flacoste!
[05:41] <stub> cprov-lunch: mawson:~stub/launchpad_prod.20061004.dump
[05:41] <stub> salgado: staging updated, and the script running now. Might be some time...
[05:41] <stub> salgado: I'll run it again tomorrow too after the db update
[05:41] <jamesh> salgado: you'll find it easier to get your code through review if you use a real class ...
[05:42] <salgado> stub, great, thanks
[05:42] <stub> salgado: (The database is two weeks out of sync right now, so hopefully 15:38:39 INFO    Profile with id 76 and name 'name76-merged' has references from the POSubmission or SourcePackageRelease tables and could also have been created by the bugzilla import of Ubuntu bugs.
[05:42] <stub> is spurious
[05:43] <jordi> hey ho
[05:44] <salgado> jamesh, I need to build one of the fields of that schema on the fly.  do you have any suggestions on how to do that instead of doing what flacoste suggested?
[05:45] <salgado> stub, hmmm. if the database is that old it may even be that it already includes the updates from the last time we ran the script on staging... not sure
[05:45] <stub> salgado: I reset the new column to NULL
[05:45] <stub> salgado: Tomorrow will be a clean run anyway.
[05:45] <flacoste> salgado: you could also use exec with string substitutions, but that's slower (that's how we did that kind of thing before new style class)
[05:46] <salgado> exec? that's much more worst, IMHO
[05:46] <jamesh> salgado: try overriding setUpFields, chain to parent and then do "self.form_fields += form.Fields(Choice(...))"
[05:47] <jamesh> salgado: with "from zope.formlib import form" in the imports at the top of the file
[05:48] <jamesh> stub: while you're testing things, could you try running the database/schema/pending/jamesh-collapse-sourceforge-trackers.sql script on staging?
[05:50] <salgado> yeah, it works fine. thanks jamesh!
[05:50] <stub> Isn't there a way to just grab the thread-local request without a reference? The vocab could just do that.
[05:51] <stub> get the interaction, get the request, determine languages, generate the set of allowed values
[05:52] <jamesh> we've got a get_current_browser_request() helper in canonical.launchpad.webapp if that
[05:52] <jamesh> 's what you need
[05:52] <stub> jamesh: Done
[05:53] <flacoste> salgado: the exec suggestion was a joke, but jamesh suggestion is more straightforward
[05:55] <salgado> flacoste, and how about stub's suggestion? I could use get_current_browser_request() to get the request and ILaunchBag to get the user in the vocabulary
[05:55] <flacoste> salgado: yep, that would also work
[05:55] <salgado> that would make things a bit simpler, but I'm not sure if it'd be safe to assume that the request would never be none
[05:55] <Ubug2> New bug: #63990 in malone "Entering a # (hash) in the 'jump to a bug' form leads to redirect-of-death" [Undecided,Confirmed]  http://launchpad.net/bugs/63990
[05:55] <flacoste> salgado: well, i think jamesh suggestion is the simplest because it has the least indirection
[05:56] <ddaa> _thumper_: this sort of question ("what is importd?") is well covered in the doc/bazaar documentation. Maybe you should read that first to get some context for the specs.
[05:56] <jamesh> salgado: so the vocabulary might be empty if there is no request ...
[05:56] <flacoste> salgado: the vocabulary is built at a place where a) it will be used, b) all the information required to build are available directly
[05:56] <_thumper_> ddaa: I found it
[05:57] <stub> salgado: I think that is a perfectly fine invariant if you document it. Developers who use it in non-browser code will just get a StupidProgrammerError
[05:57] <_thumper_> ddaa: reading TheBazaar
[05:57] <flacoste> salgado: c) that vocabulary is very specific to that view
[05:58] <stub> I think we already have vocabularies that do similar for person name changing (or at least we did at one point?)
[05:58] <ddaa> _thumper_: mh, that page is quite outdated too... the illness of wikis
[05:58] <ddaa> they accumulate old cruft nobody cares to maintain or update
[05:58] <salgado> I never heard of such a thing before
[06:00] <salgado> what I have now (jamesh's suggestion) doesn't look too bad and is working fine, so I'll stick with that for now. already played a lot with this thing
[06:00] <flacoste> salgado, kiko: in SupportTrackerViews, we have a view called 'My Queue', and in the Unresolved issues section there is a comment to the effect that My Queue isn't a good name because of the context issue. 
[06:00] <flacoste> salgado, kiko: we have 'Worklist' and 'Needs attention' as better suggestion, which do you prefer?
[06:01] <jamesh> ddaa: you see that the bzr-0.11 stuff landed?
[06:01] <ddaa> jamesh: I do not think I received a commit notification about it
[06:02] <ddaa> nah, it does not appear landed
[06:02] <salgado> flacoste, I think I do prefer Needs attention too, although Worklist may be a better choice in that it makes clear that it's that person's worklist and not yours
[06:02] <ddaa> jamesh: I see your branch in pqm though
[06:03] <jamesh> ddaa: the changes did, but the revision lifeless committed didn't have any merges -- I've just done a trivial commit to merge the history
[06:03] <salgado> flacoste, maybe changing the title if you're looking at your own page could make it less confusing?
[06:03] <flacoste> salgado: do you think we could name it 'Requests that needs my attention' in the product/distro context and 'Requests that needs attention' in the person context?
[06:03] <kiko> flacoste, what does the list present?
[06:04] <ddaa> jamesh: the last commit in sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/bzr/dev/ is dated 2006-07-13 AFAICT
[06:04] <ddaa> ha
[06:04] <jordi> hm, no mpt
[06:04] <flacoste> kiko: the requests that needs an action on the part of the user (logged in user in the product/distro context and that user in the person context)
[06:04] <ddaa> confused
[06:04] <jordi> hmm, no danilo
[06:04] <ddaa> rocketfuel-built parents are not set right
[06:05] <carlos> jordi: he had a power problem a couple of hours ago
[06:05] <ddaa> okay I see a new bzr has landed in rocketfuel
[06:05] <carlos> jordi: I sent an email to warthogs
[06:06] <kiko> flacoste, Requests needing attention?
[06:06] <jamesh> ddaa: perhaps the email didn't go out because it was a manual merge?
[06:06] <ddaa> sure
[06:06] <jamesh> ddaa: and the bzr update appears to be a pull rather than a merge
[06:06] <ddaa> it's a pqm post-commit thing that sends the emails AFAIK
[06:06] <flacoste> kiko: what about Requests needing my attention in the product/distro context?
[06:07] <kiko> "Requests needing my attention in Ubuntu"?
[06:07] <ddaa> jamesh: indeed, looks like a pull
[06:07] <kiko> or "Requests in Ubuntu needing attention"?
[06:07] <ddaa> jamesh: lifeless: well done, thank you
[06:07] <jordi> carlos: okay. I think mpt's changes are good.
[06:08] <carlos> jordi: go, go, go
[06:08] <jordi> carlos: should I send to kde, gnome and our two lists?
[06:08] <carlos> hmmm
[06:08] <jordi> carlos: or should I post this in the public wiki and point people at it?
[06:08] <flacoste> kiko: that's fine for a title, but not for the action menu
[06:08] <carlos> jordi: I think we should have in our website so we can point people to it later
[06:09] <jordi> carlos: which website? :)
[06:09] <jordi> There's so many
[06:09] <carlos> jordi: also, check with Riddell how to send the answer to KDE
[06:09] <carlos> jordi: I don't know... wiki.ubuntu.com ?
[06:09] <flacoste> salgado: tt-workflow has a conflict because of the merging of PersonCreationRationale
[06:09] <flacoste> salgado: what's the code I should use?
[06:09] <carlos> jordi: that document is quite Ubuntu specific
[06:09] <flacoste> salgado: (for the janitor robot)
[06:09] <carlos> jordi: about GNOME, I guess danilo should handle it, he asked to do it
[06:09] <salgado> flacoste, ah, the creation_rationale, you mean?
[06:10] <flacoste> salgado: yep
[06:10] <jordi> carlos: aha. I actually thought he prefered someone else doing it.
[06:10] <carlos> jordi: me too, but we talked about it and he said that he will handle that request
[06:11] <salgado> flacoste, you can use UNKNOWN for now, I think. can you also file a bug asking for a new rationale to be created for our bots and assign it to me?
[06:11] <salgado> I'll take care of updating any existing robots when I get to fix it
[06:11] <flacoste> salgado: ok, UNKNOWN is what was used for the bugwatch updater?
[06:12] <salgado> flacoste, I didn't use any rationale explicitly, but since it won't be updated by the guess-rationale script, that's the rationale it'll end up with
[06:13] <jordi> carlos: okay.
[06:13] <jordi> I'll mail 3 lists.
[06:14] <jordi> carlos: either wiki.ubuntu.com or features.lp.net. I don't know what kind of stuff is supossed to go in features.
[06:14] <jordi> is there any other public wiki about launchpad?
[06:14] <carlos> features?
[06:14] <jamesh> jordi: help.launchpad.net
[06:14] <jordi> help, yeah
[06:14] <carlos> jordi: dude, that's the spec website
[06:15] <jordi> I know
[06:15] <carlos> jordi: that's not a wiki...
[06:15] <jordi> I mean, there's so many places I get in trouble trying to make sense out of it :)
[06:15] <jordi> ok :P
[06:15] <carlos> jordi: well, help.launchpad.net is for help about launchpad
[06:15] <carlos> this is an answer about the concerns related to Ubuntu translations
[06:15] <jordi> is this a "help" document? I don't think.
[06:16] <carlos> it affects Launchpad but also the way Ubuntu teams work
[06:16] <jordi> ok, let's go wiki.ubuntu.com then
[06:19] <jordi> carlos: ok, posted in https://wiki.ubuntu.com/RosettaKDECollaboration
[06:19] <jordi> just after pressing Send, I realised we could have used a more generic name. I think I should rename it.
[06:19] <jordi> RosettaAndUpstreamCollaboration?
[06:20] <carlos> yeah
[06:20] <carlos> that's what I was going to ask you
[06:20] <carlos> jordi: thanks
[06:21] <jordi> heh
[06:21] <jordi> ok, announcing
[07:42] <flacoste> salgado: bug 64010 is the missing enum value
[07:48] <salgado> flacoste, you need to subscribe the launchpad team to that bug
[07:48] <salgado> (I have no rights to see it)
[07:48] <flacoste> bradb: how come that wasn't done automatically when I turned the confidential flag on?
[07:49] <bradb> flacoste: I'd have to be able to read the bug report to see
[07:50] <flacoste> salgado, bradb: done, I subscribed Launchpad Developers 
[07:52] <matsubara> flacoste: there's a explanation from jamesh here: https://launchpad.net/bugs/59846
[07:52] <Ubugtu> Malone bug 59846 in malone "We need a script to fix the subscribers of private bugs" [Undecided,Confirmed]  
[07:53] <flacoste> ok, then it's a new bug
[07:53] <matsubara> but apparently when you report a bug as private no one but yourself is subscribed to it
[07:53] <flacoste> matsubara: i didn't report it as private
[07:53] <flacoste> i filed it as a public bug, and then change the visibility
[07:54] <flacoste> bradb: is this a new bug? I though implicit subscribers were subscribed explicitely when the visibility was changed?
[07:54] <bradb> flacoste: hrm, I'm trying to figure out why launchpad-security wasn't subscribed to it
[07:54] <bradb> oh, you turn the flag on after the fact...
[07:55] <flacoste> bradb: what I did was: i) +filebug (didn't check the security flag'; ii) change status/assignee; iii) marked bug confidential
[07:58] <flacoste> bradb: so should I file a bug about this?
[07:58] <bradb> flacoste: yeah, that is weird
[08:00] <bradb> flacoste: i think i know what it is...
[08:01] <bradb> flacoste: the forms were converted to LaunchpadEditFormView
[08:01] <bradb> and SQLObjectToBeModifiedEvent got lost in the shuffle
[08:01] <bradb> the subscriber that listens for that doesn't get fired
[08:01] <bradb> so, no implicit -> explicit conversion
[08:02] <bradb> the tests publish that event when they test it
[08:02] <bradb> (make_subscriptions_explicit_on_private_bug is the subscriber in question)
[08:04] <bradb> the simple fix would be to publish SQLObjectToBeModifiedEvent in the base edit form view, like our previous base edit form used to do
[08:10] <Ubugtu> New bug: #64015 in launchpad "mail on new packages uploaded" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64015
[08:11] <carlos> cprov: hi
[08:11] <carlos> cprov: around?
[08:11] <cprov> carlos: yes
[08:11] <carlos> cprov: just for your information
[08:12] <bradb> flacoste: basically, the bug edit form was converted to LaunchpadEditFormView, and stopped publishing SQLObjectToBeModifiedEvent along the way, so the relevant event sub is not getting fired.
[08:12] <carlos> production had the required conditions to debug the problem between Rosetta and buildd since yesterday
[08:12] <carlos> cprov: we got a new OO.org build
[08:12] <bradb> flacoste: the tests publish that even when the test it
[08:12] <carlos> cprov: did you see any buildd breakage?
[08:12] <flacoste> bradb: ok, so I should file a new bug
[08:12] <bradb> flacoste: the easy fix should be to just publish that event in LaunchpadEditFormView
[08:13] <bradb> flacoste: yes please!
[08:13] <flacoste> bradb: a better fix is to use a mutator and remove the SQLObjectToBeModifiedEvent hack
[08:13] <cprov> carlos: no, but were the fixes rolled out ?
[08:14] <carlos> cprov: hmm that's a good question...
[08:14] <carlos> let me check
[08:14] <cprov> carlos: I guess we were lucky ;)
[08:14] <bradb> flacoste: yeah. i just suggested the one-line fix. .setPrivate would take somewhat more effort.
[08:14] <carlos> cprov: yeah... dammit...
[08:14] <carlos> :-(
[08:14] <bradb> well, "one-line", plus 30 more to test it
[08:15] <flacoste> bradb: a page test would catch that bug
[08:15] <bradb> yeah
[08:15] <bradb> that's the 30 lines i'm thinking of, mostly narrative
[08:16] <cprov> carlos: it's fine, if I have the change I try it in dogfood tomorrow, but as far as it doesn't break, we won't be blamed (much)
[08:17] <carlos> cprov: ;-)
[08:17] <flacoste> bradb: bug 64017
[08:17] <Ubugtu> Malone bug 64017 in launchpad "Setting a bug confidential after its creation creates a ghost bug" [Undecided,Confirmed]  http://launchpad.net/bugs/64017
[08:18] <bradb> thanks
[08:26] <Ubugtu> New bug: #64017 in launchpad "Setting a bug confidential after its creation creates a ghost bug" [Undecided,In progress]  http://launchpad.net/bugs/64017
[08:46] <salgado> kiko, don't forget me! (and my diff :-)
[08:53] <jdong> how are manual uploads for dapper-backports set up?
[08:54] <jdong> are core-devs able to manually upload to dapper-backports?
[08:58] <salgado> flacoste, have you noticed that after doing a search for tickets you get kicked out of the support facet (meaning that the "Support" link is not greyed out in the menu)?
[08:58] <salgado> (https://staging.launchpad.net/distros/ubuntu/+tickets)
[08:58] <flacoste> salgado: yeah
[08:58] <salgado> do you know what causes that?
[08:58] <flacoste> because of the extra params
[08:58] <salgado> it doesn't seem to happen in production
[08:58] <salgado> or am I crazy?
[08:58] <flacoste> it doesn't?
[08:59] <flacoste> it does also in production
[08:59] <salgado> not for me
[08:59] <flacoste> it does here
[08:59] <flacoste> https://launchpad.net/distros/ubuntu/+tickets?field.search_text=&field.sort=by+relevancy&field.sort-empty-marker=1&field.actions.search=Search&field.status=Rejected&field.status-empty-marker=1
[08:59] <salgado> weird... in production the link gets greyed out but it's still a link
[09:00] <salgado> in staging it's not greyed out
[09:00] <flacoste> salgado: here, it's not greyed out in production, it is highlighted though
[09:00] <flacoste> https://launchpad.net/distros/ubuntu/+tickets
[09:00] <flacoste> that one is greyed out and highlighted
[09:00] <flacoste> the other is just highlighted
[09:01] <salgado> yeah, that's what I meant. :)
[09:03] <flacoste> salgado: i assume it is quirks of the facet recognition code
[09:08] <kiko> hmmm
[09:08] <kiko> no gcc on devpad?
[09:08] <kiko> that kind of ruins my plans
[09:08] <elmo> ?!
[09:08] <elmo> why would you want gcc on devpad?
[09:08] <kiko> elmo, well, launchpad depends on some C modules that need to be compiled first.
[09:09] <kiko> elmo, I was hoping to write a script that used launchpad to query the staging database from devpad
[09:09] <kiko> since it's the only box I have access to that can query asuka
[09:09] <elmo> oh
[09:09] <kiko> yeah.
[09:09] <kiko> I used to be able to do it on mawson so I was assuming it would work
[09:09] <elmo> mawson's a dogfood/trash box, it has half the known world installed
[09:10] <kiko> yeah :)
[09:10] <elmo> anyway, your use case is reasonable, I just don't want devpad turned into a general LP compile box for developers
[09:10] <elmo> if you RT it, I can install launchpad-dependencies
[09:10] <kiko> I'll do so.
[09:18] <SteveA> flacoste: please file bugs and tell me about bugs in facet code
[09:19] <SteveA> or bugs in facet display
[09:19] <flacoste> salgado: ^^^
[09:19] <flacoste> SteveA: i'm not sure it's a bug actually
[09:19] <SteveA> I'm working on this code for the 1.0 UI
[09:19] <SteveA> if someone files it as a bug, I can look into it and find out
[09:19] <salgado> I think it is
[09:19] <salgado> will file
[09:19] <SteveA> if it's weird, it's probably a bug :-)
[09:19] <SteveA> thanks
[09:29] <salgado> SteveA, bug 64026
[09:29] <Ubugtu> Malone bug 64026 in launchpad "Menu links seem to get disabled only if request.URL == menuitem.url" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64026
[09:35] <Ubugtu> New bug: #64026 in launchpad "Menu links seem to get disabled only if request.URL == menuitem.url" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64026
[09:39] <bradb> BjornT: do you have time to review a small, but critical patch?
[09:41] <kiko> salgado, how does localhost.dev work for you if it lacks a port number?
[09:42] <salgado> kiko, iptables -t nat -A OUTPUT -p tcp -d $LPIP --dport 80 -j DNAT --to 127.0.0.1:$LPPORT
[09:42] <kiko> you have got to be joking
[09:42] <kiko> salgado, and you run that for all boxes?
[09:42] <kiko> my box has a local apache
[09:43] <kiko> I guess it's just LPIP that's affected
[09:43] <salgado> yep
[09:43] <salgado> LPIP=$(grep launchpad.dev /etc/hosts | perl -pe's/^([^ ] +).*$/$1/')
[09:44] <bradb> kiko: do you have time for a quick review to fix bug 64017?
[09:44] <Ubugtu> Malone bug 64017 in launchpad "Setting a bug confidential after its creation creates a ghost bug" [Critical,In progress]  http://launchpad.net/bugs/64017
[09:45] <kiko> bradb, not right now, perhaps after 6.
[09:45] <Ubugtu> New bug: #64029 in launchpad "XML/RSS of cdimage mirror status" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64029
[09:45] <bradb> ok, i'll just put it up for review and nag people after the meeting tomorrow
[11:23] <kiko> matsubara, I'm having a hard time changing a foaf test 
[11:24] <matsubara> oh
[11:24] <matsubara> kiko: I touched 1 foaf test today
[11:24] <kiko> have you ever written a test for posting to +member/ ?
[11:24] <matsubara> damn it!
[11:24] <kiko> matsubara, I'm trying to convert 27-*
[11:24] <matsubara> hmm
[11:25] <matsubara> mine was 22
[11:25] <kiko> matsubara, so I can't seem to deactivate the user!
[11:25] <kiko> anyway, bbiab, meeting now
[11:25] <matsubara> are you fixing the same bug as I am?
[11:25] <kiko> https://launchpad.net/products/launchpad/+bug/57300
[11:25] <Ubugtu> Malone bug 57300 in launchpad "AssertionError while approving a team membership with a expiry date in the past." [Low,Confirmed]  
[11:26] <matsubara> ugh!
[11:26] <ddaa> yay, the new svn changeset logic just gave support for all the simple cases of replacement, with no additional logic!
[11:26] <matsubara> kiko: well, I converted and reproduced that bug in foaf/22-*
[11:27] <matsubara> and was trying to fix it, but...
[11:27] <ddaa> when you write a test for the simplest case, then realise that you do not need any more test because it covers it all by design, you know you've got it right!
[11:27] <ddaa> svn imports that actually work, soon in all the best Launchpads near you
[11:35] <flacoste> a user posted a request for merge in launchpad-support-tracker
[11:35] <flacoste> https://launchpad.net/products/launchpad-support-tracker/+ticket/1541
[11:36] <flacoste> kiko, or anybody else with admin power ^^^
[11:38] <matsubara> flacoste: good catch, altough I can't do the merge I'll subscribe the qa as the support contact for the lp-support-tracker
[11:38] <flacoste> matsubara: great
[11:38] <flacoste> matsubara: who has the privileges to fix that request?
[11:40] <matsubara> anyone on launchpad.net/people/admins
[11:40] <matsubara> but usually SteveA or kiko handles that
[11:40] <matsubara> flacoste: ^
[11:40] <flacoste> ok, thx
[11:42] <matsubara> kiko: https://sodium.ubuntu.com/~andrew/paste/fileJjDXi9.html