[12:05] <sabdfl> zyga: there's a gazillion fixes for the poll stuff landing tomorrow or wednesday
[12:05] <zyga> sabdfl: cool thanks
[12:47] <Kinnison> blargh
[12:47] <cprov> Kinnison: hey, go to bed !
[12:48] <Kinnison>     TypeError: DBSchema Item from wrong class, <class 'canonical.lp.dbschema.PackagePublishingPocket'> != <class 'canonical.lp.dbschema.PackagePublishingPocket'>
[12:48] <Kinnison> WTF?!
[12:49] <cprov> Kinnison: ehe, almost finished dep-aware ... missing dependency clause (<<, <, =) .. will do it tonight at home
[12:49] <Kinnison> cprov: cool
[12:49] <Kinnison> anyone awake who knows about dbschemas?
[12:50] <cprov> Kinnison: dbschema is tricky you should compare the values attributes not the class itself
[12:50] <Kinnison> cprov: this exception is coming from EnumCol
[12:50] <Kinnison> What's wierd is that it should be a DistroReleaseQueueStatus object
[12:51] <cprov> Kinnison: strange, let's sort it tomorrow, sleep well ...
[01:31] <JulioH> epale
[01:55] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  fix MAIL FROM to be the standard bounce address. fixes https://launchpad.net/products/malone/+bug/2593 (patch-2669: brad.bollenbach@canonical.com)
[02:09] <spiv> Kinnison: That's unlikely to be a EnumCol-specific issue.
[02:09] <spiv> Kinnison: More likely to be that you've somehow imported that module from two different locations.
[02:10] <spiv> Kinnison: e.g. if you aren't careful with sys.path, doing relative and absolute imports can cause that.
[02:12] <spiv> Kinnison: Just before that error is raised, log the id of the two classes, and maybe also the .__module__ of them.
[02:30] <Kinnison> spiv: it's security proxying
[02:31] <Kinnison> sodding enumcol was using identity
[02:34] <spiv> Aah.
[03:09] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Many fixes related to language packs and po exports and fixed as a side effect bug 1419 [r=SteveA and others trivial]  (patch-2670: carlos.perello@canonical.com)
[05:16] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Do not access Foo._defaultOrder from other classes; use a public name instead (patch-2671: guilherme.salgado@canonical.com)
[05:31] <stub> wiki authentication and launchpad will be offline for approx. 20 mins in 15 minutes time unless anyone feels like bitching
[05:33] <stub> spiv: Any Librarian or Authserver changes that require a rollout?
[05:34] <spiv> stub: Nope.
[05:34] <spiv> Well, not that I know of ;)
[05:35] <spiv> Which is good, because I'm about to grab some lunch ;)
[05:35] <stub> spiv: I have changes in LaunchpadGarbageCollection so I'll stuff that in your queue when I get a chance to polish off the first half
[05:36] <spiv> stub: Sounds good
[06:28] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  fix IBug.findCvesInText() and add test, allow setting datecreated in IMessageSet.fromText() (patch-2672: james.henstridge@canonical.com)
[07:08] <jamesh> auto-link code seems a bit to eager
[07:09] <jamesh> "debug 123" going to "de<a href=...>bug 123</a>"
[07:09] <Ubugtu> Malone bug #123: There's no direct way to see the project info when translating it Fix req. for: rosetta (upstream), Severity: Normal, Assigned to: Nobody, Status: Fixed http://launchpad.net/malone/bugs/123
[07:12] <Keybuk> weird, my test failed with "Connection Refused" in a piece of code I didn't go near!
[07:35] <jamesh> hi BjornT 
[07:35] <BjornT> hi jamesh 
[07:36] <jamesh> BjornT: I've got the basics of the bugzilla->Malone importer mostly working
[07:37] <jamesh> it was really easy to write with the Malone APIs
[07:37] <BjornT> cool, nice to hear
[07:38] <jamesh> need to handle migration of attachments, milestones and a few other fields
[07:40] <BjornT> when do you think it will be finished?
[07:41] <jamesh> Hopefully we can run a test import on staging by the end of the week
[07:41] <jamesh> one thing I've punted is rewriting "bug XYZ" bits in comments
[07:41] <jamesh> which is difficult :)
[07:43] <BjornT> ah, true, i can see it being a problem
[07:52] <jamesh> at the moment, the information I'm not handling include: operating system, platform, version, milestone, keywords, bug relationships, privacy and attachments
[08:05] <jamesh> none of the canonical-only bugs on bugzilla.ubuntu.com really look sensitive ..
[08:09] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=stevea]  kill the sourcerer twin (patch-2673: scott@canonical.com)
[08:10] <Keybuk> oh, see, it works now
[08:18] <jamesh> Keybuk: did it die in one of the cscvs tests before?
[08:18] <Keybuk> something like that
[08:18] <Keybuk> connection refused
[08:20] <jamesh> those tests occasionally fail, which is annoying (probably bad cleanup or something)
[08:37] <Keybuk> someone who knows zope ... is it possible for a class to implement two interfaces?
[08:38] <spiv> Yes.
[08:39] <Keybuk> excellent
[08:39] <Keybuk> I'm considering adding an IPathable or something (I need a better name) to some of the database classes which will add followPath, constructPath and resolvePath functions
[08:40] <Keybuk> and moving all of the hct "URL" code into there
[08:40] <spiv> As "pydoc zope.interface.implements" could tell you :)
[08:40] <Keybuk> (out of the big hctapi functions)
[08:40] <Keybuk> spiv: that would involve knowing that thing
[08:40] <Keybuk> I know more about ancient japanese suicide rituals than I do about zope
[08:44] <ajmitch> knowing those rituals is always handy when learning zope
[08:47] <jamesh> ajmitch: you don't have the zope nature
[08:47] <ajmitch> which is?
[08:49] <spiv> ajmitch: zope 2?
[08:50] <jamesh> zope 3 is a lot nicer to work with
[08:50] <ajmitch> spiv: yes, I've just started digging into zope 3
[08:50] <ajmitch> and I agree, zope 3 does look a lot nicer
[08:50] <spiv> Right.  Zope 3 is a much more pleasant experience.
[09:06] <Keybuk> I'm told that falling on one's sword is actually quite a pleasant experience
[09:06] <Keybuk> you don't have much in the way of nerves, and usually cut your backbone anyway if you do it right
[09:06] <Keybuk> so there's not much pain
[09:06] <Keybuk> and the feeling of all your blood pouring out of your body is quite euphoric
[09:08] <sivang> hmm
[09:08] <sivang> MOrning all btw
[09:09] <sivang> Keybuk: sounds interesting :)
[09:09] <spiv> Keybuk: The trick with distrowatch is to remember to add in the kubuntu and edubuntu numbers too ;)
[09:09] <spiv> oops, ww.
[09:10] <Keybuk> spiv: they're both small-fry
[09:14] <SteveA_> Keybuk: i'm not so keen on 'IPathable' being implemented directly in the database code
[09:14] <SteveA_> it's a 'presentation' thing
[09:14] <SteveA_> like saying what URL something is at in the web application
[09:15] <SteveA_> so would be better done as some adapters, i think
[09:15] <SteveA_> but, if you want to do it directly in the database code, then provided it has a clean interface
[09:15] <SteveA_> we can refactor later if needed
[09:16] <SteveA_> also, the malone email UI has its own concept of 'pathable'
[09:16] <SteveA_> which is different from the hct one
[09:16] <SteveA_> which also suggests keeping them both out of being directly in the database is good
[09:17] <Keybuk> SteveA_: how would you do it; right now it's three huge functions which rely on isinstance
[09:17] <Keybuk> which just seems wrong
[09:17] <Keybuk> what comes next in a URL is directly related to the type; so putting it in the code for that type seems "proper"
[09:24] <SteveA_> adapters
[09:24] <SteveA_> but, i must have a lithuanian lesson now
[09:24] <SteveA_> we can talk about it a bit later.
[09:26] <Lathiat> what does a '_' in a url actually signify
[09:26] <Lathiat> err, a +
[09:27] <Keybuk> SteveA: ok, I don't expect to start implementing it this morning
[09:31] <jamesh> Lathiat: we use it to avoid namespace collisions
[09:32] <Lathiat> jamesh: in what way?
[09:32] <jamesh> Lathiat: things like usernames, etc can not begin with a plus, so if we create a page that begins with a plus then it won't ever collide with a name
[09:32] <Lathiat> jamesh: ah ok
[09:33] <Lathiat> i guess the +newteam page is wrong then
[09:34] <jamesh> why?
[09:34] <Lathiat> oh actually not
[09:34] <Lathiat> it can contain a +, just not start with one
[09:35] <jamesh> /people/+newteam is safe because you can't create a person or team called "+newteam"
[09:35] <Lathiat> jamesh: yeh sorry i meant the comment on the newteam page
[09:35] <Lathiat> i didn't see the separation between starts with and contains
[10:06] <stub> SteveA: I already did the production rollout today as I wanted the DB down during the quiet time. I'll land other fixes as cherry picks when they come in.
[10:07] <stub> Gina had issues - I was hoping to have fixed them already but baz was taking ages pulling down kiko's branch
[10:48] <sabdfl> Failure in test test_simple_sendmail (canonical.launchpad.mail.ftests.test_stub)  
[10:48] <sabdfl> bugger
[10:49] <sabdfl> stub: any idea what b0rked my landing?
[10:49] <sabdfl>   Expected:      'nobody@example.com'  Got:      'nobody1@example.com'  
[10:49] <sabdfl> that was the only test failure
[10:49] <stub> nope. I havn't touched that code for months and months.
[10:53] <stub>     >>> from_addr, to_addrs, raw_message = stub.test_emails.pop()
[10:53] <stub>     >>> if from_addr == 'nobody1@example.com':
[10:53] <stub>     ...     from_addr, to_addrs, raw_message = stub.test_emails.pop()
[10:53] <stub>     >>> from_addr
[10:53] <stub>     'nobody@example.com'
[10:54] <stub> sabdfl: Maybe that 'if from_addr' needs to become a loop? It looks like there are a number of emails, and the one it is looking first might not be the first. That test might fail if there happen to be three emails in the test_emails list.
[10:54] <jamesh> is it possible to temporarily disable zope event handlers?
[11:02] <WaterSevenUb> does anyone know why about-ubuntu firefox welcome page does not use the translated about-ubuntu that is available through help?
[11:02] <WaterSevenUb> zyga, hi there.
[11:02] <zyga> WaterSevenUb: hey, how are you :)
[11:02] <SteveA_> jamesh: what do you want to do?
[11:02] <zyga> WaterSevenUb: AFAIR there were some technical difficulties and some people were working on it
[11:03] <SteveA_> stub: okay, so you've done a production roll-out, and i can prepare my fixes for a cherry pick.  what happened with gina on staging exactly?
[11:05] <WaterSevenUb> launchpad error: ProgrammingError
[11:05] <WaterSevenUb> A server error occurred. 
[11:05] <jamesh> SteveA_: prevent email from going out while manipulating bugs
[11:06] <SteveA_> oh, like in a conversion script, for example?
[11:06] <SteveA_> so you just want to send the mail to /dev/null
[11:06] <sabdfl> errr stub, you already did the production rollout? without my code?
[11:06] <jamesh> yeah
[11:06] <SteveA_> jamesh: let me think for a minute
[11:07] <jamesh> SteveA_: I could imagine it being useful within Launchpad too, if we ever have a "mass change bugs" UI
[11:08] <jamesh> something like bugzilla's "change multiple bugs at once", but without the spam
[11:08] <sabdfl> stub, SteveA_: i need to get cracking on UBZ matter, am already a day overdue from yesterday's PQM slowness and gina
[11:08] <sabdfl> can i ask you to land my branch please?
[11:08] <SteveA_> jamesh: there's a difference between turning certain events off for your script, and turning them off during some processing of the webapp
[11:08] <SteveA_> sabdfl: yes
[11:08] <sabdfl> it's reviewed, and tests pass locally
[11:08] <SteveA_> sabdfl: i can land your branch today.  what's the information i need?
[11:09] <sabdfl> mark.shuttleworth@canonical.com/launchpad--newpackageclasses--0
[11:09] <SteveA_> what patch level are you up to?
[11:09] <sabdfl> 41
[11:09] <sabdfl> i won't do further work on that branch
[11:09] <jamesh> SteveA_: yep.  Doing it for the script is the important bit
[11:09] <SteveA_> mark.shuttleworth@canonical.com/launchpad--newpackageclasses--0
[11:09] <SteveA_> got it
[11:10] <SteveA_> and, it is as you want it, review comments included
[11:10] <sabdfl> i have tagged off kiko's launchpad and will work on gina again later, once kiko is back so we can talk about it
[11:10] <SteveA_> and just has an issue with unrelated flaky tests
[11:10] <sabdfl> SteveA_: yes, precisely
[11:10] <carlos> morning
[11:10] <sabdfl> jamesh: can we talk about the schedul-o-matic?
[11:10] <SteveA_> okay.  i'll handle it, and sms you if there are serious problems
[11:12] <sabdfl> SteveA_: cool, thanks very much
[11:12] <sabdfl> SteveA_: best get in there before the pqm queue grows again
[11:17] <sivang> sabdfl: I can email -devel with the preferred LP spec/bof registeration instructions (As you described to me yesterday) if you like, so LP can start to have them in.
[11:17] <SteveA_> jamesh: for your script, we can just ensure that those event subscribers are not registered.   for a more general, and multi threaded app, we need to add an 'event channel' that has the behaviour we need.
[11:18] <stub> SteveA: you handling marks branch?
[11:18] <sabdfl> sivang: go for it
[11:19] <sabdfl> i'll follow up with more detail, but it would be great for you to get the ball rolling. thanks!
[11:19] <SteveA_> stub: yes
[11:19] <stub> SteveA: I'll send my (work in progress) gina email
[11:19] <SteveA_> stub: are you planning to cherrypick mark's branch, or to roll out again from RF ?
[11:19] <sivang> sabdfl: my pleasure :)
[11:20] <Kinnison> SteveA_: the kwargs comments you had
[11:20] <Kinnison> SteveA_: do you really want me to list every argument in full in those functions?
[11:20] <SteveA_> Kinnison: yes.
[11:20] <Kinnison> SteveA_: yeesh. Oookay, but yeesh
[11:21] <stub> SteveA: I'll cherry pick Mark's branch
[11:21] <SteveA_> Kinnison: we did the kwargs thing before.  in a few months, it will be a mysterious piece of code
[11:21] <SteveA_> and it will be totally non-obvious what it does
[11:22] <SteveA_> it was a maintenance disaster, and took a lot more effort to fix than anyone expected
[11:22] <SteveA_> so, i'm rather apprehensive about usint **kwargs now
[11:23] <Kinnison> just seems large and wasteful to me, but okay
[11:31] <WaterSevenUb> zyga, you are using breezy in Polish, right? Do you have the "Translate this application..." translated let us say in synaptic, for example... Is it translated in firefox too?
[11:32] <WaterSevenUb> zyga, in the "Help" menus. In my firefox this strings appear in english whereas in other applications appear translated.
[11:37] <zyga> WaterSevenUb: yes
[11:37] <zyga> WaterSevenUb: checking
[11:38] <zyga> WaterSevenUb: ha, it's not translated
[11:38] <zyga> good catch WaterSevenUb 
[11:38] <zyga> WaterSevenUb: I'll ask mvo
[11:40] <zyga> WaterSevenUb: we're in the subject #u-devel
[11:40] <WaterSevenUb> zyga, I'm watching.... ;)
[11:50] <looksaus> I'm looking for a description of planned Launchpad features regarding bounties
[11:50] <looksaus> is there a public document describing those?
[11:51] <Kinnison> SteveA: in a class definition, does PEP8 want spaces here or not:
[11:51] <Kinnison> class Foo:
[11:51] <Kinnison>    bar = 10
[11:51] <Kinnison>       ^ ^
[11:54] <Kinnison> Anyone? ^^
[11:57] <Kinnison> I'm gonna assume "yes" given my reading of PEP8
[11:58] <stub> yes
[12:00] <SteveA> looksaus: i don't think we have anything written up about bounties.  if you're interested, you can see what launchpad already does, write some notes on the wiki, register it in launchpad as a spec.
[12:00] <SteveA> Kinnison: what stub said
[12:01] <SteveA> it also wants a blank line above  bar = 10
[12:01] <looksaus> register in launchpad as 
[12:01] <looksaus> oops, sorry
[12:01] <Kinnison> SteveA: yeah, but that's not what I was asking :-) Thanks
[12:02] <looksaus> k, will do
[12:06] <SteveA> ddaa: would baz get any faster if i nuked my revlib?
[12:06] <ddaa> hell no!
[12:07] <ddaa> good hardlinking is the key to a fast baz with launchpad code
[12:07] <ddaa> library-relink, "baz diff -s --link", and fl-cow
[12:07] <sivang> I'm getting "Constraint not satisfied" error on https://launchpad.net/products/ubuntu/+addspec
[12:08] <sivang> I am trying to register "OneClickI18n" from the BOFs list at the wiki
[12:08] <sivang> the complaint is about that name, "OneClickI18n"
[12:08] <sivang> is there something wrong with naming a spec like this?
[12:11] <SteveA> ddaa: okay, where can i read how to do this?
[12:12] <sivang> eh, it won't accept the wiki name. just lowered case with dashes between words
[12:12] <SteveA> sivang: that error message should be improved
[12:12] <SteveA> maybe file a bug on it?
[12:12] <ddaa> SteveA: https://wiki.launchpad.canonical.com/LaunchpadHackingFAQ#head-7ede78aa7deeb4b4c9e649ad7bf58422279436f6
[12:12] <sivang> SteveA: will do that, sure
[12:13] <ddaa> SteveA: there's no documentation about the fl-cow stuff in the FAQ, I do not use it personally, it's lifeless' turf.
[12:13] <ddaa> I'm using hardlinked trees, though.
[12:21] <Kinnison> Is there a way to get pqm to fail given I know it'll eventually fail
[12:22] <Kinnison> I.E. can I force it to give up now?
[12:23] <SteveA> has it already started on your job?
[12:28] <Kinnison> yeah, Znarl fixed it for me :-)
[12:35] <Kinnison> Znarl|Saville
[12:36] <Znarl> Kinnison : Hello?
[12:49] <Lathiat> hrm, https://launchpad.net/people/motu/+assignedbugs is throwing back ReuestExpired/A server error occured errors
[12:49] <sabdfl> Znarl: could you point isv@ubuntu.com to mdy@ubuntu.com please?
[12:51] <Znarl> sabdfl : I don't have access to email yet.
[12:52] <sabdfl> could you ask elmo to do it, or create an RT entry for it please? the address is already live on my wiki page, be a bummer for it to bounce :-)
[12:52] <Znarl> Yep, will do.
[12:52] <sabdfl> thankee muchlee
[12:56] <mpt> Gooooooooooood morning
[12:57] <ajmitch> morning mpt 
[01:00] <Keybuk> ok, where's bradb?!
[01:00] <Keybuk> please don't tell me that Malone is going to send every "Ubuntu Development Team" bug to every single ubuntu developer's personal mailbox
[01:01] <Kinnison> only if noone has set a team email address
[01:01] <Keybuk> but the team address also stops things like the "Someone wants to join" reports, no?
[01:01] <sabdfl> moin moin mpt
[01:02] <Kinnison> Keybuk: those go to the owner/moderators iirc
[01:02] <Keybuk> seriously, if you don't see the problem here, subscribe to ubuntu-bugs for a day
[01:02] <matsubara> good morning!
[01:03] <Keybuk> Kinnison: how do I change that e-mail address?
[01:04] <Keybuk> This team has no contact email address. This means that Launchpad notifications directed to this team will be sent to each one of its members.
[01:04] <Keybuk> ... that doesn't say what kind of notifications?
[01:04] <Keybuk> is that the one I want?
[01:07] <BjornT> Keybuk: yes, that's the one. this will be improved with PackageSubscriptions and ProductSubscriptions, where you can choose if you want to subscribe to bugs or not.
[01:08] <Keybuk> is there any way to just set it to a null address?
[01:09] <BjornT> you mean, don't send any notifications at all? i don't think so, but you could ask salgado about it.
[01:17] <cprov> hi, I got a strange error from PQM yesterday, my merge failed in test_simple_mail. Has someone received something similar ?
[01:17] <SteveA> cprov: yes
[01:17] <SteveA> i'm looking into it at the moment
[01:17] <SteveA> i can reproduce it sometimes
[01:17] <SteveA> if i run all the tests, and then just that test alone, i get the error
[01:17] <SteveA> i'm going to improve that test
[01:18] <cprov> SteveA: I've never catched it, requested the merge again let's see if it works, otherwise will wait yours, thank you 
[01:19] <SteveA> yeah, it's one of those tricky errors
[01:21] <ddaa> Hey SteveA, is there a way to clear some tables of sampledata before running some tests?
[01:22] <SteveA> why would you want to do that?
[01:22] <ddaa> I'm annoyed by the non-locality of sampledata affecting many tests in many different places. I'd much prefer my tests to set up their own Branch etc. object or explicitely call a method that sets the sample data I need for the test.
[01:23] <ddaa> So, I may just remove the sampledata, but kiko says it's useful to the manual Q&A people.
[01:23] <SteveA> you can modify sample data within a test
[01:24] <ddaa> That may need privs not available normally, like dropping rows in table where that's not normally possible.
[01:24] <SteveA> can you just be additive?
[01:25] <SteveA> you could add a special db user for that test's setup
[01:25] <SteveA> but it is better if you can add your own stuff
[01:25] <salgado> stub, just to make sure.. the shipit export is scheduled to wednesday 0h UTC, right?
[01:25] <ddaa> That's awkyard to be only additive, since the sampledata (which I mostly just ugraded) already touches many convenient things, like "Sample User".
[01:25] <mpt> BjornT: Do you have any idea when PackageSubscriptions and ProductSubscriptions will arrive?
[01:26] <ddaa> SteveA: but I guess that's what I'll have to do.
[01:26] <ddaa> SteveA: BTW, I was wondering at whether the passwords for the sampledata users were documented somewhere?
[01:26] <SteveA> yes
[01:26] <SteveA> they are all 'test'
[01:26] <SteveA> and it is documented in the sampledata
[01:27] <ddaa> Mh... apparently it was not obvious enough...
[01:27] <ddaa> thanks
[01:28] <ddaa> Well... apparently no...
[01:28] <ddaa> cannot log in as robert.collins@canonical.com with that password
[01:28] <salgado> stub, just to make sure.. the shipit export is scheduled to wednesday 0h UTC, right?
[01:28] <ddaa> neither to david.allouche@canonical.com
[01:28] <stub> salgado: Yes
[01:29] <stub> salgado: erm... well 0h BST 
[01:29] <stub> salgado: close enough?
[01:30] <salgado> stub, yes, I think it's okay.
[01:31] <stub> elmo: Do you have a particular attachment to running servers in the BST timezone, or can we switch to UTC at some point to avoid start/end DST crazies (and confused DBAs)?
[01:31] <SteveA> ddaa: look in database/sampledata/foaf.sql
[01:31] <SteveA> ddaa: there are a few sample people with password 'test'
[01:31] <BjornT> mpt: no, no idea. currently i'm doing some support tracker work, when i'm done with that i'll see if i can dedicate some time to implement the specs. i think they are quite important for malone.
[01:34] <mpt> indeed
[01:34] <mpt> BjornT: We need ProjectSubscriptions too (e.g. for the MOTUs and for Launchpad), so perhaps the ProductSubscriptions and PackageSubscriptions specs can be merged and expanded into a RegistrySubscriptions or similar to save work
[01:35] <mpt> so that they have consistent data models and Web interfaces
[01:35] <ddaa> SteveA: thanks
[01:38] <BjornT> mpt: yeah i think so too. we might need DistributionSubscriptions as well.
[01:38] <SteveA> BjornT: did you land any changes involving email tests into RF recently?
[01:38] <Kamion> where's the right place to send changes to source information for imports? (due to directories moving around in svn)
[01:39] <BjornT> SteveA: no, but bradb did
[01:39] <BjornT> SteveA: what's the problem?
[01:39] <SteveA> i want to know what he changed.
[01:39] <SteveA> it has triggered a problem with leaky data between tests
[01:40] <SteveA> it is hard to reproduce the problem, but i've seen it locally
[01:40] <SteveA> and various people have seen it in pqm
[01:40] <SteveA> i'm disabling the test that fails
[01:40] <SteveA> but i want to get to the bottom of it
[01:40] <BjornT> he changed from_addr, which is passed to simple_sendmail, to be 'bounces@canonical.com' instead of the same as the From header
[01:43] <SteveA> okay, got the pqm commit message
[01:45] <SteveA> i gotta say, the baz model is really good for such investigations
[01:50] <SteveA> BjornT: i can't see anything in brad's changes that would trigger the problems i'm seeing.  he changed some things, but didn't add anything new in particular.
[01:50] <BjornT> SteveA: if it's the same failure salgado reported, i think i know what's the problem
[01:50] <SteveA> what is it?
[01:51] <BjornT> SteveA: in the test there is 'if from_addr == 'nobody1@example.com'. now, from_addr will always be 'bounces@canonical.com', so the condition will always be false
[01:51] <SteveA> the test often passes
[01:52] <SteveA> Failed example:
[01:52] <SteveA>     message['From'] 
[01:52] <SteveA> Expected:
[01:52] <SteveA>     'nobody@example.com'
[01:52] <SteveA> Got:
[01:52] <SteveA>     'nobody1@example.com'
[01:52] <SteveA> 
[01:52] <SteveA> and, that's the failure
[01:52] <SteveA> it's going at a lower level than what brad's change addresses
[01:52] <BjornT> yeah, the if statement is there since you don't know in what order the mails were sent in, sometimes it's the correct order, sometimes not
[01:53] <SteveA> ioc
[01:53] <SteveA> the if statement is wrong
[01:53] <BjornT> exactly
[01:53] <SteveA> i think the test should be made more robust
[01:53] <SteveA> by listifying, and then sorting
[01:53] <SteveA> and then printing out
[01:53] <SteveA> the queue
[01:54] <SteveA> anyway, thanks for the pointer.  i'll go fix it
[01:54] <BjornT> cool
[01:56] <salgado> hey BjornT. have some time for a quick review?
[01:57] <BjornT> salgado: maybe, i'll have to step out for a while soon. send it to me, and i'll see if i can do it before i leave.
[01:59] <salgado> BjornT, thanks, dude. but unfortunately I just found I have a method with side effects that shouldn't be there. I'll have to fix this and send it to you later
[02:29] <zyga> sabdfl: ping
[02:29] <zyga> sabdfl: you've said that if polls don't work today I should ping you
[02:29] <zyga> so I do
[02:31] <salgado> zyga, it was me who said that. ;)
[02:31] <zyga> hmm
[02:31] <zyga> maybe I've confused you, sorry
[02:31] <zyga> anyway, is the upload with gazillion fixes already done?
[02:39] <salgado> zyga, the merge queue is still pretty big, which means that even if I try to merge something, it'll take quite some time (3h, at least)
[02:39] <stub> an update was rolled out to production around 8 hours ago.
[02:39] <zyga> hmm
[02:39] <zyga> so is it patched or not?
[02:39] <zyga> I'm confused ;-)
[02:40] <zyga> it's fine if it's still in the queue
[02:40] <salgado> zyga, no, this update stub refers too doesn't include the fix for that problem
[02:40] <zyga> okay so it's in the queue
[02:41] <zyga> it's a matter of time
[02:41] <salgado> zyga, we can delete one of the options for you (while that problme is not fixed), if you want
[02:41] <zyga> salgado: no, I'll wait - there is no rush really
[02:41] <zyga> salgado: if you could though
[02:42] <zyga> extending the poll deadline for 7 days would be nice
[02:42] <salgado> it's not yet in the queue. kiko has that fix but didn't sent the merge request yet
[02:48] <sabdfl> salgado: my patch (which stub and stevea_ are landing and taking to production) does include poll fixes and page layout changes
[02:48] <sabdfl> i don't know if it fixes the specific issue zyga is having
[02:48] <sabdfl> SteveA, stub: success with the newpackageclasses landing?
[02:49] <SteveA> sabdfl: it is at #3 in pqm right now, and i fully expect it to merge this time.
[02:49] <sabdfl> what was the test issue?
[02:50] <SteveA> a test of the email test enironment had become undeterministic because of a change brad made.  it wasn't brad's fault, rather the test that went wrong was not robustly written.
[02:50] <SteveA> at #1 in pqm is my patch to disable that test.  #2 is something important from Kinnison.  #3 is your branch.  #4 is a correct, deterministic re-enabling of the problematic test.
[02:52] <zyga> how long does it take to process a patch in the queue?
[02:52] <zyga> I guess it runs some test after each patch, right?
[02:52] <SteveA> about 45 minutes i think
[02:52] <SteveA> maybe more
[02:52] <SteveA> a lot of the time is spent in building the correct source code environment
[02:53] <Kinnison> s'between 45m and 1h depending on how busy chinstrap is
[02:53] <SteveA> and this will be made much quicker when we use bzr for launchpad
[02:53] <SteveA> we've also asked to get a dedicated box for integrating launchpad code
[02:53] <SteveA> which will make us not depend on other people using chinstrap or not
[02:53] <ddaa> niemeyer: 
[02:53] <SteveA> and it can be a faster machine that chinstrap, too ;-)
[02:53] <ddaa> let's have this quick review
[02:54] <ddaa> First thing, you should not rely on the branch name to map to arch namespace.
[02:54] <ddaa> Instead rely on the branch url.
[02:54] <ddaa> I see no reason at first why Taxi should do any name mangling, except to create new branches.
[02:55] <niemeyer> ddaa: I just followed the mangling convention used in the samples in the database.
[02:56] <ddaa> I understand. But the branch name is mutable.
[02:56] <ddaa> It just happens to be set that way in the sampledata because of how it was migrated.
[02:56] <niemeyer> ddaa: About relying on the branch name, I understand. I didn't implement it that way because I'm not yet sure about how to build the url.
[02:57] <niemeyer> ddaa: So far the given url is always a file in the local disk.. should I just use it and expect that the real environment will give a real url?
[02:57] <Kinnison> ciao all
[02:58] <niemeyer> ddaa: Ok, I was just explaining how I got there.. will remove the mangling.
[02:58] <ddaa> niemeyer: I think we talked about that before. The url in the branch should be the publicly visible URL. The one importd actually use (to mirror to) has a different head but the same tail. The head of the backend url is archive_mirror_dir, the head of the frontend url should be similarly configurable.
[02:58] <ddaa> Which is still different from the url of the local branch used for the import, which needs not be configurable since it's importd private data.
[02:59] <ddaa> In a nutshell:
[03:01] <ddaa> local branch (currently not meaningful, there's a tree and an archive) -> writeable sftp arch.ubuntu.com backend url (archive_mirror_dir) -> public http arch.ubuntu.com url (branch.url)
[03:01] <niemeyer> ddaa: I think I misunderstand the meaning of url then..
[03:01] <niemeyer> ddaa: Why do we have an url at all, if it has a fixed head? Why storing that in a database?
[03:02] <niemeyer> ddaa: Why not storing just the part that actually changes?
[03:02] <ddaa> The Branch.url is what we'll display in Launchpad. And people are going to be able to register their own branches.
[03:02] <ddaa> It just happens that branches created by importd are all in the same place, that importd knows about.
[03:02] <niemeyer> ddaa: I see.. it's fixed only for importd. Ok
[03:03] <sabdfl> carlos: ping
[03:03] <sabdfl> "En Ubuntu, como ahora."?
[03:04] <niemeyer> sabdfl: What should be the meaning?
[03:05] <sabdfl> not sure
[03:05] <niemeyer> sabdfl: That's strange, at least to my portuguese spanish.. :)
[03:06] <niemeyer> "In Ubuntu, like now.", or something close to that..
[03:07] <niemeyer> ddaa: I'm still here.. let me know about other comments and when you finish reviewing please.
[03:14] <bradb> stub: Did your browser notification message stuff land yet? I don't recall whether or not I saw a merge for that yet.
[03:14] <ddaa> niemeyer: I do not understand getBranchRevision
[03:14] <ddaa> niemeyer: Revision.revision_id is UNIQUE
[03:14] <niemeyer> ddaa: It gets the revision having revision_id and linked to branch.
[03:15] <niemeyer> Hummm
[03:15] <ddaa> so you can just Revision.selectOneBy(revision_id=revision_id)
[03:15] <stub> bradb: Nope. It was undergoing a hefty refactoring after review, and is almost ready.
[03:15] <bradb> ok
[03:16] <niemeyer> ddaa: Right
[03:16] <niemeyer> ddaa: But notice that this functions checks if the revision is actually linked to the given branch.
[03:17] <ddaa> That would be a meaningful sanity check.
[03:17] <ddaa> But it's not apparent you are making a sanity check as it stands.
[03:17] <ddaa> (now, it will be a whole different story with bzr...)
[03:17] <niemeyer> If revision_id is unique, it's a bit strange on a first sight that they're not directly linked to a branch.
[03:17] <niemeyer> Will have to think further about that
[03:18] <ddaa> niemeyer: the schema is that way because bzr requires it
[03:18] <ddaa> ATM you are mapping Arch onto a bzr model.
[03:18] <ddaa> so such weirdness is expected
[03:18] <niemeyer> ddaa: Ok, will try to come up with something better
[03:19] <ddaa> There's going to be another significant transition when we really start supporting Bzr, but Launchpad will not need to care.
[03:19] <ddaa> (at least, not much)
[03:21] <ddaa> BTW, your code does the right thing already, this method is not used :)
[03:21] <niemeyer> ddaa: I've put it there just to see if you were really reviewing the code.
[03:22] <niemeyer> ddaa: More seriously, this is used in the tests.
[03:22] <niemeyer> ddaa: Also notice that line: # FIXME These get*() methods should be moved to somewhere else.
[03:22] <niemeyer> :)
[03:23] <ddaa> The way I read it, it means "that shoud go into database.Branch". Not "that should go into the test suite"
[03:23] <ddaa> Hand-wavy comments: bad
[03:23] <niemeyer> ddaa: "somewhere else" reads more like "i have no idea, but not here please". :-)
[03:24] <niemeyer> ddaa: What are "hand-wavy" comments?
[03:26] <ddaa> http://en.wikipedia.org/wiki/Hand_waving
[03:27] <ddaa> generally, a comment that's so vague as to at best useless and at worst misleading
[03:27] <niemeyer> ddaa: Ok, will be more careful next time.
[03:28] <ddaa> Any such comment raises review red flags, because either it's a temporary marker and should have be fixed before review, or it marks something that cannot be done now for some reason, which should be explained.
[03:28] <ddaa> I'm a bit of a bastard reviewer, I reckon.
[03:29] <niemeyer> ddaa: For that specific comment, please read it as: # FIXME: The get* methods may be useful to other parts of the code, so I don't think they should be in the test suite, otherwise I would have written them there. OTOH, if the mangled name is not mangled anymore, part of this becomes useless.
[03:30] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  temporarily disable problematic stub mailer test (patch-2674: steve.alexander@canonical.com)
[03:30] <ddaa> Good. Unashamed admission of ignorance.
[03:31] <ddaa> That's useful :)
[03:31] <lifeless> and finally, gnight all here
[03:31] <niemeyer> ddaa: Not alone, though. :)
[03:31] <niemeyer> lifeless: Good night!
[03:31] <ddaa> lifeless: gnight
[03:32] <sabdfl> night lifeless
[03:33] <sabdfl> ddaa, niemeyer: how is TheBazaar looking?
[03:34] <niemeyer> sabdfl: For my untrained eyes, it's looking like a mess right now.
[03:34] <ddaa> sabdfl: niemeyer is making progress with teaching taxi about the new schema. I have started fixing some page, but I'm have a lot of trouble at becoming one with launchpad testing.
[03:34] <ddaa> niemeyer assessment is essentially correct
[03:35] <sabdfl> niemeyer, ddaa: ok, its early days, we have a few weeks to bring order to the mess
[03:35] <sabdfl> your goal is to be able to render a page like the kernel git listing page for every product in LP
[03:36] <sabdfl> and to make the workflow really easy for people using bzr
[03:36] <sabdfl> bzr branches should just show up, in the right places
[03:36] <ddaa> sabdfl: I think I could restore the functionality we had in London in a few days, what is giving me a hard time is deciding what to put in the test suite and how.
[03:36] <niemeyer> Sounds quite tangible
[03:36] <sabdfl> well, you should have sampledata, and page tests that exercise it, for sure
[03:37] <ddaa> even that is bothering me, I do not like at all the loss of locality.
[03:37] <sabdfl> SteveA: do you know if anything landed from kiko on the gina front? i branched from his -215, i think, was that the latest?
[03:37] <ddaa> sabdfl: couple of questions about the schema
[03:38] <sabdfl> fire away
[03:38] <SteveA> i haven't heard anything from kiko on gina since i left last night
[03:38] <ddaa> 1. can we get rid of Revision.owner?
[03:38] <SteveA> stub ran kiko's changes on staging, and got various errors.  you were cc-ed into that email.
[03:38] <ddaa> seems pointless granularity to me
[03:39] <ddaa> In all cases, it's taxi (or some variant thereof) that's going to create revision objects in the db.
[03:39] <ddaa> What makes sense to Launchpad is only Branch.owner
[03:39] <niemeyer> ddaa: We'll probably want to refactor RevisionNumber as well..
[03:40] <ddaa> sabdfl: I'd also like a reply to the "changes in history" mail I wrote late last week.
[03:40] <niemeyer> ddaa: Right now the only way to relate a revision to a branch is using revision numbers, and that's not how bzr/baz/arch work.
[03:40] <ddaa> sabdfl: and I'm also sort of uncomfortable with the NOT NULL Branch.home_page.
[03:40] <sabdfl> ddaa: in bzr, you have shared branches, anybody could commit right?
[03:41] <ddaa> niemeyer: that's how bzr works
[03:41] <sabdfl> ddaa: +1 to ALTER TABLE Branch ALTER COLUMN home_page DROP NOT NULL;
[03:41] <ddaa> sabdfl: ack
[03:41] <sabdfl> niemeyer: the same revision could be in multiple branches
[03:42] <sabdfl> so you need a linking table
[03:42] <sabdfl> and it could be different revision number in different branches, so that linking table needs to keep track of that
[03:42] <niemeyer> sabdfl: Sure.. I'm talking about the revision number (rev_no).
[03:42] <sabdfl> where's that?
[03:42] <niemeyer> revisionnumber
[03:42] <sabdfl> should not be Revision.rev_no
[03:42] <ddaa> sabdfl: with the case of a shared "centralised" branch, the owner should be a Team. I see no use case for a Revision.owner. Users are not allowed to alter revision data.
[03:42] <sabdfl> niemeyer: i believe you need that
[03:43] <sabdfl> RevisionNumber.sequence would have been my preferred name
[03:43] <mpt> sabdfl: In changing HTML comments containing implementation details to TAL comments, I touched 34 other templates. Should I get someone to review the branch again in that case?
[03:43] <ddaa> and multiple committers is already covered by revision_author, which is not a Person for a reason.
[03:43] <niemeyer> sabdfl: I think we do as well, but that's the only way to have a revision linked with a branch right now, isn't it?
[03:43] <sabdfl> ddaa: think of "owner" not only as a permissions thing, but also an "i created this" thing
[03:43] <sabdfl> you need to show WHO created it
[03:43] <ddaa> sabdfl: that's what Revision.revision_author is about
[03:43] <sabdfl> you want to render a page that lists revisions, with commit messages, and the COMMITTER
[03:44] <sabdfl> at the same time, someone else could tell you about a branch, so then they would be the owner of those revisions
[03:44] <sabdfl> don't drop it arbitrarily now
[03:44] <sabdfl> don't stress about it either
[03:44] <sabdfl> next?
[03:44] <niemeyer> How do I say that revision revid123 is present in a branch?
[03:44] <sabdfl> niemeyer: yes, the only way
[03:44] <ddaa> sabdfl: I'm entirely happy with making all revision.owner be "Launchpad admins", but that would be a bit pointless :)
[03:44] <sabdfl> you need to create a RevisionNumber for it
[03:45] <niemeyer> ddaa: Agreed
[03:45] <sabdfl> ddaa: it's got nothing to do with editability, ok?
[03:45] <sabdfl> read above
[03:45] <niemeyer> sabdfl: But not all revisions which are present in a branch have revsison numbers
[03:45] <niemeyer> revision
[03:45] <sabdfl> they don't?
[03:45] <sabdfl> they can be parents, or merged in, right?
[03:45] <ddaa> sabdfl: ack what you said
[03:45] <niemeyer> sabdfl: Right
[03:46] <sabdfl> niemeyer: that is reflected elsewhere in the data schema, i think
[03:46] <ddaa> RevisionParent
[03:46] <sabdfl> there should be a RevisionParent table
[03:46] <sabdfl> aha
[03:46] <ddaa> no matching sqlobject yet, no use for it ATM
[03:47] <niemeyer> sabdfl: There is one
[03:47] <sabdfl> there is one what?
[03:47] <sabdfl> oh, table
[03:47] <niemeyer> sabdfl: Ok.. understood
[03:48] <niemeyer> sabdfl: It still does not reflect the fact that even though a revision *has* a parent, it may not be present in the branch.
[03:48] <ddaa> BTW, I agree RevisionNumber.rev_no is not a terribly good name...
[03:49] <ddaa> niemeyer: ghosts?
[03:49] <niemeyer> sabdfl: So you don't know which revisions are in the branch.
[03:49] <niemeyer> ddaa: Yes
[03:50] <ddaa> The database models the global revision pool. Bzr only garantees availability of revisions listed in revision-history, that's why I wrote that mail about "changes in history".
[03:50] <niemeyer> ddaa: Right.. so we're in sync. Launchpad has no idea if a given revision is present on a branch or not.
[03:50] <niemeyer> ddaa: Only if it's in the history
[03:51] <niemeyer> ddaa: I don't know if we want to import that info or not.
[03:51] <ddaa> Right, and bzr does not garantee anything more than availability of revisions present in the history.
[03:51] <ddaa> I do not think we would want.
[03:52] <ddaa> Especially because I can readily imagine a supermirror using one big centralised store.
[03:52] <niemeyer> ddaa: That's the whole point. If it ensured that all revisions were in the branch, Launchpad would have the presence information already.
[03:52] <niemeyer> ddaa: And that whole discussion gets back to the fact that branches may change their history.. oh dear.
[03:53] <sabdfl> ok, can you explain this to me? i'll try to recommend a change to the schema to give you waht you want
[03:53] <ddaa> sabdfl: it's all explained in careful detail with a proposed schema change in the launchpad mailing list.
[03:53] <niemeyer> sabdfl: I don't really know if we *want* it.
[03:53] <sabdfl> what is the difference between a revision that is "in the history" or "present on a branch" ?
[03:54] <sabdfl> ddaa: url? title of email?
[03:54] <niemeyer> sabdfl: I'm just pointing out that we don't have in Launchpad information about which revisions are present in the branch, besides the branch history.
[03:54] <ddaa> "How to change the history of branches in Launchpad"
[03:54] <ddaa> IMO there's no difference.
[03:54] <sabdfl> niemeyer: what do you mean by "present in the branch"?
[03:55] <SteveA> salgado: hi
[03:55] <SteveA> salgado: https://chinstrap.ubuntu.com/~dsilvers/paste/fileLCiVRZ.html
[03:55] <Kinnison> bradb: Did you mail me the details on sending mail from zopeless scripts in the end?
[03:55] <niemeyer> sabdfl: The revision is present in the branch ancestry information, even if it's not in the history.
[03:55] <bradb> Kinnison: No I mentioned the doc to read to you yesterday though. Perhaps you weren't around.
[03:55] <bradb> doc/sending-mail.txt
[03:55] <niemeyer> sabdfl: bzr accepts "ghost" relations (<revid> My parent is 123, but he's not here.)
[03:55] <Kinnison> possibly
[03:55] <ddaa> niemeyer: I think bzr has no branches. Only stores and histories.
[03:56] <niemeyer> ddaa: Huh?
[03:56] <Kinnison> bradb: rock on, ta
[03:56] <Kinnison> bradb: Hmm, can that do bcc ?
[03:56] <ddaa> niemeyer: can you give me a definition of bzr branch that is neither: "the revision history" or "what is in the revision store of that branch"?
[03:57] <niemeyer> ddaa: A bzr branch is a set of files which contain information about a given project.
[03:57] <salgado> SteveA, thanks dude. /me switches to urgent-fixes mode
[03:57] <Kinnison> bradb: also, what's the deal wrt. when during transaction-commit the mail gets sent?
[03:57] <SteveA> salgado: you know what it is?
[03:57] <Kinnison> bradb: is it after the db says "yes" or before?
[03:57] <niemeyer> ddaa: Stores and revision histories are contained in a branch.
[03:57] <salgado> SteveA, no, I don't. but I'll find out
[03:58] <ddaa> niemeyer: that is the user model
[03:58] <niemeyer> ddaa: That's the bzr model..
[03:58] <SteveA> salgado: another example here https://chinstrap.ubuntu.com/~dsilvers/paste/filebJHYel.html
[03:58] <ddaa> I'm asking about the conceptual model of bzr.
[03:58] <bradb> Kinnison: Isn't bcc'ing just a matter of adding the bcc header to your message?
[03:58] <Kinnison> bradb: that simple_sendmail interface appears to take a body, not a full mail
[03:58] <Kinnison> bradb: unless I'm reading it wrongly
[03:59] <SteveA> also, salgado, change intOrZero to give the passed in value in the error output
[03:59] <niemeyer> ddaa: That's what I think the conceptual model is..
[03:59] <salgado> SteveA, sure
[03:59] <ddaa> niemeyer: -> #bzr
[03:59] <bradb> Kinnison: hm, true, that should probably be renamed to "msg" instead
[03:59] <niemeyer> ddaa: And I don't understand what's the point of this, btw.. :)
[04:00] <kiko> morning
[04:00] <niemeyer> ddaa: I'm just pointing out that we don't know if we can find information about a given revision in a branch or not..
[04:00] <kiko> Kinnison, you got reply-mail
[04:00] <Kinnison> bradb: So I can add arbitrary headers in the "body" argument?
[04:00] <ddaa> niemeyer: I think there is a point in ontologies.
[04:01] <ddaa> niemeyer: i disagree we can
[04:01] <bradb> Kinnison: In looking at the implementation, there's a headers dict parameter you can use to add the headers, in this case.
[04:01] <niemeyer> ddaa: Can we?
[04:01] <ddaa> niemeyer: -> #bzr
[04:01] <Kinnison> kiko: ack
[04:01] <Kinnison> bradb: rock on
[04:01] <Kinnison> bradb: thanks dude
[04:02] <bradb> Kinnison: re: transactional. The email gets delivered during the commit AIUI. I don't know anything more specific than that.
[04:02] <kiko> Kinnison, SteveA: I have a couple more gina bugfixes
[04:02] <kiko> I want to know if I should invest time in the gina doctest at this point
[04:02] <kiko> and I need help with Build
[04:02] <kiko> spent the morning looking into this and doing reviews
[04:03] <SteveA> kiko: you should co-ordinate with mark too
[04:03] <SteveA> i'm going for some lunch
[04:03] <SteveA> mark's soyuz landing is at #2 in the pqm queue right now
[04:03] <SteveA> and i expect it to go through this time
[04:03] <kiko> finally
[04:03] <SteveA> when stu gets back from dinner, he's getting this onto staging
[04:03] <SteveA> (there was a strange spurious conflict issue)
[04:03] <Kinnison> kiko: I'm going to read your mail and respond then we'll see what we're up to
[04:04] <SteveA> so, the main thing now is to fix up gina and test gina on staging.
[04:04] <SteveA> i have a few chores to do after getting something to eat, but i'll be around later on.
[04:04] <kiko> Kinnison, cool.
[04:07] <bradb> kiko: http://69.70.209.33/products/firefox/+bugs -- I changed the UI as per your and mpt's suggestion and rearranged the ZPT so that the search widget ZPT is in once place and use-macro'd into callsites. Can I merge this patch?
[04:08] <bradb> stub!
[04:08] <stub> Brad!
[04:08] <bradb> i had another quick schema change request to make, if you have time
[04:08] <kiko> bradb, that host isn't accessible from here :-/
[04:08] <bradb> allowing nulls for Specification.specurl
[04:08] <stub> Will it break my assigned bugs page this time?
[04:09] <kiko> probably
[04:09] <stub> Please do make the URL nullable
[04:10] <bradb> stub: you broke my app, so i broke your assigned bugs report
[04:10] <Kinnison> kiko: responded
[04:12] <kiko> Kinnison, thanks
[04:12] <jordi> carlos: can you send a request for stub for that Urdu plural forms request?
[04:13] <stub> bradb: You want me to do the NULL Specifiation.specurl, or do you want to land it with some changes?
[04:13] <bradb> stub: if you could just make the schema change, and I'll worry about fixing the app-level changes today, that'd be great
[04:14] <stub> ok.
[04:14] <jordi> stub: hey stub.
[04:14] <kiko> bradb, no connection.
[04:14] <bradb> (i'll make sure there's test data with a null url this time too, so that i can at least blame the tests when we find out which pages break because of this)
[04:15] <stub> wuss
[04:16] <bradb> kiko: oh, the port number, :8086
[04:18] <kiko> that's more like it
[04:18] <kiko> bradb, now we're talking! pastebin a diff for me
[04:20] <bradb> ok
[04:21] <kiko> bradb, you do realize that the underline under the bug # is kooky, right?
[04:22] <kiko> _5 .__ 
[04:22] <kiko> craack
[04:22] <salgado> stub, the production logs are not being synced?
[04:22] <mpt> kiko: If responding to a review results in minor changes to 34 more files, should I get another review?
[04:23] <bradb> kiko: i didn't cut the page up that way. it only looks particular kooky because of the separation between the number and the title
[04:23] <bradb> (done to line up the IDs)
[04:23] <mpt> kiko, that kooky separation is fixed in my bug-listings-love branch, which failed PQM last night
[04:23] <kiko> mpt, at least put a diff up somewhere
[04:23] <stub> salgado: I have no idea. I don't have the foggiest idea where the mirror is
[04:23] <kiko> okay, thanks mpt 
[04:23] <mpt> kiko: somewhere for what? jamesh's script does that already
[04:24] <kiko> salgado, they are rsynced to chinstrap AFAIUI
[04:24] <kiko> mpt, well, jamesh' script takes a while to pick up new changes..
[04:24] <salgado> stub, I thought they were in chinstrap:~stub/production_logs
[04:24] <salgado> and in fact they're there, but out of sync
[04:25] <stub> salgado: Those ones I've synced manually once or twice. SteveA got elmo or Zarl to sync them across somewhere regularly IIRC
[04:25] <bradb> meanwhile, I'm thinking we need a better connection between upstreams, between distros, and between upstreams and distros. All this URL-hacking-as-navigation is pretty old skool.
[04:25] <salgado> kiko, do you know where they are? (the production logs)
[04:25] <salgado> SteveA is not here, I guess
[04:26] <stub> salgado: I'll do a manual sync for now
[04:27] <bradb> so: 1. making it easy to jump from one product's bugs to another's, 2. same idea for D's, DSP's, and SP's, 3. being able to quickly jump to the bugs filed on a specific packaging of an upstream and 4. being able to quickly jump to the relevant upstream's bugs for a DSP/SP
[04:27] <bradb> mpt: have you done any thinking about how to better connect those entities, so that we can hack URLs less often?
[04:27] <salgado> stub, thank you!
[04:27] <stub> salgado: enjoy (all 500MB! )
[04:28] <kiko> salgado, yes, I do
[04:28] <kiko> salgado, /srv/gangotri*/
[04:29] <mpt> bradb: No, apart from reporting that bug about product->package bug listing links
[04:30] <bradb> ok
[04:30] <bradb> that's what brought it to my attention once again
[04:30] <bradb> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/fileGMWnKf.html
[04:31] <ddaa> niemeyer: so, my point was that Launchpad does not model bzr branches.
[04:31] <ddaa> It models bzr histories and the bzr ancestry-graph.
[04:31] <ddaa> And you are damn right.
[04:31] <ddaa> It breaks on the edge of known space.
[04:32] <jordi> kiko: hey dude
[04:33] <jordi> kiko: remember we had a team for Shona called "shona" that we wanted to rename to "ubuntu-l10n-sn"?
[04:33] <jordi> You asked me to remind at some point, because two weeks ago you couldn't do it
[04:33] <niemeyer> ddaa: Understood
[04:33] <ddaa> Cannot model ghost revisions, that's a problem, but not for importd, at least.
[04:34] <niemeyer> ddaa: Indeed
[04:34] <ddaa> One point each. Play again.
[04:34] <kiko> jordi, we can't do it yet, I need to merge in gneuman's patches, but they still have issues.
[04:35] <niemeyer> ddaa: Changes may be needed in importd.. but that issue is much more conceptual that about implementation, as you say.
[04:35] <niemeyer> than about
[04:35] <ddaa> niemeyer: right now, just map baz onto the not-quite-bzr-but-almost schema we have.
[04:35] <niemeyer> ddaa: I'm late for lunch.. will be glad to know your general opinion about taxi, and other comments you may have.
[04:36] <niemeyer> ddaa: Will you stay around for a while, or would you like to discuss that right now?
[04:36] <ddaa> I'll leave in about 2:30 hours
[04:37] <niemeyer> Nice.. I'll try to have a quick lunch and get back.
[04:37] <ddaa> I think I need some rest now :)
[04:37] <niemeyer> ddaa: Thanks for discussing it :)
[04:40] <jordi> kiko: ok. When should I try again?
[04:42] <kiko> jordi, let's hope for next week
[04:45] <sabdfl> jordi: should be easy to rename a team
[04:46] <jordi> sabdfl: really?
[04:47] <jordi> sabdfl: if you think it can be done, /people/shona should be ubuntu-l10n-sn
[04:48] <stub> Kinnison: ping
[04:48] <sabdfl> jordi: damn, kiko was right
[04:48] <sabdfl> i used to be able to rename people
[04:48] <Kinnison> stub: yo
[04:49] <jordi> sabdfl: WillBeFixed(TM)
[04:49] <jordi> :)
[04:49] <sabdfl> kiko: hmm +review works for me
[04:49] <sabdfl> is there an issue, or can i just try it?
[04:49] <Kinnison> sabdfl: +review should just work
[04:49] <stub> Kinnison: So it looks like we have duplicate SourcePacakgeReleases in the production DB. If we nuke them, should Gina rebuild everything happily or are there sourcepackagereleases in there from other sources?
[04:50] <salgado> sabdfl, someone dropped that for teams. I asked gneuman to put it back, but kiko hasn't merged his changes yet
[04:50] <Kinnison> stub: the only things in launchpad gina imported IIRC
[04:50] <kiko> sabdfl, +review might work -- I have a patch and test for the team issue.
[04:50] <salgado> sabdfl, there should be no issues, +review might work for teams too
[04:50] <kiko> salgado, I would have, but there are other problems in his patch
[04:50] <jordi> sabdfl: I have some people here asking about translations for the CoC.
[04:50] <Kinnison> stub: certainly gina is the only way to get stuff into the db
[04:50] <sabdfl> stub: i dont think we should have anything there, that must be from a gina run
[04:50] <Kinnison> stub: until I land my uploader
[04:50] <Kinnison> which would be made easier if you lot would stop sending patches :-)
[04:50] <jordi> sabdfl: should we handle this similary to the unofficial GPL translations?
[04:50] <sabdfl> jordi: https://launchpad.net/people/ubuntu-l10n-sn/
[04:50] <sabdfl> done
[04:51] <sabdfl> Kinnison: i'm sure pqm feels the same :-)
[04:51] <jordi> sabdfl: good :)
[04:51] <jordi> thanks
[04:51] <ddaa> sabdfl: after considerable banging of head, I think niemeyer and I agreed on what are the problems.
[04:51] <jordi> sabdfl: you should tell kiko how you did this, for the next time.
[04:52] <ddaa> So, there's the changing history thing, that's covered in the mail with the subject: "How to change the history of branches in Launchpad"
[04:52] <stub> Kinnison: So I'll add nuking the contents of sourcepackagereleasefile, sourcepackagerelease and securesourcepackagepublishinghistory to the list of stuff to delete
[04:52] <ddaa> And there is the problem of ghost revisions.
[04:52] <jordi> sabdfl: back to code of conduct; FSF promotes trasnlations of thE GPL, but strongly recommends that they are not used for licensing, just as reference.
[04:52] <ddaa> Which will requires some schema change, I'm not clear which, yet.
[04:53] <Kinnison> stub: sprf, then sspph, then spr
[04:53] <Kinnison> stub: after you've cleared the binaries
[04:53] <jordi> ie, translations of the Code of Conduct could be linked from the page with the text, but with big flashy red letters stating its nothing official; what you need to sign is the English version.
[04:54] <sabdfl> ddaa: ok. as i understand it, the problem is that a bzr branch can refer to a branch that you cannot see. that should be no problem. we should be able to create a revision entry for it without the branch.... even the revision-and-branch, perhaps, with no revision number.
[04:54] <sabdfl> jordi: sounds good
[04:54] <kiko> jordi, I've noticed already
[04:54] <jordi> this would help people understand what the CC is, should they have problems with the English.
[04:54] <sabdfl> the system will enforce what it recognises, anyway
[04:54] <kiko> yeah, it's already picky enough as it is!
[04:54] <sabdfl> if there is real demand, we could do real-certified-translations
[04:55] <ddaa> sabdfl: the problem is that we may have a revision without having its ancestor.
[04:55] <ddaa> Yet knowing the revision_id of the ancestor.
[04:55] <sabdfl> i see. well lets talk more at UBZ
[04:55] <sabdfl> kiko: so, was -215 your latest changes to gina?
[04:56] <jordi> sabdfl: it should be easy to translate; it's not evil legalsee language.
[04:56] <ddaa> ack -> UBZ
[04:56] <kiko> sabdfl, no, -217
[04:56] <sabdfl> jordi: yes, agreed, and its designed to be friendly, so a local language one is a good idea.
[04:56] <sabdfl> we just have to be a little careful, to get "official" ones, and update the system to know about those, serve them, and recognise them when they come back signed
[04:57] <sabdfl> a good topic for UBZ spec action
[04:57] <sabdfl> kiko: full branch id?
[04:57] <kiko> christian.reis@canonical.com--lozenge/launchpad--devel--0--patch-217
[04:57] <jordi> sabdfl: will add a spec
[04:57] <kiko> sabdfl, I was asking if we should invest in gina.txt today.
[04:57] <sabdfl> ddaa: will you add a spec to the UBZ schedule for the ghost revision issue?
[04:58] <sabdfl> gina.txt?
[04:58] <sabdfl> test?
[04:58] <ddaa> sabdfl: will talk to JaneW about it.
[04:58] <jordi> sabdfl: a translation of one of these documents should be done quite openly, in the language/motu mailing lists or whatever. Whatever is needed so drafts get lots of reads
[04:58] <sabdfl> ddaa: err... easy, (1) write spec on wiki, (2) register in LP, (3) add to UBZ agenda in LP
[04:59] <sabdfl> just write the braindump summary intro paragraph for now
[04:59] <bradb> kiko: can i merge the patch?
[04:59] <ddaa> sabdfl: okay, on my way.
[04:59] <sabdfl> jordi: agreed
[05:00] <kiko> bradb, I still see reference to old-style and new-style in the patch. Why?
[05:00] <bradb> hm, that is unintentional. /me checks
[05:00] <kiko> bradb, the docstring for get_sortorder_from_request at least needs to be updated. I think you didn't read your diff.
[05:05] <jordi> kiko: when you have a min; can gnome-l10n-ku be added to gnome-translators?
[05:05] <bradb> kiko: changed to:
[05:05] <bradb> def get_sortorder_from_request(request):
[05:05] <bradb>     """Get the sortorder from the request."""
[05:05] <bradb>     if request.get("orderby"):
[05:05] <bradb>         return request.get("orderby").split(",")
[05:05] <bradb>     else:
[05:05] <bradb>         # No sort ordering specified, so use a reasonable default.
[05:05] <bradb>         return ["-priority", "-severity"] 
[05:06] <bradb> removed current_sortorder from the template, because I guess we don't need it anymore
[05:06] <kiko> bradb, that's better
[05:06] <kiko> jordi, sure
[05:07] <kiko> jordi, if you give me URLs for your requests it's easier :)
[05:07] <jordi> kiko: sorry. :)
[05:08] <bradb> kiko: does that mean i can merge it then? :)
[05:08] <jordi> add https://launchpad.net/people/gnome-l10n-ku to https://launchpad.net/rosetta/groups/gnome-translation-project/
[05:08] <syn\ack> hi
[05:08] <kiko> bradb, isn't there a bug filed on the fact that you can't file bugs on binary packages?
[05:09] <salgado> SteveA, around?
[05:09] <kiko> kurdish, jordi?
[05:09] <kiko> thanks mpt
[05:10] <bradb> kiko: I dunno. Our search sucks. There might have been such a bug in the now deceased dogfood data we had.
[05:10] <jordi> kiko: yes
[05:10] <kiko> done, jordi 
[05:10] <jordi> kiko: thanks man
[05:10] <mpt> kiko: for?
[05:11] <sabdfl> kiko: ok, gina needs some deep surgery
[05:11] <sabdfl> i don't mind doing it today
[05:12] <sabdfl> i need help setting up the test environment
[05:12] <sabdfl> what do you use? an archive copy?
[05:12] <kiko> sabdfl, I can probably do it myself, since I now am happier than I used to be with it
[05:12] <sabdfl> elmo: how big is a copy of main i386 and ppc?
[05:12] <kiko> sabdfl, I want to be able to work on gina.txt for this though
[05:12] <sabdfl> kiko: ok, i'd like to be involved, though, since i think that will speed things up
[05:12] <sabdfl> that's a good idea yes
[05:12] <kiko> because it's going to be a lot better than testing on staging and discovering "ah it failed"
[05:12] <bradb> kiko: can i merge this patch?
[05:13] <kiko> bradb, get a new diff up. sabdfl, if you can take a quick look at gina.txt I can tell you more or less what the plan is
[05:13] <bradb> kiko: a new diff up for what?
[05:13] <kiko> bradb, for your latest changes.
[05:13] <bradb> i just pasted the change i made, and there were two lines of ZPT that i removed
[05:14] <kiko> bradb, you don't really want to make my life easier, do you?
[05:14] <bradb> argh. /me feels himself crushed under the weight of process.
[05:15] <kiko> bradb, what are you going to work on after this?
[05:15] <sabdfl> kiko: looks good
[05:16] <bradb> kiko: bugfixing: DR release bug counts, nullable spec URLs, and then getting into linking upstreams and distributions more effectively.
[05:16] <kiko> bradb, okay, cool. I've assigned bug 3322 to matsubara.
[05:16] <Ubugtu> Malone bug #3322: It should be possible to indicate a binary package when filing a bug Fix req. for: malone (upstream), Severity: Normal, Assigned to: Diogo Matsubara, Status: New http://launchpad.net/malone/bugs/3322
[05:16] <bradb> meanwhile, i'm also anxiously waiting for stub's browser notification message patch to land, so that i can provide useful feedback all over Malone
[05:17] <kiko> sabdfl, I want to add: a second distro release, and about 10 more packages that test the codepaths. At the moment we only test: one distro release, archictecture independent, so a lot of this is just hanging there in space.
[05:17] <bradb> kiko: ok
[05:17] <sabdfl> kiko: makes sense
[05:17] <carlos> jordi, d
[05:17] <carlos> jordi, sure
[05:17] <sabdfl> we need a sourcepackagerelease and binary package releases that are published in BOTH distroreleases
[05:18] <kiko> sabdfl, exactly, some published with the same version, some with newer versions
[05:18] <sabdfl> yes
[05:18] <kiko> sabdfl, I don't suggest testing failure modes, because that will take too much time -- just make sure it copes with what we will have
[05:19] <sabdfl> testing failure modes should be straightforward?
[05:19] <kiko> sabdfl, how do you suggest I do it using the existing gina.txt?
[05:20] <sabdfl> hmm... i see. check for error messages in the log?
[05:20] <sabdfl> i did this with cve importing
[05:21] <kiko> sabdfl, I'd need to add an extra loop for each failure mode, to test properly, don't you think?
[05:22] <sabdfl> kiko: well. not necessarily
[05:22] <sabdfl> say there are X clear failure conditions we want to detect
[05:22] <kiko> okay
[05:22] <sabdfl> if yo have one sample archive, and can run gina over it, you should get X error messages in the log
[05:22] <sabdfl> test for that
[05:22] <sabdfl> it's not perfect, but it's a start
[05:22] <kiko> agreed
[05:23] <kiko> it's what I suggested above as not testing "properly", but it is a reasonable check.
[05:23] <kiko> okidokie
[05:23] <kiko> let me have lunch and delve into this
[05:26] <bradb> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/fileyn9YYf.html
[05:28] <sabdfl> gosh, pocket_distrorelease is a bad name for "the distro and pocket into which we are dumping data"
[05:29] <kiko> bradb, is there any reason to define sortwidget_label as a separate macro?
[05:30] <kiko> +    <table>
[05:30] <kiko> +      <tr tal:condition="view/showListView"
[05:30] <kiko> bradb, that condition is redundant with the one in a containing tal:list_view
[05:31] <kiko> bradb, I'm assuming the rest of the changes to that file are the advanced search form, yes?
[05:33] <kiko> bradb, it would have been nice if you had added to bugtask-macros-listview a batched-list macro, but that's optional
[05:33] <bradb> kiko: i made it a separate macro because the widget was originally going to be used in more than one kind of layout, but now i've just added the whole thing (i.e. including the search widget) to the DSP bug listing, so it probably doesn't need to me
[05:34] <kiko> bradb, I guess it's consistent with the other widget in there though
[05:34] <kiko> r=kiko with these comments
[05:35] <bradb> right, that extra showListView class is unneeded. I removed it.
[05:37] <kiko> clause
[05:37] <bradb> kiko: re: the sortwidget macros then: should the macro be written such that it's forced that the label/widget are a row in a table?
[05:38] <kiko> bradb, nah, I'd leave then as-is, they are consistent with the other widget in there.
[05:38] <bradb> i didn't make any changes to the advanced search form
[05:39] <kiko> maybe reindented?
[05:39] <jordi> carlos: great, thanks
[05:39] <kiko> look at the diff
[05:39] <bradb> kiko: right, reindentation
[05:40] <jordi> carlos: I created the spec sabdfl asked for; https://wiki.ubuntu.com/RosettaTeamlessTranslating
[05:40] <jordi> I know the spec name could be better :)
[05:40] <jordi> carlos: can you have a look if I'm misisng something?
[05:40] <bradb> kiko: does that address everything to your satisfaction?
[05:41] <bradb> stub: how does the db patch look?
[05:41] <sabdfl> jordi: call the mode "Organised" perhaps?
[05:41] <sabdfl> Close / Organised / Open?
[05:42] <sabdfl> kiko: gina hurts my brain a little
[05:42] <sabdfl> kick me next time is use the word "temporary" to describe something to be written
[05:42] <sabdfl> or better, PIE me
[05:43] <kiko> sabdfl, well, she wasn't so bad in the beginning -- we just never considered rearchitecting her to cope with the added requirements.
[05:44] <kiko> bradb, yeah, looks okay.
[05:44] <kiko> go for it
[05:44] <bradb> ok, thanks
[05:44] <sabdfl> it's only 2,000 lines of code, we could refactor it pretty easily and clean it up
[05:44] <sabdfl> i like the use of the config system
[05:44] <kiko-fud> that was Kinnison's work!
[05:44] <sabdfl> and the idea of having handlers is sound
[05:44] <kiko-fud> :)
[05:45] <sabdfl> the PackagesMap grew a little out of control, though
[05:45] <sabdfl> that should be a set of classes, not a class with nested dicts
[05:45] <kiko-fud> there's a lot of duplication
[05:45] <jordi> sabdfl: organised... I wouldn't get much sense of what "Organised" means if I had to select one of the three
[05:45] <kiko-fud> and the handling of source and binary packages shouldn't be so identical
[05:45] <kiko-fud> anyway
[05:46] <kiko-fud> out for a bit, back in 2m
[05:46] <kiko-fud> 20m
[05:46] <sabdfl> jordi: i'm trying to give the sense of there being some structure
[05:46] <sabdfl> Structured?
[05:47] <jordi> sabdfl: we might want to come up with a name at the BOF
[05:47] <jordi> hmm.
[05:47] <sabdfl> jordi: actually, i think i could implement this in about 2 hours with tests
[05:47] <sabdfl> there's only one or two methods that need to be updated to know about the new way
[05:47] <sabdfl> let me take a look, since kiko has gina under the whip
[05:48] <jordi> ok
[05:48] <sabdfl> jordi: hmm.... maybe even faster
[05:49] <jordi> I had some QA concerns; ie Rosetta lacking a team for Occitan, but a KDE team already existing
[05:49] <jordi> that could generate translation clashes, right?
[05:55] <salgado-lunch> back
[05:55] <ddaa> niemeyer: ping
[05:56] <niemeyer> Pong!
[05:56] <niemeyer> ddaa: pong!
[05:56] <ddaa> https://launchpad.net/products/launchpad/+spec/ghost-revisions
[05:57] <ddaa> Let's fire a gobby
[05:57] <niemeyer> ddaa: Cool
[05:57] <niemeyer> ddaa: Can you host it?
[05:58] <ddaa> Yup
[05:58] <niemeyer> (I'm nat'ed)
[05:58] <niemeyer> ddaa: Please, run two different ones..
[05:58] <ddaa> why  two?
[05:58] <niemeyer> ddaa: One for the original code, and one for your changes..
[05:59] <ddaa> well... you have the original code... don't you?
[05:59] <niemeyer> ddaa: Sure.. but having the changes marked in the code while we're looking at it is nice.
[06:00] <niemeyer> ddaa: Would that be uncomfortable to you?
[06:00] <ddaa> not sure what you mean -> msg
[06:03] <stub> bradb: could take some time. I've had to nuke my revlib
[06:03] <bradb> stub: i hear ya
[06:12] <jordi> is it normal that site navigation doesn't go past Launchpad>>Products>>Oregano when I'm viewing a potemplate or whatever?
[06:12] <jordi> see https://launchpad.net/products/oregano/+series/main/+pots/oregano/
[06:13] <Kinnison> can someone remind me how to run a specific pagetest story?
[06:13] <Kinnison> it's something like python test.py -f . story
[06:13] <Kinnison> ?
[06:13] <kiko> Kinnison, I don't think it's possible, is it?
[06:13] <jordi> kiko: can you go here https://launchpad.net/products/oregano/+launchpad and mark it as "Rosetta official"?
[06:14] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: r=spiv, mark's soyuz loving. (patch-2675: mark.shuttleworth@canonical.com, rocketfuel@canonical.com, scott@canonical.com)
[06:15] <Kinnison> sabdfl: congrats
[06:16] <SteveA_> Kinnison: python test.py -f --test=name.txt
[06:16] <Kinnison> SteveA_: that runs a specific doctest
[06:16] <SteveA_> jordi: that's in the design for breadcrumbs.  there's a spec on it like LaunchpadHierarchyNavigation
[06:16] <BjornT> Kinnison: what you can do is python test.py -f --test=<regexp>, with a regexp that will match all the tests in the story. it's not guaranteed to work, though...
[06:16] <Kinnison> SteveA_: can i use that to run a full pagetest story?
[06:16] <Kinnison> BjornT: arse
[06:16] <SteveA_> Kinnison: you can run all the pagetests
[06:16] <SteveA_> Kinnison: python test.py -f canonical.launchpad.ftests.test_pages
[06:16] <SteveA_> that's not very very slow
[06:17] <Kinnison> SteveA_: okay, ta
[06:17] <SteveA_> jordi: the idea is that the breadcrumbs stop where you've got navigation by menus
[06:17] <SteveA_> jordi: if you find a place where breadcrumbs are insufficient or confusing, then file a bug with that url, and why they are confusing.
[06:17] <SteveA_> jordi: it is easy to fix such things by tweaking the breadcrumbs.
[06:18] <jordi> SteveA_: nod
[06:18] <jordi> SteveA_: ok, its new and it struck me as a bug
[06:18] <SteveA_> it is good to see these things fro mother 
[06:18] <SteveA_> it is good to see these things from other points of view
[06:18] <jordi> yes
[06:18] <SteveA_> the main thing is not whether they look odd, but whether they work for navigation
[06:18] <SteveA_> although, not looking odd helps too ;-)
[06:20] <jordi> heh
[06:20] <salgado> SteveA, I can't reproduce that problem, but it seems to me that form.get(sometextentry) is returning None
[06:21] <mpt> jordi: the breadcrumbs take you up to where other navigation takes over
[06:21] <jordi> nod
[06:21] <salgado> SteveA, in what cases it's expected to return None when that's a text entry?
[06:21] <mpt> jordi: The "other navigation" is in a pretty bad state at the moment, but that's not the breadcrumbs' fault
[06:22] <mpt> and it'll improve
[06:22] <jordi> damn
[06:22] <jordi> is this a known bug? https://launchpad.net/products/xqf/unknown/+edit
[06:24] <carlos> kiko, wow
[06:24] <SteveA_> salgado: on the phone with scott
[06:25] <carlos> kiko, seems like librarian is not behaving as it should or we have a transaction problem I'm not aware of...
[06:25] <mpt> portlet-actions!
[06:25] <carlos> kiko, anyway, I'm tired of those errors, I'm going to catch that exception and will do an uncached export if we get it
[06:26] <SteveA_> mpt, jordi fixed in a branch of mine
[06:26] <SteveA_> to be cherrypicked RSN
[06:26] <mpt> ok
[06:26] <kiko> carlos, I asked spiv to look into this for a long time
[06:26] <kiko> he hasn't managed to find the issue
[06:26] <kiko> so I think you're right
[06:26] <carlos> yeah, I know
[06:26] <carlos> that's why I'm going to implement an easy workaround
[06:27] <jordi> SteveA_: k
[06:29] <salgado> stub, https://launchpad.net/errors/showEntry.html?id=1129652737.180.0711841574497
[06:30] <salgado> stub, apparently, accessing person.preferredemail is taking too long
[06:31] <kiko> salgado, log expired though
[06:31] <salgado> https://launchpad.net/errors/showEntry.html?id=1129652737.180.0711841574497
[06:31] <stub> salgado: when from? Most likely something else was locking the person table
[06:31] <salgado> stub, apparently, always
[06:32] <salgado> just go to https://launchpad.net/people/+requestmerge?field.dupeaccount=kiko
[06:32] <salgado> :P
[06:32] <salgado> and try to merge
[06:32] <kiko> trying to steal my karma!
[06:32] <salgado> if I were doing that for karma I would merge jordi's account
[06:33] <salgado> he's been cheating the karma framework for a long time
[06:34] <stub> That exception isn't very helpful - it isn't telling us what the query is :-/
[06:35] <carlos> salgado, that's my fault
[06:36] <salgado> carlos, the karma thing, I guess?
[06:37] <carlos> salgado, yeah
[06:38] <salgado> stub, am I crazy or this traceback (https://chinstrap.ubuntu.com/~dsilvers/paste/file2QSIT1.html) means that it expired when trying to check if I'm a member of the launchpad_developers, in order to show me the traceback?
[06:38] <stub> salgado: that is correct
[06:39] <kiko> this has happened to me quite a few times.
[06:39] <stub> Nothing unusual running
[06:39] <stub> No cronjobs anway
[06:40] <stub> We need that exception to include the dud sql :-(
[06:40] <kiko> is that easy to do?
[06:41] <stub> kiko: Should be I think
[06:41] <matsubara> Does anybody know why the IProductSeriesSource and IProductSeries are split on two Interfaces? All the data of the IProductSeriesSource are defined to one db table: productseries, is there a reason for that?
[06:42] <stub> kiko: should I try your gina fixes on staging or wait until you and mark land that work being discussed before?
[06:43] <stub> matsubara: it would likely be to make assigning permissions easier. 
[06:43] <stub> matsubara: butress administrators get write access to one interface, other people only get write access to the other
[06:45] <matsubara> thanks stub 
[06:46] <sabdfl> jordi: done
[06:46] <sabdfl> carlos: can I send you the patch?
[06:46] <carlos> sabdfl, which patch?
[06:46] <sabdfl> for the teamless translating bits
[06:46] <carlos> sure
[06:47] <sabdfl> it has no tests. you'll need to add some.
[06:47] <kiko> stub, let's try my fixes -- what do you think?
[06:47] <matsubara> by the way, what is this butress thing? I can't find anything on the wiki...
[06:47] <carlos> sabdfl, ok
[06:47] <jordi> sabdfl: we've been discussing about the convenience of having a 3rd mode. We should just make Teamless mode the default in Closed?
[06:47] <kiko> matsubara, it's what became "the bazaar"
[06:47] <sabdfl> matsubara: Buttress is the old name for TheBazaar
[06:48] <matsubara> thanks :)
[06:48] <sabdfl> jordi: no, Closed means "nothing happens without a designated translator". the new Structured mode means "where there is no designated translator, you can go wild"
[06:49] <kiko> if stub's justification is correct, however, it's odd that you need two interfaces for a single form, matsubara.
[06:49] <sabdfl> hmm.... carlos, can we try dsomething?
[06:49] <sabdfl> i'll do baz undo, then send you a tar of the resulting dir, and you try to redo it over there?
[06:49] <carlos> sabdfl, ok
[06:49] <jordi> sabdfl: aha; reverting spec :)
[06:50] <sabdfl> or i could commit  this to my current ginafixes branch
[06:50] <kiko> sabdfl, that's going to make it more difficult to read..
[06:50] <sabdfl> kiko: right, i'm trying to avoid that
[06:51] <sabdfl> but am not making any gina changes since you are handling that and neither of us wants conflicts :-)
[06:51] <sabdfl> carlos:  it should pass tests, because there is no test data with the new permission
[06:51] <matsubara> kiko: I'm just trying to replicate the old form, and the old one had fields from both Interfaces.
[06:52] <sabdfl> so if it doesn't, then shout :-)
[06:52] <kiko> oh
[06:52] <kiko> matsubara, that's what I think is weird -- what fields are those? are they protected by any particular permission code in the template or browser code?
[06:52] <carlos> sabdfl, I prefer the first option, send me the undo directory, please...
[06:53] <salgado> is staging down?
[06:54] <mpt> ddaa?
[06:54] <ddaa> mpt: pong
[06:54] <mpt> ddaa: "resolved: One or more of the paths supplied doesn't exist."
[06:55] <mpt> This is for an .arch-ids file
[06:55] <ddaa> ha
[06:55] <ddaa> yes
[06:55] <ddaa> resolved is stupid and broken
[06:55] <mpt> I did cp foo.id.rej foo.id
[06:55] <mpt> because foo.id didn't exist
[06:55] <matsubara> the fields are: releaseroot and releasefileglob, and I think they belong to another form: productseries-source and shouldn't be on productseries-edit
[06:55] <mpt> and then resolved
[06:55] <ddaa> mpt: just fix all your conflicts and then "baz resolved --all"
[06:55] <mpt> ok
[06:57] <jordi> sabdfl: should I still add a spec for this in LP, or is it enough now as there's code in your tree?
[06:58] <sabdfl> jordi: go ahead and add it
[06:59] <sabdfl> be nice to be able to say Implemented when it lands
[07:00] <salgado> Kinnison, around?
[07:00] <Kinnison> salgado: yes
[07:00] <kiko> matsubara, what does ddaa think?
[07:01] <kiko> matsubara, either that, or you need to move them from one interface to another
[07:01] <ddaa> well... they sure would be weird in +edit
[07:02] <ddaa> I guess +source would be better
[07:02] <ddaa> but Keybuk is the consumer of this data
[07:02] <ddaa> not me
[07:02] <kiko> so what does Keybuk say?
[07:02] <ddaa> so he's the guy to ask about permission policy
[07:02] <salgado> Kinnison, you have write access to dogfood, right?
[07:02] <matsubara> they are on the +edit now with the current non auto generated form
[07:02] <Kinnison> salgado: yes
[07:03] <salgado> Kinnison, would you apply a small patch there for me, so I can test something?
[07:04] <Kinnison> salgado: sure
[07:04] <salgado> Kinnison, great. what revision are we running there?
[07:08] <Kinnison> salgado: quite an old one. You want me to upgrade first?
[07:09] <salgado> Kinnison, no. the patch is one that's already in production. I want to make sure that patch causes a timeout I'm seeing
[07:10] <salgado> Kinnison, this is it: https://chinstrap.ubuntu.com/~dsilvers/paste/filezvL3VY.html
[07:12] <Kinnison> can you put it in a file on mawson?
[07:12] <kiko> salgado, except_()?
[07:12] <Kinnison> salgado: we're at 2608 on mawson
[07:13] <salgado> Kinnison, I don't have access to mawson
[07:13] <salgado> Kinnison, it should be safe to replay rocketfuel@canonical.com/launchpad--devel--0--patch-2617
[07:14] <Kinnison> I'll try
[07:14] <salgado> kiko, yes, I guess that's what's causing the timeout when trying to merge accounts
[07:14] <kiko> hmmm wonder how it's implemented
[07:14] <Kinnison> salgado: patch replayed, dogfood restarted
[07:15] <salgado> kiko, the same way as intersect() and union()
[07:16] <kiko> salgado, hmmm
[07:16] <kiko> Kinnison, architecturetag is just a stringcol. did you know that?
[07:16] <kiko> processorfamily is foreignkey
[07:16] <kiko> build.*
[07:16] <kiko> sorry, DAR.*
[07:17] <salgado> Kinnison, in dogfood, do we have the same limits we have in production for how long a query can run?
[07:19] <Kinnison> salgado: dunno
[07:19] <Kinnison> salgado: I doubt it
[07:19] <Kinnison> kiko: yes
[07:19] <Kinnison> kiko: that's completely correct
[07:19] <kiko> Kinnison, and I can trust it even so?
[07:19] <kiko> it's not even a dbschema value
[07:19] <kiko> I don't understand why
[07:20] <salgado> Kinnison, okay, thanks for applying the patch. you can undo it if you want; I won't need it anymore
[07:20] <Kinnison> kiko: because it's arbitrary for the distribution
[07:20] <Kinnison> kiko: It's the most trustworthy bit
[07:21] <niemeyer> ddaa: Thanks for the session
[07:21] <ddaa> I'm outta here guys.
[07:22] <kiko> Kinnison, sounds dangerous -- why not have the distribution register the tag it likes? anyway, hacking on
[07:24] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  make test_simple_sendmail work deterministically (patch-2676: steve.alexander@canonical.com)
[07:36] <kiko> Kinnison, is the Releases.gz guaranteed to only contain one copy of a file?
[07:36] <kiko> Kinnison, s/file/package name/ s/copy of/entry for/
[07:38] <Kinnison> kiko: Packages.gz will only ever contain one stanza per package name
[07:43] <kiko> Kinnison, thanks.
[07:44] <kiko> Kinnison, in the pool I can find the dsc, the tar and the diff, right?
[07:44] <kiko> and the deb
[07:44] <Kinnison> yes
[07:45] <Kinnison> the pool is pool/component/initial/spn/
[07:45] <Kinnison> where "initial" is a-z or liba-libz as appropriate
[07:45] <jordi> gotta leave to my internet-less flat. Laters.
[07:45] <Kinnison> and comes from the spn
[07:46] <kiko> Kinnison, why are source packages kept in an arch-specific directory? do we symlink between architectures?
[07:47] <Kinnison> they're not
[07:47] <Kinnison> the pool is everything in together
[07:49] <kiko> oh, right
[07:49] <kiko> doh
[07:49] <kiko> I'm being silly
[07:49] <kiko> man, util-linux is big
[07:49] <kiko> sucks
[07:49] <Nafallo> apt-get update outside pool, apt-get upgrade inside pool :-)
[08:02] <carlos> sabdfl, do you have the patch ready?
[08:06] <kiko> SteveA_, you're not going to like +1mb of test matter for gina, are you?
[08:07] <SteveA_> kiko: sounds a lot.  why so big?  it needs real binaries?
[08:07] <kiko> well
[08:07] <kiko> I'd like to test with real packages
[08:07] <kiko> I'm looking for small ones
[08:08] <Kinnison> lua50
[08:08] <Kinnison> s'small
[08:08] <SteveA_> kiko: do you need the real binary data though?
[08:08] <SteveA_> i mean, gina basically just sticks it in the librarian
[08:08] <SteveA_> so any data will do
[08:08] <SteveA_> you can turn off sig checking
[08:09] <kiko> well
[08:09] <salgado> SteveA, 5lines diff: https://chinstrap.ubuntu.com/~dsilvers/paste/fileTvU7fv.html
[08:09] <kiko> salgado, no, we run dpkg -e and stuff on the packages.
[08:10] <kiko> errr
[08:10] <kiko> SteveA_, that was for you. no can do.
[08:10] <kiko> I'll try and make the hit smaller
[08:10] <SteveA_> salgado: r=me
[08:10] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Fix for bug 1623: external bug tracker page only shows 10 latest watches. When viewing a bugtracker, allow optionally displaying all bugtracker watches via a GET variable (patch-2677: christian.reis@canonical.com)
[08:10] <salgado> SteveA, ta!
[08:11] <SteveA_> kiko: don't worry too much about it
[08:11] <kiko> thanks SteveA_ 
[08:11] <SteveA_> kiko: just get gina working
[08:11] <salgado> it is not, as expected
[08:11] <SteveA_> salgado: one thing
[08:11] <SteveA_> what happens if an exception gets kw args?
[08:12] <salgado> it breaks!
[08:12] <SteveA_> aha
[08:12] <SteveA_> so, do this
[08:13] <SteveA_> don't give the exception *args and **kw
[08:13] <SteveA_> make its init take  def __init__(self, sqlargs, sqlkw):
[08:13] <SteveA_>     Exception.__init__(self, sqlargs, sqlkw)
[08:13] <SteveA_> do that
[08:14] <SteveA_> and make sure that the subclass of RequestExpired also works
[08:14] <SteveA_> the subclass is RequestQueryTimeout or something like that
[08:14] <SteveA_> in the same module
[08:18] <salgado> SteveA, why do this instead of simply calling RequestExpired('foo', args, kwargs)? they seem to do the same thing, no?
[08:20] <SteveA_> why do what?
[08:20] <SteveA_> have a separate exception type?
[08:20] <SteveA_> or write a special __init__ ?
[08:20] <SteveA_> you don't need to write a special __init__, of course
[08:20] <SteveA_> as the default Exception __init__ does the job
[08:21] <SteveA_> so, if that's what you meant, well spotted
[08:23] <salgado> so, no need to change anything apart from the *args and **kwargs to args and kwargs?
[08:23] <SteveA_> you need to implement the same thing in RequestQueryTimeout
[08:23] <SteveA_> or whatever that exception is called
[08:24] <salgado> is that supposed to be a subclass of RequestExpired? was it added recently?
[08:24] <salgado> I can't seem to find any subclass of RequestExpired
[08:25] <SteveA_> oh... that merge failed
[08:25] <SteveA_> so okay, go ahead and add it
[08:25] <SteveA_> and i'll square it when i get the commit landed
[08:26] <Kinnison> ciao
[08:33] <mpt> Who wrote librarianformatter_noca.txt?
[08:41] <kiko> pas mois
[08:41] <kiko> moi
[08:44] <kiko> is there something you run that gets you a zopeless console, salgado?
[08:44] <salgado> kiko, yes
[08:45] <salgado> cd canonical/database ; python -i harness.py
[08:50] <kiko> aha
[08:50] <kiko> Kinnison, do you know what preimport_sourcecheck() is useful for?
[08:56] <salgado> SteveA, did you see the messages where I said I couldn't reproduce that traceback you found in the logs today? might you have some time to discuss it?
[09:07] <mpt> crap
[09:07] <carlos> https://launchpad.net/distros/ubuntu/breezy/+sources/gnome-games
[09:07] <carlos> I think that page is a bit weird
[09:07] <carlos> it says that " This source package is not published in The Breezy Badger Release."
[09:08] <carlos> but you can see there information about that package being published ....
[09:08] <carlos> or at least released...
[09:08] <mpt> It uses the word "pocket"
[09:08] <mpt> That's weird in itself :-)
[09:11] <mpt> SteveA: ping
[09:17] <mpt> kiko, can I change the zope source code?
[09:18] <kiko> mpt, not really
[09:19] <mpt> One of the LP tests is failing because it expects "An error occurred", and it's getting "An error occured"
[09:19] <mpt> I think the misspelling is coming from zope
[09:22] <kiko> mpt, possibly, but, well, should't we be providing a better error message?
[09:23] <jbailey> mpt: Shouldn't it give a 500 response code with it for an error page?  Maybe just test for that.
[09:24] <mpt> kiko, jbailey: it's a portalmessage in an addform
[09:24] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Added Urdu plural form (patch-2678: carlos.perello@canonical.com)
[09:24] <mpt> It's followed by a more specific error at the particular control
[09:33] <kiko> mpt, we have launchpad-addform.pt, don't we?
[09:34] <zyga> kiko: hi
[09:34] <zyga> kiko: were you recently hacking public polls?
[09:35] <mpt> kiko: yes, which calls for "status"
[09:35] <mpt> which equals "view/update"
[09:35] <mpt> and view seems to be in zope somewhere
[09:35] <salgado> kiko, how's it going with that patch for poll traversals?
[09:39] <kiko> salgado, you need to help gneuman, I've asked him like 3 times to get your help
[09:39] <kiko> salgado, look at your INBOX -- how many emails did you reply to me today?
[09:41] <salgado> kiko, the one related to #759 I'll discuss with matsubara soon. gneuman hasn't asked for help today, apart from some questions
[09:44] <kiko> salgado, can you kick him for me?
[09:45] <sabdfl> SteveA: so was PQM good to you?
[09:47] <kiko> ffs
[09:49] <salgado> kiko, he said he's going to do some cleanup before
[09:50] <kiko> yeah yeah
[09:54] <sabdfl> SteveA_: ping ^
[09:58] <kiko> Kinnison, does publisher.publish() know not to publish a file twice?
[09:59] <sabdfl> Kinnison: have we opened up the uploader?
[09:59] <sabdfl> kiko: i have the TB now, then will continue looking at gina
[09:59] <sabdfl> want to try to give you some concrete suggestions based on the current architecture
[10:00] <sabdfl> the main thing i'm trying to discover is whether the source and binary package maps can be combined in such a way that you know, when you are importing a binary package, about ALL the binary packages in the "build"
[10:05] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Fix to make RequestExpired show the sql query. r=SteveA (patch-2679: guilherme.salgado@canonical.com)
[10:07] <kiko> sabdfl, well, you could look at the source record and sniff through its binaries line, but I think that's often not complete. you could also put together an additional data structure that mapped source packages to binary packages.
[10:07] <sabdfl> kiko: only way to be certain would be to do it backwards - go through all binaries, and keep track of which source they came from
[10:08] <kiko> sabdfl, in a way, we do this already, right?
[10:08] <sabdfl> i figure we need to create a consolidated data structure that knows about the binaries and the source packages, linked
[10:08] <sabdfl> kiko: no
[10:08] <sabdfl> we don't
[10:08] <sabdfl> at the moment its two separate lists, as i read the code
[10:08] <sabdfl> one of source packages
[10:09] <sabdfl> and the a set of binpkg lists, by architecture
[10:13] <kiko> I mean, we already go through all binary packages per architecture in the main gina loop
[10:13] <kiko> salgado, otoh, is it vital that we discover this ahead of time, or can we do it lazily (as we currently do)?
[10:13] <kiko> or do you think that we're not going to manage avoiding duplicating builds if we don't take this approach.
[10:14] <salgado> huh?
[10:14] <kiko> duh
[10:14] <kiko> sabdfl!
[10:17] <sabdfl> kiko?
[10:17] <sabdfl> what i would want to end up with is a data structure in python that models the SPR -> Build -> BPR structure we want in the db
[10:17] <sabdfl> then have Gina iterate over that structure, and map the bits we want into the db
[10:18] <sabdfl> either SPN/BPN only, or SPR's, or the whole lot
[10:18] <salgado> BjornT___, ping
[10:27] <carlos> sabdfl, the .diff was good enough, thanks
[10:27] <carlos> sabdfl, time to have dinner, later will add tests and request a trivial merge
[10:27] <carlos> sabdfl, thanks
[10:30] <sabdfl> np
[10:30] <sabdfl> i hope that's a popular little feature-ette
[10:30] <sabdfl> jordi: ^
[10:30] <sabdfl> kiko: what's with the !?
[10:34] <kiko> sabdfl, it was a correction to salgado, my brain's all gina today.
[10:42] <kiko> this is going to be a long night
[10:45] <sabdfl> kiko: i apologise, i should have taken a long look at gina some time ago
[10:45] <SteveA_> sabdfl: yes
[10:46] <SteveA_> sabdfl: you pinged earlier
[10:46] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=kiko]  create a sortorder widget for the various bug listings that were using pesky table headers on list views. (patch-2680: brad.bollenbach@canonical.com)
[10:47] <sabdfl> SteveA_: so did newpackageclasses land? on both production and HEAD?
[10:47] <SteveA_> it landed in HEAD.  stub should have put it onto staging
[10:48] <SteveA_> it'll be put onto production tomorrow, assuming nothing bad happened on staging
[10:49] <kiko> this is fun
[10:49] <kiko> SteveA_, I have a question for you. can you take a quick one?
[10:50] <kiko> I am testing gina
[10:50] <kiko> gina creates source package releases
[10:50] <kiko> however
[10:50] <kiko> if I do
[10:50] <kiko>     >>> SourcePackageRelease.select().count()
[10:50] <kiko> before and after gina.txt
[10:50] <kiko> (well, inside it, but before the call that spawns gina inside it)
[10:50] <kiko> I always get back 6.
[10:50] <SteveA_> you need to commit
[10:50] <kiko> I do
[10:50] <kiko> many times indeed
[10:51] <kiko> oh
[10:51] <SteveA_> in the doctest
[10:51] <kiko> I see what you mean.
[10:51] <SteveA_> seeing as you probably shell out
[10:51] <kiko> right, right
[10:51] <kiko> of course
[10:51] <kiko> SteveA_, using the ztm, right?
[10:51] <SteveA_> kiko: what's happening with gina?
[10:52] <SteveA_> kiko: import transaction ; transaction.get_transaction().commit() iirc
[10:52] <SteveA_> there are examples elsewhere i think
[10:52] <SteveA_> kiko: do i need to do anything with gina on staging / talk with stub tomorrow morning?
[10:53] <kiko> SteveA_, I'm working on tests for it
[10:53] <kiko> refactoring and cleaning up as I go
[11:07] <looksaus> who is responsible for the bounty system in Launchpad?
[11:09] <looksaus> and... someone here suggested me to create a "specification" in Launchpad
[11:10] <looksaus> should I just add that info to the wiki somewhere?
[11:17] <Kinnison> kiko: How do you mean?
[11:18] <Kinnison> sabdfl: I'm cleaning up my branch, merging in your stuff, solving the conflicts etc
[11:18] <Nafallo> yay! /me added a hackergotchi ;-)
[11:19] <Kinnison> SteveA_: I have a bizarre pagetest brokenness
[11:21] <SteveA_> Kinnison: seen the hacking FAQ on accommodating whitespace?
[11:22] <Kinnison> not uet
[11:23] <Kinnison> I don't think that's the issue
[11:23] <sabdfl> Kinnison: merging in my stuff from HEAD? did it land there?
[11:24] <Kinnison> sabdfl: your stuff landed earlier today
[11:24] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  fix the release bug counts on the bug listing + test (patch-2681: brad.bollenbach@canonical.com)
[11:25] <Kinnison> Life hasn't been made easy by overly-fragile pagetests
[11:27] <Kinnison> is our sampledata now newly huger or something?
[11:35] <Kinnison> SteveA_: once I have a copy of this test output, will you have a quick look at it for me?
[11:35] <SteveA_> Kinnison: i need to sleep now.
[11:35] <Kinnison> that's fair
[11:36] <Kinnison> thanks
[11:36] <Kinnison> each pagetest story gets its own fresh database to run in, yes?
[11:37] <Kinnison> so any contamination from my nascentupload doctest shouldn't reach it, yes?
[11:37] <SteveA_> yes
[11:38] <Kinnison> thanks
[11:38] <Kinnison> sleep well
[11:38] <Kinnison> and I'll see you in the morning
[11:38] <SteveA_> okay
[11:38] <SteveA_> i'll be around
[11:54] <carlos> sabdfl, around?
[11:56] <carlos> sabdfl, I think we lost the link to change the permission rights (Closed or Open) for a product or distro
[11:56] <sabdfl> carlos: ?
[11:57] <carlos> sabdfl, I don't find it
[11:57] <carlos> and I don't remember the URL
[11:57] <sabdfl> https://launchpad.net/distros/ubuntu/+changetranslators
[11:57] <sabdfl> it's under the Translations facet
[11:57] <carlos> sabdfl, the form that lets you set the kind of permissions that a distribution or product has to handle translations
[11:58] <carlos> oh!
[11:58] <carlos> right
[11:58] <carlos> sabdfl, thanks!
[11:59] <sabdfl> i had to look for it too when i was testing this afternoon :-)
[11:59] <sabdfl> but i think this is the right place for it
[12:00] <sabdfl> carlos: you want to test these scenarios:
[12:00] <sabdfl>  - user is a designated translator for that product and language
[12:00] <carlos> sabdfl, yeah, it makes more sense
[12:00] <sabdfl>  - user is not a designated translator, and there is a translator designated
[12:01] <sabdfl>  - there are no designated translators
[12:02] <carlos> ok