[12:27] <BenC> Hey lp'ers
[12:28] <BenC> I notice that on https://launchpad.net/distros/ubuntu/+milestone/ubuntu-6.10-beta if you hit Status, it doesn't exactly sort like you would expect
[12:28] <lifeless> hmm, I think theres a bug already
[12:28] <lifeless> but perhaps not
[12:28] <BenC> I'm guessing that it's sorting on some other target for the bug besides the one aimed at the milestone
[12:29] <BenC> actually, no, it isn't
[12:29] <BenC> just isn't right :)
[12:29] <lifeless> can you file a bug please
[12:30] <lifeless> be sure to copy the sorted output from bug 54690 through 59883 in
[12:30] <Ubugtu> Malone bug 54690 in foo2zjs "[Edgy]  Please sync new upstream version" [Medium,Fix released]  http://launchpad.net/bugs/54690
[12:30] <BenC> sure thing
[12:30] <lifeless> as that shows the problem really vividly
[12:30] <lifeless> (fix released, confirmed, fix released)
[12:33] <BenC> bug 62526 filed
[12:33] <Ubugtu> Malone bug 62526 in launchpad "Status sorting on milestone listing is wrong" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62526
[12:34] <BenC> thanks guys
[12:40] <Ubugtu> New bug: #62526 in launchpad "Status sorting on milestone listing is wrong" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62526
[12:53] <WebMaven> SteveA: ping
[01:50] <Ubugtu> New bug: #62532 in launchpad "release pages does not show changelog" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62532
[02:11] <WebMaven> SteveA: ping
[04:10] <mdz> any launchpad developers awake?
[04:11] <jamesh> yes
[04:11] <mdz> jamesh:  do you know if anything big is going on with Rosetta right now?
[04:11] <mdz> I'm having trouble with bug 46559
[04:13] <jamesh> mdz: I don't think anything special has changed
[04:13] <mdz> jamesh: do you have access to look at any of that sort of thing?
[04:14] <mdz> if they are doing a big import, I don't even know where that would run
[04:14] <mdz> this is a huge blocker for ubuntu
[04:14] <jamesh> I think you'll have to wait for stub (who should be up soon)
[04:15] <mdz> jamesh: I'll be in and out; would you pounce on him for me?
[04:15] <jamesh> okay
[04:15] <mdz> have him call or SMS me and I'll explain
[04:16] <jamesh> by the look of that bug, the affected soyuz code would need to be changed to be able to retry the failing transaction
[04:16] <jamesh> (which a lot of the scripts aren't set up to do)
[04:17] <mdz> I've tried it 4 times in a row and it has failed consistently
[04:17] <mdz> a couple of hours ago, it ran successfully
[04:21] <mdz> jamesh: do you know if there has been a production update recently?
[04:21] <jamesh> there was one yesterday
[04:22] <mdz> about what time?
[04:25] <jamesh> mdz: looks like it would have finished around 9:00 UTC
[04:25] <Ubugtu> New bug: #62545 in soyuz "View all builds for a just published SourcePackage crashes" [Medium,In progress]  http://launchpad.net/bugs/62545
[04:25] <mdz> so ~17 hours ago
[04:26] <mdz> that doesn't seem consistent
[04:26] <jamesh> ah: <stub> soyuz is still down - I'll wait a tick until malcc shows up and he can confirm it should still be running with the old code.
[04:27] <jamesh> there may be another update time for the soyuz code
[04:27] <mdz> the first failure was around 0038 UTC
[04:27] <lifeless> we dont update soyuz as part of the regular update
[04:27] <lifeless> because its fragile
[04:27] <mdz> malcc won't be up for several hours
[04:28] <spiv> The soyuz code was updated.
[04:28] <lifeless> hmm, I'm going low-blood-sugar, let me grab some food, back in 10 (sorry, I realise this is urgent, but mistakes here would be bad)
[04:28] <mdz> looks like that question was resolved several hours later
[04:29] <mdz> with soyuz being updated as spiv said
[04:29] <mdz> this problem is only a couple of hours old
[04:29] <spiv> Right.  stub talked to malcc ~15 hours ago, and updated soyuz, and Kamion reported that the problem he observed was now fixed.
[04:29] <mdz> I think I just got lucky, the most recent publisher run seems to be succeeding after 7 failures in a row
[04:30] <jamesh> that isn't too surprising given the type of error
[04:40] <lifeless> back
[04:43] <lifeless> looking
[04:43] <lifeless> mdz: poimport is running
[04:44] <lifeless> mdz: please try now
[04:47] <mdz> lifeless: I got lucky and one succeeded; we don't have any more uploads in the queue
[04:48] <lifeless> mdz: what time did it succeed ?
[04:49] <mdz> lifeless: shortly before I said it for the first time in this channel
[04:49] <mdz> which was 1929 local, 0229 UTC
[04:49] <lifeless> thanks
[04:49] <mdz> while you were away
[04:50] <lifeless> well, I have killed poimport anyhow, you should have no further trouble
[04:53] <mdz> lifeless: thank you
[04:53] <mdz> lifeless: is that something which runs automatically?  any idea why things are going badly today in particular?
[04:54] <mdz> lifeless: I sent a message to launchpad@ about the situation; if you could follow up with your findings and actions I'd appreciate it
[04:54] <mdz> meanwhile I'm going to drive the cd image builds
[04:55] <mdz> I've re-enabled the hourly run of the publisher and will let it fall where it may
[04:57] <lifeless> mdz: yes, it runs from cron
[04:57] <lifeless> no idea about what made it unhappy today, the rosetta devs may have more insight.
[04:57] <lifeless> I've already replied to your launchpad@ email, if anything new crops up I shall follow up
[05:19] <mdz> thanks
[05:27] <jamesh> we should really look at how we want scripts to handle retries on aborted transactions
[05:27] <jamesh> so that problems like this could be avoided
[06:00] <mpt_> Goooooooooooooooood afternoon Launchpadders!
[06:36] <stub> lifeless: Did you get any more feedback from the distro team? I'm wondering if the poimport cron job needs to be disabled or run less often, or if it is only the occasional run that causes blockage.
[06:37] <lifeless> 12:53 < mdz> lifeless: thank you
[06:37] <lifeless> 12:53 < mdz> lifeless: is that something which runs automatically?  any idea why things are going badly today in particular?
[06:37] <lifeless> 12:54 < mdz> lifeless: I sent a message to launchpad@ about the situation; if you could follow up with your findings and actions I'd appreciate it
[06:37] <lifeless> 12:54 < mdz> meanwhile I'm going to drive the cd image builds
[06:37] <lifeless> 12:55 < mdz> I've re-enabled the hourly run of the publisher and will let it fall where it may
[06:37] <lifeless> stub: no more feedback no.
[06:38] <mdz> stub: I don't think I can provide any feedback which would help with that decision
[06:38] <mdz> stub: someone needs to find out why that job was causing a problem, when it apparently doesn't usually
[06:38] <mdz> perhaps it was running for an extended period of time
[06:39] <mdz> whatever it was doing differently, it needs to not do that
[06:39] <stub> serialization exceptions are expected when running in serializable transaction isolation level. We either need to handle them, or lower the transaction isolation.
[06:40] <stub> Some runs will be more likely to trigger them (probably big rosetta imports), but they can still happen any time until we fix the problem.
[06:41] <stub> The fix is trivial (and documented in that bug report), but will need to be tested before landing on production.
[06:44] <mdz> stub: that bug report was marked wishlist until a couple of hours ago :-/
[06:44] <stub> I'll leave the cronjob enabled if things are happy now - there is already a new poimport process running - but we can disable it if necessary to keep the release moving (maybe run it once or twice a day manually)
[06:44] <mdz> stub: who do I call to get it stopped and disabled if needed?
[06:45] <stub> mdz: Yeah - I hadn't heard of it causing much besides minor annoyance before and soyuz didn't have a particularly robust test process setup
[06:45] <stub> mdz: Me, lifeless, admins, stevea (I think)
[06:45] <mdz> thanks
[06:45] <stub> poimport process running as launchpad on gangotri, and spawned from launchpad's crontab
[06:46] <stub> Process can be killed without harm - it will recover
[07:50] <mpt> stu1, ping
[07:51] <stu1> mpt: pong
[07:51] <jamesh> the enumvalue:foo TALES expression would be useful if it worked with security wrapped values ...
[07:53] <mpt> stub, do you know why the web stats claim that there has been zero traffic on blueprint.launchpad.net?
[07:54] <stub> Because we moved to features.launchpad.net?
[07:54] <mpt> oh.
[07:54] <lifeless> rotfl
[07:55] <mpt> That's not a blueprint, that's a feature!
[07:55] <mpt> thanks stub 
[07:55] <stub> You want to rt a request to get the stats for features.launchpad.net put up and blueprint.launchpad.net removed?
[08:00] <mpt> yeah
[08:47] <sivang> morning
[09:03] <SteveA> good morning
[09:04] <carlos> morning
[09:34] <SteveA> stub: hi
[09:48] <slytherin> Can anyone tell me how can I apply for a mailing list for a l10n team.
[10:17] <mpt> BjornT, ping
[10:17] <BjornT> mpt: pong
[10:18] <mpt> BjornT, I saw you said "I'm working on this" in the enter-URLs-as-bug-watches bug
[10:18] <mpt> Is there an existing spec for that?
[10:18] <mpt> or is it too small to need a spec?
[10:23] <BjornT> mpt: well, i'm planning to do it steps. the first one will be to simply allow an url in the remote bug field, but still keeping the ability to choose a bug tracker manually.
[10:23] <BjornT> mpt: there is a spec at https://wiki.ubuntu.com/BugForwardingWorkflow, though, with some mock-ups at http://www.async.com.br/~kiko/mockups/bug-forwarding-workflow.html
[10:26] <SteveA> mpt: hello.  I will try calling usman now.
[10:27] <BjornT> mpt: there has also been some discussion about this on the mailing list.
[10:27] <Burgundavia> BjornT: those mockups look really busy to me
[10:28] <Burgundavia> BjornT: I also dislike the term "indicate"
[10:29] <mpt> BjornT, could those mockups be put on the wiki? Last week I went through a bunch of specs that linked to mockups on cprov.gwyddion.com, a host that no longer exists. I'm not saying that async.com.br is going to stop existing, but it would be nice to keep all parts of the spec in one place
[10:31] <BjornT> Burgundavia: yeah, they are quite busy. it could be worth redesigning them, to make the field where you enter the bug url more prominent.
[10:31] <SteveA> mpt: he's in a meeting, but I left a message and he'll call me back when he's available.
[10:32] <mpt> ok
[10:33] <BjornT> Burgundavia: i also don't like the them "indicate", but it's so hard to come up with a good term. this has been discussed before, but no suitable term was found.
[10:35] <jamesh> Burgundavia: it is better than the "request fix in" language
[10:35] <jamesh> but isn't perfect
[10:39] <BjornT> mpt: iirc, we tried to put the mockups on the wiki at first, but there were some problems with linking to images or something, so we did it like this instead.
[10:40] <mpt> wellllll, those ones don't really need images :-)
[10:42] <SteveA> mpt: do you have sometime to talk about the structural object presentation code?
[10:42] <mpt> SteveA, sure
[11:05] <carlos> danilo_: hey dude
[11:05] <danilo_> carlos: hi
[11:05] <carlos> danilo_: is your network link working well today?
[11:06] <danilos> carlos: not really, and I racoon (VPN) packages are broken for my "backup" provider, so I am back at my parents house :(
[11:06] <danilos> s/I racoon/ipsec and racoon/
[11:06] <danilos> i.e. bug 44246
[11:06] <Ubugtu> Malone bug 44246 in ipsec-tools "racoon-0.6.5-4ubuntu1 fails to configure" [Medium,Confirmed]  http://launchpad.net/bugs/44246
[11:07] <carlos> :-(
[11:07] <carlos> well, at least you can work
[11:07] <danilos> yeah
[11:07] <carlos> did you see my request for help?
[11:07] <danilos> not yet, where? email?
[11:07] <carlos> danilos: yeah, email
[11:07] <carlos> I'm stalled with some tests
[11:07] <carlos> it fail and I don't find why
[11:08] <danilos> I've been setting up ADSL on my new computer, so I still started a bit late
[11:08] <carlos> don't worry
[11:10] <danilos> so, what do you need help with?
[11:10] <danilos> (until all of my email gets downloaded, which goes a bit slower at 256kbps)
[11:12] <carlos> danilos: sftp://devpad.canonical.com/home/warthogs/archives/carlos/launchpad/bug-44214/
[11:12] <carlos> that branch
[11:12] <carlos> and test translationimportqueue.txt
[11:14] <danilos> sure, I'm checking it out right now
[11:15] <danilos> I got so used to 1-2mbps connection, that all this is now terribly slow ;)
[11:15] <carlos> :-P
[11:31] <Ubugtu> New bug: #62584 in soyuz "Deathrow executioner doesn't guarantee stay of execution time" [Medium,Confirmed]  http://launchpad.net/bugs/62584
[11:40] <jordi> 123
[11:40] <carlos> jordi: 456
[11:40] <carlos> :-)
[11:47] <danilos> btw, I should probably filter translation imports into another account on the server directly, since I am only at 1200/1600 messages now
[11:50] <carlos> danilos: well, I think we should disable those emails if there are no errors with the imports
[11:50] <danilos> carlos: yeah, most likely, is there a bug about it, or should I report it?
[11:51] <carlos> report it, please
[12:10] <Ubugtu> New bug: #62595 in launchpad "Timeout to low for ISO images?" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62595
[12:20] <Ubugtu> New bug: #62598 in rosetta "Successful imports should not send email to rosetta@launchpad.net" [Wishlist,Confirmed]  http://launchpad.net/bugs/62598
[12:26] <carlos> bug #62598 a.k.a. stop spamming admins!!
[12:26] <Ubugtu> Malone bug 62598 in rosetta "Successful imports should not send email to rosetta@launchpad.net" [Wishlist,Confirmed]  http://launchpad.net/bugs/62598
[12:26] <carlos> :-P
[12:27] <danilos[brb] > ;)
[01:16] <jamesh> ddaa: I've done a bit more work untangling the $series/+source form.  I'd appreciate if you could take a quick look over the action button implementations for the sourceadmin functionality.
[01:17] <ddaa> URL?
[01:17] <jamesh> https://devpad.canonical.com/~jamesh/pending-reviews/jamesh/launchpad/bug-50569/full-diff
[01:18] <ddaa> bah, okay, I'll figure out the branch from that
[01:18] <jamesh> the changes in lib/canonical/launchpad/browser/productseries.py are the interesting ones as far as this goes
[01:19] <jamesh> I got rid of IProductSeriesSourceSet and IProductSeriesSource while doing this too ...
[01:19] <ddaa> I was hardly making sense at all of that code before, so I am mostly interested in the UI result
[01:19] <ddaa> jamesh: there's a bug open on merging those classes, you can take it
[01:19] <jamesh> yep
[01:20] <jamesh> the ProductSeriesView class is down to 170 lines after pulling the +source/+sourceadmin stuff out
[01:21] <jamesh> ddaa: the "FTP details" bit will be moved from the +source form soon, so pretend it isn't there when looking at the changes.
[01:28] <ddaa> jamesh: maybe remove the "# DEPRECATED" in browser.bazaar, it's just confusing and has not enough information to be useful. 
[01:29] <jamesh> both, or just for /bazaar/series ?
[01:30] <ddaa> I was thinking of /bazaar/series
[01:30] <ddaa> I dunno which other one you're thinking of
[01:30] <jamesh> done.
[01:30] <jamesh> ddaa: in that class, there are two occurences of "# DEPRECATED"
[01:31] <ddaa> hu?
[01:31] <ddaa> products?
[01:31] <ddaa> WTF is that for
[01:31] <jamesh> ddaa: I can traverse like this: https://launchpad.net/bazaar/products/launchpad
[01:31] <ddaa> ???
[01:32] <ddaa> there's a problem with cruft in launchpad
[01:32] <jamesh> it changes the layer, so I suppose it might have been intended that "/bazaar/products/foo would display the same as "/products/foo/+branches" does
[01:32] <jamesh> but it can probably go completely
[01:33] <jamesh> of course, 'series' could probably just be a view on /bazaaar
[01:34] <jamesh> rather than using IProductSeriesSet as a context
[01:34] <ddaa> that page is also quite crufty
[01:34] <ddaa> for example the "Ready" checkbox is no longer useful
[01:34] <ddaa> it appears to ignore disabled products
[01:34] <ddaa> I mean, not ignore
[01:35] <ddaa> it has the old crazy js hack from plone that prevent keyboard navigation of the table
[01:36] <jamesh> I updated/simplified that template a little, btw
[01:36] <ddaa> but since it's only for admin use, it's not a biggie
[01:36] <jamesh> so you can navigate with the keyboard
[01:39] <ddaa> jamesh: FYI, I think the ProductSeries.syncCertified is buggy: it checks for a non-null timestamp instead of looking for the value of the importstatus
[01:39] <ddaa> well... which makes senses in the context it is used in allowCertify...
[01:40] <ddaa> I also sometimes need to put an import into production without going through autotest first, like the python import
[01:40] <ddaa> to short out the double import
[01:42] <ddaa> In the current design, an import should allowCertify if it's DONTSYNC, TESTING, TESTFAILED or AUTOTESTED
[01:43] <ddaa> eventually, I want to redesign importstatus, but it's not yet clear how.
[01:43] <ddaa> that would probably take the value of import_branch into account
[01:43] <cprov> carlos: ping
[01:44] <carlos> cprov: pong
[01:44] <carlos> did you see the bug report and the mail thread about buildd vs Rosetta?
[01:45] <cprov> carlos: hi dude, yep, process-accepted isn't using READ_COMMITED yet
[01:45] <cprov> carlos: I'll request stub quick review and get it done
[01:46] <carlos> cprov: Oh, I thought you tried it and failed...
[01:47] <carlos> cprov: ok, thanks
[01:47] <stub> There was a bug where the setting was not taking effect which might have blocked the fix - I don't remember. 
[01:48] <jamesh> ddaa: thanks.  We probably want to disallow these options if the rcstype isn't one of CVS or SVN too, right?
[01:49] <ddaa> Well...
[01:50] <ddaa> Actually, there should be a constraint, (rcstype = 0) = (importstatus is NULL)
[01:50] <ddaa> if the rcstype is any of the deprecated type, the behaviour is undefined :)
[01:51] <jamesh> in the state my branch is in, it'll set rcstype = BAZAAR if that checkbox gets checked
[01:51] <jamesh> s/checkbox/radio button/
[01:51] <ddaa> hu?
[01:51] <ddaa> which checkbox?
[01:51] <jamesh> the "Bazaar" radio button
[01:52] <ddaa> please do not use that
[01:52] <ddaa> it would get in the way of separating ExternalBranch from ProductSeries
[01:53] <jamesh> okay.  I'll look at refactoring how I do that part of the code.
[01:55] <elmo> cprov/malcc: drescher:
[01:56] <elmo>  /dev/cciss/c0d0p1     533G  481G   26G  95% /
[01:56] <malcc> elmo: Argh
[01:57] <malcc> elmo: Did we ever resolve for you whether or not that bunch of stuff could be deleted?
[01:57] <elmo> malcc: we did it and it was
[02:01] <stub> cprov: r=stub on the transaction isolation fix
[02:02] <cprov> stub: thank you !
[02:02] <stub> Done a test run anywhere, or is the test suite enough now?
[02:07] <ddaa> jamesh: in your branch, http://launchpad.dev/products/firefox/1.0 is broken
[02:07] <ddaa> as in oops
[02:07] <jamesh> gar.  I was probably a bit over-eager in cleaning things up
[02:08] <ddaa> the hct-status stuff is used in a lot of places
[02:09] <ddaa> jamesh: I think the Bazaar branch thing should be independent from the CVS/SVN stuff
[02:09] <ddaa> as it is actually in the underlying database
[02:10] <ddaa> It's initial value should be something like:
[02:10] <ddaa> empty if user_branch and import_branch are both null
[02:10] <ddaa> user_branch if user_branch is set
[02:10] <ddaa> import_branch if user_branch is null and import_branch is set
[02:11] <ddaa> setting it to a value != from import_branch sets user_branch
[02:11] <ddaa> setting it to a value == import_branch clears user_branch
[02:12] <jamesh> The alternative would be to just point people at +edit
[02:12] <jamesh> might be easier than the alternatives
[02:13] <ddaa> I cannot speak about implementation, but I think what I described would be quite intuitive to use
[02:13] <ddaa> but I'm very strongly biased...
[02:13] <jamesh> ddaa: ignoring the "bazaar branch" option on the form for now, it is possible to submit the form with no details entered.  The action buttons will need to handle that situation
[02:14] <ddaa> mh... I am not sure, are you asking a question?
[02:16] <jamesh> yeah: how should the buttons act if rcstype == NONE?
[02:17] <ddaa> it should be allowed in some circumstances
[02:18] <ddaa> allowed to Edit (owner) if importstatus < PROCESSING (not in production)
[02:18] <ddaa> allowed to Admin (vcs-import and admin) in all cases
[02:21] <ddaa> Then, it should clear import_branch, import_status, datelastsynced, syncinterval, rcstype, cvsroot, cvsmodule, cvsbranch, cvstarfileurl, svnrepository, dateautotested, dateprocessapproved, datesyncapproved, datestarted, datefinished
[02:21] <jamesh> what I mean is that if the form has "No RCS details" selected, we don't want you to be able to put the import into production
[02:21] <ddaa> the bkrepository and targetarch* fields will be deleted when the current remove-gnuarch lands
[02:22] <ddaa> jamesh: successfully posting that form should remove all the vcs-import information
[02:22] <ddaa> so, yes, you do not want to put that into production
[02:23] <ddaa> actually, you should not even be allowed because of db constraints
[02:24] <ddaa> in ForeignBranch terms, that would be the action equivalent to deleting a ForeignBranch
[02:24] <ddaa> jamesh: I am not sure I am answering your question
[02:25] <jamesh> ddaa: I think you have explained it okay.
[02:30] <ddaa> note that the importstatus-based access restriction can lead to some interesting race conditions
[02:30] <ddaa> for example, an Edit loads the form and clears the details, an Admin posts the form to approve the import for production, and the Edit posts the form.
[02:31] <ddaa> The second post should fail. It's probably a unlikely enough race that it's okay to oops.
[02:33] <jamesh> ddaa: they should get an unauthorised exception, right?
[02:33] <jamesh> since they no longer have launchpad.EditSource permission when they post
[02:34] <ddaa> jamesh: right
[02:43] <salgado> stub, BjornT, around?
[02:43] <stub> salgado: yes
[02:44] <BjornT> salgado: i'm around, but i'm about to leave for a while
[02:45] <salgado> BjornT, stub, I'd like to discuss quickly if we should or not make Person.creation_rationale a NOT NULL and set a rationale for accounts created through the web UI
[02:45] <salgado> this is what I had in mind initially, and I actually implemented it
[02:45] <stub> What prompted the change?
[02:45] <salgado> but then at some point I thought that the rationale would only make sense for automatically created accounts
[02:46] <salgado> that is, we don't actually need a rationale for accounts created by their owners
[02:46] <stub> NULL generally means 'this hasn't been set', so it is a bit ambiguous given that the field can be NULL or rationale.UNKNOWN
[02:47] <BjornT> salgado: i think that it should be NOT NULL. that makes you think about what the rationale should be when creating new persons automatically. it's much easier to pass None, than to pass an incorrect rationale to createPerson()
[02:47] <stub> If we have a status for accounts created by their owners, then we actually know that this account was created by their owner.
[02:47] <salgado> on the other hand, having the rationale NOT NULL would make things simpler, and we could have a special rationale (something like rationale.OWNER_CREATED) for accounts created through the web
[02:47] <stub> Rather than some screwup
[02:48] <salgado> yeah, this is what I had initially
[02:48] <sabdfl> we should try to ensure that new people all have a rationale, even if that's "registered when ordering shipit CD's".
[02:48] <sabdfl> we often have people say "launchpad has an account for me and i don't know why"
[02:48] <sabdfl> when often they created those themselves!
[02:48] <stub> We can even use it to store more information. For example, OWNER_CREATED_LAUNCHPAD and OWNER_CREATED_SHIPIT etc. But that might be overkill.
[02:49] <sabdfl> this is especially true if we create the account when parsing the real world (mailing lists, po files, bug reports etc)
[02:49] <salgado> sabdfl, that, specifically, we can't tell. because from shipit we simply direct people to launchpad and ask them to create an account
[02:49] <sabdfl> salgado: trivial to fix and necessary to do so
[02:49] <jamesh> salgado: we know a URL to send people back to after they register their account though, right?
[02:49] <stub> salgado: There is a URL referencing shipit that is used to send the user back after sighup.
[02:50] <salgado> yeah, we could use the redirection url
[02:50] <sabdfl> salgado: in the case of direct person creation we absolutely must ask the person doing the creation to leave some comment on why they created the record. ideally we also get permission to email the newly-registered person, quoting that reason AND the registrant's name
[02:51] <malcc> elmo: The space all goes into our endless archive of everything ever uploaded, which grew around 40GB in August. We need an infinite disk, or a plan for when to archive/delete these. I've raised https://launchpad.net/products/soyuz/+bug/62612 as a home for discussion on what to do.
[02:51] <Ubugtu> Malone bug 62612 in soyuz "Need a drescher disk space strategy" [Undecided,Unconfirmed]  
[02:52] <salgado> sabdfl, that is what I had in mind
[02:54] <stub> salgado: Based on this discussion, I think the column should become NOT NULL and a value stored for all users.
[02:55] <salgado> stub, agreed. I'm already changing it. :)
[02:55] <salgado> stub, btw, should the UPDATE statements be moved to a separate sql script and moved to the pending/ directory?
[02:56] <ddaa> jamesh: clearing vcs import details appeared to work with your branch, but then setting them back again causes an oops
[02:56] <stub> UPDATES are fine in the database patches provided they don't modify the sample data, and are required if you are setting the column to NOT NULL.
[02:57] <salgado> I see
[02:57] <ddaa> jamesh: actually, just posting the form w/o change causes an oops: http://launchpad.dev/products/a52dec/failedbranch/+source
[02:57] <ddaa> as Foo Bar
[02:58] <ddaa> jamesh: test coverage for +source/+sourceadmin is seriously lacking, so do not assume that not breaking tests means it's good.
[02:58] <salgado> stub, how about teams; what rationale do you think we should use for them?
[02:59] <stub> Hmm... I guess the field makes no sense for teams, so the column should be NULLable but with a check constraint CHECK (creation_reason IS NULL = teamowner IS NULL). Sound reasonable?
[03:00] <salgado> yeah, I think so
[03:00] <ddaa> stub: hey, can you give some love to the db patch in sftp://devpad.canonical.com/home/warthogs/archives/david/launchpad/remove-gnuarch? It's in the DBA review queue and has r=SteveA already
[03:00] <Ubugtu> New bug: #62612 in soyuz "Need a drescher disk space strategy" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62612
[03:01] <sabdfl> stub: is it a text field, or a combination reason int not null, comment text nullable?
[03:02] <stub> sabdfl: combination int and comment text
[03:02] <sabdfl> cool
[03:02] <salgado> stub, shouldn't it be CHECK (creation_rationale IS NULL = teamowner IS NOT NULL)?
[03:03] <stub> salgado: yes
[03:04] <salgado> stub, https://devpad.canonical.com/~andrew/paste/file0TTwYT.html ; I'm adding the comments now, btw
[03:10] <stub> salgado: Will those updates mess with your sample data, or will it just reset the values?
[03:12] <salgado> stub, no, the branch includes a patch to the sampledata too
[03:13] <stub> salgado: See if make sampledata still works after building a fresh database with your patch and the updated sample data. 
[03:14] <salgado> stub, the current sampledata doesn't have the rationale for validated accounts, but I'll add them and it should pass, I think
[03:16] <SteveA> ddaa: ping
[03:16] <stub> If the patch screws the sampledata rebuilding, then we need to move the UPDATES to a post rollout data migration script and delay adding the CHECK constraint until a future rollout.
[03:17] <ddaa> SteveA: I'm about to go out to the photographer
[03:17] <ddaa> back in < 1h
[03:17] <salgado> stub, hmmm. I don't see what you mean. isn't it enough to just update the sampledata to not break the new constraint?
[03:18] <stub> salgado: There is a catch-22 situation in how the sample data is rebuilt. I can't quite recall the details unfortunately :-(
[03:20] <bradb> stub: If I \e'd a query, then quit postgres, how can I get the whole query back? \e'ing again brings up an empty editor, and line-by-line copy-and-pasting the readline history is against my religion.
[03:20] <stub> bradb: Dunno if you can.
[03:21] <bradb> hrm. blasphemy it is.
[03:23] <stub> ddaa: Huh. I missed that earlier because it is flagged merge-approved
[03:26] <salgado> stub, updated sampledata works fine with this patch: https://devpad.canonical.com/~andrew/paste/file6i8b5C.html
[03:26] <salgado> (same as the previous one, but added a name to the constraint)
[03:27] <stub> salgado: So rebuilding the sample data again works, and the diff between current.sql and newsampledata.sql does not show anything alarming? If so, r=stub
[03:28] <stub> salgado: patch-67-21-0.sql
[03:28] <salgado> stub, actually, I didn't try rebuilding the sampledata... I changed it manually. I'll see if I can rebuild it
[03:29] <salgado> yeah, it rebuilt just fine
[03:29] <salgado> thanks stub
[04:22] <kiko-zzz> hello hello
[04:30] <malcc> Morning kiko. Any thoughts on https://launchpad.net/products/soyuz/+bug/62612 ?
[04:30] <Ubugtu> Malone bug 62612 in soyuz "Need a drescher disk space strategy" [Critical,Confirmed]  
[04:30] <kiko> let's see.
[04:33] <kiko> malcc, I think that's something the distro team is best equipped to give consel on, but why don't we just throw away anything that's more than a month old?
[04:34] <malcc> kiko: Doesn't sound unreasonable
[04:35] <kiko> malcc, historically, have uploads from before that period been useful?
[04:36] <malcc> kiko: Sometimes useful, but not usually vital. A couple of times when builds have gone missing or other odd data artifacts have turned up, it's been useful to check what was originally uploaded
[04:36] <kiko> malcc, even for builds that are more than a month old?
[04:36] <malcc> kiko: I can think of one time I looked at something at least that old, but it wasn't vital that it was still there.
[04:36] <malcc> kiko: We could go for three months, we've got space for that and at least it's finite
[04:37] <kiko> malcc, fine by me as well. how much would that save today?
[04:37] <malcc> kiko: Probably around 100 gigs, don't know exactly
[04:37] <kiko> wow
[04:38] <kiko> malcc, should we chat a bit now about effects of the rollout?
[04:38] <malcc> kiko: Sure
[04:39] <kiko> malcc, privmsg or ##soyuz1.0?
[04:39] <malcc> kiko: How about ##soyuz1.0?
[04:39] <jgi> hi everyone
[04:39] <kiko> y not
[04:39] <kiko> yo jgi 
[04:39] <jgi> I'm trying to upload a new template for the WengoPhone project, but I don't see anything in the import queue
[04:40] <jgi> Could you please tell me where I should check if I've done something wrong?
[04:40] <kiko> jgi, sounds odd. matsubara can you give him a hand?
[04:41] <carlos> kiko: I can take care of that, don't worry
[04:41] <carlos> jgi: hi
[04:41] <kiko> cool
[04:41] <jgi> carlos, hi
[04:41] <carlos> jgi: where did you upload it?
[04:41] <jgi> kiko, thanks!
[04:41] <jgi> carlos, here: https://launchpad.net/products/wengophone/trunk/+pots/qtwengophone/+upload
[04:42] <carlos> jgi: that's the right place
[04:42] <carlos> let me check...
[04:46] <carlos> jgi: hmmm, I guess it's not this file: http://librarian.launchpad.net/4519061/qtwengophone_en.po (I think our system changed the filename, so don't pay attention to it)
[04:48] <carlos> jgi: I don't see any other entry that failed or was imported recently for wengophone
[04:49] <carlos> jgi: if that's the file you uploaded.... it looks broken
[04:49] <carlos> it contains translations and the file format seems like is not completely correct...
[04:52] <jgi> carlos, hmmm...
[04:53] <jgi> carlos, the file I uploaded does not contain any translation
[04:54] <carlos> jgi: this one contains just one string as translation and a lot of "              " for the other strings:
[04:54] <carlos> #: 
[04:54] <carlos>             AIMSettings
[04:54] <carlos>         #2
[04:54] <carlos> msgid ""
[04:54] <carlos> ""
[04:54] <carlos> "                Password:"
[04:54] <carlos> "            "
[04:54] <carlos> msgstr ""
[04:54] <carlos> "                Pasvorto:"
[04:54] <carlos> "            "
[04:54] <carlos> it's the second message
[04:54] <carlos> our system says that that file was imported by wengo launchpad bot
[04:55] <jgi> ok, it must have been imported a while ago
[04:55] <carlos> and the date when it was generated was on 2006-09-27 12:05+0200
[04:55] <carlos> that's today
[04:55] <jgi> ok, indeed, this file may well be wrong
[04:55] <jgi> but the last one I uploaded is probably fine, and it's different
[04:56] <jgi> for example
[04:56] <jgi> here's the entry for Password:
[04:56] <jgi> #: AIMSettings#2 GoogleTalkSettings#2 JabberSettings#2 LoginWindow#5
[04:56] <jgi> #: MSNSettings#2 SimpleIMAccountManager#1 SubscribeWengo1#9 SubscribeWengo2#4
[04:56] <jgi> #: YahooSettings#1
[04:56] <jgi> msgid "Password:"
[04:56] <jgi> msgstr ""
[04:56] <carlos> that looks better
[04:56] <carlos> let me check again...
[04:57] <WebMaven> SteveA: ping
[04:57] <carlos> jgi: could you tell me what do you have in the header of that file for 'POT-Creation-Date' ?
[04:57] <jgi> carlos, 2006-09-27 14:06
[05:00] <carlos> jgi: I don't see any trace of that file in our system
[05:00] <carlos> neither as failed, imported or waiting for being approved
[05:00] <carlos> did you see the confirmation message?
[05:00] <jgi> yes, this is what I found in the import queue
[05:00] <jgi> yep, I got the confirmation message
[05:01] <carlos> could you try again?
[05:01] <jgi> sure
[05:01] <jgi> done
[05:01] <carlos> thanks
[05:01] <carlos> jgi: I see it now
[05:01] <carlos> https://launchpad.net/rosetta/imports/+index?target=products&status=NEEDS_REVIEW&type=pot
[05:02] <carlos> hmm
[05:02] <carlos> I don't know what happened the first time...
[05:02] <carlos> jgi: did you tried it more than once?
[05:02] <jgi> carlos, yes
[05:02] <jgi> weird
[05:02] <jgi> anyway
[05:03] <jgi> thank  you very much, I'll drop you a line if the problem reappear
[05:03] <carlos> kiko, SteveA: Is there anyway to debug a file upload based on our system logs?
[05:03] <carlos> jgi: thanks
[05:03] <carlos> kiko, SteveA: either apache or zope ones
[05:05] <kiko> carlos, no, though it depends on what you mean by debug.
[05:06] <carlos> kiko: well, know whether a file upload was actually done
[05:06] <carlos> without errors
[05:07] <kiko> carlos, hmmm, not entirely sure. I guess the apache log would log a 200 versus a 500 maybe?
[05:07] <carlos> no idea
[05:26] <Ubugtu> New bug: #62632 in launchpad "Jabber account should be obsfucated like email addresses" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62632
[05:27] <ddaa> Is someone here willing to have a pre-impl chat with me about some interesting bit of cscvs (yes, there are some).
[05:27] <ddaa> ?
[05:30] <stub> bradb: Do you think Ian's problem is common? I was wondering if we need a data migration script that unsubscribes anyone from a bug they are explicitly subscribed to if they are implicitly subscribe to it.
[05:31] <bradb> stub: His filter seems somewhat specific.
[05:31] <stub> (not that this will help Ian, so I'll check and run that migration tomorrow when my brain is working)
[05:31] <bradb> stub: We could consider doing that explicit -> implicit migration though...
[05:33] <stub> something to sleep on. Might do some possible harm as well as possible good.
[05:37] <matsubara> cprov-lunch, malcc: time for a quick review (40 lines) that fixes OOPS-269C298?
[05:37] <Ubugtu> https://devpad.canonical.com/~jamesh/oops.cgi/269C298
[05:38] <malcc> matsubara: Yes
[05:38] <matsubara> malcc: https://sodium.ubuntu.com/~andrew/paste/fileKK72c1.html
[05:41] <malcc> matsubara: Yes, looks fine to me
[05:45] <matsubara> malcc: sending to pqm. thanks!
[05:47] <jordi> danilos: hey man
[05:54] <jordi> danilos: ping?
[05:55] <Ubugtu> New bug: #62634 in launchpad "Tags returned by find_tags_by_class have unexpected .string value when tag contains another tag" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62634
[06:00] <Ubugtu> New bug: #62635 in rosetta "Feature request: Template categorization" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62635
[06:18] <kiko-afk> carlos, almost finished the refactoring!
[06:19] <kiko-afk> wooo!
[06:19] <carlos> that's good news!!!
[06:19] <carlos> do you need help with test fixes?
[06:21] <kiko-afk> carlos, I may. I still need to get form posting to work again
[06:21] <kiko-afk> my work dropped about 300 lines in total!
[06:21] <carlos> cool
[06:21] <kiko-afk> carlos, do you know if there are any alt language suggestions for evolution?
[06:22] <carlos> as long as we don't miss any feature :-P
[06:22] <kiko-afk> in sampledata?
[06:22] <kiko-afk> or is there a url where I can test alt language?
[06:22] <carlos> kiko-afk: any language with translations is enough
[06:22] <kiko-afk> I'm currently testing using
[06:22] <kiko-afk> http://localhost:8089/products/evolution/trunk/+pots/evolution-2.2/es/+translate?start=0&alt=ab
[06:22] <kiko-afk> but because form posting is broken I can't add any :-(
[06:24] <carlos> kiko-afk: that template doesn't have any other translation
[06:24] <trappist> I've just noticed a doc on an xmlrpc interface for filing bugs.  are there plans for similar interfaces for finding, updating, modifying etc. existing bugs?  or does such a thing already exist?
[06:25] <kiko-afk> carlos, do any template have?
[06:25] <kiko-afk> trappist, there are plans but no implementation yet.
[06:26] <carlos> kiko-afk: http://launchpad.dev/distros/ubuntu/hoary/+source/pmount/+pots/pmount/
[06:27] <carlos> kiko-afk: chose any language there and use as alt= any other language code from that list
[06:27] <kiko-afk> woo, awesome
[06:27] <kiko-afk> thanks
[06:31] <kiko-afk> carlos, can I replace:
[06:31] <kiko-afk> Croatian (Alternate Language):   	 	
[06:31] <kiko-afk> with just
[06:31] <kiko-afk> Croatian:
[06:31] <kiko-afk> ?
[06:31] <kiko-afk> the parenthesized text doesn't really add much
[06:31] <kiko-afk> even if the user is confused as to why it's there
[06:32] <kiko-afk> the text doesn't really tell him
[06:32] <carlos> Well, Mark choose that label. It adds from where it comes
[06:32] <carlos> but I see your point
[06:32] <kiko-afk> from where it comes is great
[06:32] <carlos> anyway, we need to improve those labels
[06:32] <kiko-afk> yeah.
[06:33] <kiko-afk> I'm all for keeping Croatian
[06:33] <carlos> to note 'Comes from upstream' and things like that
[06:33] <kiko-afk> sure
[06:33] <kiko-afk> but that could be added to the string or as a note
[06:33] <cprov> matsubara: ping
[06:33] <kiko-afk> not the bold title
[06:33] <kiko-afk> okay, I'll do it, complain later :)
[06:33] <carlos> ;-)
[06:33] <matsubara> cprov: pong
[06:34] <cprov> matsubara: a similar fix is in my `buildd-ui`, see https://devpad.canonical.com/~jamesh/pending-reviews/cprov/launchpad/buildd-ui/full-diff
[06:36] <cprov> matsubara: can you merge them, the use of ID for the <div> is very interesting because you can use pagetest-helpers, which makes the tests more robust, IMO.
[06:37] <cprov> matsubara: what do you think ?
[06:37] <matsubara> cprov: indeed, but I already sent to pqm with r=malcc
[06:38] <carlos> danilos: hi, around?
[06:38] <cprov> matsubara: no problem, I will wait and merge into mine.
[06:39] <cprov> matsubara: please, request the cherrypick 
[06:41] <kiko-afk> right please do so
[06:42] <matsubara> cprov: ok.
[06:42] <cprov> matsubara: thanks 
[06:44] <jordi> danilos: ping?
[06:49] <matsubara> cprov: btw, I don't think you need to import the pagetest helper functions. they're available in the pagetest namespace.
[06:49] <cprov> matsubara: yes, just figured it out (exactly this minute), thank you ;)
[07:16] <carlos> kiko-fud: I need to leave now, please, mail me if I should do anything with your branch or if you merge it so I can resume TranslationReview
[07:27] <danilos> jordi: pong
[07:27] <kiko-afk> BjornT, are you around?
[07:28] <BjornT> hi kiko-afk 
[07:28] <kiko-afk> BjornT, quick question. you know setupWidgets(), right? are the form elements' names always prefixed by "field."? is there a way around that?
[07:30] <BjornT> kiko-afk: i don't think there is any easy way around it. it's possible to changed 'field.' to something else, but if you pass in an empty prefix, you'll get the field names prefixed with '.' (e.g. '.fieldname')
[07:30] <kiko-afk> BjornT, okay, never mind then. I'll adapt the client code.
[07:33] <danilos> anyway, going out now
[08:47] <zeeeee> hi all, how do i get the code for a project, eg https://launchpad.net/products/newt/? can i see the src using my web browser, or do i need bazaar? (what command(s) should i use on baz to check out the files?)
[08:51] <matsubara> zeeeee: $ bzr branch http://bazaar.launchpad.net/~vcs-imports/newt/main should work
[08:56] <zeeeee> thanks matsubara 
[09:05] <Ubugtu> New bug: #62663 in malone "Subscribed bug does not show on subscribed bugs list" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62663
[10:30] <kiko-afk> whew
[10:30] <kiko-afk> I think form posting now works.
[10:39] <salgado> BjornT, still around?
[10:39] <BjornT> salgado: yeah
[10:40] <salgado> BjornT, about the issue with urls_and_rationales and registered_origins, I was thinking about a simple test to check that all values of the latter are keys of the former, but I'm not sure where to place it
[10:41] <salgado> BjornT, would a test like that be okay and, if so, do you have any suggestion on where to place it?
[10:44] <Mez> hey - I've had a think. Wouldnt it be possible for rosetta to sync *.pot/*.po files from KDE's SVN ...
[10:44] <Mez> solving a major "political" issue between the 2 projects ?
[10:45] <BjornT> salgado: it was such a test i was looking for, so yes, it'd be ok. if you can't find a suitable place to put it, maybe put it in the view class' docstring?
[10:47] <salgado> BjornT, yeah, I thought about the view docstring too. guess it's okay for now
[10:52] <seb128> Mez: the political issue being that changes don't go back upstream?
[11:03] <kiko-afk> WOO! IT WORKS!
[11:03] <Mez> seb128, that and when it's changed in KDE it doesnt change in ubuntu
[11:03] <kiko-afk> man
[11:03] <kiko-afk> this SO COOL
[11:03] <seb128> Mez: an import from the SVN will not change that
[11:04] <Mez> seb128, but it could be sorted so it adds the stuff back to SVN - surely ?
[11:04] <seb128> if upstream accept to have rosetta commiting to the SVN
[11:04] <seb128> dunno about KDE but GNOME translator would not like that for sure
[11:05] <Mez> lol
[11:05] <seb128> they have some proof-reading, etc
[11:05] <Mez> well I'll have words ;)
[11:05] <seb128> rosetta quality is usually lower
[11:06] <Mez> seb128, probably ;) but it could even just email out the translations to mailing lists or something something would be nice
[11:06] <Mez> rather than nothing
[11:06] <seb128> right
[11:06] <lifeless> SteveA: who is richard wilbur ?
[11:06] <seb128> I've already discussed about that with carlos too
[11:06] <Mez> and what was said ?
[11:06] <Mez> if you dont mind me being nosy
[11:06] <seb128> Mez: it has nothing to do with sync from SVN though
[11:07] <seb128> it was said they are working on it
[11:07] <Mez> fair enough... but a sync from svn would be nice aswell ;)
[11:07] <seb128> they just have lot to do and not many people
[11:07] <seb128> sync from svn is nice
[11:07] <Mez> you already have it ?
[11:07] <seb128> it just doesn't fix the diff with upstream issue, nor the quality issue
[11:07] <seb128> no
[11:07] <seb128> "would be nice" rather
[11:07] <Mez> ;)
[11:08] <Mez> seb128, true but it's a step in the right direction - surely?
[11:08] <Mez> anyways - I tg to work :(
[11:12] <ddaa> hi lifeless
[11:12] <ddaa> I'm redesigning svn_oo.ChangesIterator, and I'd like your input to be sure I'm not being over complicated
[11:13] <ddaa> lifeless: can we have a preimpl chat on that?
[11:27] <lifeless> ddaa: yes, tonight
[11:28] <ddaa> okay, that is my tomorrow morning then
[11:29] <lifeless> you have skype ?
[11:30] <lifeless> (asterisk is still unspeakable quality for me)
[11:30] <ddaa> yes
[11:30] <lifeless> I'm rbtcollins
[11:30] <ddaa> though I'd prefer a text chat for that, since it's a seriously hairy matter
[11:30] <lifeless> we can do both
[11:40] <Docta> hey
[11:41] <Docta> i have a problem
[11:41] <Docta> can anyone tell me how i would install a program on ubuntu
[11:42] <matthewrevell> Docta: Hello - you're most likely to get a good answer in #ubuntu
[11:42] <matthewrevell> Docta: This channel is for launchpad.net
[11:43] <Docta> oh ok
[11:43] <Docta> what OS do you use
[11:44] <ddaa> lifeless: okay, I asked for your authorization
[11:44] <LarstiQ> ddaa: lifeless just went to aikido
[11:45] <ddaa> hrm
[11:46] <ddaa> s/heel/hell/
[11:47] <ddaa> LarstiQ: changeset processing is probably the most tricky problem I had to tackle
[11:47] <LarstiQ> I feel I'm missing context here?
[11:48] <ddaa> I'm just talking generally, I'm rewriting the bit of cscvs that interprets svn log entries to apply changes to a bzr tree
[11:48] <ddaa> and doing it right becomes quite hairy very quickly
[11:49] <ddaa> I have some consolation knowing that TreeTransform is one of the most voodoo parts of bzr
[11:49] <ddaa> and that generating changesets from cvs is MAJOR voodoo
[11:50] <ddaa> so it seems that anything that deals with creating or applying changeset just has to be complicated
[11:51] <LarstiQ> but patch and diff are so simple! *curses at hunks failing to apply*
[11:51] <ddaa> hum hum
[11:52] <ddaa> there was some discussion on bzr some time ago about diff implementation, and it looked far from simple
[11:52] <ddaa> not talking of patch, which AFAIK is just utterly non-correct, but has the right heuristics that make it work most of the time
[11:53] <ddaa> and there is indeed something out there that applies patch whenever possible, it's called "darcs" and very little people really understand what it actually does...
[11:54] <LarstiQ> so I understand you're having fun?
[11:54] <ddaa> some sort if highly geeky fun
[11:55] <ddaa> the sort that sends you to a padded room when you abuse it
[12:00] <mpt> Gooooooooooooooooood morning Launchpadders!