[12:04] <lucas> I'll do that tomorrow, i was just leaving :-)
[12:04] <kiko> okay, sure
[12:06] <lucas> actually it's already bug 31672
[12:06] <Ubugtu> Malone bug 31672 in malone "Use search filters for the text version of bug listings" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/31672
[12:07] <kiko> mpt, ping?
[03:22] <spiv> jamesh: Any idea why pending-reviews is breaking with AttributeError: 'BzrBranch' object has no attribute '_branch_format' on ddaa's branches?
[03:23] <jamesh> spiv: because he upgraded them to metadir format
[03:23] <jamesh> (bzr 0.8)
[03:24] <jamesh> I just added a check for attributeerror so that the rest of the page would render
[03:24] <spiv> Ah, and the bzr pending-reviews uses can't handle that?
[03:24] <jamesh> I'm currently running it against bzr 0.7
[03:24] <spiv> Right.
[03:24] <jamesh> (I switched back to 0.7 due to the inventory reweave slowdowns)
[03:25] <jamesh> Will probably switch forward again soon
[03:25] <jamesh> I talked with lifeless about using repositories to speed things up too
[03:26] <spiv> Yeah, repos sound like they'd be good for this.
[03:27] <jamesh> bzr-0.7 doesn't seem to give a nice error message in the presence of 0.8-style branches/repositories
[03:34] <jamesh> dapper sure is orange
[03:39] <jamesh> spiv: do you know if pqm will accept david's branches in the format they're now in?
[03:58] <jamesh> spiv: never mind.  I guess it must, since ddaa's last merge succeeded
[06:17] <mpt_> kiko-zzz, not yet
[06:17] <mpt_> about to do that now
[06:23] <jamesh> if anyone upgrades to dapper, and has trouble installing postgresql, this bug might help: https://launchpad.net/distros/ubuntu/+source/postgresql-common/+bug/36921
[06:23] <Ubugtu> Malone bug 36921 in postgresql-common "postgresql fails to install" [Normal,Unconfirmed]  
[06:23] <jamesh> the postgresql-common package doesn't believe that there is a 6.06 release of Ubuntu (only a 6.04 release)
[06:54] <mpt_> Burgwork, yes, the certificate problem is a known bug
[06:55] <mpt_> kiko-zzz, pong
[06:57] <mpt_> Burgwork, bug 6659
[06:57] <Ubugtu> Malone bug 6659 in launchpad "Launchpad requests user certificate from Safari, MSIE/Windows, MSIE/Mac" [Major,Confirmed]  http://launchpad.net/bugs/6659
[09:10] <robitaille> is it a new thing that we cannot edit the status of Debian bugs in LP?
[09:11] <jamesh> robitaille: yes
[09:11] <jamesh> robitaille: because debian bug statuses are edited at bugs.debian.org :)
[09:11] <robitaille> but, the status are wrong in LP
[09:11] <jamesh> that's because the debbugs status synching code isn't in operation yet :(
[09:12] <robitaille> ah...is it coming soon?
[09:12] <jamesh> I think so
[09:12] <jamesh> if you create new tasks against debian for existing bugs, the task will have a status of "unknown"
[09:13] <ajmitch> is this a recent change, not being able to change the debian bug status?
[09:13] <robitaille> I was looking at an old one, marked as fixed in Debian since 2004... malone 8333
[09:13] <Ubugtu> Malone bug 8333 in bind9 "/usr/bin/nsupdate: nsupdate barfs on tsig operation" [Major,Unconfirmed]  http://launchpad.net/bugs/8333
[09:13] <jamesh> we should probably reset the existing debian tasks to unknown til the code is in operation
[09:13] <jamesh> ajmitch: ~ 1 or 2 weeks ago
[09:13] <ajmitch> hm, I thought I could change them recently
[09:14] <ajmitch> must have been just before that
[09:14] <jamesh> the idea is that you shouldn't have to change them
[09:14] <robitaille> jamesh:  less than 1-2 week?  I think I changed some status 2-3 days ago.  Not that it matters
[09:14] <jamesh> hmm
[09:14] <robitaille> jamesh:  +1 for changing the status of these old bugs to unknown.  
[09:14] <jamesh> come to think of it, that code probably got rolled out on friday
[09:16] <ajmitch> how about those that have already been set as fixed?
[09:16] <robitaille> it makes sense that they acquire whatever status is in debian BTS
[09:17] <jamesh> ajmitch: well, once things are synchronising correctly, it won't matter
[09:17] <robitaille> might as well all make them unknown...
[09:18] <ajmitch> there's probably still some BTS info that won't be represented in malone, like tags
[09:18] <stub> It was the Friday rollout
[09:20] <robitaille> like the wontfix tag?  
[09:21] <robitaille> I guess it will have to stay open in malone
[09:24] <jamesh> ajmitch: tags?
[09:25] <jamesh> robitaille: WONTFIX is effectively rejected
[09:25] <dilys> Merge to devel/launchpad/: [trivial]  Fix bracket handling in text search queries (Bug #32071) (r3355: Stuart Bishop)
[09:27] <jamesh> spiv: trialing an updated pending-reviews script, using a persistant repository
[09:27] <ajmitch> jamesh: http://www.debian.org/Bugs/Developer has a list of tags that the BTS supports, most of them are handled by statuses in malone
[09:31] <jamesh> ajmitch: the debbugs syncing code tries to convert the list of tags to the equivalent Malone status
[09:58] <lifeless> moin moin
[09:59] <ajmitch> hi lifeless 
[10:00] <jamesh> lifeless: I started a pending-reviews run with repository support
[10:01] <lifeless> jamesh: nice. hows it looking ?
[10:01] <jamesh> dunno yet.  It is still working on ddaa's first branch
[10:01] <jamesh> I took your advice and set it up to keep the repo around between runs, creating branches beneath it as needed
[10:02] <lifeless> k
[10:04] <jamesh> lifeless: here's the changes I made: https://chinstrap.ubuntu.com/~dsilvers/paste/file5usrdG.html
[10:04] <jamesh> not sure if that is the preferred way to create the repos/branches or not
[10:05] <jamesh> lifeless: also, pygpgme tarballs are available here: http://cheeseshop.python.org/pypi/pygpgme
[10:05] <lifeless> a little convulted but ok
[10:07] <lifeless> mmm, was I asking ?
[10:07] <lifeless> I'd simply do
[10:08] <lifeless> meh, latency killing me, maybe after mail spools
[10:27] <jamesh> lifeless: I think bzr might be doing the inventory reweave thing, which seems a bit weird when pulling into an empty repository
[10:29] <lifeless> jamesh: uhm, known bug in an empty repo
[10:29] <lifeless> jamesh: will only happen the once
[10:29] <jamesh> lifeless: okay
[10:29] <lifeless> it copied a file without filtering, which is 'tsk' naughty
[10:29] <jamesh> good thing I won't be blowing away the repo then :)
[10:29] <lifeless> I need to fix that
[10:30] <jamesh> hopefully this will allow ddaa's pending branches to display again
[10:32] <jamesh> ddaa: I'm not complaining.  I would have needed to do this change sooner or later
[10:32] <jamesh> and hopefully it will give a noticeable speed boost
[10:33] <ddaa> jamesh: mh... lacking context, I guess you are upgrading the pendingmerges page to a newer bzr
[10:33] <lifeless> jamesh: just the change to a recent bzrlib will fix ddaa's branches
[10:34] <carlos> morning
[10:34] <jamesh> ddaa: https://chinstrap.ubuntu.com/~jamesh/pending-reviews/ <- your branches are red because I was using bzr-0.7, which doesn't like metadir branches
[10:35] <jamesh> ddaa: I've updated the code to use the new APIs and am waiting to see if it all works properly
[10:35] <jamesh> lifeless: I'm using the head of bzr.dev
[10:35] <ddaa> I've got my whip handy
[10:51] <ddaa> Is there a specific reason why nobody has removed debonzi's portlet-refactor branch from the pending reviews?
[10:51] <ddaa> I'd guess that by now it has probably bitrotten into uselessness
[10:55] <lifeless> ddaa: no specific reason. Probably a good thing to do
[10:55] <lifeless> ddaa: but please check if it has conflicts and tal w tih stevea or kiko first
[10:55] <lifeless> talk. with. Spelling good is.
[10:55] <lifeless> ddaa
[10:55] <lifeless> ah, thanks
[10:55] <ddaa> okay, I understand why nobod has bothered then
[11:31] <Kinnison> carlos: id you still need my help, yes
[11:34] <carlos> Kinnison: hi
[11:35] <carlos> Kinnison: I wonder how do you handle in soyuz the .tar.bz2 files
[11:35] <carlos> Kinnison: we are having problems with it 
[11:35] <carlos> https://launchpad.net/products/rosetta/+bug/1982
[11:35] <Ubugtu> Malone bug 1982 in rosetta "System Error on tar.bz2 upload" [Normal,Confirmed]  
[11:36] <carlos> and I didn't see any special case for it in soyuz, but I think you support it as an input format, right?
[11:36] <Kinnison> there's no bz2 support in source packages, no
[11:36] <Kinnison> we support bz2 compressed .deb files
[11:37] <carlos> oh, so you produce it but you don't read it?
[11:37] <Kinnison> but since we do nothing but read the filename inside the .deb and verify the controls, no, we don't read them
[11:39] <carlos> ok
[11:39] <carlos> thanks anyway
[11:46] <mpt> PQM is ignoring me
[11:46] <lifeless> how so ?
[11:47] <mpt> Completely so
[11:47] <mpt> It's not even sending failure notices
[11:47] <lifeless> is it getting the request in its queue ?
[11:47] <mpt> no
[11:47] <jamesh> mpt: are the messages being queued locally and not sent?
[11:47] <lifeless> check your mail config
[11:47] <jamesh> mpt: try running mailq
[11:48] <mpt> a-ha
[11:48] <mpt> 4 * "Host or domain name not found. Name service error for name=pqm.ubuntu.com type=MX: Host not found, try again"
[11:48] <mpt> I guess I should be sending to pqm@pqm.launchpad.net now?
[11:48] <lifeless> if someone told you to disable_dns_lookups=yes in postfix, undo that and shoot them
[11:48] <lifeless> no, the email address has not changed.
[11:49] <lifeless> $ host -t MX pqm.ubuntu.com
[11:49] <lifeless> pqm.ubuntu.com mail is handled by 10 fiordland.ubuntu.com.
[11:49] <mpt> 10:47:51@~> host -t MX pqm.ubuntu.com
[11:49] <mpt> pqm.ubuntu.com mail is handled by 10 fiordland.ubuntu.com.
[11:50] <lifeless> your postfix is either confused or misconfigured
[11:50] <lifeless> did you reconfigure it at the sprint ?
[11:50] <mpt> no
[11:50] <mpt> it was working fine there
[11:50] <mpt> and I don't know how to configure it, so I'm reasonably sure I haven't since :-)
[11:51] <mpt> something in /etc/postfix/?
[11:51] <lifeless> try sudo invoke-rc.d postfix restart
[11:51] <lifeless> -might-  help
[11:53] <mpt> That works
[11:53] <mpt> thanks lifeless and jamesh 
[11:53] <lifeless> np
[11:54] <lifeless> does it before it starts
[11:54] <lifeless> to ensure theres no crapola
[11:54] <mpt> Doing it when it finished instead would be too risky?
[11:55] <lifeless> it does it when it finishes too
[11:55] <lifeless> but theres no guarantee that it finished correctly is there :)
[11:55] <mpt> oh
[11:55] <mpt> fair enough
[11:57] <jamesh> lifeless: looks like I only got a single inventory reweave in the pending-reviews script run, as you said
[11:57] <jamesh> lifeless: it is still running through the other branches, so we'll see how it goes
[12:00] <jamesh> lifeless: I think I found something else that would speed things up: installing cElementTree ...
[12:19] <jamesh> lifeless: compare the times in the last column of https://chinstrap.ubuntu.com/~jamesh/pending-reviews.old/ with https://chinstrap.ubuntu.com/~jamesh/pending-reviews/
[12:20] <jamesh> pretty good, except for the branch that took 2 hours :)
[12:21] <lifeless> so run it again :)
[12:21] <lifeless> its looking good 
[12:22] <jamesh> yeah
[12:22] <jamesh> I'll try compiling cElementTree to see if that improves things further
[12:35] <jamesh> ddaa: your david/launchpad/baz2bzr branch seems to have disappeared in your switch to repositories
[12:36] <ddaa> yes, old abandoned crap
[12:36] <lifeless> ddaa: so edit the pending reviews page plase!
[12:45] <jamesh> lifeless: https://chinstrap.ubuntu.com/~jamesh/pending-reviews/ <- that run took 18 minutes
[12:45] <lifeless> good
[12:45] <jamesh> compared to 1.5 hours for the bzr-0.7 run
[12:46] <jamesh> which skipped all of ddaa's branches
[12:47] <jamesh> and 2:50 hours for the previous run (2:20 of which was on the first branch)
[12:53] <mpt> Come on PQM, send me a failure message
[12:53] <mpt> just one
[12:53] <mpt> please
[12:54] <lifeless> mpt: your zcml is still f*cked
[12:54] <lifeless> I'm not going to make pqm send you 100MB failure messages
[12:55] <mpt> I was sure I'd fixed that!
[12:56] <jamesh> did you push your changes?
[12:58] <mpt> yes, two hours ago
[12:59] <mpt> one minute before sending the request
[01:00] <mpt> "No module named bzrdir"
[01:02] <dilys> Merge to devel/launchpad/: [trivial]  Fixes error icon and bug context error formatting. (r3356: Matthew Paul Thomas)
[01:03] <stub> So does 'bzr init-repository' do anything useful for us?
[01:09] <jamesh> stub: if you have a working tree backed by a shared repository, and switch to another branch inside that repo using "bzr pull --overwrite", it should be a lot faster
[01:10] <stub> How do you link a working tree to a shared repository?
[01:11] <lifeless> bzr checkout
[01:11] <stub> In the repository?
[01:12] <lifeless> bzr checkout --help
[01:14] <jamesh> lifeless: it'd be good to get a howto on best practices for using bzr repositories at some point
[01:14] <lifeless> jamesh: the community is working on tha at the moment
[01:14] <jamesh> great
[01:19] <stub> bzr checkout --help mentions nothing about repositories. --lightweight looks interesting, but I don't know if we can use them with PQM (if I push a lightweight branch to chinstrap, is the result a 'normal' branch?)
[01:20] <lifeless> a lightweight checkout has no history data
[01:20] <lifeless> but the branch it refers too does
[01:20] <jamesh> stub: it seems the best way to work is to have a local repository, and store your branches (with no working trees) in that repo
[01:20] <lifeless> I'm in a meeting right now, could you jump to #bzr perhaps ?
[01:20] <jamesh> stub: then use "bzr checkout --lightweight" to create working trees of those branches
[01:21] <jamesh> stub: you can then rsync the repo as a whole to chinstrap
[01:21] <jamesh> each branch is basically just the revision-history file, so the repo will be similar in size to a single branch in bzr-0.7
[01:23] <stub> jamesh: But how do you get a branch into the repository? Is it just a case of creating a branch in that directory? 
[01:24] <jamesh> stub: I found doing a simple "bzr branch" created a branch with its own repo, so it doesn't seem that simple yet
[01:25] <jamesh> stub: I did "bzr init --format=metadir some-dir-under-the-repo", and then did a pull into that branch
[01:25] <Kinnison> I thought "bzr branch something /some/path/under/repo" worked
[01:25] <lifeless> Kinnison: if the source branch is in metadir format
[01:26] <lifeless> Kinnison: otherwise it will not upgrade and thus cannot use the repo
[01:26] <jamesh> Kinnison: it created a 0.7 style branch when I tried that while testing the pending-reviews code
[01:26] <Kinnison> what about "bzr branch --format=metadir something /some/path/under/repo"
[01:26] <Kinnison> ?
[01:26] <Kinnison> or do we not do that?
[01:27] <jamesh> I didn't see a --format in the "bzr branch" help
[01:27] <Kinnison> oh
[01:27] <lifeless> Kinnison: planned I think
[01:28] <Kinnison> lifeless: aha
[01:28] <Kinnison> jamesh: I guess the init/pull trick is the right thing then
[01:29] <lifeless> bzr checkout will do it :)
[01:29] <lifeless> not --lightweight
[01:29] <LarstiQ> iirc branch supports --format right now
[02:08] <dilys> Merge to devel/launchpad/: [trivial]  fix checkwatches.py from crashing when an UnsupportedBugTrackerVersion occurs. (r3357: Bjorn Tillenius)
[02:38] <kbrooks> how do i delete specs?
[02:59] <kbrooks> how do i delete specs?
[03:00] <Kinnison> I'm guessing that either you can't, or noone knows how
[05:22] <stub> Is Steve around this week? 
[05:22] <seb128> hi
[05:22] <seb128> bradb: ping? :)
[05:22] <kiko> stub, he arrives back in .lt on wednesday. how's zope3.2 looking?
[05:23] <stub> Its still blocked on Steve looking at stuff. Heaps of hair has grown on the branch, so I've been spending quite a few hours dealing with the fallout in the test suite (not done yet).
[05:24] <kiko> stub, does it still look a ways off? steve had hoped that most of the blockers were dealt with
[05:25] <stub>  kiko: We could have landed it last week. Now I don't know - depends on how easy it is to get the test suite running again.
[05:25] <seb128> kiko: hi. Did you figure about the "no way to edit upstream tasks not pointing to an another bug tracker" issue? Should I open a bug about it?
[05:26] <jamesh> seb128: what is the use of an upstream task that is (a) not linked to a remote bug watch and (b) is for a product that doesn't use Malone?
[05:26] <jamesh> (just wondering about the use cases)
[05:26] <kiko> stub, darn, I didn't know that. well, let's get steve and you focused on that thursday/friday and perhaps we can get it in by next week.
[05:27] <kiko> BjornT, ping?
[05:27] <David_Mills> Hi all, I'd like to know what to do with this bug I've discovered (or not): When I boot a dapper 5 live CD, I can't get static networking to work. I've looked in bugzilla.gnome.org, where they say the bug is fixed, but I can't see any trace of said fix getting into Dapper.
[05:27] <BjornT> hi kiko 
[05:27] <Kinnison> David_Mills: try asking on #ubuntu
[05:28] <David_Mills> OK, will do thanks
[05:28] <seb128> jamesh: some people abused about it and no we have no way to reject them to start :p
[05:28] <seb128> jamesh: like submitter bugged wrongly on upstream and bugs have not been triaged yet
[05:28] <kiko> BjornT!
[05:28] <jamesh> seb128: okay, so it is a legacy issue
[05:28] <seb128> :)
[05:29] <jamesh> seb128: (since you can't open new bugs against products not using Malone now)
[05:29] <jamesh> I am not sure what the plan is for that
[05:29] <bradb> seb128: pong, though i can't add much to the above discussion
[05:29] <kiko> BjornT, can you check up on what seb128 is pointing out?
[05:29] <BjornT> sure
[05:29] <seb128> bradb: no, I was going to ask you what "gnome-open http://launchpad.net" opens as browser :)
[05:30] <bradb> seb128: ah :) FF
[05:30] <seb128> bradb: are you opening http or https from evo?
[05:30] <bradb> http
[05:31] <jamesh> bradb: unless you configure a different default browser in preferences -> preferred applications
[05:31] <bradb> jamesh: bug 22687
[05:32] <BjornT> seb128: would it help setting the upstream tasks to "Unknown"? that way it wouldn't have an incorrect status. the ones linked to a bugzilla bug tracker will be synched to their correct status, and those not linked will remain as unknown.
[05:32] <seb128> what is the issue with me modifying tasks no pointed to an another bug tracker?
[05:33] <kiko> stub, are we rolling out this week? what revision?
[05:33] <stub> kiko: Don't know. Any opinions?
[05:33] <jamesh> seb128: assuming a bug watch is attached, you shouldn't have to (once the checkwatches script is running properly)
[05:33] <kiko> stub, let me look at the commit log.
[05:34] <seb128> depending what upstream task are for
[05:34] <jamesh> seb128: it should just have the correct information.
[05:34] <seb128> is "that's an upstream issue but we didn't forward it yet" a valid usecase for you?
[05:34] <BjornT> seb128: it's mostly due to added ui complexity. but if you have a strong use case, we could make it possible.
[05:35] <jamesh> seb128: is an extra bug task useful to you at that point?
[05:35] <seb128> BjornT: my usecase is that we have some stuff stucked to a wrong state and pointing to no other bug tracker, so stucked where they are
[05:35] <seb128> jamesh: not really
[05:35] <seb128> but would you prevent people to open upstream tasks when they don't set an upstream bug tracker url so?
[05:36] <jamesh> I think you need to give a bug tracker URL to do that now
[05:36] <seb128> like refuse to open a gedit upstream task if there is no bugzilla bug number given?
[05:36] <seb128> ah
[05:36] <seb128> no you don't
[05:36] <jamesh> see https://launchpad.net/distros/ubuntu/+source/evolution/+bug/22687/+upstreamtask, for instance
[05:36] <seb128> I just tried
[05:36] <seb128> https://launchpad.net/products/evolution/+bug/22687
[05:36] <jamesh> well, maybe you should :(
[05:36] <seb128> I just opened the upstream task
[05:37] <kiko> stub, what is the current revision we are running?
[05:37] <seb128> weird that you pointed the same bug I had open :p
[05:37] <BjornT> seb128: yes, that should have been cleaned up before. if we set them to Unknown, they wouldn't have an incorrect state anymore, and it would be less confusing. it sure does sound easier to me than manually updating all the upstream bug tasks.
[05:37] <seb128> oh, bradb pointed it to you before
[05:39] <seb128> BjornT: please make the upstream bug number required from now to open a new upstream task so
[05:39] <seb128> there is no point to let people open "unknow" tasks than can't be changed
[05:40] <jamesh> it should be required if the upstream hasn't specified that they use malone
[05:41] <kiko> stub, so we're running 3329. perhaps 3338? thing is, carlos wanted 3353 but that brings in a ton of new stuff that I'd rather we didn't roll out just yet.
[05:41] <kiko> stub, so perhaps 3338 + 3353?
[05:41] <kiko> stub, and next week we get a host of new stuff?
[05:41] <seb128> jamesh: what is the point to open a task you can't change?
[05:42] <jamesh> seb128: the upstream task would be editable if you opened it on Launchpad or Malone
[05:42] <seb128> ah, k
[05:42] <jamesh> since they use Malone for bug tracking
[05:42] <BjornT> seb128: yeah, i'll do that in my next patch. there is a small issue if the upstream uses a bugtracker we don't support, but we can deal with that later i guess.
[05:42] <seb128> so basically the upstream tasks turned to something like the bugzilla URL field we had
[05:42] <carlos> kiko-fud, stub: I was not sure to ask for the cherrypick.. but if it's possible... O:-)
[05:42] <seb128> with just status update indicated
[05:43] <stub> kiko-fud: I think lifeless also wanted r3348
[05:44] <stub> I'll see how the cherry picking goes tomorrow.
[05:46] <kiko-fud> stub, hmm, interesting.
[05:47] <lifeless> stub: are we doing a full rollout ?
[05:47] <stub> sounds like a rollout tomorrow
[06:18] <Severian> I found a ticket on Launchpad where I knew the answer to fix it.  I added a comment to tell the user and they say it is fixed.  The ticket was assigned to me.  I can't figure out what to do next.  I believe I should close it or answer it, but I can't find the place to do either.
[06:18] <Severian> I found a ticket on Launchpad where I knew the answer to fix it.  I added a comment to tell the user and they say it is fixed.  The ticket was assigned to me.  I can't figure out what to do next.  I believe I should close it or answer it, but I can't find the place to do either.
[06:35] <Severian> I'll ask back later.  I have other tickets I can answer, but I want to understand the process to do them right.  Bye for now.
[06:58] <kiko-fud> hello hello!
[07:07] <lifeless> updating gangotri with a config update, appservers will be down for 5 minutes
[07:08] <kiko> thanks for the heads-up lifeless 
[07:08] <kiko> what's the config update about?
[07:10] <lifeless> fixing the sftp push facility
[07:10] <kiko> is it bustificated?
[07:10] <lifeless> yes
[07:11] <kiko> can I help somehow?
[07:11] <kiko> oh, I see
[07:11] <kiko> branchpuller not configured?
[07:11] <kiko> BjornT!
[07:12] <BjornT> kiko!
[07:12] <kiko> how's it going biker?
[07:12] <kiko> I just had a fat lunch 
[07:13] <BjornT> it's still snowy here...
[07:13] <kiko> long winter you guys up north got, eh?
[07:14] <lifeless> done
[07:14] <BjornT> yeah seems like it. but it's starting to warm up and melt away now.
[07:14] <lifeless> kiko - there was a disconnect between two config items which we fixed at the sprint but was not worked around in the production config 
[07:14] <kiko> lifeless, understood
[07:14] <lifeless> it just needed a config tweak.
[07:15] <lifeless> and when the rollout happens will become irrelevant
[07:57] <sladen> can you nuke  https://launchpad.net/people/old
[07:57] <kiko> sladen, no, we can't. who is he?
[07:58] <sladen> old@broken.account 
[07:59] <kiko> I can merge it with matthew's main account.
[07:59] <kiko> does he want that?
[07:59] <sladen> sounds good, but it'll be a little hard to confirm that email address...
[08:25] <kiko> sladen, I can merge it for him, we have an interface for that now. I just need to make sure that he wants it :)
[08:25] <sladen> kiko: dunno, it's a hang-over from some badly imported bugzilla bugs
[08:26] <sladen> kiko: and I only noticed it because I found two "Matthew Garretts" subscribed to the same bugs
[08:28] <kiko> carlos, seen jamesh' recommendation wrt python-magic?
[08:28] <kiko> sladen, is he around?
[08:29] <sladen> kiko: AFAICT it's an import artifact that would be impossible to create manually because launchpad would require the email address to be confirmed before account creation
[08:29] <sladen> eg. I've reported multiple mdz's before
[08:30] <kiko> yeah, I'm pretty confident it is too
[08:30] <kiko> is he around?
[08:35] <kiko> sladen, merged -- he seems to be idle. hope he won't mind.
[08:46] <kiko> hey BjornT 
[08:49] <kiko> 04:15:49 ERROR   Failed to parse XML description for http://bugzilla.mozilla.org bugs set([u'121498',
[08:49] <kiko> +u'273524', u'223132', u'50201', u'262258', u'235115', u'316885', u'328056', u'296002', u'18401',
[08:49] <kiko> +u'31143', u'275223', u'319819', u'142994', u'156493', u'223340', u'325884', u'216132', u'325644',
[08:49] <kiko> +u'298457', u'162640', u'328417', u'328418', u'69230', u'100022', u'319847'] ): mismatched tag: line
[08:49] <kiko> +28, column 4
[08:49] <kiko> this is a bummer
[08:49] <kiko> fixable?
[08:54] <kiko> bradb, did you ever have time to look at jamesh' project bug page?
[08:58] <bradb> kiko: i might have seen it. where is it?
[09:00] <kiko> pending-reviews AFAICR
[09:02] <bradb> hm, maybe i'm thinking of the old page then
[09:03] <kiko> he has asked you to review it at least once before, hasn't he?
[09:03] <kiko> it's simple
[09:04] <bradb> I don't see any email about it.
[09:04] <kiko> funny
[09:07] <kiko> can you fish it out of pending-reviews?
[09:09] <bradb> kiko: Sure. Maybe I can review it tomorrow morning? I'm trying to get security teams into review today myself.
[09:09] <kiko> it's pretty short, but sure
[09:14] <bradb> I've taken it out of the queue and added it to my todo for tomorrow morning
[09:19] <kiko> thanks
[09:32] <kiko> carlos, ping?
[09:33] <infinitezeros> hey guys do i get the ubuntu cds for free?
[09:33] <kiko> infinitezeros, a) this is not the right channel to ask b) shipit.ubuntu.com
[09:33] <infinitezeros> kiko: shipit.ubuntu.com is that a channel?
[09:34] <kiko> https://shipit.ubuntu.com/ to be precise
[09:34] <infinitezeros> kiko: they dont talk about charges... are these free?
[09:34] <kiko> please read the FAQ at that site
[09:34] <infinitezeros> thanks
[09:39] <kbrooks> how do i delete specs?
[09:45] <infinitezeros> kiko: thanks mate
[09:46] <kiko> kbrooks, you can't right now.
[10:29] <kiko> carlos, ping?
[10:31] <kbrooks> jblack, curious.have you heard of easyubuntu?
[10:31] <carlos> kiko: pong
[10:31] <jblack> kbrooks: not offhand, no
[10:32] <kbrooks> jblack, OK. are you running ubuntu dapper?'
[10:32] <kiko> carlos!
[10:32] <kiko> what's up my man?
[10:32] <jblack> kbrooks: Yes
[10:32] <kbrooks> jblack, thanks.
[10:32] <carlos> kiko: returning to normal life ;-)
[10:32] <kiko> carlos, how's the hacking going?
[10:33] <jblack> kbrooks: On some of my machines, at any rate
[10:33] <carlos> kiko: fine, debian-installer is being translated officially 
[10:33] <kiko> wow, that is awesome
[10:33] <carlos> kiko: openoffice should be imported now too
[10:33] <carlos> and only kde is left to be imported
[10:33] <kiko> carlos, did you land all your stuff from last week?
[10:34] <carlos> well, most of dapper is ready...
[10:34] <carlos> kiko: yes
[10:34] <kiko> cool
[10:34] <kiko> so kde still pending
[10:34] <carlos> yes
[10:34] <kiko> there was something else we needed to work on before kde; what was it?
[10:34] <carlos> I'm importing the .pot files now
[10:35] <carlos> to reduce the amount of 'noise' on the import queue and will import the .po manually if we don't get an update on dapper. I need to talk with Riddell about it
[10:35] <carlos> kiko: the automatic blocking of .po files?
[10:35] <carlos> kiko: that's done, reviewed by you and landed
[10:36] <carlos> at least the plan was implement it and then KDE stuff
[10:36] <kiko> and so how is the KDE stuff looking?
[10:37] <carlos> nothing done yet, I will start with it tomorrow
[10:37] <kiko> ah, I see
[10:37] <kiko> so what's up yesterday and today?
[10:38] <carlos> bug #1982, debian installer data fix, and new upload
[10:38] <Ubugtu> Malone bug 1982 in rosetta "System Error on tar.bz2 upload" [Normal,In progress]  http://launchpad.net/bugs/1982
[10:39] <kiko> for bug 1982, did you see jamesh' comment?
[10:39] <Ubugtu> Malone bug 1982 in rosetta "System Error on tar.bz2 upload" [Normal,In progress]  http://launchpad.net/bugs/1982
[10:39] <carlos> openoffice imports + other new uploads approvals and some KDE imports too
[10:39] <kiko> rock and roll
[10:39] <carlos> kiko: yes, I'm going to modify my patch to check it directly
[10:39] <kiko> okay, awesome. wanted to make sure that was on track
[10:40] <carlos> kiko: what I'm not sure
[10:40] <kiko> man the mailspam from rosetta is looking /good/ this week!
[10:40] <carlos> is if the big endian and little endian would be a problem here
[10:40] <carlos> kiko: ;-)
[10:41] <kiko> I don't think it's a problem if you do read(3)
[10:41] <kiko> and at any rate we are big endian on the servers you will run this code on, right?
[10:41] <carlos> ok
[10:42] <carlos> kiko: well.. that woul break tests on ppc
[10:42] <carlos> s/woul/would/
[10:42] <kiko> don't think it will though -- AFAIK a read() on a file object will return a consistent result no matter what byte ordering the arch has.
[10:42] <kiko> I might be wrong, but I rarely am
[10:43] <carlos> yeah, if read handles that, it's fine ;-)
[10:43] <kiko> how much code work does KDE need?
[10:44] <carlos> kiko: I think tomorrow I would have something working
[10:44] <carlos> kiko: Oh, I just remember the other thing we talked about
[10:45] <carlos> the .pot export fix
[10:45] <carlos> we are exporint empty .pot files
[10:45] <kiko> right
[10:45] <kiko> that should be easy to fix, no?
[10:45] <kiko> testing may prove more difficult, though
[10:45] <kiko> carlos, did you see https://launchpad.net/products/rosetta/+bug/36843 btw?
[10:45] <Ubugtu> Malone bug 36843 in rosetta "Problem with wrapping in file ooo-help; file has errors" [Normal,Unconfirmed]  
[10:45] <carlos> kiko: yes, I asked for that bug report
[10:46] <carlos> but I would prefer to finish with KDE support so we can announce dapper as being ready to be translated
[10:46] <carlos> anyway, that one should be easy to fix
[10:46] <carlos> and I can work on it while waiting for make check
[10:47] <kiko> okay, just wanted to know whether I confirmed it or not.
[10:48] <carlos> hmm
[10:49] <carlos> kiko: why did you added me to the To field of the mail about process-mail.py error?
[10:49] <kiko> carlos, by mistake, ignore it.
[10:49] <carlos> ok
[10:49] <carlos> just wondering if there is something I should check.
[11:04] <kiko> carlos, is there a bug or spec about PoMsgSetPage?
[11:04] <carlos> kiko: spec
[11:04] <kiko> thanks
[11:05] <carlos> kiko: https://launchpad.net/products/rosetta/+spec/pomsgset-page
[11:05] <kiko> thanks
[11:07] <carlos> WTF
[11:07] <carlos> 35600
[11:07] <carlos> need review...
[11:07] <kiko> ?
[11:07] <carlos> What's going on!!!??
[11:07] <carlos> this smells like kde-i18n being imported...
[11:07] <kiko> carlos, is https://launchpad.net/products/rosetta/+spec/translation-uploads implemented?
[11:08] <carlos> kiko: yes
[11:08] <carlos> that's what introduced the import queue
[11:08] <kiko> anything left?
[11:10] <carlos> no, I think it's done
[11:10] <kiko> ok, cool.
[11:11] <kiko> carlos, what about https://launchpad.net/products/rosetta/+spec/rosetta-openoffice-support --?
[11:11] <kiko> and https://launchpad.net/products/rosetta/+spec/initiating-upstream-translation --?
[11:12] <carlos> that spec should be removed or marked as suppersed by https://launchpad.net/products/rosetta/+spec/rosetta-oo-import-export
[11:12] <kiko> thanks.
[11:13] <carlos> kiko: initiating-upstream-translation is now superseed by translatuon-uploads
[11:13] <kiko> ok
[11:14] <kiko> and https://launchpad.net/products/rosetta/+spec/rosetta-oo-import-export is fully implemented?
[11:14] <carlos> kiko: I need to review it
[11:14] <carlos> but I guess the answer is yes
[11:14] <carlos> as we have oo already imported
[11:14] <carlos> doko did it
[11:15] <kiko> could you review it and then confirm? tack it on your todo to get back to me on that
[11:15] <doko> carlos: already imported?
[11:15] <carlos> sure
[11:15] <carlos> doko: the import is working now
[11:15] <carlos> doko: it will take a couple of hours more...
[11:15] <carlos> doko: https://launchpad.net/rosetta/imports/+index?status=APPROVED&type=all
[11:16] <doko> cool
[11:16] <kiko> carlos, is similar-languages implemented?
[11:17] <carlos> kiko: confirmed.... around 25000 .po files coming from KDE....
[11:17] <kiko> cool
[11:17] <carlos> kiko: not so cool...
[11:17] <kiko> really?
[11:17] <carlos> we need the automatic approval of KDE....
[11:17] <kiko> it can be done later, can't it?
[11:17] <carlos> later?
[11:18] <carlos> are you going to approve 25000 .po files by hand??
[11:18] <kiko> just suggesting it doesn't block any of your immediate work. :)
[11:20] <carlos> kiko: similar-languages is not implemented
[11:20] <kiko> ok
[11:21] <kiko> what about https://launchpad.net/products/rosetta/+spec/launchpad-po-import -- ?
[11:21] <carlos> well... KDE support is already planned :-P
[11:21] <kiko> heh
[11:22] <carlos> kiko: that one is half implemented since long ago... the main missing feature is the CONTINUITY_THRESHOLD thing
[11:22] <LarstiQ> carlos: did you recently handle blender .pot generation?
[11:23] <kiko> carlos, is it an important feature?
[11:23] <carlos> LarstiQ: it's already imported, yes
[11:23] <LarstiQ> carlos: I just got told there were some problems with it
[11:23] <carlos> kiko: well, it's something that should be implemented to prevent bad imports, but not a top priority
[11:23] <kiko> ok.
[11:24] <carlos> LarstiQ: martin added the .pot generation back to dapper
[11:24] <LarstiQ> carlos: mdz or mbp?
[11:24] <carlos> LarstiQ: and yesterday, he added a header to that .pot file to be valid
[11:24] <carlos> LarstiQ: pitti
[11:24] <LarstiQ> ooh
[11:24] <LarstiQ> but yes
[11:25] <LarstiQ> carlos: so should I talk to pitti if I want to know more?
[11:25] <kiko> carlos, https://launchpad.net/products/rosetta/+spec/help-translate-page is implemented, right?
[11:26] <carlos> LarstiQ: depends on what do you want to know ;-)
[11:26] <carlos> LarstiQ: perhaps I can help you
[11:27] <carlos> kiko: right
[11:28] <LarstiQ> carlos: just wanting to know everything going on with blender :)
[11:29] <carlos> LarstiQ: perhaps pitti can help you then ;-)
[11:30] <kiko> carlos, I was reading through the rosetta-firefox spec
[11:30] <kiko> you know, it seems like most work is on the packaging side
[11:30] <carlos> kiko: right, it is
[11:30] <carlos> kiko: Rosetta changes are minimum
[11:31] <kiko> should we start nagging mdz/iwj about this?
[11:31] <kiko> carlos, also, look at:
[11:31] <kiko> http://www.rtklib.org/roundtriptests/ff_1.5rc1_xpi/pa-IN.diff
[11:32] <kiko> is it mishandling non-ascii?
[11:33] <kiko> seems to mishandle escapes
[11:33] <kiko> not too much else
[11:34] <carlos> kiko: well, we (me) are the gettext experts... (or at least we should :-P)
[11:34] <carlos> kiko: we need to finish the spec so they have a procedure to follow
[11:34] <kiko> carlos, what is left to finish in the spec? it seems like a reasonable starting point
[11:35] <carlos> kiko: well, we had some problems to get a .xpi package from the .po file
[11:35] <kiko> that's a problem they can solve
[11:35] <carlos> kiko: what's that diff about?
[11:35] <kiko> is there anything that needs deciding on the rosetta/launchpad interfaces before moving ahead?
[11:35] <kiko> carlos, a round-trip test. never mind that if you don't know what it is :)
[11:36] <carlos> kiko: that diff seems to be comparing two different encodings
[11:37] <kiko> the encoding header didn't change though
[11:37] <kiko> anyway
[11:37] <kiko> nbd
[11:37] <carlos> unicode vs latin? where ? is a number
[11:37] <kiko> so can I start talking about to with mdz?
[11:37] <carlos> kiko: well, pitti was going to work on it
[11:37] <carlos> when we give him the needed bits
[11:37] <kiko> what does he need?
[11:37] <kiko> I don't think that's a working arrangement
[11:38] <carlos> kiko: launchpad needs to have a new upload page without authentification available only inside our DC to accept uploads from people.ubuntu.com to get updates (this will be reused by debian-installer)
[11:39] <carlos> kiko: the instructions about how to get .po files to be imported into Rosetta and the instructions to get the .xpi back from Rosetta exports
[11:39] <kiko> carlos, hmmm. why can't it use the existing system of attach and upload?
[11:40] <carlos> kiko: because this is handled outside the standard upload from soyuz
[11:40] <carlos> and we should be able to use a script to do the upload
[11:40] <carlos> we talked with Steve about this at UBZ
[11:40] <carlos> and he suggested that solution
[11:41] <kiko> any reason why it should be handled outside the standard upload?
[11:43] <carlos> kiko: yes
[11:44] <carlos> a new release of firefox would imply two uploads to get valid language packs 
[11:44] <carlos> the first one will upload the new .pot file and cannot include any .po file from rosetta or we would lose the additions from upstream
[11:45] <kiko> why?
[11:45] <carlos> then, a new upload will be required that will include the .po from rosetta + the merged translations from upstream
[11:51] <kiko> but why would we lose additions from upstream?
[11:55] <carlos> because we cannot get the exports from rosetta + the additions from upstream at the same time using the usual procedure
[11:56] <carlos> kiko: firefox is not using .po files as its standard way to get translations from
[11:56] <kiko> because the rosetta export won't be included in the source package?
[11:56] <kiko> I see.
[11:57] <carlos> not in the first upload for a new version
[11:57] <carlos> kiko: this problem will be gone when we add native support for .xpi files inside Rosetta
[11:57] <kiko> well, we could ask ian to do that, couldn't we?
[11:58] <kiko> s/when/if :)
[11:58] <carlos> kiko: well, I think it's much less work that internal form
[11:58] <carlos> we need it anyway for debian-installer
[11:59] <kiko> I don't quite see why it is /much/ less work but it might simplify the packager's life, yeah
[11:59] <carlos> kiko: because we already have such form
[11:59] <carlos> kiko: it's a matter of remove the authentification
[12:01] <kiko> carlos, btw, you still need to fix permissions on that form so that jordi can go back to editing potemplates, eh?
[12:02] <carlos> right
[12:03] <kiko> bug filed?