[02:30] <mpt> Gooooooooooooooooooooood afternoon Launchpadders!
[02:35] <kiko-zzz> hello mpt
[02:35] <kiko-zzz> I'm the zzz man
[02:39] <jordi> zzz
[02:39] <jordi> dude
[02:39] <jordi> I'm going to be zzz tomorrow
[02:42] <kiko-zzz> I'm sending pqm patches
[02:44] <mpt> kiko-zzz, this bug importance work is sending me dangerously close to learning about SQL*Join
[02:47] <kiko-zzz> really? I wonder why
[02:52] <mpt> because now that I've fixed the DB classes to default to sorting by importance rather than by severity then priority, the list of bugs reported by X is returning bugs reported by other people too
[02:53] <mpt> it's probably just a silly mistake of mine somewhere
[02:53] <mpt> meanwhile, "Failed to load application: No module named conch.ssh"
[02:53] <spiv> mpt: you need a sourcecode/twisted directory
[02:54] <mpt> ah, thanks
[02:54] <mpt> how recent is that?
[02:54] <spiv> Since about half-way through the sprint :)
[02:57] <mpt> hmm, I've merged rocketfuel since then
[02:57] <mpt> Odd it didn't get copied in
[03:00] <spiv> Well, merging rocketfuel would have merged in the need for it, but like other sourcecode/* things, it's a seperate branch.
[03:00] <mpt> ah
[03:00] <mpt> hence the occasional need to cd sourcecode/whatever; bzr pull; cd ../..
[03:00] <spiv> Yep.
[03:01] <mpt> wow, some tests are passing now
[03:01] <spiv> Heh :)
[03:09] <dilys> Merge to devel/launchpad/: [r=fabbione,radix (what a man has to do to land a patch on a saturday)]  Fix for bug #3910: Sorting +specs table doesn't work. Allows specifying sortkey/revsortkey inside a <td> and handle that in the JS sorting code; cleans up templates that provide sortkeys. Some gratuitous cleaning up and detabifying as I go. (r3381: kiko)
[03:10] <radix> woot, I'm famous
[03:19] <mpt> It's not Saturday!
[03:19] <lifeless> it could be
[03:25] <spiv> Hmm, the runmirror cron script seems to be badly broken.
[03:26] <lifeless> thats the baz 1 one
[03:26] <lifeless> yes ?
[03:27] <spiv> lifeless: I have no idea, I just see it's sending an error report every time it runs :)
[03:28] <lifeless> hmm, maybe my lperrors subscription dies
[03:28] <lifeless> last I have is nov 11
[03:28] <lifeless> got an archive url for me? or forward me one ?
[03:29] <spiv> lifeless: https://lists.ubuntu.com/mailman/private/launchpad-error-reports/Week-of-Mon-20060403/024989.html
[03:29] <spiv> lifeless: It's alternating with rosetta-poimport.py at the moment, just take a peek at the archives...
[03:30] <spiv> (I'm glad I subscribe to error reports digests!)
[03:30] <lifeless> thats the bzr on
[03:30] <lifeless> *one*
[03:31] <lifeless> do you have time to peek at this ?
[03:31] <lifeless> its almost certainly crap data coming out of the branches-to-pull.txt page
[03:31] <lifeless> such as a URL with spaces in it
[03:32] <lifeless> I'll do a cherry pick for a fix.
[03:41] <lifeless> spiv: ping
[03:42] <spiv> lifeless: Ok, I'll look.
[03:42] <spiv> lifeless: Although...
[03:42] <lifeless> spiv: thanks. You know the url ?
[03:43] <spiv> lifeless: https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-04-01/A1
[03:43] <spiv> lifeless: There's a heap of those in the last lp error summary
[03:43] <lifeless> hah
[03:43] <lifeless> well thats the fault then
[03:43] <spiv> lifeless: So maybe runmirror is choking on the error page :)
[03:44] <lifeless> indeed
[03:44] <spiv> lifeless: Ah, presumably my change to the config values somehow broke the config being used.
[03:45] <lifeless> looking
[03:46] <lifeless> its missing the supermirrorsftp section in launchpad.conf in configs/production1/launchpad.conf
[03:46] <lifeless> can you add that ? rs=lifeless
[03:49] <lifeless> ok that should be sorted
[03:51] <spiv> Ok, I think the cron job is on a 10 minute interval, so we should find out if it worked pretty quickly.
[03:53] <spiv> lifeless: Just to production1?
[03:53] <lifeless> yep
[03:53] <spiv> Ok.
[03:53] <lifeless> only production1 offers the internal pages for this
[03:53] <spiv> Ah.
[04:12] <spiv> lifeless: Well, there are no new error reports from runmirror, so I guess it worked.
[04:12] <spiv> lifeless: Thanks
[04:12] <lifeless> np
[04:12] <lifeless> thank you for spotting it
[04:18] <radix> thanks guys :-)
[04:34] <dilys> Merge to devel/launchpad/: [rs=lifeless]  Add missing supermirrorsftp section to configs/production1/launchpad.conf, fixing http://gangotri.ubuntu.com:9000/supermirror-pull-list.txt. (r3382: Andrew Bennetts)
[04:50] <mpt> actually, make check_merge output in general
[05:16] <stub> Probably me forgetting that 'print foo,' inserts a space and I should have used 'sys.stdout.write(foo)'
[05:19] <mpt> stub, it's in random places like the middle of a "[05:20] <stub> mpt: Yup. Probably every 1024 characters if you can be bothered counting ;)
[05:20] <stub> I'll commit a fix.
[05:23] <lifeless> stub: what did you do ?
[05:23] <stub> print foo,
[05:24] <lifeless> stub: I meant where :).
[05:24] <spiv> lifeless: test_on_merge.py
[05:24] <spiv>             chunk = os.read(proc.stdout.fileno(), 1024)
[05:24] <spiv>             print chunk,
[05:25] <lifeless> spiv: ah the incremental output foo
[05:25] <spiv> lifeless: Right.
[05:25] <lifeless> could just pass stdout and stderr to the child as is;)
[05:26] <mpt> The incremental output rocks, btw
[05:26] <stub> Want to collate stdout and stderr
[05:27] <lifeless> on pqm ?
[05:29] <spiv> lifeless: Also, test_on_merge wants to watch stdout/err for timeout reasons.
[05:29] <lifeless> should really be in pqm core ;0
[05:29] <spiv> Yeah, probably.
[05:30] <spiv> lifeless: what do you make of bug 37823?
[05:31] <lifeless> I think it renders whack
[05:31] <lifeless> https://launchpad.net/products/bzr/+bug/37823
[05:31] <mpt> Ubugtu, wakey wakey
[05:31] <spiv> mpt: It msged me to say "This bug is private".
[05:52] <dilys> Merge to devel/launchpad/: [trivial]  Don't insert random spaces in test_on_merge.py output (r3383: Stuart Bishop)
[06:21] <lifeless> spiv: interesting glitch in the rules
[06:21] <lifeless> spiv: we should fix that
[06:24] <spiv> lifeless: I can't see how it would happen, if you're referring to 37823.
[06:26] <lifeless> I am
[06:32] <lifeless> ok, I'm gonna take a break, its been 8 hours straight
[06:33] <lifeless> back in a bit
[06:33] <lifeless> BjornT: look at the rendering here - is it meant to look like that ?
[06:33] <lifeless> https://launchpad.net/products/bzr/+bug/37823
[06:33] <lifeless> spiv: ddaa has fixed is branch apparently
[06:36] <spiv> lifeless: hmm, yeah, pending-reviews agrees.  Cool, I'll do that review finally :)
[06:38] <dilys> Merge to devel/launchpad/: [trivial]  Fixes bug 2250 (Rosetta shows 'appoint additional translators' even when you don't have permission to use it) and bug 6666 (visited links on bug page have insufficient contrast) . (r3384: Matthew Paul Thomas)
[06:48] <stub> mpt: Should we be dropping BugTask.priority at the same time as your other work, or leave it for the future?
[06:48] <stub> (or someone else to deal with)
[07:05] <mpt> stub, sabdfl said to leave it
[07:05] <mpt> in case we use it later
[07:06] <stub> ok
[07:06] <mpt> though dropping it would have been easier, because then I'd know *all* uses of it in the code should be removed, not just some of them :-)
[07:07] <stub> mpt: You can rename the column ;)
[07:08] <stub> If you want to confirm that all uses are removed, 'ALTER TABLE BugTask RENAME priority TO obsolete_priority' should do the trick
[08:00] <zorglub> hi
[08:01] <zorglub> are rosetta imports processed ?
[08:15] <spiv> zorglub: There's an problem with them at the moment it seems, when carlos is awake it should be resolved.
[08:17] <jamesh> spiv: w.r.t. my TacTestHandler fixes, I had a few questions
[08:17] <jamesh> TacTestSetup, even
[08:17] <spiv> jamesh: Oh?
[08:18] <jamesh> spiv: (1) some uses create separate instances of the class for setup and teardown and some keep the instance around for teardown.  Is it worth supporting both uses?
[08:19] <jamesh> and (2) before my changes, the existing implementation handles teardown of daemons if the pidfile is still there from last run.  I wonder if it would be better to add an atexit handler to remove daemons?
[08:20] <jamesh> s/remove/kill/
[08:20] <spiv> jamesh: (1) No, just support one.  I'd prefer that the instance should be kept around, because it potentially makes things simpler for the implementation, but maybe that's a YAGNI.  But there should be only one way, either way (I know both are in use atm).
[08:21] <spiv> atexit isn't sufficient -- what if the test suite died ungracefully?
[08:21] <spiv> Or even more likely, a previous tearDown didn't get to the tac teardown, because something else failed first.
[08:22] <spiv> (Or a setUp failed after starting a tac, but before completing, therefore tearDown never runs)
[08:22] <jamesh> spiv: I think the support for not keeping the instance around probably hides some cases of tests not correctly cleaning up too
[08:22] <zorglub> spiv: ok thanks
[08:22] <spiv> zorglub: Feel free to nag carlos and/or file a bug if it's not fixed soon, though :)'
[08:22] <jamesh> potentially introducing order dependence in tests
[08:23] <jamesh> so perhaps setUp() should check for the pidfile and kill the old daemon + emit a warning if it finds the daemon
[08:24] <spiv> jamesh: Sounds good.
[08:24] <spiv> jamesh: I wonder if pidfiles are even necessary if we aren't fully daemonising...
[08:25] <jamesh> spiv: well, it helps us detect a previously running daemon
[08:25] <jamesh> spiv: which is a good thing from a robustness perspective
[08:26] <spiv> I guess I'm wondering if the way we're spawning these processes now means by default they'll die when the parent does... if that's not the case, we still want the pidfiles.
[08:26] <jamesh> they don't seem to ...
[08:26] <spiv> Fair enough.
[08:27] <jamesh> I suppose we could do that if there was a pipe between the two processes -- write end in the parent, read end in the child
[08:27] <jamesh> have the child exit on HUP
[08:28] <jamesh> not sure how best to do that in the twisted framework though
[08:28] <spiv> jamesh: Well, Twisted doesn't touch the SIGHUP handler.
[08:29] <jamesh> spiv: I don't mean UNIX signals -- I mean the HUP condition from poll()
[08:29] <carlos> morning
[08:29] <jamesh> or exception from select()
[08:29] <spiv> Oh, I see
[08:30] <jamesh> it might be easier to just continue with the pidfile code ...
[08:31] <spiv> jamesh: something like twisted.internet.stdio to hook up an object to an already open pipe, and then the attached protocol would see the connectionLost event.
[08:31] <spiv> But yeah, it's a bit messy, I'd stick with the pidfile stuff atm.
[08:32] <jamesh> if we got the pipe trick working, it should be very reliable -- the write end of the pipe gets closed by the OS when the test suite exits causing the hangup
[08:34] <spiv> jamesh: Assign a bug to me, I'll look at it sometime soon.  It's a nice solution.
[08:44] <jamesh> spiv: https://launchpad.net/products/launchpad/+bug/37837
[08:44] <Ubugtu> Malone bug 37837 in launchpad "Make daemons spawned by test suite exit more reliably" [Normal,Confirmed]  
[08:45] <spiv> jamesh: Thanks.
[08:51] <lifeless> thank you god
[09:13] <spiv> carlos: around?
[09:13] <carlos> spiv: yes
[09:13] <carlos> hi
[09:14] <spiv> carlos: see my mail about rosetta-poimport.py?
[09:14] <carlos> spiv: yes, I already answered it
[09:14] <carlos> hmm
[09:14] <carlos> but my laptop didn't send the answer...
[09:14] <carlos> grrr
[09:14] <spiv> carlos: cool, zorglub was asking about imports earlier, you might want to let him know when it's fixed :)
[09:14] <carlos> spiv: it was fixed on Friday
[09:15] <spiv> carlos: Really?  That's odd.
[09:15] <carlos> spiv: but it was not cherrypicked...
[09:15] <spiv> Ah.
[09:15] <carlos> I didn't think it was necessary... until now...
[09:15] <spiv> I should say, "fixed and released" :)
[09:16] <spiv> carlos: This and runmirror have been spamming the error reports list all weekend, we've fixed the runmirror issue, it'd be nice to fix this one too.
[09:16] <spiv> It's sending an error mail every 10 minutes.
[09:17] <carlos> spiv: I know
[09:17] <carlos> spiv: with my email answer I asked stuart to cherry pick the patch
[09:17] <spiv> carlos: Ok.  Just nagging you before kiko does ;)
[09:17] <carlos> it's a one line change
[09:17] <carlos> spiv: kiko pointed me to that bug... :-P
[09:18] <spiv> :)
[09:18] <carlos> stub: hi 
[09:18] <stub> carlos: hi
[09:18] <carlos> stub: could you cherry pick r3373 ?
[09:19] <carlos> stub: or apply the change manually? it's just a matter of rename a variable name
[09:19] <carlos> spiv: thanks for bugging me ;-)
[09:20] <stub> ok
[09:20] <spiv> carlos: Anytime :)
[09:20] <carlos> stub: thanks
[09:21] <lifeless> interesting statistic I'd like to know stub
[09:21] <lifeless> stub: meantime from cherrypick request to rollout
[09:22] <lifeless> stub: I think there is a incorrect perception that it takes days to get cherrypicks out there.
[09:22] <stub> We don't do enough to give a meaningful statistic - sample size is way too small
[09:22] <spiv> lifeless: "meantime"... that's how long stub is in a grumpy mood after doing a cherrypick? ;)
[09:23] <lifeless> stub: https://wiki.launchpad.canonical.com/FasterCodeUpdates
[09:23] <lifeless> stub: I have the feeling that everything in that spec can be addressed by 'request cherrypicks for template only changes'
[09:24] <lifeless> stub: but I have some concerns about trying to automate commits to production by anyone, particularly as *you still need to do a rollout* to get the changes in
[09:25] <stub> Yup. If cherry picks take time to rollout, it is generally because they are being batched.
[09:27] <stub> Having changes land too fast into production is often counter productive too - there have been a number of cases of simple fixes that have had to be rolled out not working, causing frustration and further quick fixes. Rather than investing time investigating and fixing the problem properly.
[09:27] <lifeless> stub: please jump into the discussion on that spec
[09:28] <stub> There is no discussion on that spec
[09:28] <lifeless> refresh it
[09:28] <stub> Nope
[09:29] <mpt_> lifeless, "I" needs a @NAME@
[09:29] <stub> oic
[09:29] <lifeless> mpt_: ?
[09:30] <mpt_> i.e. it's non-trivial to work out who wrote who "I" refers to
[09:30] <mpt_> s/who wrote//
[09:31] <lifeless> mpt_: context my small compatriot, context!
[09:32] <lifeless> or in other terms, WTF are you talking about ?
[09:32] <jamesh> spiv: does the rewrite rule I gave in https://launchpad.net/products/launchpad/+bug/37818 sound like it would fix the problem?
[09:32] <Ubugtu> Malone bug 37818 in launchpad "http://bazaar.launchpad.net/~user/product/branch is a 404" [Minor,Confirmed]  
[09:34] <mpt_> lifeless: context! You were talking about "the discussion on that spec". The discussion you have added is not obviously by you. But the amount of time I have now spent trying to explain this has now exceeded the amount of time required for me to add your wikiname to the page myself, so I'll stop talking
[09:34] <lifeless> mpt_: oh, the spec. Sure, know I know what you are talking about.
[09:34] <spiv> jamesh: It sounds likely to me.
[09:35] <jamesh> spiv: I suppose it needs admin intervention to fix though?
[09:35] <spiv> jamesh: I guess file an rt request... yeah.
[09:35] <lifeless> erm
[09:35] <lifeless> spiv, jamesh - whats this for ?
[09:35] <lifeless> if its vostok? we had some serious trouble with those rules.
[09:35] <jamesh> lifeless: go to e.g. http://bazaar.launchpad.net/~radix/subol/main.dev and get a 404
[09:35] <spiv> AFAIK, the admins are the only people with access to that apache conf.
[09:36] <lifeless> I'd like to verify it offline before *any* attempt to change it in production
[09:36] <jamesh> lifeless: a rewrite rule to redirect to the same thing with a slash on the end
[09:36] <spiv> jamesh: lifeless is right about the trouble we had with them, though :)
[09:36] <lifeless> jamesh: theres a much easier fix
[09:36] <jamesh> oh?
[09:36] <SteveA> stub: i've wondered if it is possible to have launchpad running on some domain use new presentation code, but run against the production database, as a useful kind of staging.
[09:36] <lifeless> we have a rule that just needs a / turned into (/|$)
[09:37] <lifeless> that should fix it in one hit without generating double lookups
[09:37] <jamesh> lifeless: you need a redirect in either case
[09:38] <jamesh> or at least want a redirect
[09:38] <lifeless> jamesh: why ?
[09:38] <stub> SteveA: What does that give us that staging doesn't? Except for the ability for untested UI changes to create broken data in the production database?
[09:38] <jamesh> lifeless: programs trying to resolve relative URIs
[09:39] <lifeless> jamesh: please go on
[09:39] <lifeless> oh, I see where you are coming from
[09:40] <lifeless> yes, we could do that too. we have a separate problem.
[09:40] <lifeless> https://launchpad.net/products/bzr/+bug/37823
[09:40] <lifeless> garh 
[09:40] <lifeless> ubugtu SFTU I know its private
[09:41] <SteveA> stub: what does that give us that staging doesn't?  users.
[09:42] <spiv> Of course, fixing the 404 alone doesn't solve the whole issue -- it'll probably lead to "the URL for my branch is empty", because our apache config doesn't show the .bzr directory in listings.
[09:42] <stub> SteveA: Why would users be using bleedingedge.launchpad.net? If users *are* using it, why would be also want to bother with the 'standard' site?
[09:42] <SteveA> because we expect things to break more often on the bleeding edge
[09:42] <jamesh> spiv: that'd involve updating IndexIgnore to not exclude dot files
[09:43] <stub> I don't see how that improves the end user experience
[09:43] <lifeless> they can choose when to bleed
[09:44] <stub> I see the preferred launchpad ui giving more exceptions, and the production environment ending up more complex creating larger maintenance burdens with the necessary larger downtime periods.
[09:44] <lifeless> jamesh, spiv please test a tweaked config offline, then I'm extremely happy for an rt request to be filed
[09:45] <lifeless> I think its worth solving both bugs at once
[09:45] <jamesh> lifeless: I'm not sure what bug 37823 says because it is private, btw :)
[09:45] <lifeless> jamesh: you should be able to access it
[09:45] <lifeless> btw stub and I can do apache config on vostok
[09:45] <jamesh> lifeless: why?
[09:45] <spiv> lifeless: launchpad-dev doesn't seem to be subscribed.
[09:45] <lifeless> so you dont need an rt request
[09:46] <spiv> jamesh: try now
[09:46] <lifeless> subscribed
[09:47] <spiv> lifeless: heh, look at the activity log, we both subscribed launchpad developers :)
[09:47] <lifeless> ;)
[09:47] <spiv> I'm mildly impressed that malone didn't blow up ;)
[09:48] <jamesh> it doesn't do any of the "midflight collision" stuff that bugzilla does
[09:50] <lifeless> well that was obviously a three-way merge with the same result on both sides
[09:50] <spiv> lifeless: ...obviously.  ;)
[09:51] <SteveA> stub: so, upon reflection, you feel that this is not a good idea.
[09:54] <carlos> stub: hi, we got some 'garbage' from openoffice (it was not a problem with Rosetta) and we need to cleanup Rosetta from those broken imports
[09:54] <carlos> stub: I prepared this https://chinstrap.ubuntu.com/~dsilvers/paste/filedmfMPY.html to do the cleanup and then import the fixed .po files again
[09:55] <carlos> stub: I'm going to test it on staging when the mirror ends
[09:55] <stub> SteveA: No. Landings that meet the criteria that the new environment would allow (template changes only and no dependancies on python or db schema changes that have not yet been rolled out) are very rare, and thus the new environment would rarely be any different from the real production environment. It would only serve to complicate things.
[09:55] <carlos> after testing it on staging, could you execute it on production?
[09:56] <SteveA> stub: i think you meant "yes" as in "yes, on reflection i feel that this is not a good idea"
[09:57] <SteveA> although, i should clarify that i'm talking about changes in presentation code, python and template, not just templates, for bleedingedge.whatever
[09:57] <stub> SteveA: i guess
[09:58] <stub> I need a nap ;)
[09:58] <SteveA> which increases the scope of what could be rolled out there early
[09:59] <stub> If you increase the scope, then we start having an issue with broken code irreparably corrupting the production database.
[09:59] <stub> Or reparably - it is still a pita when it happens with fully reviewed and tested code.
[10:00] <SteveA> have you seen any times when presentation code has done this?
[10:00] <lifeless> SteveA: so when you say presentation you are excluding anything that changes canonical.launchpad.database
[10:00] <lifeless> ?
[10:00] <SteveA> not quite that
[10:01] <stub> I've seen plenty of code that should be database fall through into the presentation layer. And if this is a mechanism for bypassing beurocracy, then more code will fall through like that.
[10:01] <SteveA> i'm saying anything in launchpad/templates or launchpad/browser
[10:01] <SteveA> the rationale for this is to get some kind of staging system actually used somewhat
[10:10] <jamesh> lifeless: tested the rewrite URL I proposed at https://launchpad.net/products/bzr/+bug/37823 locally
[10:11] <jamesh> seems to work correctly (does redirects where it should, gives 404s where it should)
[10:11] <lifeless> ok.
[10:11] <lifeless> thanks
[10:24] <stub> lifeless: Cherry picking https://lists.ubuntu.com/mailman/private/arch-commits/2006-March/005638.html , I get  WARNING: Conflict adding file lib/canonical/launchpad/webapp/z3batching/__init__.py.  Moved existing file to lib/canonical/launchpad/webapp/z3batching/__init__.py.moved.
[10:24] <stub> lifeless: Yet that patch doesn't touch that file
[10:25] <lifeless> stub: did that file already exist locally ?
[10:25] <lifeless> or something ?
[10:27] <stub> lifeless: https://chinstrap.ubuntu.com/~dsilvers/paste/file4RdtLb.html
[10:30] <stub> I get the same thing trying to cherry pick r3382, so I guess it would be any patch after the one that moved that file
[10:33] <mpt> yow, +tickets isn't batched
[10:34] <mpt> BjornT, ping
[10:56] <lifeless> stub - do a revert
[10:56] <lifeless> stub: then do bzr st
[10:56] <lifeless> is there any output from bzr st ?
[11:03] <lifeless> mpt: your branch 35086 has conflicts
[11:17] <BjornT> mpt: pong (i'm having problems with my internet connection)
[11:21] <Mithrandir> hmm, can anybody tell me why htts://launchpad.net/people/tfheen shows the ubuntu-drivers logo in the list of logos?
[11:22] <jamesh> Mithrandir: because you are a member of that team?
[11:23] <Mithrandir> oh, indirectly I am, it seems.
[11:24] <ajmitch> for some reason core-dev was added as a member
[11:25] <Mithrandir> see #u-d for the description
[11:25] <Mithrandir> or reason, or whatever. :-)
[11:30] <mpt> BjornT, you wrote: "+   * On +filebug ... Also provide a link to file a bug on any related packages." There's a bug report saying that should be on the product's +bugs page, rather than its +filebug page. Thoughts?
[11:31] <mpt> For example, /products/a/+bugs should link to /distros/b/+source/a/+bugs
[11:46] <carlos> stub: is staging being updated?
[11:46] <carlos> it's taking too much time, isn't it?
[11:49] <jordi> carlos: there's a zwiki and plone pots that I'm leaving on hold
[11:49] <jordi> the rest is imported
[11:49] <carlos> jordi: cool, thanks
[11:49] <jordi> carlos: how hard would it be to further filter between distro and series stuff?
[11:50] <jordi> ie, "show needs_review for any kind of file belonging to product series"
[11:50] <carlos> jordi: not too much... I already thought that and I guess I will add it after KDE support lands
[11:50] <jordi> so I can find series po files easily
[11:50] <jordi> ok, thanks
[12:07] <stub> carlos: The staging server did not update properly. I'm sorting it now.
[12:08] <carlos> stub: ok
[12:08] <carlos> anyway, I'm going to move my scripts to use at noon
[12:08] <carlos> stub: thanks
[12:09] <stub> carlos: Updates are probably starting an hour later now too with London kicking over to summer time
[12:09] <carlos> stub: well... my cronscript is also at London time zone
[12:15] <jamesh> is there any way to tell cron that a particular crontab should be interpreted as UTC?
[12:22] <stub> carlos: back up
[12:24] <carlos> stub: cool, thanks
[12:38] <dilys> Merge to devel/launchpad/: [trivial]  Remove comments for removed table (r3385: Stuart Bishop)
[12:47] <erdalronahi> carlos: Hi, just answered your mail on the mailinglist
[12:47] <erdalronahi> thanks for helping
[12:50] <carlos> erdalronahi: I already answered too ;-)
[12:50] <carlos> erdalronahi: you are welcome
[12:50] <erdalronahi> ;-)
[12:50] <erdalronahi> the re-import will be finished tomorrow?
[12:51] <carlos> not sure
[12:52] <carlos> I'm still finishing testing the deletion
[12:52] <carlos> and we need to reimport breezy and dapper...
[12:52] <carlos> count with Wednesday
[12:53] <carlos> dapper's openoffice is really huge
[12:53] <carlos> now that we include the documentation...
[12:54] <jordi> reimport breezy and dapper?
[12:54] <jordi> WTF?
[12:56] <carlos> jordi: OpenOffice
[12:56] <mdke> so is rosetta ready for dapper now for packages other than openoffice?
[12:56] <carlos> mdke: and KDE
[12:57] <carlos> but due the massive imports that we are going to do this week... I'm not going to announce it yet
[12:57] <mdke> oh cool. all the upstream translations are in for everything except kde and ooo?
[12:57] <carlos> mdke: most of them, yes
[12:57] <carlos> I'm still reviewing what's missing
[12:58] <carlos> but mainly KDE 
[12:58] <carlos> is missing
[12:58] <mdke> very cool
[12:58] <carlos> and OO is broken...
[12:59] <erdalronahi> but the translations from Breezy are not yet imported, right?
[12:59] <carlos> stub: I guess is ok if I use my staging rights to check some deletions before I ask you to do it on production, right?
[12:59] <erdalronahi> The bulk of our translations is there, not upstream
[12:59] <carlos> erdalronahi: yeah, not yet imported
[01:00] <carlos> that's another point to deferer the announcement
[01:00] <stub> carlos: Sure. Staging is there to be abused ;)
[01:00] <carlos> ok
[01:00] <carlos> ;-)
[01:07] <carlos> stub: btw... how's going the cherrypick?
[01:07] <stub> carlos: I'm getting spurious conflicts
[01:08] <carlos> with mine?
[01:08] <carlos> it's one line change + a big test change
[01:16] <stub> carlos: So. Conflicts in files that your patch (and others I need to cherry pick) don't touch.
[01:16] <stub> c/So/No/
[01:16] <carlos> oh
[01:16] <carlos> ok
[01:23] <jamesh> lifeless: I put together this simple script to convert a tree of bzr branches into a repository: http://people.ubuntu.com/~jamesh/make-bzr-repo.sh <- does it look sane?
[01:30] <lifeless> jamesh: other than being in sh ?
[01:33] <mpt> jordi, ping
[01:35] <stub> lifeless: I've done the cherry picks using diff & patch. Running tests now.
[01:37] <jordi> mpt: hi
[01:40] <mpt> jordi, do you have a more definite idea yet of whether you'll be able to attend Extramadura in September?
[01:44] <koke> carlos: around? our l10n-es memberships have expired :)
[01:44] <carlos> koke: hi
[01:44] <carlos> koke: really? :-P
[01:44] <koke> Jorge Bernal   	2005-04-01  	 Expired on 2006-04-02
[01:45] <carlos> X-)
[01:46] <carlos> koke: fixed
[01:46] <carlos> wow, the list of pending people is huge...
[01:47] <carlos> koke: why aren't you rejecting people? there are many people waiting since 2005
[01:47] <carlos> well, rejecting or accepting them...
[01:49] <koke> I usually wait to see if they subscribe to the list
[01:49] <SteveA> mpt: http://blog.drinsama.de/erich/en/linux/2006040302-msie-on-linux
[01:50] <SteveA> "You can run MSIE 6 on Linux quite well by now. Not that there is any reason to do so. (Okay, maybe if you are a webdesign professional you'll want to make sure your layout works fine with MIES, too.)
[01:50] <SteveA> "
[01:50] <mpt> awesome
[01:51] <SteveA> it is two days too late for an april fool
[01:51] <SteveA> i wonder if ubuntu will put MSIE in multiverse ;-)
[01:52] <mpt> There's a wiki page you can propose it for inclusion, iirc
[01:53] <siretart> SteveA: installing that isn't that hard either. we already ship wine
[01:54] <ajmitch> SteveA: there are scripts around that setup ie 5, 5.5 & 6 in a few minutes
[01:54] <ajmitch> it even works :)
[01:55] <SteveA> awesome
[01:55] <ajmitch> useful for checking layout
[01:56] <erdalronahi> carlos: sorry, I didn't get your answer due to a connection error
[01:57] <erdalronahi> When can we hope to see the translations from Breezy imported into Dapper?
 The bulk of our translations is there, not upstream
 erdalronahi: yeah, not yet imported
 that's another point to deferer the announcement
[01:57] <carlos> erdalronahi: as soon as I finish fixing KDE and OpenOffice, I will work on it
[01:58] <erdalronahi> That means?
[01:59] <carlos> erdalronahi: that I will try to get it ready to be executed next week
[01:59] <erdalronahi> ok, thanks
[01:59] <carlos> stub: Is there any way to use JOINS with an UPDATE sentence?
[01:59] <stub> carlos: Yes.
[01:59] <stub> Check the 8.1 docs - I think it was a recent introduction
[02:00] <carlos> ok
[02:00] <carlos> thanks
[02:00] <carlos> without joins... the update is taking ages
[02:00] <LeeJunFan> carlos: fixing kde and openoffice media:/? you're my hero :)
[02:00] <stub> file:///usr/share/doc/postgresql-doc-8.1/html/sql-update.html
[02:01] <carlos> LeeJunFan: media:/ ?
[02:01] <carlos> stub: thanks
[02:06] <LeeJunFan> carlos: openoffice doesn't like kde's media:/ url's when you save/load.
[02:06] <carlos> LeeJunFan: sorry dude... I'm talking about translations with Rosetta...
[02:07] <carlos> I don't know KDE programming and thus... I cannot fix that
[02:09] <stub> carlos: Cherry picks done
[02:09] <carlos> stub: cool, thanks
[02:12] <carlos> erdalronahi: I'm not sure I will have OO fixed today, the tests I'm executing atm are taking much more time than I expected
[02:13] <carlos> and will not be ready to be executed today by our DBA
[02:14] <carlos> so it will be dalayed until tomorrow  (I will finish the tests today and request its execution today)
[02:20] <erdalronahi> carlos: ok, I will have a look now and then :)
[02:20] <carlos> erdalronahi: I will announce it anyway
[02:20] <carlos> when it's ready
[03:03] <kiko> hey salgado!
[03:03] <salgado> yo kiko
[03:03] <kiko> how's it going old man?
[03:04] <salgado> not too bad. rsyncing stuff back from the laptop
[03:04] <kiko> we upgraded to 8.1 on anthem and on the workstations fwiw
[03:04] <kiko> seems to be working well
[03:04] <salgado> ah, good
[03:04] <kiko> anthem is breezy
[03:04] <kiko> any problems noticed so far?
[03:05] <salgado> no, nothing
[03:05] <kiko> great
[03:20] <kiko> ping ***
[03:20] <kiko> is anyone radically opposed to having the launchpad meeting this wednesday?
[03:20] <kiko> I'll need to be out this thursday morning and steve isn't going to be around
[03:23] <salgado> is it a known problem that the binarypackagename widget is prefilled with the wrong value when you try to edit the status of a bug? (https://launchpad.net/distros/ubuntu/+source/codespeak-lib/+bug/6128 shows the problem)
[03:23] <Ubugtu> Malone bug 6128 in codespeak-lib ""py.test2.4" fails" [Normal,Confirmed]  
[03:25] <kiko> what value is it prefilled with?
[03:25] <kiko> bradb?
[03:25] <salgado> "Re: "py.test2.4" fails"
[03:26] <kiko> salgado, there is nothing in the box AFAICS
[03:28] <salgado> indeed, I reloaded the page and can't see it anymore
[03:28] <salgado> I'm sure I didn't paste it there, though. specially because I didn't copied that string from anywhere
[03:29] <bradb> salgado: Have you ever seen that problem before?
[03:29] <salgado> no. first time
[03:30] <bradb> ok
[03:34] <kiko> salgado?
[03:35] <salgado> yep?
[03:35] <kiko> oh, didn't see your comment above
[03:35] <kiko> why did you drop off?
[03:37] <kiko> spiv, ping?
[03:37] <salgado> kicked the power cord 
[03:37] <kiko> doh
[03:37] <kiko> the whole room's power cord?
[03:37] <kiko> do the UPSs not hold water?
[03:37] <kiko> perhaps I should give you guys the new one I bought
[03:38] <kiko> PERHAPS
[03:38] <salgado> matsubara has the UPS, and no, it doesn't work
[03:39] <kiko> these UPSs are not worth shit, we shouldn't by anything but APC any longer
[03:39] <kiko> we should replace them gradually
[03:41] <salgado> that would be great
[03:42] <kiko> yeah, but will take a few months as they are expensive.
[03:50] <matsubara> who have permission to edit support request for the launchpad product? 
[03:52] <kiko> mmmm
[03:53] <matsubara> nm kiko, bug 3157
[03:53] <Ubugtu> Malone bug 3157 in launchpad "Anyone should be able to edit a support ticket" [Normal,Confirmed]  http://launchpad.net/bugs/3157
[04:21] <koke> carlos: I'm a member again but not an admin
[04:21] <carlos> kiko: fixed
[04:22] <carlos> stub: I cannot resume a screen session I have on asuka
[04:22] <matsubara> kiko: bug 6429 would benefit of some attention. Lots of support requests on it.
[04:22] <Ubugtu> Malone bug 6429 in grub-splashimages "Links to consumed tokens generate 404 errors" [Unknown,Unknown]  http://launchpad.net/bugs/6429
[04:22] <carlos> stub: is that normal?
[04:22] <carlos> stub: of course, I created it ;-)
[04:22] <kiko> matsubara, that's a salgado bug, you know -- perhaps you should talk to him?
[04:23] <stub> carlos: you are not connected as the user who created the session, or if you ran it as launchpad, you have sudo'd to the launchpad user rather than connect directly via ssh.
[04:23] <carlos> ok, fixed... My fault
[04:23] <kiko> stub, can you remind me what revision we are currently running?
[04:23] <carlos> stub: the problem is that it was already attached
[04:23] <carlos> by a previous session that died
[04:23] <stub> screen -r -d
[04:23] <matsubara> kiko: I'll assign to him then.
[04:23] <carlos> stub: yeah, I did it already
[04:23] <carlos> thanks anyway
[04:23] <kiko> matsubara, wait
[04:23] <kiko> matsubara, grub-splashimages?
[04:24] <kiko> matsubara, and also.. there's a launchpad bug on this, isn't there?
[04:24] <matsubara> kiko: yes, I assigned the launchpad one to him. 
[04:24] <kiko> ok
[04:24] <stub> We are now running r3354 with the following revisions cherry picked in: r3358, r3362, r3373, r3382
[04:24] <kiko> invalidate that one then?
[04:24] <kiko> thanks stub 
[04:25] <matsubara> kiko: the task or whatever it's called now. I can't invalidate the grub-splashimage one. It's not editable
[04:26] <kiko> horrible
[04:29] <kiko> salgado, did you see your MM account is active?
[04:30] <salgado> kiko, MM = mawson?
[04:30] <kiko> mirror management and yes, mawson
[04:33] <salgado> yes, I've seen it's active
[04:33] <salgado> should I just make a new checkout from rocketfuel and run it against staging's db?
[04:34] <kiko> why not?
[04:34] <matsubara> carlos: ping
[04:35] <salgado> just wanted to make sure this is the right thing to do
[04:35] <carlos> stub: hmm, could you take a look at https://chinstrap.ubuntu.com/~dsilvers/paste/file9i98Sb.html and tell me if there is any obvious way to improve those queries? the first update is taking ages to be executed on staging (more than 30 minutes)... and we need to execute that on production tomorrow after i'm sure all things are "migrated" as I expected...
[04:35] <carlos> matsubara: pong
[04:36] <matsubara> carlos: is there any open bug on OOPS-78D530?
[04:36] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/78D530
[04:36] <SteveA> bradb: hey there
[04:36] <bradb> SteveA: hi
[04:37] <carlos> matsubara: that's already fixed
[04:37] <carlos> matsubara: I fixed it in London
[04:37] <carlos> matsubara: did it appear again?
[04:38] <stub> carlos: It might run faster if you replace the Foo JOIN Bar JOIN Baz syntax with FROM Foo, Bar, Baz, and move the ON clauses into the WHERE clause.
[04:38] <matsubara> carlos: could you point me to the bug number? I'm just triaging open support requests.
[04:39] <SteveA> bradb: up for some coffeehousing over skype?
[04:39] <matsubara> carlos: i'll link to the bug number and close the support request.
[04:39] <carlos> stub: is that faster???
[04:40] <carlos> stub: I had that way and as it's also slow, I changed it to use joins
[04:40] <bradb> SteveA: sure, heh
[04:40] <carlos> matsubara: I don't think I filed a bug as I introduced that bug the same week
[04:40] <carlos> matsubara: but let me check, just in case...
[04:40] <stub> carlos: actually, it will generate the identical plan so it won't help
[04:42] <bradb> SteveA: calling...
[04:42] <SteveA> i restarted skype
[04:43] <SteveA> try now
[04:43] <carlos> matsubara: no, I didn't file a bug as it was a side effect of fixing another bug
[04:43] <carlos> and I did the fix using the old branch
[04:44] <bradb> hm, not working. i'll try restarting skype here too, for good measure.
[04:44] <matsubara> carlos: ok, thanks
[04:44] <carlos> matsubara: you are welcome
[04:45] <stub> carlos: Can't really improve that. Selecting the results on jubany only takes about 20 seconds. But updating the 3.67 million rows will take a while.
[04:46] <carlos> there are 3.67 million rows???
[04:46] <carlos> wow
[04:47] <carlos> stub: If you explain me the way to do it, most of those updates could became a DELETE from two tables
[04:47] <carlos> i'm doing the update to remove the reference to that row
[04:47] <carlos> so I can execute the DELETE
[04:50] <carlos> stub: I'm not removing the POSelection rows because I will recreate them again with next import and it's ok to leave them with those fields set to NULL, but If is faster... I can just do a DELETE ON CASCADE of all matching POSelection rows
[04:50] <stub> You can't do a delete on cascade unless I recreate the foreign key constraints as ON DELETE CASCADE
[04:51] <kiko> aieee
[04:54] <carlos> stub: so your script to delete POTemplate deletes all dependencies first
[04:54] <stub> carlos: yes
[04:55] <stub> (but on delete cascade has to do that too - just does it automatically)
[04:56] <carlos> stub: well, but the delete on cascade doesn't need to do the UPDATE...
[04:56] <carlos> stub: what's faster? a DELETE or an UPDATE?
[04:56] <stub> I think we should redo these constraints, some on delete cacade, some on delete nullify, but I won't have that ready for tomorrow.
[04:56] <stub> carlos: I can't answer that without benchmarking it ;)
[04:58] <carlos> stub: ok, then... Do you think is doable that we have a command on execution that will block those tables (and Rosetta) for an hour or even more?
[04:59] <carlos> I guess is better if I split the SQL commands to do it in smaller steps, right?
[04:59] <stub> carlos: We can schedule launchpad downtime
[04:59] <stub> carlos: Or redo it as a Python script to do a few at a time.
[04:59] <carlos> stub: I can do a few at a time with SQL
[05:00] <carlos> I'm handling 13-14 POTemplates at the same time
[05:00] <carlos> I can do one, commit, another one, commit, etc...
[05:13] <stub> carlos: It might help, but there will still be significant lengths of time with the tables locked.
[05:13] <carlos> ok, I will go then with the python script
[05:14] <carlos> stub: I guess that the way to go is execute that query, get a slice of 1000-2000 entries, update them, commit, get a new slice of entries, commit ... until It's done
[05:15] <carlos> stub: do you think I should get more/less entries per transaction?
[05:15] <stub> carlos: yes. I'd go with a chunk size of 5000
[05:15] <carlos> ok
[05:16] <carlos> stub: Which user should I use to connect to the database? launchpad?
[05:16] <stub> If it has the relevant rights, sure.
[05:16] <stub> Otherwise, whatever. postgres if necessary.
[05:16] <carlos> stub: I need to delete rows so I guess that's the user that will have all rights as I don't have such action available for other scripts
[05:17] <carlos> ok
[05:18] <carlos> I will prepare it, ask for review and leave it as a tool to fix this kind of breakages... something tells me that we will need it again in the future...
[05:28] <carlos> stub: night
[05:31] <elmo> bzr: WARNING: Unable to update the working tree of: <blahblah>
[05:32] <elmo> wassat mean?
[05:32] <SteveA> dunno.  try #bzr
[05:33] <ddaa> elmo: that means bzr coders do not know the distinction between a warning and an informative message.
[05:34] <ddaa> elmo: when pushing via sftp, the working tree cannot be updated (for various reasons)
[05:34] <ddaa> if the branch you are pushing to (via sftp) has a working tree, bzr will print this warning.
[05:34] <ddaa> I _think_ that is always true for v6 branches (created with bzr-0.7)
[05:35] <elmo> ddaa: ah, I see, thanks
[05:35] <ddaa> actually, there was a lot of discussion about fixing that message, I think it might have improved in 0.8
[05:36] <iwj> How can I tell who the current bug contact(s) are for a package ?  I'm looking at  https://launchpad.net/distros/ubuntu/+source/psutils  and I don't see it.
[05:36] <ddaa> elmo: the result of such a push (with v6 branches) is working tree with "uncommitted changes"
[05:36] <ddaa> which is quite confusing.
[05:36] <elmo> ddaa: hmm, well that affect my ability to submit to pqm?
[05:36] <ddaa> elmo: absolutely not
[05:37] <kiko-phone> iwj, if you click on Bugmail settings they are included in a portlet in the lower left.
[05:37] <kiko-phone> would you like me to include that portlet in the main page?
[05:38] <iwj> Oh, so they are.  I clicked on `bugmail settings' but I didn't realise that the existing state I would be modifying would be hidden in the corner.
[05:38] <iwj> Including that info in the `"psutils" source package in ubuntu:' info would be sensible.
[05:39] <kiko-phone> I'll do that now, thanks.
[05:39] <iwj> Really, the whole contents of that portlet should be in the main body of the distros/ubuntu/+source/psutils page ...
[05:41] <kiko-phone> yep
[05:49] <iwj> Thanks.
[06:03] <kiko-phone> iwj, in PQM now.
[06:09] <kiko-phone> is PQM hung?
[06:11] <elmo> nothing's running
[06:12] <kiko-phone> odd.
[06:29] <elmo> OH MY GOD bzr push is so slow
[06:29] <kiko-fud> elmo, rsync or sftp?
[06:29] <elmo> err...
[06:30] <elmo> look, over there, something really shiny and interesting!
[06:30] <kiko-fud> rsync is usually much faster
[06:31] <ddaa> yup
[06:31] <ddaa> sftp push will alledgedly get much better with knits
[06:31] <elmo> ok, so I'm an idiot.  but how do I use rsync?
[06:31] <elmo> rsync://chinstrap.ubuntu.com/home/warthogs/archives/james.troup@canonical.com/launchpad/cleanup doesn't seem to work
[06:31] <ddaa> elmo: man! this is going to the quotes page!
[06:32] <kiko-fud> elmo, first, you need bzrutils installed, and second, you just use "chinstrap.ubuntu.com:/..."
[06:32] <elmo> you mean bzrtools, I guess, but ok, trying
[06:33] <kiko-fud> sorry, yes, doing 4 things at once
[06:33] <kiko-fud> but now going to have lunch
[06:33] <ddaa> the best strategy ATM for launchpad-sized branches is to have shared repo and rsync it wholesale (by hand) to chinstrap.
[06:34] <elmo> ddaa: isn't that pretty much what bzr push with rsync does?
[06:34] <ddaa> elmo: bzr branches should not be uploaded to the Baz archive anyway.
[06:35] <ddaa> rather something like "rsync -a --delete mybranch chinstrap:/home/warthogs/archives/elmo/launchpad"
[06:35] <ddaa> or "rsync -a --delete mybranch/ chinstrap:/home/warthogs/archives/elmo/launchpad/cleanup" if the names differ
[06:35] <elmo> hmm, ok, I'll do that instea
[06:35] <elmo> thanks
[06:36] <ddaa> elmo: that's pretty much what bzr push with rsync does, but I just have too much trouble to make that one to work properly
[06:37] <ddaa> also, bzr push does (AFAIK) know about shared repos, and using that with rsync saves you 300MB of upload for every new branch.
[06:37] <ddaa> ... does _not_ know...
[06:38] <ddaa> then you can have single script to upload the whole repo whenever you want.
[07:35] <carlos> kiko-fud: I just added to pending review KDE support, at the end, it was not so difficult and includes a test ;-)
[07:36] <carlos> see you!
[08:00] <jblack> Ok guys. I'm out. I'll be leaving the mailing lists presently, so it'll be best to get ahold of me via phone, #bzr or email. 
[08:01] <jblack> You're a great team and you do good things. Keep honest and do good work.
[08:01] <salgado> jblack, good luck, dude. we'll miss you here
[08:02] <bradb> best of luck jblack
[08:02] <jblack> salgado: I'm sure our paths will cross again. We don't live in _that_ big of a world.
[08:03] <ddaa> dunno the cause, but dapper feels snappier than brezzy
[08:03] <ddaa> maybe it's the kernel, or maybe it's the working video accell...
[08:03] <jblack> Anyways, take care guys and do well. Viva la bzr! =D
[08:04] <bradb> i'm happy that my built-in wireless works, even n-m seems not to notice
[08:04] <ddaa> bradb: took a bit of poking around, since AGPFastWrites now cause xorg to lock, but now I actually have 3D accell. Need to waste some money and time on things like tuxrace, Q3 and SOL, now :)
[08:04] <bradb> s/even/even though/
[08:05] <bradb> heh
[08:16] <bradb> mpt: I sent you a patch to fix your Malone Simplifications test failures.
[08:50] <kiko> lifeless, elmo: pqm seems to be disabled.
[08:52] <salgado> and staging is still dead
[08:53] <kiko> wtf is wrong with these people
[09:15] <ddaa> kiko: salgado: the branch puller (runmirror on supermirror@vostok) appears to be broken
[09:15] <kiko> oh?
[09:15] <ddaa> kiko: don't you read your error reports?
[09:15] <kiko> ddaa, your script also seems to be broken, needing a database update/rollout
[09:15] <kiko> update-branches
[09:15] <kiko> I do
[09:15] <ddaa> kiko: just done rollout
[09:15] <kiko> cool
[09:16] <kiko> well
[09:16] <kiko> the runmirror script stopped sending me output at 2:40 this morning
[09:16] <kiko> does that mean it was fixed?
[09:16] <kiko> or did it just die?
[09:16] <ddaa> uh... right :)
[09:16] <ddaa> it's no longer whining...
[09:24] <ddaa> salgado: can you fix the branch puller?
[09:25] <ddaa> it's really dead
[09:25] <kiko> not running at all?
[09:26] <ddaa> the bzr.dev branch published by launchpad is out of date
[09:26] <ddaa> well, that or it's running slogging its way slowly through some backlog...
[09:27] <salgado> I guess I can
[09:27] <ddaa> mh
[09:27] <salgado> ddaa, is https://lists.ubuntu.com/mailman/private/launchpad-error-reports/Week-of-Mon-20060403/024961.html the problem you're refering to?
[09:27] <ddaa> it looks like it's running actually (looking at vostok top)
[09:28] <ddaa> though, with no measurable CPU activity...
[09:28] <kiko> strace it!
[09:29] <ddaa> man, I understand why people prevented women from working... mine is blathering on the phone next door
[09:31] <salgado> ddaa, I think it was the http://gangotri.ubuntu.com:9000/supermirror-pull-list.txt page that was broken
[09:32] <ddaa> kiko: I do not have enough privs to strace
[09:32] <kiko> blimey
[09:32] <kiko> who is the script running as?
[09:32] <ddaa> user is supermirror
[09:33] <kiko> and you can't su to him?
[09:33] <ddaa> no
[09:33] <ddaa> currently, have to ask elmo/Znarl, and frankly they have better things to do
[09:34] <ddaa> there was discussion in London about transferring that stuff to the DBAs
[09:35] <kiko> DBAs? 
[09:35] <kiko> nooooo
[09:36] <ddaa> salgado: yes, that's the problem I'm referring to
[09:37] <salgado> is it possible that the breakage was on that page?
[09:37] <salgado> the script will not produce any output if it runs successfully
[09:37] <salgado> which is intentional, since it runs every 5 minutes
[09:38] <kiko> that script was broken, we know it, right?
[09:39] <salgado> no
[09:39] <salgado> that error message was because the content it got from http://gangotri.ubuntu.com:9000/supermirror-pull-list.txt was not what it expects it to be
[09:40] <salgado> although it might be desirable to fail graciously if the content of that page is not what it expects, the problem wasn't actually in the script, AFAICT
[09:40] <kiko> mmmm
[09:41] <kiko> did you see the error message that was happening until today 2:40am?
[09:41] <salgado> ah, there's another one?
[09:42] <kiko> well
[09:42] <kiko>   File "/srv/sm-ng/lib/jobmanager.py", line 59, in branchStreamToBranchList
[09:42] <kiko>     (branchnum, branchsrc) = line.split(" ")
[09:42] <kiko> ValueError: need more than 1 value to unpack
[09:42] <salgado> the only one I've seen is the "ValueError: need more than 1 value to unpack"
[09:42] <salgado> yes, this one happened lots of times
[09:42] <salgado> that page is working fine now
[09:42] <salgado> ddaa, ^^
[09:42] <kiko> we could at least fix that codepath though
[09:45] <ddaa> salgado: I take it you somehow fixed the error reporting, so it would give a listing of failure in a reasonable format
[09:45] <salgado> kiko, you mean, to skip the branches for which we can't get an id and src url?
[09:45] <ddaa> if that's the case, it would make much sense just to log a warning if some line fails to parse (including the faulty line).
[09:45] <kiko> yeah.
[09:46] <ddaa> anyway, launchpad should not ever generate such a line...
[09:46] <salgado> exactly
[09:47] <ddaa> but it makes sense to log an error (better than warning) and proceed rather than blowing up.
[09:47] <salgado> I'm pretty sure this will only happen if that page is completely busted
[09:47] <salgado> in which case, we'll end up skipping all lines
[09:48] <kiko> bustificated
[09:48] <kiko> bustified
[09:48] <kiko> abustated
[09:48] <kiko> you know how it feels
[09:48] <kiko> the lowercase failure
[09:50] <ddaa> I'm pretty pretty sure the runmirror script is hung.
[09:50] <ddaa> Need to figure out how and when will the new code be rolled out.
[09:51] <ddaa> debiggin
[09:51] <ddaa> debugging this thing is like trying to hit a grue with a pea shooter
[10:20] <mpt> BjornT, ping
[10:21] <kiko> hey mpt 
[10:21] <mpt> hi kiko
[10:22] <kiko> how's it going down under?
[10:23] <BjornT> hi mpt 
[10:23] <mpt> kiko, I'll answer that question when I'm fully awake
[10:23] <mpt> :-)
[10:24] <ajmitch> mpt: just don't look out the window then
[10:24] <mpt> BjornT, https://launchpad.net/distros/debian/+source/grub-splashimages/+bug/6429
[10:24] <Ubugtu> Malone bug 6429 in grub-splashimages "Links to consumed tokens generate 404 errors" [Unknown,Unknown]  
[10:24] <mpt> not raining again, is it?
[10:24] <mpt> no, just cloudy, I'll do some laundry today
[10:25] <mpt> BjornT, how does/should someone reject/remove the grub-splashimages line for being irrelevant?
[10:26] <ajmitch> isn't that waiting on the debbugs syncing code?
[10:26] <kiko> not really in that case
[10:26] <ajmitch> since debian tasks were made uneditable a week or two ago
[10:27] <mpt> that one's not linked to any watch
[10:27] <kiko> it's just that grub-splashimages doesn't use malone, right?
[10:27] <mpt> no, it's on the Ubuntu package kiko
[10:27] <mpt> sorry, the Debian package
[10:27] <BjornT> mpt: it's not possible today. i think it should be possible to remove them though, any suggestions how to do it?
[10:29] <mpt> BjornT, perhaps the "Status" area should be two radiobuttons, (*) Automatic  ( ) Not a bug here
[10:29] <mpt> That's a bit lame, but it's early in the morning
[10:31] <mpt> or maybe even a <select> like it is normally
[10:34] <BjornT> mpt: yeah, a <select> is probably better for similarity to normal bugtasks (and it makes the implementation simpler :)). do you know if there's a bug open for this?
[10:35] <mpt> no, but I'll report one if there isn't, just wanted to pick your brain first
[10:35] <mpt> thanks
[10:36] <BjornT> cool
[10:36] <mpt> ah, there's bug 3140
[10:36] <Ubugtu> Malone bug 3140 in malone "Bug watches can't be removed" [Normal,Confirmed]  http://launchpad.net/bugs/3140
[10:36] <mpt> which meant something slightly different at the time it was reported, but is just as valid in the "no watch without a cockfosters" world
[11:06] <kiko> ddaa, push branches are published to bazaar.launchpad.net?
[11:06] <ddaa> yes
[11:07] <kiko> and pushed to that box as well?
[11:07] <ddaa> to vostok, yes
[11:07] <ddaa> hu
[11:07] <ddaa> yes, publishing box is the same as the same as sftp server box (and same as branch puller)
[11:12] <kiko> salgado, how many lines was cprov's soyuz branch when it landed?
[11:15] <salgado> 20k?
[11:16] <kiko> no way?
[11:16] <kiko> seriously?
[11:16] <mpt> cf. my headings branch was 7k (though much easier, of course)
[11:17] <salgado> the diff with context was around that, yes
[11:17] <kiko> soyuz had drug-inspired code inside it mpt
[11:17] <kiko> the most drugs your code has is some diet dr. pepper
[11:17] <mpt> and drugs make everything easier?
[11:17] <kiko> you haven't spent much time around drug addicts, have you?
[11:17] <mpt> I tried Dr. Pepper at Elika's eating club, and didn't like it
[11:18] <mpt> it tastes like marzipan
[11:18] <kiko> it is indeed foul
[11:18] <mpt> I'm an L&P person
[11:24] <ddaa> drugs do not make everything easier, but they make everything else matter less
[11:25] <ddaa> which indeed makes it easier to cope with everything else falling apart
[11:51] <kiko-afk> man, PQM sucks this week
[11:51] <kiko-afk> 100% of downtime so far