[12:55] <_axiom> Is there no way to vote for the bugs on launchpad?
[01:12] <bradb> _axiom: nope
[01:13] <bradb> _axiom: The issue, in various forms, has been discussed.
[01:13] <bradb> _axiom: What we've gathered so far indicates that the real issue is to figure out where the smell is coming from, what the worst bugs are.
[01:14] <bradb> And the assumptions are that people (like me) are lazy, and stupid, among other limitations: http://www.well.com/~doctorow/metacrap.htm
[01:14] <bradb> So, there's a better way, I think: bug heat.
[01:16] <bradb> Flickr has a way to search photos by "most interesting". When you ponder bugs for a bit, you realize bugs can be examined in the same way. Which ones have: 1. the most subscribers? 2. the most duplicates? 3. a patch already available? 4. the largest discussion? etc.
[01:17] <bradb> voting has some issues, like that voting really, well, isn't. i.e. In a true democracy, he who gets the most votes (or owns the electronic voting machines) wins. Not so with bugs.
[01:50] <_axiom> bradb: thanks for the thought on voting, I do suscribe to bugs, but I still wish I could vote.
[01:51] <bradb> _axiom: I'm implementing nominations right now, fwiw. So you can nominate bugs for releases.
[02:45] <_axiom> bradb: nominations sounds like a great idea.  looking forward to it
[02:45] <Ubugtu> New bug: #57175 in launchpad "Bad publish command for uploading gpg key" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57175
[03:56] <jkakar> I need to "Register a bzr branch" before I can "Add a bzr" to a bug, right?
[04:05] <jamesh> jkakar: yeah
[04:05] <jamesh> jkakar: unless it is something you pushed to bazaar.launchpad.net, in which case it has already been registered
[04:06] <jkakar> jamesh: I see.  Thanks for clarifying.
[04:12] <jkakar> jamesh: So, now that I've registered my branch with Launchpad and given it a URL, at some point the supermirror will come by and slurp it up, right?
[04:12] <lifeless> yup
[04:13] <jamesh> jkakar: yeah.  It will put a mirror of it on http://bazaar.launchpad.net/
[04:13] <jamesh> and import some of the metadata into the LP database (currently only used to show the recent commits)
[04:13] <jkakar> jamesh: Ah, okay cool.  As I expected.  Thanks.
[04:46] <stub> Launchpad is going down in 15 minutes. Estimated downtime is 3.5 hours. This is to perform a large amount of data migration to open Edgy translations up under Rosetta.
[05:02] <jamesh> spiv: had a go at doing automatic dir creation in the sftp server, but have run into more code that isn't deferred-safe
[05:02] <spiv> jamesh: ah, ouch.
[05:03] <spiv> jamesh: which code?
[05:04] <jamesh> spiv: first I was looking at AdaptFileSystemUserToISFTP.makeDirectory(), which was doing self.filesystem.fetch(dirname).createDirectory(basename)
[05:04] <jamesh> that was pretty easy to convert, and meant I could manually log in via the sftp command line client and issue "mkdir ~user/product/branch" and have it succeed
[05:05] <jamesh> but bzr is trying to check if the branch exists by checking for ~user/product/branch/.bzr/branch-format
[05:05] <jamesh> the filesystem.fetch() call is essentially a sequence of dirnode.child() calls
[05:05] <jamesh> and this one now fails because the deferred isn't returned at the end of the chain
[05:06] <jamesh> changing filesystem.fetch to be deferred aware would affect a lot of call sites
[05:06] <spiv> Yeah.  Hmm.
[05:08] <spiv> jamesh: how does it check for it?  by trying to open the file?
[05:08] <jamesh> spiv: yeah.  The exception I'm getting comes from a packet_OPEN() call
[05:08] <jamesh> which fails inside the fetch() call
[05:09] <spiv> Maybe the easiest thing to do is to subclass AdaptFileSystemUserToISFTP and change how it handles openFile
[05:10] <spiv> e.g. copy-and-paste the existing implementation, but change the call to fetch
[05:10] <spiv> Make it call a "fetchDeferred" (which you'd need to write, of course...)
[05:11] <jamesh> okay.  I suppose I could do that for the makeDirectory() fix
[05:11] <spiv> A nastier hack would be to override it to just do something different for opens of "*/*/*/.bzr/branch-format", but that's too likely to break in future, aside from being just plain nasty :)
[05:12] <spiv> Changing it to call a deferred-aware version of fetch is an incremental step in the direction it needs to go anyway.
[05:14] <jamesh> I will probably need to do the same for getAttrs()
[05:15] <jamesh> so you suggest doing this on the LP side rather than modifying twisted?
[05:16] <spiv> I'd prefer a fix to Twisted, but I'm not sure we can incrementally fix this in Twisted.
[05:16] <jamesh> fair enough
[05:17] <spiv> It'd be a large change to the whole vfs package to do properly.  In the meantime, the hacks to make this work for LP are pretty small and self-contained.
[05:19] <jamesh> would you prefer this sort of hack in a separate file, or should I just put it in one of the existing source files? (sftponly.py maybe?)
[05:20] <spiv> Hmm.  Probably a seperate file, but use your judgement.
[05:40] <lifeless> jamesh: we should just mkdir the product dir automatically yes ?
[05:41] <lifeless> I dont get why .bzr/branch-format is involved, as the sm shouldn't be making the branch magically
[05:41] <jamesh> lifeless: that's what I'm trying to implement.  The problem is that doing the mkdir involves an XMLRPC call (to find the product ID)
[05:41] <lifeless> err
[05:41] <jamesh> that involves a deferred, and twisted isn't expecting a deferred there
[05:42] <lifeless> ah, so when bzr does mkdir branch in product. thats when the deferred is needed
[05:42] <jamesh> the first thing bzr does is try to open /~user/product/branch/.bzr/branch-format
[05:42] <jamesh> twisted then does fetch('/~user/product/branch/.bzr').openFile('branch-format')
[05:43] <jamesh> the fetch() call iterates over the path components calling dirnode.child() to get the next node
[05:44] <jamesh> my change was to make the child() call for "/~user" try and create the product directory if it doesn't exist, which meant returning a deferred
[05:44] <jamesh> which trips up the fetch() call
[05:44] <lifeless> so we want the branch-format open to fail
[05:45] <lifeless> I think you are hooking it in too early
[05:46] <jamesh> it is the same hook for the openFile() and makeDirectory() calls
[05:46] <lifeless> what does the twisted mkdir call do - fetch('/~user/product').mkDir('branch') ?
[05:46] <jamesh> yes
[05:46] <jamesh> that one works because the child() call that returns a deferred is at the end
[05:46] <spiv> (well, s/mkDir/makeDirectory/ iirc, but yes)
[05:47] <lifeless> so, why not do:
[05:47] <lifeless> (pseudocode)
[05:47] <jamesh> (well, I changed the makeDirectory() call to handle fetch() returning a deferred)
[05:47] <lifeless> if !product in user-map return ProductProduct(product)
[05:47] <lifeless> s/ProductP/ProxyP/
[05:48] <lifeless> and give that implementation a makeDirectory that does what it needs to do
[05:49] <jamesh> hmm
[05:50] <jamesh> so we return a different dir node than the normal SFTPServerProductDir that looks empty, but supports a createDirectory() call that looks up the productID and creates the branch
[05:51] <jamesh> that sounds like it could work and be a lot less invasive
[05:51] <jamesh> thanks
[05:51] <spiv> What if there is no product with that name?
[05:51] <jamesh> spiv: then the createDirectory() call fails :)
[05:52] <spiv> Oh, transferring the error to a mkdir further down the tree?
[05:52] <jamesh> I'll give this idea a shot and see how it works
[05:54] <jamesh> if the createDirectory() succeeds, we add a proper SFTPServerProductDir node to the UserDir and hook the new BranchDir to it
[05:54] <lifeless> right
[05:57] <lifeless> spiv: yes, the mkdir further down is what we want to fail
[05:59] <spiv> lifeless: well, "want" is perhaps not the word I'd choose, but I'll settle for it if it's the easiest way :)
[05:59] <spiv> It does seem like this scheme will work.
[05:59] <lifeless> spiv: depends on how you squint
[05:59] <spiv> So in that respect I'm happy :)
[05:59] <jamesh> spiv: the only side effect is that I'll be able to change dir to /~user/not-a-product and see an empty directory
[05:59] <lifeless> spiv: the way I'm squinting, we are not doing an implicit mkdir at the product level. rather we are saying that 'mkdir product/branch' should fail if theres no product
[06:00] <spiv> jamesh: well, it's just a minor inconsistency, basically.  Not so bad on its own...
[06:00] <lifeless> remember that sftp has no server side cwd, so its always full path consttructions
[06:00] <lifeless> jamesh: we dont need listdir to work on this thing, bzr wont try to list it.
[06:00] <jamesh> okay, so you can do a list dir in /~user/not-a-product
[06:00] <jamesh> lifeless: sure.  That's just a side effect
[06:01] <jamesh> it would be more work to not support that ...
[06:02] <lifeless> sure, either is fine
[06:02] <lifeless> jus tnoting that we dont have a need for that in the use case
[06:30] <jamesh> lifeless/spiv: seems to work fine.
[06:30] <lifeless> yay
[06:31] <jamesh> less than 100 lines of diff too ...
[07:31] <jamesh> stub: does the maintenance look like its on track?
[07:31] <jamesh> or is that difficult to measure?
[07:35] <stub> jamesh: It is difficult to measure unfortunately.
[07:35] <stub> The bulk of the time is spent on one or two SQL queries, so we can't get progress indicators.
[07:35] <jamesh> fair enough
[07:46] <jamesh> stub: I suppose when we have a pillar name blacklist, https://launchpad.net/products/malone will need renaming ...
[07:47] <jamesh> given what https://launchpad.net/malone is currently used for
[07:48] <stub> I suspect /malone will cease to exist in its current form, becoming /bugs or bugs.launchpad.net. /malone will be the Malone product (although I'd rather see just one Launchpad product instead of these pseudo product thingies)
[07:48] <jamesh> so we won't worry about the broken links?
[07:58] <spiv> stub: I agree about the pseudo products
[07:59] <stub> jamesh: We can't have our cake and eat it too in this case.
[07:59] <stub> Renaming the Malone product breaks links too remember
[08:00] <jamesh> I guess we could do apache-level redirects for the most common cases
[08:00] <stub> I'd rather not tie ourselves up in knots though. Links change. Deal with it. (is my take on the general issue)
[08:01] <stub> Not that I mess around on the UI side of things much any more ;)
[08:04] <jamesh> stub: I take it the pillar name black list would just be another table like product, project or distro with triggers that update PillarName?
[08:04] <jamesh> would make it easy to update from the web UI
[08:21] <stub> jamesh: It is just a table containing a list of regexps.
[08:21] <stub> PillarName *might* grow a trigger that checks the blacklist, but I expect that will bite us
[08:21] <jamesh> stub: okay.  If we just wanted to block particular names, having another table that filled in pillarname would have been an elegant way to do it
[08:22] <stub> We want to blacklist names like admin\d*
[08:24] <jamesh> spiv: https://devpad.canonical.com/~jamesh/pending-reviews/jamesh/launchpad/sftp-create-prefix/full-diff <- that's the patch to remove the need for --create-prefix
[08:25] <jamesh> (well, there is one small change I did since then)
[08:26] <spiv> jamesh: I've already taken a peek :)
[08:26] <spiv> jamesh: feel free to put it in my queue, I'll make sure it's reviewed tonight
[08:36] <carlos> morning
[08:36] <carlos> stub: hi, how's going Edgy opening?
[08:36] <carlos> do you need anything from me?
[08:37] <stub> Looks like it has just finished :)
[08:37] <SteveA> good morning
[08:38] <stub> 03:43:17 INFO    Starting...
[08:38] <stub> 03:43:17 INFO    Filling POTemplate table...
[08:38] <stub> 03:43:17 INFO    Filling POTMsgSet table...
[08:38] <stub> 03:44:49 INFO    Filling POMsgIDSighting table...
[08:38] <stub> 03:49:17 INFO    Filling POFile table...
[08:38] <stub> 03:52:24 INFO    Filling POMsgSet table...
[08:38] <stub> 04:25:22 INFO    Filling POSubmission table with active submissions...
[08:38] <stub> 05:45:53 INFO    Filling POSubmission table with published submissions...
[08:38] <stub> 05:56:31 INFO    Filling POSelection table...
[08:38] <stub> 06:37:05 INFO    Updating POFile's statistics
[08:38] <stub> 06:37:05 INFO    Done...
[08:38] <SteveA> stub: mpt has some code that must land on stagin within the next 1hr or so.  he had trouble pushing it from his laptop yesterday evening.
[08:38] <carlos> stub: I guess you did the Breezy -> Dapper migration first... right?
[08:38] <stub> carlos: yes. Just need to run update-stats.py now
[08:38] <carlos> stub: cool!
[08:38] <SteveA> stub: we're going to debug that now.  any reason why I shouldn't just stick it on staging when we've got that sorted?
[08:39] <stub> SteveA: Nope. Go for it.
[08:40] <carlos> stub: and seems like launchpad.net shows the right data :-P
[08:48] <stub> carlos: update-stats.py is running anyway. Should take about an hour based on past runs.
[08:49] <carlos> stub: well, I mean, that it shows the right data with the migration you did, the statistics update is still needed
[08:50] <jamesh> that's weird.
[08:51] <jamesh> I added a comment to a bug and got back a "new bug reported" email 
[08:54] <BjornT> jamesh: did you subscribe to the bug as well? there's a bug open on that.
[08:54] <jamesh> BjornT: I set myself as the assignee, so I'm an "also notified" subscriber
[08:57] <jamesh> spiv: https://launchpad.net/products/launchpad-bazaar/+bug/36888 <- this looks fixed in production.  You want to close it?
[08:57] <Ubugtu> Malone bug 36888 in launchpad-bazaar "supermirror sftp shows branches for non-hosted branches" [Medium,Confirmed]  
[08:57] <BjornT> jamesh: right. the idea was that if someone assigned you to a bug for example, then you'd get a summary of the bug. but the easiest solution was chosen; send a 'new bug reported' email to all newly notified people, which is quite confusing.
[08:57] <jamesh> BjornT: okay.  At first I thought it might have been something to do with the maintenance
[08:59] <jamesh> BjornT: one confusing area is that I don't actually get the message added to the bug when I got subscribed
[09:01] <BjornT> jamesh: hmm, you should get the comment... i'll take a look at it.
[09:01] <jamesh> BjornT: I just got the initial bug comment plus the affects, importance, assignee and status headers
[09:05] <SteveA> stub: when did staging last sync its DB with production?
[09:05] <SteveA> I see on staging that there are various files in the launchpad tree not under revision control
[09:06] <SteveA> also... why do I need to say PYTHONPATH= /usr/bin/bzr  on staging, to get bzr working?
[09:10] <SteveA> lifeless: got 2 mins for a bzr question?
[09:12] <lifeless> sure
[09:16] <stub> SteveA: Staging db finished rebuilding at 0350 UTC, from a backup started at 0110 UTC
[09:17] <stub> SteveA: bzr, I have no idea.
[09:23] <SteveA> stu1: I think there's something about the standard PYTHONPATH that means running bzr while in the launchpad tree gets the launchpad multi-tree's bzr libraries
[09:25] <jamesh> SteveA: I did a fix for the sftp server so you don't need to use --create-prefix when pushing a branch (with the help of spiv and lifeless)
[09:26] <jamesh> so we should be able to update the docs once that goes live
[09:26] <SteveA> cool
[09:26] <SteveA> I'm very happy about that
[09:26] <SteveA> was it a large change in the end?
[09:27] <jamesh> my first try would have been quite large, since I was running into some areas of twisted that weren't expecting to see deferred's
[09:27] <jamesh> lifeless came up with an alternative method that was a lot less invasive
[09:28] <jamesh> that implementation was very small and simple
[10:33] <danilos> carlos: ping
[10:33] <carlos> danilos: pong
[10:33] <danilos> carlos: what's the state of edgy migration? is it done?
[10:34] <kiko> danilos++
[10:34] <carlos> danilos: yeah, the statistics script is being run atm
[10:34] <jamesh> carlos, danilos: congratulations
[10:35] <carlos> jamesh: thank you
[10:35] <danilos> carlos: cool, happy to see that!
[10:35] <danilos> kiko: hey, what are you doing up this late? :)
[10:35] <danilos> jamesh: thanks (most of it to carlos, though!)
[10:35] <carlos> hmmm, stuart is not around... well, we have a way to know if the script ended ;-) 
[10:36] <danilos> yeah, if stats are right? :)
[10:36] <kiko> danilos, it's actually early -- I'm on london!
[10:36] <carlos> https://launchpad.net/distros/ubuntu/edgy/+translations
[10:36] <danilos> kiko: ah, that explains itI got used to you coming around at 16h or so
[10:36] <carlos> seems like the statistics update finished
[10:37] <carlos> danilos: now, we should wait one or two days until the new .pot files from Edgy are imported so we get up to date information
[10:37] <danilos> carlos: yeah, wow!
[10:37] <danilos> you think from packages?
[10:37] <carlos> danilos: yeah
[10:37] <carlos> what we have there is exactly what we got from Dapper
[10:37] <carlos> I need to check with Stuart if the poimport script is enabled
[10:38] <danilos> right, including pot's
[10:38] <carlos> right
[10:41] <mpool> mpt: ping?
[10:53] <sabdfl> mpt: 16px or 16pt?
[10:53] <sabdfl> usman says standard is 11pt?
[10:56] <danilos> carlos: what do you think of adding kde-i18n malone tag  (examples: bug 3990, bug 46982)?
[10:56] <Ubugtu> Malone bug 3990 in rosetta "rosetta should not display the first line of a message id, if it starts with _:" [High,Confirmed]  http://launchpad.net/bugs/3990
[10:56] <Ubugtu> Malone bug 46982 in rosetta "Rosetta does not accept correct KDE plural forms when there are more than 2" [Critical,Confirmed]  http://launchpad.net/bugs/46982
[10:57] <kiko> danilos, I think it's more a "high-visibility" thing, IYAM
[10:57] <carlos> danilos: I don't think we need it
[10:57] <carlos> there are only two specific bugs...
[10:57] <carlos> and new KDE versions are not even using those anymore...
[10:58] <carlos> which doesn't mean we are not going to support it...
[10:58] <mpt> mpool, pong
[10:58] <mpt> sabdfl, 16px
[10:58] <danilos> carlos: right, I forgot that KDE4 is switching away from them
[10:59] <jordi> woah, the rosetta-users thread keeps growing
[10:59] <seb128> what is the discussion about?
[11:00] <danilos> carlos: re bug 1297, should it be closed now?
[11:00] <Ubugtu> Malone bug 1297 in rosetta "Translations on 5.04 and 5.10" [Medium,Confirmed]  http://launchpad.net/bugs/1297
[11:00] <jamesh> malcc: you've still got r=jamesh on your bug-55896 branch
[11:00] <jamesh> with that change
[11:00] <malcc> jamesh: Thanks
[11:00] <carlos> danilos: yes, please, do it
[11:00] <malcc> jamesh: I was getting a bit worried, any more suggestions there'd be no code left :)
[11:03] <jamesh> malcc: it looks a lot more readable than the original, so it is more likely to be correct ...
[11:03] <malcc> jamesh: Yes, I like it much better now, thanks very much for all your suggestions
[11:04] <danilos> carlos: Rejected (because it's 5.04 -> 5.10, not 5.10 -> 6.06) or simply Fix Committed?
[11:13] <danilos> btw carlos, poimport seems to be running and well :)
[11:26] <jamesh> BjornT: re: the extra email I got when subscribing to the bug, it looks like I got two emails for the change: one including the original comment with ddaa as the sender (he opened the bug in question) and a second one with me as the sender (I made the change to the bug)
[11:30] <carlos> danilos: hi, my computer crashed
[11:30] <carlos> danilos: set it as fixed explaining that we did a 5.10 -> 6.06 migration + 6.06 -> Edgy copy
[11:30] <carlos> I already stated in that bug that we were not going to do the 5.04 -> 5.10 migration
[11:32] <carlos> oh, I see you already did it
[11:32] <carlos> danilos: thanks
[11:34] <danilos> carlos: np :)
[11:38] <danilos> carlos: what has happened with potemplatename editing? it has changed a bit, and bug 3986 doesn't seem relevant anymore?
[11:38] <Ubugtu> Malone bug 3986 in rosetta "Update links when you change a potemplatename" [Medium,In progress]  http://launchpad.net/bugs/3986
[11:40] <carlos> danilos: ?
[11:40] <carlos> it's relevant, if you change the name, we should do the redirect...
[11:41] <carlos> in fact, we already talked about where and how to fix it...
[11:41] <danilos> carlos: yeah, I have the fix ready
[11:41] <carlos> then?
[11:42] <danilos> carlos: I wanted to merge it, but new links are like http://localhost:8086/potemplatenames/5/+edit (i.e. ID instead of name in URL)
[11:42] <carlos> danilos: the bug is about potemplate editing 
[11:42] <carlos> that's the edition of potemplatenames
[11:43] <BjornT> jamesh: right. that's bug 51046.
[11:43] <Ubugtu> Malone bug 51046 in malone "The newbug-style email a new bug contact receives on product/package reassignment is confusing" [High,Confirmed]  http://launchpad.net/bugs/51046
[11:43] <danilos> ah right, sorry for bothering you: that's a problem of patches sitting for a long time
[11:44] <kiko> danilos, I won't be able to do any reviews this week, please choose someone else -- sorry
[11:45] <carlos> isn't Robert the one that choose the reviewer?
[11:46] <danilos> kiko: but the one review I'd like you to do is only a response to your initial review: I fixed some PEP-8 stuff, and cleaned-up some tests, no code changes other than that, so it should be really simple and short :)
[11:47] <danilos> kiko: it's "chart fixes" email you sent me
[11:48] <kiko> danilos, you'll need to keep nagging me about it till 9pm..
[11:48] <danilos> kiko: sure, no problem if that's the only thing to do :)
[11:49] <kiko> okay. 
[12:01] <Ubugtu> New bug: #57217 in rosetta "Parsing of format specification error" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57217
[12:01] <danilos> is user_browser equivalent to old-style 'Authorization: Basic no-priv@canonical.com:...'? or should I use anon_browser? (I guess user_browser)
[12:03] <kiko> danilos, user_browser is test@canonical.com
[12:03] <kiko> danilos, anon_browser is no user logged in.
[12:03] <mdke> jordi: around?
[12:04] <Tobias__> Hi all. I have a question to the .po import. How long does it take (very roughthly) until (a) it appears Translation Queue and (b) until the translations are available at the project?
[12:04] <carlos> Tobias__: it appears in the import queue as soon as you do the upload
[12:04] <danilos> kiko: yeah, but I am trying to replace old-style usage, and I simply need equivalent of no-priv... I'll try with user_browser, it should be equivalent from my reading
[12:05] <carlos> Tobias__: but the navigation of such queue is a bit ... difficult, I already started some code to improve that
[12:05] <carlos> Tobias__: b) depends on the kind of import you do
[12:05] <carlos> there are some situations (new .pot uploads) that need an admin review
[12:06] <mdke> I was wondering about edgy pot templates. The ubuntu-docs templates seem to be the same as for dapper, but there are no pot templates in the Edgy ubuntu-docs package (because it isn't ready for translation), have these templates just been carried over from Dapper?
[12:06] <carlos> Tobias__: if it's a direct upload inside a URL like: launchpad.net/products/..../+pots/foo/es/+upload it should be quite fast to get it imported
[12:06] <jordi> mdke: here
[12:06] <carlos> and only depends on the amount of entries in the queue
[12:07] <carlos> mdke: yes
[12:07] <carlos> mdke: we are in the process of opening Edgy
[12:07] <carlos> and first step was to copy Dapper translations
[12:07] <carlos> and after that, import all .pot files from Edgy
[12:07] <carlos> Tobias__: btw, just because we are importing Edgy... the queue is quite busy atm
[12:08] <mdke> carlos: so people will be translating the dapper templates of ubuntu-docs, even though there are no such templates in Edgy?
[12:09] <carlos> stub: I just sent you a cherry pick request. Is there any chance to get that done today?
[12:09] <carlos> mdke: well... I guess ubuntu-docs is a corner case
[12:09] <danilos> carlos: shouldn't those potemplates which didn't exist in edgy not be migrated? or did these potemplates actually exist, just were empty?
[12:09] <carlos> mdke: we do that to reuse as much as possible of the work already done in Dapper
[12:09] <mdke> don't templates change from release to release in all packages?
[12:10] <mdke> I understand importing po files, but not pot templates
[12:10] <stub> carlos: ok
[12:10] <carlos> danilos: we don't know the ones that exist or will exist in Edgy until we open it
[12:10] <carlos> mdke: we cannot import a pofile without a potemplate associated
[12:10] <danilos> mdke: yeah, but we need to import pots for referential integrity: they'll get updated after first time imports from packages
[12:10] <carlos> mdke: and templates doesn't change so much between releases
[12:11] <mdke> in that case, I'll try and update the packages ASAP
[12:11] <carlos> mdke: new additions, some removals and some changes and a lot of untouched strings
[12:11] <mdke> some names of templates may change
[12:11] <carlos> mdke: sure, and we will detect and rename them
[12:11] <mdke> great
[12:11] <carlos> evolution is a good example
[12:11] <mdke> do I need to tell you which are getting renamed?
[12:12] <carlos> mdke: yeah, that would be helpful
[12:12] <carlos> mdke: anyway, if you want, we can remove all them
[12:12] <mdke> some have been separated into separate templates too
[12:12] <carlos> mdke: but you should take care of migrate any existing translation that can be reused from Dapper
[12:12] <mdke> well, obviously it would be nice to have the dapper translations reused where strings haven't changed
[12:12] <mdke> exactly, yeah
[12:13] <carlos> stub: thanks
[12:13] <carlos> as I said, ubuntu-docs is a corner case
[12:13] <mdke> carlos: thanks for explaining
[12:13] <carlos> mdke: np
[12:17] <carlos> danilos: do you have time for a brief meeting?
[12:17] <danilos> carlos: sure
[12:20] <Ubugtu> New bug: #57220 in launchpad "product-release-finder dies with database integrity error" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57220
[12:20] <mdke> ooh, cool feature
[01:19] <danilos> carlos: please update https://launchpad.canonical.com/RosettaLandings with your stuff
[01:19] <carlos> danilos: ok, thanks!
[01:33] <carlos> cprov: hi, around?
[01:34] <cprov> carlos: yes
[01:34] <carlos> cprov: I need some help with soyuz DB
[01:34] <malcc> My advice is, put the DB down and back away
[01:34] <cprov> carlos: ehe, don't do anything with it ;)
[01:34] <carlos> malcc: ;-)
[01:34] <cprov> carlos: so, what I can do for you ?
[01:35] <carlos> cprov: I need to get the list of SourcePackageName rows in Edgy that are not part of main
[01:35] <carlos> I was using SourcePackageRelease
[01:36] <kiko> carlos, you need to query the publishing tables.
[01:36] <carlos> but Edgy could have more than one SourcePackageRelease for the same SourcePackageName so I get duplicates
[01:36] <cprov> carlos: SSPPH.status = PUBLISHED and component != 'main' 
[01:36] <kiko> carlos, select SPPH entries on edgy that refer to that release.
[01:36] <cprov> carlos: not published ;)
[01:36] <kiko> carlos, don't use SourcePackageRelease.distrorelease. it's not what you think it is.
[01:37] <carlos> kiko: it's the distro that got the upload, that's enough for what I want
[01:37] <kiko> carlos, I'm not sure it is, though.
[01:37] <carlos> I just want to cleanup the import queue from universe entries
[01:37] <kiko> hmmm.
[01:37] <kiko> well
[01:37] <carlos> so I'm sure they were imported in Edgy
[01:37] <carlos> s/imported/uploaded/
[01:38] <kiko> it doesn't matter
[01:38] <kiko> you still need the publishing tables to tell you if it's published in universe or main.
[01:38] <kiko> you can do this using a python script if you like
[01:38] <kiko> it may be easier
[01:38] <carlos> anyway, i will explore the SSPPH table ;-)
[01:38] <carlos> kiko: I'm preparing a DELETE command for Stuart
[01:39] <carlos> I prefer to use SQL for this if it's possible
[01:39] <kiko> ok
[01:39] <kiko> show us the query when you're done to ensure you got the right thing.
[01:40] <carlos> sure
[01:40] <carlos> thanks
[01:46] <Ubugtu> New bug: #57237 in soyuz "removeFile crashes because random.choice is trying to index a set" [High,Confirmed]  http://launchpad.net/bugs/57237
[01:53] <Tobias__> I have another question regarding the upload of a .po file. Who can accept a file marked as "Needs Review"? Any team member or only the "(owner)" or ...?
[01:54] <carlos> Tobias__: only Rosetta Admins are able to do it manually
[01:55] <Tobias__> Rosetta Admin != Admin of a product?
[01:55] <carlos> Tobias__: if your entry notes has a line like: "Will be imported into ..." it will be done automatically once our import scripts reach that entry
[01:56] <carlos> s/notes//
[01:56] <carlos> Tobias__: no, Rosetta admin == https://launchpad.net/people/rosetta-admins
[01:57] <Tobias__> Ok, I see "will be imported". Thus it may simply take some hours more.
[01:59] <carlos> yeah, Edgy imports are running now so the queue is a bit busy right now...
[02:00] <Tobias__> "Needs review" means indeed that Rosetta admins have to click something or will it be done all automatically by some script?
[02:02] <carlos> Tobias__: both
[02:02] <carlos> Tobias__: the script checks if it can be approved automatically
[02:03] <carlos> Tobias__: if that's possible, it changes the status to Approved
[02:03] <carlos> if it's not, it remains there until and admin approves it
[02:03] <carlos> Tobias__: the fact that it has a 'Will imported into...' legend is a good way to know that the script will be able to approve it automatically
[02:06] <Tobias__> Thanks.
[02:08] <carlos> np
[02:09] <mdz> hey hey...https://launchpad.net/distros/ubuntu/edgy/+translations
[02:09] <mdz> carlos: thanks
[02:10] <carlos> mdz: you are welcome
[02:11] <carlos> mdz: thanks danilo and stuart too that helped me to get that done
[02:30] <erdalronahi> hi carlos
[02:30] <carlos> erdalronahi: hi
[02:30] <erdalronahi> the migration worked well so far, isn't it
[02:30] <danilos> carlos: is updatescript done?
[02:30] <danilos> updatestats, that is :)
[02:30] <carlos> erdalronahi: yeah, seems like it worked ;-)
[02:30] <carlos> danilos: yeah, a couple of hours ago :-P
[02:30] <erdalronahi> should we continue our work on Edgy now, or not yet?
[02:31] <carlos> well, is better if you wait for the final announcement
[02:31] <carlos> but nothing added now will be lost
[02:31] <carlos> it's just that what we have in edgy is exactly the same we have in dapper
[02:31] <carlos> until our script finish importing the new .pot files from Edgy
[02:34] <mdke> danilos: nice email
[02:35] <mdke> good work guys
[02:35] <danilos> carlos: what are valid potemplate names when I try to rename them? nothing I tried actually works
[02:36] <carlos> danilos: IPOTemplateName.name
[02:38] <danilos> carlos: hum, but I can't rename evolution-2.2 to evolution-2.2-blah, even if it seems to be allowed
[02:38] <danilos> mdke: thanks :)
[02:39] <carlos> danilos: you need to create first a potemplatename with such name (what you try to do is a bug or a missed feature, depends on who talks about it)
[02:39] <mdke> looking forward to seeing those communication barriers broken down :)
[02:41] <carlos> see you later!
[02:41] <carlos> mdke: we will try our best. Kiko is helping there already
[02:41] <danilos> carlos: later dude, enjoy the lunch
[02:41] <mdke> great to hear it.
[02:44] <erdalronah1> carlos, my connection broke down, if you answered, I didn't get it
[02:45] <danilos> erdalronah1: I'll paste you carlos' response (he's out for the lunch)
 erdalronahi: yeah, seems like it worked ;-)
 well, is better if you wait for the final announcement
 but nothing added now will be lost
 it's just that what we have in edgy is exactly the same we have in dapper
 until our script finish importing the new .pot files from Edgy
[02:47] <erdalronah1> I got that, carlos. the other question was, will things that we add in Dapper now make it into Edgy as well, or will that be lost.
[02:49] <danilos> erdalronah1: uhm, I see above "<carlos> but nothing added now will be lost"
[02:50] <danilos> :)
[02:50] <erdalronah1> danilos, he said that for edgy, i think
[02:51] <erdalronah1> nothing added to edgy will be lost, even after synchronizing with upstream, isn't it?
[02:51] <danilos> erdalronah1: well, I, for one, know that our migration script can migrate that stuff as well; not sure when are we going to run it again, but it's worth discussing
[02:52] <danilos> erdalronah1: yeah, that's right
[02:53] <erdalronah1> That is fantastic news
[02:54] <danilos> erdalronah1: yeah, carlos really rocked hard on this one :)
[03:38] <carlos> jordi: hi, around ?
[03:42] <flacoste> bradb: ping
[03:42] <sivang> re
[03:42] <bradb> flacoste: pong
[03:43] <flacoste> bradb: we don't have any private bug in sampledata?
[03:43] <bradb> flacoste: nope
[03:44] <flacoste> bradb: shouldn't we?
[03:44] <flacoste> bradb: how do we test private bugs? the test usually create them?
[03:45] <bradb> flacoste: Yeah.
[03:46] <bradb> flacoste: For many of the privacy tests, creating a private bug, or modifying its status is an important part of the test.
[03:46] <kiko> flacoste, I won't be able to do your reviews this week. better to choose another reviewer.
[03:46] <danilos> kiko: nag time: review bug-2237 branch ;)
[03:47] <flacoste> kiko: fine
[03:47] <kiko> sorry.
[03:47] <flacoste> kiko: do you think you can have a quick look at my reply for the workflow spec and give me the ok on that?
[03:47] <flacoste> kiko:  like this week?
[03:48] <kiko> flacoste, nope. next week.
[03:49] <flacoste> kiko: ok, like monday? i will fix the support contact bug this week then
[03:49] <kiko> flacoste, suuuure.
[03:50] <flacoste> lol, that sounded convinced ;-)
[03:53] <flacoste> bradb: i'm reading bug.txt and I wonder why there is events notification as part of setting the bug private?
[03:54] <flacoste> bradb: wouldn't just setting private = True be sufficient?
[03:54] <kiko> flacoste, probably because our event triggers are in the wrong place.
[03:55] <bradb> flacoste: Things happen when a bug is set private, like all implicit subscribers get directly subscribed to the bug.
[03:55] <flacoste> bradb: don't tell me this is done by event suscribers?
[03:55] <bradb> and, yes, our event notifications are in the wrong layer
[03:56] <bradb> flacoste: yeah, event subscribers, why?
[03:57] <flacoste> i would expect that kind of behavior done in a setPrivate method() or something
[03:57] <flacoste> ortherwise it means that a client needs to trigger events to set bug private, which kind of suck API-wise
[03:57] <carlos> stub: are you doing anything in staging?
[03:58] <bradb> flacoste: couldn't you argue the same thing for most uses of events?
[03:58] <flacoste> bradb: not really
[03:58] <stub> carlos: nope
[03:58] <carlos> it's down
[03:59] <bradb> flacoste: "ortherwise it means that a client needs to trigger events to set bug private", though events are triggered for a bug that is modified in any way.
[04:00] <stub> Ahh... asuka was rebooted earlier and I didn't check to see if they had restarted staging
[04:01] <carlos> well, it's fixed now
[04:01] <flacoste> bradb: the problem is that from what i understand, setting 'bug.private = True' leaves the bug in a inconsistent state, some side effects of setting a bug won't be processed, maybe i'm understanding it wrongly
[04:01] <bradb> flacoste: Right, ISWYM.
[04:02] <flacoste> bradb: i would expect a setPrivate method or something like that to set the state correctly, not rely on some event subscribers for that
[04:02] <kiko> flacoste, agreed.
[04:02] <bradb> maybe the only strong use case we have for events is email notifications
[04:02] <kiko> bradb, what we had discussed before, right?
[04:03] <bradb> kiko: I don't remember a setPrivate discussion.
[04:03] <bradb> I remember a discussion about firing off events in the db layer, and well, the transitionToStatus precedent.
[04:04] <kiko> right
[04:04] <kiko> that's what I'm referring to
[04:04] <bradb> flacoste: Can you open a bug on the private -> setPrivate thing?
[04:05] <flacoste> bradb: sure, doing this right now
[04:05] <bradb> awesome
[04:15] <flacoste> bradb: bug 57296
[04:15] <Ubugtu> Malone bug 57296 in malone "Needs a proper API to set a bug as private" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57296
[04:17] <bradb> flacoste: thanks
[04:24] <Mez> stub, ping
[04:25] <Ubugtu> New bug: #57296 in malone "Needs a proper API to set a bug as private" [Untriaged,Confirmed]  http://launchpad.net/bugs/57296
[04:25] <SteveA> stub: any idea why a load of trial stuff gets run when I do "make run" ?
[04:28] <SteveA> hmm, perhaps an old twisted tree
[04:29] <Mez> hmm- anyone here with access to delete stuff from the supermirror or delete branches on lp ?
[04:31] <SteveA> at this time of day, it would normally be ddaa
[04:31] <SteveA> but he is on vacation
[04:31] <Mez> :'(
[04:31] <SteveA> if it can wait several hours, lifeless will be able to
[04:31] <Mez> SteveA, it's been waiting several weeks :P
[04:32] <mdz> cprov: ping
[04:32] <mdz> cprov,malcc: any idea what's going on here?  https://launchpad.net/distros/ubuntu/+source/kexec-tools/1.101-2
[04:32] <mdz> " 1.101-2  	 Superseded by  1.101-2"
[04:33] <malcc> mdz: We're looking
[04:33] <malcc> mdz: Expressions of surprise are echoing around the sprint room as I type
[04:34] <kiko> mdz, broken HTML?
[04:34] <kiko> mdz, oh, are you asking about the package superseded by itself?
[04:34] <kiko> that's just a consequence of a broken gina run
[04:35] <kiko> that was done during the rollout.
[04:35] <kiko> the package was imported twice and then the publisher kicked the older record out.
[04:35] <kiko> don't worry. :)
[04:35] <Ubugtu> New bug: #57300 in launchpad "AssertionError while approving a team membership with a expiry date in the past." [Low,Confirmed]  http://launchpad.net/bugs/57300
[04:41] <kiko> danilos, carlos: what are all these NameNotAvailable errors?
[04:42] <carlos> kiko: which NameNotAvailable errors?
[04:42] <danilos> kiko: is it about potemplate name changes?
[04:42] <kiko> carlos, danilos: see oops report please. DAILY.
[04:42] <carlos> I'm trying to get up to date with my email
[04:43] <kiko> prioritizing it helps
[04:43] <carlos> kiko: but even if I'm up to date, some context is also a good thing
[04:43] <kiko> carlos, ^^^
[04:45] <danilos> kiko: I was thinking we should first let matsubara triage things from oopses, will do from now on
[04:45] <kiko> danilos, well, he will do that, but if the first and topmost crash is yours..
[04:45] <kiko> it makes sense to be aware of it.
[04:46] <kiko> anyway, just a tip
[04:47] <danilos> kiko: sure, not that we don't have enough things on our plates already
[04:47] <carlos> kiko: it's the first time I see it
[04:48] <kiko> danilos, as long as you take care of topcrashers. you can analyze it and ask somebody else to fix it, but you should be aware of it
[04:48] <kiko> carlos, yeah, same here. I never saw it before, and I suspect it could be a single user trying to do the same thing many times
[04:49] <carlos> I guess
[04:49] <carlos> kiko: but anyway looks like a bug
[04:49] <kiko> well, all crashes are bugs. :)
[04:51] <carlos> kiko: https://sodium.ubuntu.com/~andrew/paste/fileTR8kR2.html
[04:51] <carlos> that error makes no sense
[04:52] <carlos> we got the string from the database
[04:52] <carlos> but after that, our code fails to find it again...
[04:52] <carlos> :-?
[04:55] <kiko> let's see
[04:55] <carlos> hmm
[04:55] <carlos> I think I found the problem
[04:55] <carlos> or at least the only explanation I can think on...
[04:56] <kiko> hmmm
[04:56] <flacoste> bradb: how can I check that a user is allowed to access a private bug?
[04:56] <carlos> but that means that the user was playing with the system without using our forms or he was translating while a .pot file was updated and one of the msgids was disabled in that new .pot file....
[04:57] <bradb> flacoste: The standard check_permission("launchpad.View", bug), perhaps.
[04:58] <kiko> carlos, the latter one could be, hmmm.
[04:59] <carlos> kiko: I don't see any .pot import for dapper in our queue
[04:59] <kiko> well, it was yesterday was it not?
[05:00] <carlos> and it should be there at least for 3 days
[05:00] <kiko> even if it was approved?
[05:00] <carlos> kiko: yeah, we move them to the 'IMPORTED' status
[05:00] <carlos> and leave them there for three days
[05:00] <kiko> I see.
[05:01] <carlos> just to help us to debug this kind of things
[05:01] <kiko> odd then
[05:02] <carlos> anyway, I will debug this problem
[05:02] <carlos> because there are some oops from different people
[05:02] <carlos> so I guess it's another bug that I'm missing
[05:03] <carlos> even if it's not a bug in our side, the exception raised is completely wrong...
[05:15] <kiko> hey SteveA
[05:15] <kiko> is there a way to group soyuz tests inside launchpad/doc/ ?
[05:15] <kiko> perhaps into a story even?
[05:15] <kiko> or a set of stories?
[05:25] <jamesh> kiko: grouping unrelated tests into stories is not helpful
[05:25] <jamesh> (at least the way pagetest stories are interpreted)
[05:26] <carlos> kiko: https://launchpad.canonical.com/RosettaLandings
[05:26] <carlos> kiko: is that information enough for your weekly report?
[05:26] <carlos> (sending you it by email directly)
[05:27] <kiko> carlos, well, I already do that work, going through commits.
[05:27] <kiko> carlos, what I wanted was a one-two paragraph description of user-visible changes
[05:27] <kiko> and a description of progress that happened outside of landings
[05:27] <kiko> and a description for landings in the case where the landings were very very obscure.
[05:27] <kiko> that would help me more
[05:28] <carlos> ok, so we need to change the concept of that page
[05:28] <carlos> I thought you were more interested on the landings we do
[05:28] <carlos> anyway, that's easy to do too
[05:29] <kiko> the landings I see in launchpad-commits
[05:29] <kiko> that's easy to keep track of
[05:29] <kiko> the hard part is the stuff which only you guys know about (or understand well!)
[05:30] <jamesh> kiko: if you want to group stuff under launchpad/doc into subdirectories, it should be pretty easy to modify launchpad/ftests/test_system_documentation.py to find them there
[05:30] <carlos> kiko: does it include user support? or just things related directly with launchpad server?
[05:30] <jamesh> no need to add order dependencies to currently independent tests
[05:31] <kiko> carlos, user support is good too
[05:31] <carlos> ok
[05:31] <kiko> anything that would make sense in a launchpad report
[05:31] <carlos> kiko: when are you going to send next report?
[05:33] <kiko> carlos, next tuesday, I think -- next rollout.
[05:35] <carlos> ok, we will prepare a new version of our document tomorrow and check it again with you to be completely sure that it fits what you expect
[05:35] <carlos> danilos: did you read it? ^^^^
[05:36] <danilos> carlos: not yet, I will now
[05:36] <kiko> sure thing!
[05:36] <kiko> thanks
[05:37] <carlos> danilos: it's just that we need to improve our report page
[05:37] <danilos> carlos: sure, need to add mention of new plural forms formulae etc.
[05:37] <carlos> danilos: but let's do it tomorrow in our daily meeting
[05:38] <carlos> danilos: yeah
[05:38] <danilos> carlos: sure
[05:38] <Mez> are there any reasons bugs have dissapeared from the DB?
[05:38] <carlos> Mez: As far as I know, we don't remove any bug ever
[05:40] <Mez> carlos: weird... I'm getting an OOPS-234A373
[05:40] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/234A373
[05:41] <carlos> hmm, The oops page is not working...
[05:41] <Mez> https://launchpad.net/products/ubp-hoary-unofficial/+bug/1844
[05:41] <Ubugtu> Malone bug 1844 in ubp-hoary-unofficial "k3b crashes when many files dragged into a project" [Untriaged,Unconfirmed]  
[05:41] <matsubara> carlos: that's because the oops is not available yet
[05:41] <carlos> matsubara: and we get an Internal Server Error? 
[05:41] <carlos> that's broken...
[05:42] <malcc> Yeah, we should get an OOPS for it :)
[05:42] <matsubara> carlos: yeah, it's broken. I noticed that today and will report it.
[05:43] <carlos> Mez: seems like that product doesn't exist anymore...
[05:43] <carlos> matsubara: ok, thanks
[05:43] <Mez> why would the product have been deleted?
[05:43] <carlos> I think kiko did some cleanups
[05:44] <carlos> kiko: ?
[05:44] <carlos> did you touch that one?
[05:44] <Mez> well if they're doing cleaning - could someone clear out evil bad branches ?
[05:45] <bradb> hm, that bug 1844 situation is indeed strange. the bug is still reported on that product, so it must exist in the db
[05:45] <Ubugtu> Malone bug 1844 in ubp-hoary-unofficial "k3b crashes when many files dragged into a project" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/1844
[05:46] <carlos> bradb: indeed it exists: https://launchpad.net/products/rosetta/+bug/1844
[05:46] <bradb> maybe the product was marked inactive or something?
[05:46] <carlos> bradb: but seems like the product is being hidden
[05:46] <bradb> yeah
[05:46] <carlos> I guess
[05:48] <carlos> Mez: are you using that product?
[05:49] <newz2000> bug 57298 was reported against ubuntu but really should be against the product ubuntu-website. What is the best way for me to make the proper association?
[05:49] <Ubugtu> Malone bug 57298 in Ubuntu "[wiki bug]  Link tabs float in Opera" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57298
[05:49] <carlos> Mez: if that's the case, please, file a bug against launchpad to show it again. I guess it was an error 
[05:49] <danilos> kiko: any chance of finding some time to review 2237? (as I said, only tests and style issues changed)
[05:50] <mdke> newz2000: reject the Ubuntu task and open an Upstream ubuntu-website task
[05:51] <Mez> carlos: no - I just was looking at old stuff
[05:51] <carlos> I see
[05:53] <Mez> grr
[05:53] <Mez> Does ANYONE have access to the supermirror? 
[05:53] <Mez> I just need a folder deleting
[05:54] <Mez> it's beginning to **** me off now
[05:54] <kiko> Mez, have you tried doing a bzr init to it?
[05:54] <newz2000> mdke: thanks, that was exactly what I was looking for
[05:55] <Mez> kiko ... ?
[05:55] <LarstiQ> Mez: http://bzr.richtlijn.be/bzr.create-prefix/ has a 'bzr push --force' that should help
[05:56] <Mez> bzr: ERROR: unknown long option '--force' for command push
[05:56] <LarstiQ> Mez: I don't like the naming and other aspects of it, but does it work for you?
[05:56] <LarstiQ> Mez: well yeah, you do need my branch. I can give you a patch if you want
[05:57] <Mez> LarstIQ... I dont have access to change the files for bzr
[05:58] <LarstiQ> Mez: do you mind downloading my branch then, and using the bzr from there? If it does work for you, I'll polish it up and submit to bzr.dev
[06:09] <reitblatt> Anyone know if there has been any movement on https://launchpad.net/products/malone/+bug/48860 ?
[06:09] <Ubugtu> Malone bug 48860 in malone ""Also notified" makes difficult to unsubscribe" [Critical,Confirmed]  
[06:10] <bradb> reitblatt: Not yet, sorry.
[06:10] <reitblatt> Check out Bug #47848
[06:10] <Ubugtu> Malone bug 47848 in ubiquity "should warn at partitioning stage if /boot is on XFS" [Medium,Fix released]  http://launchpad.net/bugs/47848
[06:11] <reitblatt> there have been a LOT of dupes, and a lot of people are getting upset =/
[06:11] <reitblatt> would it be possible for someone to manually unsubscribe people in that list?
[06:11] <reitblatt> just as a temp solution?
[06:12] <bradb> urgh, that is rough
[06:12] <reitblatt> I count about 90 dupes on that bug
[06:13] <reitblatt> so, at least that many people pulled in on it
[06:13] <reitblatt> it was a very popular bug ;)
[06:13] <bradb> reitblatt: a temp solution is not really possible on that bug, sorry.
[06:14] <reitblatt> any ideas how long till we get a solution then?
[06:14] <reitblatt> not trying to rush you
[06:14] <reitblatt> just like to know
[06:14] <bradb> reitblatt: i understand your pain. it depends on the solution. if you were able unsubscribe from that bug, would you expect to be just unsubscribed from the dupe that caused you to get notifications from that bug to begin with?
[06:15] <reitblatt> not my pain, I don't have too much of a problem with it
[06:15] <reitblatt> GMail handles it real nice
[06:16] <reitblatt> I'm just concerned that we may be losing future bug reports and users
[06:17] <bradb> me too
[06:18] <bradb> there's one big thing i have to get off my plate before i can get to fixing that.
[06:18] <bradb> and i've almost gotten that big thing off my plate
[06:18] <reitblatt> awesome
[06:20] <reitblatt> how many guys you got working on Malone?
[06:23] <bradb> reitblatt: officially, two. but several more on the lp dev team have fixed malone bugs.
[06:30] <Ubugtu> New bug: #57312 in rosetta "Translation form fails with NameNotAvailable exception" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57312
[06:38] <Mez> still fetching
[06:38] <Mez> aha just finished
[06:40] <lucasvo> why do .po files need a review?
[06:40] <Mez> LarstiQ, now what ?
[06:41] <LarstiQ> Mez: iirc, you have a branch you want to push, right?
[06:41] <lucasvo> and how long does it take?
[06:41] <Mez> LarstiQ - one sec
[06:42] <Mez> http://mez.pastebin.com/773330
[06:43] <LarstiQ> interesting
[06:44] <LarstiQ> lifeless: are you around?
[06:44] <Mez> I cant blow it away thats the thing I need an LP admin to do it
[06:45] <LarstiQ> Mez: do you think you might be able to delete .bzr instead?
[06:46] <Mez> theres nothing in that folder
[06:46] <LarstiQ> perhaps I'm confusing things
[06:46] <Mez> I deleted it all
[06:48] <LarstiQ> I thought you had leftovers from an interrupted push?
[06:48] <Mez> http://mez.pastebin.com/773332
[06:48] <Mez> I deleted them manually
[06:48] <Mez> but I cant delete the folder itself
[06:49] <LarstiQ> right, I can't personally help with that. But wasn't the actual goal something else?
[06:49] <Mez> to upload the damn branch
[06:50] <LarstiQ> ok, so I didn't misremember
[06:51] <LarstiQ> Mez: afaict, you should be able to 'bzr init sftp://mez@bazaar.launchpad.net/~katapult-dev/katapult/0.3.x-dev' at this point
[06:52] <Mez> http://mez.pastebin.com/773336
[06:52] <LarstiQ> could you paste the ~/.bzr.log traceback for this?
[06:54] <LarstiQ> Mez: does the create-prefix bzr behave differently for the init?
[06:55] <Mez> it works if i use your version
[06:55] <LarstiQ> you are using 0.8.2 otherwise?
[06:55] <LarstiQ> that would mean that remote-init fix only got included in 0.9, feh
[06:56] <Mez> ooh iot's working
[06:56] <Mez> mez@tiber % ~/bzr.create-prefix/bzr push                                                /home/mez/katapult/0.3.x-dev 12:49PM
[06:56] <Mez> Please rename ~/.bazaar/branches.conf to ~/.bazaar/locations.conf
[06:56] <Mez> Using saved location: sftp://mez@bazaar.launchpad.net/~katapult-dev/katapult/0.3.x-dev
[06:56] <Mez> Enter passphrase for key '/home/mez/.ssh/id_dsa':
[06:56] <Mez> Please rename ~/.bazaar/branches.conf to ~/.bazaar/locations.conf
[06:56] <Mez> I think
[06:56] <Mez> brb
[06:56] <LarstiQ> Mez: any reason you aren't renaming branches.conf? :)
[06:57] <LarstiQ> ddaa, lifeless: could you confirm deleting branches from the supermirror is strictly disallowed in all cases?
[06:57] <Mez> LarstiQ, is it meant to error out there ?
[06:58] <Mez> or should it like ...
[06:58] <Mez> carry on with upload?
[06:58] <Mez> ah it's pushing now :D
[07:08] <carlos> see you!
[07:15] <Mez> who can rescan a branch ?
[07:20] <LarstiQ> Mez: that happens automatically, if possible, ddaa or lifeless would be the ones to convince it to do so automatically
[07:21] <Mez> how often automatically ?
[07:23] <LarstiQ> the reasonable upper limit people expect is once daily, though it can happen faster
[07:23] <LarstiQ> sftp:// is accessible immediately of course, so team members can keep working
[07:24] <Mez> ah cool
[07:24] <Mez> thats useful
[07:26] <LarstiQ> https://launchpad.net/people/mez/+branch/katapult/0.3.x-dev right?
[07:26] <Mez> gah what worked for one branch didnt work properly for another
[07:26] <LarstiQ> or no
[07:27] <Mez> ?
[07:27] <LarstiQ> https://launchpad.net/people/katapult-dev/+branch/katapult/0.3.x-dev
[07:27] <Mez> https://launchpad.net/people/katapult-dev/+branch/katapult/0.3.x-dev
[07:27] <Mez> it pushed properly
[07:28] <LarstiQ> 19:26:46 < Mez> gah what worked for one branch didnt work properly for another
[07:28] <LarstiQ> what did you mean with that?
[07:28] <Mez> well for 0.3.x-dev i init'd then pushed
[07:28] <Mez> now with dev
[07:28] <Mez> I've inited and push wont work
[07:29] <LarstiQ> the init is a bit of a workaround, handy for when you have an existing dir you want to use, but can't remove it
[07:29] <LarstiQ> Mez: what other branch is this?
[07:29] <Mez> ~katapult-dev/katapult/dev
[07:30] <Mez> hmm its now working
[07:30] <Mez> weird
[07:31] <Mez> LarstiQ, ty for the help :D
[07:32] <LarstiQ> Mez: np, feel free to nag me in the future
[07:32] <LarstiQ> I can't do much about launchpad, but I can hack on bzr ;)
[07:32] <Mez> np, will do
[07:34] <salgado> bradb, around?
[07:35] <Mez> where are the instructions for using the supermirror?
[07:37] <bradb> salgado: hi, just got back
[07:40] <salgado> hey bradb.  I think I recall you saying something about "browser.getControl(name='foo').value = 'bar'"  not working properly?
[07:41] <salgado> am I crazy or you did actually notice that?
[07:42] <bradb> salgado: You might have to do .value = [...] 
[07:42] <bradb> salgado: What kind of control?
[07:42] <LarstiQ> Mez: I don't see anything on help.launchpad.net
[07:43] <LarstiQ> Mez: so I'd go with http://blogs.gnome.org/view/jamesh/2006/08/17/1 then
[07:44] <janimo> hi all, who should I ping to try reimporting some upstream svn trunks to native bzr this time, as they failed with the baz imports?
[07:44] <salgado> bradb, yeah, it's a checkbox and I did .value = [...] .  I thought you said something about it not working because of the name='foo'.
[07:45] <bradb> salgado: checkbox should be .selected = True
[07:45] <bradb> salgado: I usually write that as: browser.getControl("Label of checkbox").selected = True, for clarity
[07:46] <salgado> oh, right
[07:46] <salgado> yeah, I do that too, but I want to specify a different value for the checkbox --not one of the values that are rendered and thus have a label
[07:47] <salgado> this is obviously not the right place to test this.  I'll move it somewhere more appropriate
[07:48] <salgado> gotta run
[07:53] <bradb> salgado-afk: xx-bug-listing-unexpected-form-data.txt does that kind of testing in the URL, but that's not so good if you're doing a post, of course...
[07:53] <sivang> night all, I'm singing out for today.
[07:56] <kiko> jamesh, the issue I have is that I need a very large bit of setup done for the soyuz tests.
[07:57] <kiko> jamesh, so it would benefit us a lot if we could run them as a story
[07:57] <kiko> jamesh, setup first, and then the tests.
[08:03] <Mez> w00t :D
[08:21] <Zaxxon> ! files
[08:21] <Zaxxon> ! help
[08:21] <Zaxxon> ? help
[08:47] <liran_> how to submit new bug on launchpad?
[08:48] <bradb> liran_: Do you want to file a bug on the Launchpad application itself?
[08:48] <flacoste> liran_: https://launchpad.net/products/launchpad/+filebug
[08:48] <bradb> Or in Ubuntu, etc.
[08:49] <liran_> bradb: yeah im part of the ubuntulaptopteam so i want to submit a bug to the team
[08:50] <bradb> liran_: For Ubuntu, it's https://launchpad.net/distros/ubuntu/+filebug
[08:50] <bradb> liran_: They'll automatically get the bugmail if they're a bug contact for the package on which you file the bug.
[08:51] <liran_> bradb: you mean in the package text box i should fill up "UbuntuLaptopTeam"?
[08:51] <liran_> bradb: because i dont see anywhere else to assign the bug specifically for the team.
[08:52] <bradb> liran_: No, for the package, you should fill in whatever package the bug is in, or just leave it "I don't know"
[08:52] <bradb> liran_: You can assign it to the team only after the bug is filed.
[08:52] <Zaxxon> is anyone here using or know of chillispot ????
[08:52] <liran_> bradb: ahh i see.
[08:52] <liran_> Zaxxon: yeah i know of it.
[08:52] <liran_> bradb: thanks.
[08:52] <bradb> liran_: no prob
[08:53] <Zaxxon> is it hard to setup and use ??
[08:53] <liran_> Zaxxon: i've never set it up so i dont know
[08:53] <Zaxxon> will replce a wifi router do you think ??
[08:55] <Zaxxon> will it replce a wifi router what do you think ??
[08:55] <liran_> Zaxxon: it depends what you're looking for.
[08:55] <liran_> Zaxxon: its more for building a hot-spot-in-a-box which means managing users, radius, database, billing, reporting, etc.. if the only thing you want is a wifi router so i suggest just get one its cheaper and less of a headache
[08:56] <Zaxxon> well I'm setting up a HotSpot with tow ap's ext so looking for a good hotspot controller..
[08:56] <liran_> Zaxxon: whats your main directive though?
[08:58] <Zaxxon> to control log in's and to give usernames and passwords for access
[08:58] <Zaxxon> total admin
[09:00] <Zaxxon> liran_ thay have a web page ,,, i'll take a look 
[09:00] <Zaxxon> tks
[09:07] <liran_> bradb: i submitted the bug but i dont see where to assign it to a certain team
[09:08] <bradb> liran_: Sorry, it's not terribly obvious, but you have to click on the package name link on the bug page, in that table at the top.
[09:09] <liran_> oh i see.
[09:09] <liran_> bradb: yep thats it, thanks again.
[09:10] <bradb> liran_: no prob :)
[12:10] <bradb> BjornT: ping