[02:56] <spiv> lamont: If it's well-formed XML, probably elementtree.  If you're screen-scraping stuff that isn't actually proper XML/HTML, perhaps BeautifulSoup would be better.
[04:01] <mpt> Gooooooooooooooooooooood afternoon Launchpadders!
[04:08] <poningru> mpt: elo elo
[04:11] <mpt> spiv, have time for a five-minute review?
[04:22] <LaserJock> hi, anybody awake? I was wondering if it is possible to unsubscribe someone (or a team) from a bug?
[04:25] <LaserJock> and why does the column sorting on LP seem to be random?
[04:40] <mpt> LaserJock, you can unsubscribe yourself, but you can't unsubscribe other people
[04:40] <mpt> That you can subscribe other people in the first place is a long-standing bug
[04:40] <mpt> The column sorting is random because JavaScript is doing it alphabetically rather than semantically
[04:41] <mpt> s/bug/misfeature/
[04:41] <LaserJock> mpt: ok, so how would I unsubscribe a team then?
[04:42] <spiv> mpt: sure
[04:49] <mpt> spiv, https://chinstrap.warthogs.hbd.com/~dsilvers/paste/fileIFhKX4.html
[04:49] <mpt> LaserJock, you can't, that's bug 30532
[04:49] <Ubugtu> Malone bug 30532 in malone "Unable to unsubscribe a team from a bug" [Critical,In progress]  http://launchpad.net/bugs/30532
[04:50] <LaserJock> mpt: ah ok, oh well :/
[04:51] <LaserJock> no biggy, the MOTU Science team seems to be subscribed to odd bugs now and then (I think mostly because we have a package called boot)
[04:52] <mpt> Rename the package, then :-)
[04:53] <LaserJock> mpt: believe me, I've thought of that :-)
[04:53] <mpt> Badly-named packages are a usability problem
[04:53] <LaserJock> heh, I saw your ubiquity comment on -doc
[04:54] <mpt> I saw a nifty one-liner a couple of weeks ago
[04:54] <LaserJock> mpt: well I wrote an email to launchpad-users a while ago about this issue and nobody commented. maybe I didn't write it clearly
[04:55] <mpt> "Letting geeks name software is like letting marketers code it."
[04:55] <LaserJock> lol, that is good
[04:56] <LaserJock> For my issue the problem would be much better if we had package descriptions when you did a search for the package to file a bug about
[04:57] <spiv> mpt: Hmm, removing click sorting from a batch of results makes sense, but I'm not sure it fixes 36105 -- it seems to conflict with kiko's comment, at least.
[04:59] <mpt> spiv, sortkeys will still need to be added for Priority in unbatched spec lists and so on
[04:59] <mpt> they're just not relevant to any list that is batched
[04:59] <jamesh> stub: is staging borked?
[05:01] <spiv> mpt: Right.  Your title for the paste says "Fix for bugs 36105 ..." hence my concern.  Just checking that there's no confusion that this doesn't fix 36105 (even though it fixes one of the symptoms).
[05:01] <Ubugtu> Malone bug 36105 in malone "Importance sort order incorrect" [Normal,In progress]  http://launchpad.net/bugs/36105
[05:02] <mpt> spiv, well, once the clickable headers are removed, the way to sort by importance is to choose "severity, then priority" from the menu and click the button, and that will produce the correct order
[05:02] <mpt> so it does fix the bug, just not in the way kiko says
[05:03] <spiv> mpt: What about the aforementioned unbatched spec lists?  Or is that just a seperate bug?
[05:03] <mpt> (and "severity, then priority" will shortly become "by importance")
[05:03] <mpt> spiv, separate bug
[05:03] <spiv> Ok.
[05:04] <mpt> I could make the headers clickable only when there are 75 bugs or fewer ;-) ... but that wouldn't be very understandable
[05:05] <spiv> The only other concern I have is that you removing nowrap attributes (which is fine, because they aren't proper XHTML 1.0), but not replacing them with equivalent CSS.  Is that intentional?
[05:05] <spiv> Yeah, that thought crossed my mind too, but I agree.
[05:05] <spiv> (Not that I'm the UI expert here :)
[05:07] <mpt> I don't see any benefit from the nowrap -- all it does is make the table scroll horizontally, rather than resizing to fit your window
[05:07] <mpt> I think the latter is much better behavior
[05:08] <spiv> I don't have a strong opinion either way, just wanted to be sure it was intentional.
[05:08] <spiv> Looks good to merege.
[05:08] <spiv> Er, "merge" :)
[05:08] <mpt> thanks spiv
[05:14] <lamont> spiv: I went with xml.dom.minidom
[05:14] <spiv> lamont: Well, it's in the standard library, so I guess it has something going for it ;)
[05:14] <lamont> ;p;
[05:14] <lamont> lol
[05:14] <lamont> damn keyboard
[05:18] <jamesh> DOM is great if you like typing long method names
[05:21] <lamont> jamesh: I kinda noticed that.
[05:21] <lamont> but then I just got a little evil...
[05:21] <lamont> maybe I'll post the code snippet here later...
[05:21] <lamont> then you may vomit.
[05:33] <stub> yes, mysql 'runs' on windows
[05:33] <lifeless> lamont: it does
[05:33] <lifeless> spiv: asyncore, enough said
[05:33] <lamont> server too?
[05:34] <lamont> I mean, I suppose that I could just import the csv's into a non-sql database in in-core python, but I'm trying to be lazy...
[05:34] <stub> lamont: I believe so. One of the reasons why it was successful over PostgreSQL (although sane people used Firebird I hear)
[05:34] <lamont> but will check scrollback later
[05:35] <stub> lamont: sqllite has a good following for small jobs, and will be in core python 2.5 I hear
[05:55] <stub> jamesh: staging is broken due to a missing required config item.
[05:56] <jamesh> okay
[05:56] <stub> Or should I say an existing, no longer existant config item
[05:56] <jamesh> thanks for looking into it
[05:57] <stub> lifeless: For staging rollouts I'm just rsyncing launchpad-built. For production rollouts, I rsync launchpad-built and use bzr pull --overwrite to build the tree, and then rsync push
[06:02] <lifeless> stub: ok. Do you do this from balleny ?
[06:03] <stub> lifeless: Production is from balleny. staging is just on asuka.
[06:05] <lifeless> ok
[06:05] <lifeless> so you should not be affected at all
[06:09] <stub> yup
[06:11] <stub> lifeless: Although I should be building trees only using resources on balleny rather than rsyncing rocketfuel-built from chinstrap, but I haven't had much luck with config manager on balleny
[06:14] <lifeless> ah right
[06:17] <stub> Hmm.... I just tried to push my 'trivial' branch, and got told 'Local branch is not a newer version of remote branch.'. First push with the new bzr I think.
[06:19] <stub> lifeless: Anything to check before I belt it with the --overwrite stick?
[06:20] <lifeless> stub: bzr missing, if you have the patience
[06:20] <lifeless> stub: did you do a 'pull' from rocketfuel ?
[06:21] <stub> lifeless: Yes. pull, hack, commit, push
[06:21] <lifeless> that will have done it
[06:21] <lifeless> history convergence breaks rsync style pushes
[06:22] <stub> ok.
[06:22] <dilys> Merge to devel/launchpad/: [trivial]  Fix bug 41933 (OOPS trying to assign a sourcepackage to a distrorelease) (r1843: Brad Bollenbach)
[09:26] <SteveA> good morning
[09:26] <SteveA> stub: ping
[09:42] <sivang> morning
[09:45] <ddaa> good yawning
[09:59] <SteveA> hi
[09:59] <SteveA> ddaa: how's your stuff going?
[10:04] <ddaa> merging
[10:04] <ddaa> having an endless argument about error handling with lifeless off list
[10:04] <ddaa> preparing to explain bazaar-ui design decisions to mpt
[10:04] <ddaa> spending a lot of time reading and writing email
[10:05] <ddaa> told sabdfl I would be back on vcs imports this week
[10:05] <ddaa> need to test importd error reporting from jamesh and give feedback
[10:05] <ddaa> need to review branch scanner refactoring from jamesh
[10:06] <ddaa> need to make a major patch for pybaz, requested by lifeless
[10:06] <ddaa> overally, still above my head, but the situation looks like it's improving
[10:07] <SteveA> ok
[10:07] <SteveA> let's deal with each thing in turn
[10:07] <SteveA>  - merging what exactly?
[10:07] <ddaa> bunch of outstanding branches
[10:08] <ddaa> look at the recent rocketfuel commits
[10:08] <ddaa> still have a few outstanding branches blocked by spiv merging sourcecode fixage
[10:09] <carlos> morning
[10:09] <SteveA> please summarize what the branches are about
[10:09] <SteveA> hi carlos 
[10:09] <ddaa> off the top of my head
[10:09] <ddaa> bazaar documentation
[10:09] <ddaa> sabdfl bazaar ui
[10:09] <SteveA> stub: ping
[10:09] <ddaa> importd patch to product bzr branches via baz
[10:10] <ddaa> ScriptsAndDaemon compliance patch for branch scanner
[10:11] <ddaa> that was merged late last week and during week-end
[10:11] <ddaa> still in pipe:
[10:11] <ddaa> bzrtool patch for bogus strptime usage
[10:12] <ddaa> two cscvs patches containing the initial cscvs refactorings done in London and shortly after
[10:12] <dilys> Merge to devel/launchpad/: [trivial]  Fix https://launchpad.net/bugs/41108 and remove the warn_about_no_published_uploads config options that I forgot to remove from staging and jubany's config files. (r1844: Guilherme Salgado)
[10:13] <ddaa> some more controversial bazaar-ui changes I pulled back to merge the rest ASAP
[10:13] <ddaa> EOF
[10:14] <ddaa> SteveA: ping
[10:17] <SteveA> ddaa: 2 mins
[10:18] <ddaa> Also contributed to several production fixes in collaboration with jamesh, stub and salgado.
[10:18] <SteveA> ddaa: actually, can we talk in 30 mins?
[10:18] <ddaa> that stuff is behind, but it significantly slowed me down in the past couple of weeks
[10:18] <ddaa> sure
[10:18] <SteveA> thanks
[10:47] <SteveA> mpt: ping
[10:57] <SteveA> hi ddaa.  i'm almost finished with carlos
[10:59] <mpt> SteveA, pong
[11:03] <ddaa> didn't we agree to fix launchpad to conform to how we speak about projects?
[11:04] <ddaa> even I usually say "project" when I mean "product" when not talking specifically about launchpad.
[11:04] <ddaa> or did sabdfl veto it or something?
[11:05] <stub> SteveA: https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-04-28/A45 is odd. I can't think of a reason how we could get timings like that.
[11:07] <ddaa> stub: see also https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-04-28/D44
[11:08] <ddaa> only three minutes apart, my guess is something weird was happening to the system at that moment, maybe thrashing.
[11:09] <ddaa> probably related to some cronscript
[11:09] <stub> To get timings like that, we would need some sort of global resource and lock in Zope3. And I can't think what that would be, except for the global interpreter lock.
[11:09] <stub> hmm.... or thrashing I guess.
[11:10] <stub> elmo and Znarl might have cricket graphs on gandwana to tell us
[11:10] <stub> Hmm.... my one was from gangotri, yours from gandwana
[11:11] <lifeless> ddaa: sabdfl deferred it
[11:11] <SteveA> stub: there's the "email sending blocks zope" issue
[11:12] <SteveA> queued blocks zope :-(
[11:13] <SteveA> http://www.zope.org/Collectors/Zope3-dev/580
[11:13] <SteveA> i think i mentioned this when i first saw it
[11:14] <stub> Hmm.... direct delivery. 
[11:14] <SteveA> immediate delivery might actually be better, if this bug is affecting us
[11:14] <stub> We are using immediate delievery at the moment. However, sending email is actually deferred until commit time. Will slowness there show up as a soft timeout?
[11:15] <BjornT_> SteveA, stub: i think queued delivery has been fixed upstream already, there's another bug related to this in the zope3 tracker.
[11:15] <SteveA> stub: i think it can cause a soft timeout
[11:15] <SteveA> stub: can we instrument mail delivery, so we know how long it is taking in OOPS reports or in some log?
[11:16] <BjornT_> SteveA, stub: http://www.zope.org/Collectors/Zope3-dev/590
[11:16] <stub> That stuff is all Z3 - we would need to hack it in to Z3 or wrap it
[11:17] <SteveA> stub: surely it ties into transactions or publication somewhere?
[11:17] <SteveA> in any case, i think we should be able to wrap it straightforwardly
[11:18] <stub> Or just switch back to queued delivery and assume it is near instantaneous, because it will be
[11:19] <SteveA> BjornT_: do you know if we have marius' fixes in our zope3?
[11:19] <BjornT_> SteveA: we don't have them
[11:19] <SteveA> let's get them, to start with
[11:20] <SteveA> i think we should have stats gathered for OOPS timeout reports about any connection to external systems
[11:20] <SteveA> including the database, mail systems, any RPC systems, the filesystem...
[11:20] <SteveA> otherwise, when something times out and it isn't the database, we're left guessing
[11:22] <ddaa> SteveA++
[11:22] <SteveA> hi ddaa
[11:22] <BjornT_> stub: will you pull in marius' fixes to queued delivery, or should i?
[11:23] <stub> I think it is a good sign that we are now worrying about rare exceptions :-) We might need to update the daily reports now that the exception counts are statistically meaningless - perhaps listing all exceptions?
[11:23] <SteveA> ddaa: --> #launchpad-meeting
[11:23] <stub> BjornT_: I'm happy for you to - I always forget how to drive SVN
[11:24] <BjornT_> ok
[11:24] <SteveA> lifeless: you may wish to listen in on #launchpad-meeting
[11:43] <mpt> Is PQM stuck?
[11:45] <lifeless> no
[11:45] <lifeless> its reweaving a lot
[11:45] <mpt> ok, ta
[11:46] <SteveA> reknitting soon?
[11:48] <lifeless> no
[11:48] <lifeless> knits do not have a reweave.
[11:48] <mpt> They have darning!
[11:48] <lifeless> the larger operation. 'reconcile' can apply to knits, but they do not need to reweave
[11:49] <mpt> http://www.google.com/images?q=russell%20crowe%20knitting
[11:59] <lifeless> spiv: ping
[12:34] <carlos> lifeless: is safe to move to shared trees now?
[12:35] <lifeless> no
[12:35] <carlos> ok
[12:35] <lifeless> see the RocketFuelToKnits page
[12:35] <carlos> ok
[12:35] <carlos> thansk
[12:56] <Kinnison> salgado: ping?
[01:08] <jordi> carlos: hey
[01:08] <jordi> how's the ooo issue going?
[01:11] <carlos> jordi: hi
[01:11] <carlos> jordi: talking about that at #canonical-meeting
[01:11] <carlos> jordi: We are going to restore some data from a backup
[01:41] <kiko> hullo SteveA 
[01:41] <kiko> how's it going?
[01:43] <kiko> carlos, tell me about this Rosetta thing
[01:43] <carlos> kiko: #canonical-meeting
[01:48] <kiko> morning cprov 
[01:48] <cprov> kiko: good morning
[02:09] <dilys> Merge to devel/launchpad/: [trivial]  Fix staging config (r1845: Stuart Bishop)
[02:09] <kiko> thanks stub 
[02:10] <salgado> Kinnison, pong
[02:23] <salgado> stub, did you remove the warn_about_no_published_uploads config option from staging's config file? (I have if fixed on a branch that hasn't been merged yet because of a conflict)
[02:24] <stub> salgado: Yes. I thought my fix was going to conflict when I saw yours in the queue before me. I neglected to update jubany's though.
[02:25] <salgado> stub, actually, the one that I had in the queue was with the wrong commit message. that's why it didn't conflict. 
[02:25] <stub> Ahh :)
[02:25] <salgado> I'll merge jubany's fix after I merge your changes into my branch and solve the conflict
[02:25] <stub> Will your branch land soon? Or should I also submit a merge fixing jubany's config?
[02:26] <stub> ok
[02:26] <salgado> I need to wait until your changes reach rocketfuel-built
[02:27] <stub> kiko, BjornT: Do you know if debbugs on gangotri is being synced? I haven't heard back from my enquiry via rt.
[02:28] <kiko> mmmm
[02:28] <BjornT> stub: i would guess no, since the rt i filed about it hasn't been closed yet.
[02:28] <stub> ok
[02:28] <kiko> last synced on april 29th it appears
[02:29] <kiko> oh actually
[02:29] <kiko> -rw-rw-r--    1 archvsync archvsync     6781 May  2 12:33 365725.log
[02:29] <kiko> seems like it actually was synced
[02:30] <kiko> an hour ago
[02:30] <kiko> BjornT, stub: is that good news?
[02:30] <salgado> mpt, still around?
[02:30] <kiko> that's for
[02:30] <kiko> file /srv/bugs-mirror.debian.org/db-h/25/365725*
[02:31] <stub> If it is being synced, it means we have a load of dud bugwatches we need to work out how to garden.
[02:31] <stub> Or broken debbugs integration code :)
[02:31] <kiko> I'll try looking at the error logs this afternoon
[02:33] <BjornT> kiko: does /srv/bugs-mirror.debian.org/db-h/46/287146.summary exist?
[02:33] <stub> It might be worth special casing debbugs - we know we want tight integration, so we might want checkwatches.py to confirm that the db has been recently synced, and if so, it can remove bugwatches that cannot be found in the debbugs database.
[02:34] <stub> Its not like some arbitrary bugzilla instance where we need to be careful about network issues or evil caches and such
[02:34] <kiko> BjornT, nope.
[02:35] <kiko> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=287146
[02:35] <Ubugtu> Debian bug 287146 in udev "Subject: udev: wipes out /dev on 2.4 kernels" [Critical,Closed]  
[02:35] <kiko> ah but wait
[02:35] <kiko> BjornT, that file is in archive
[02:35] <kiko> not in db-h
[02:35] <kiko> BjornT, why do you only check in db-h?
[02:35] <kiko> that can't work
[02:37] <BjornT> kiko: i used the existing debbugs code, i didn't write it.
 Kamion, is it predictable? or do we just need to check inside db-h and then archive afterwards?
 kiko: it's deterministic but external folks must not attempt to predict it
[02:37] <BjornT> kiko: probably the thought was that we'll sync the bug for it gets moved to the archive, therefor we don't have to search there
[02:37] <kiko> there is stuff already in the archive
[02:38] <kiko> anyway
[02:38] <kiko> that's the bug
[02:40] <kiko> BjornT, I can probably try and fix it for you
[02:42] <BjornT> kiko: that'd be great.
[02:42] <kiko> should be easy
[02:54] <salgado> kiko, BjornT, have you seen bug 2982?
[02:54] <Ubugtu> Malone bug 2982 in launchpad "A person's Bugs page should show all bugs they are involved with" [Normal,Confirmed]  http://launchpad.net/bugs/2982
[02:54] <kiko> yes
[02:56] <kiko> BjornT, is there a bug filed on this? if not, can you please file it
[02:56] <kiko> BjornT, and also, update/close out the rt requests
[02:59] <BjornT> kiko: i don't think there's a bug open on this, i'll file one.
[03:02] <kiko> thanks!
[03:20] <BjornT> kiko: bug 42573
[03:20] <Ubugtu> Malone bug 42573 in malone "Look in the debbugs archive when syncing bug watches" [Normal,Unconfirmed]  http://launchpad.net/bugs/42573
[03:21] <kiko> thanks BjornT 
[03:33] <salgado> stub, ping
[03:33] <stub> salgado: pong
[03:35] <salgado> stub, I've merged some fixes for the branch puller a few hours ago. lifeless asked me to check with you if it's possible to do a rollout with these changes on vostok
[03:35] <stub> I'm hoping to do a rollout everywhere tonight. Give me the patch number and I'll include it.
[03:36] <salgado> stub, great. it's r1844 (the one with the wrong commit message)
[03:57] <kiko> salgado, get rid of /foaf will ya :)
[04:06] <salgado> kiko, that's on pqm now. 
[04:07] <kiko> thanks!
[04:41] <stub> I don't think we are going to get a production update done tonight - bzr is being real slow on balleny (so far it has been creating a simple branch for 1 hour)
[05:10] <bradb> matsubara: Are you going to be working on bug 41399? Colin Brace (and presumably others) got pretty frustrated by that bug, so I wonder if kiko-afk thinks it should be prioritized.
[05:10] <Ubugtu> Malone bug 41399 in malone "Unhelpful error message in distro +filebug form." [Normal,Confirmed]  http://launchpad.net/bugs/41399
[05:12] <matsubara> bradb: currently my priorities are the oops bugs, but if kiko tell me I should work on that, I will.
[05:13] <bradb> right, ok
[05:14] <kiko-afk> bradb, maybe you'll be able to get it done before matsubara anyway
[05:14] <bradb> sure, I can do it
[05:25] <ddaa> the sort of nap that hits you behind the head with a club
[06:16] <carlos> Bluekuja: hi
[06:16] <carlos> go ahead, what's the problem
[06:16] <carlos> ?
[06:17] <ddaa> carlos: ?
[06:17] <Bluekuja> i just went home, and watching my lp page i saw some translations on the 2 may
[06:17] <carlos> ddaa: he sent me a message
[06:17] <Bluekuja> that i havent done
[06:17] <carlos> Bluekuja: what's your launchpad name?
[06:17] <Bluekuja> bluekuja
[06:20] <carlos> Bluekuja: from https://launchpad.net/people/bluekuja/+translations, what didn't you translate?
[06:20] <Bluekuja> let me check
[06:21] <Bluekuja> translations are correct
[06:23] <Bluekuja> but my karma in bug management went down from 6300 to 5900 in a day
[06:23] <Bluekuja> and also there are suggestions
[06:23] <Bluekuja> that i havent done today
[06:23] <carlos> Bluekuja: well, it would be a recent upload
[06:24] <carlos> a .po file upload
[06:24] <carlos> do you translate outside Ubuntu?
[06:24] <carlos> directly for Debian/GNOME/KDE, etc...?
[06:24] <Bluekuja> yep, kde
[06:26] <Bluekuja> but why i get less karma in bug management? whats the relationship between it and translations?
[06:27] <carlos> that's another thing
[06:27] <carlos> let me finish with the translations
[06:27] <Bluekuja> okie
[06:27] <carlos> and we will get into that other issue
[06:27] <Bluekuja> ok
[06:29] <carlos> Bluekuja: the only explanation I can think on is that control-center-2.0 translations were imported today with a new package upload into Ubuntu
[06:29] <carlos> you are the latest translator for it
[06:30] <Bluekuja> yeah, it can be a good explanation
[06:30] <carlos> but, at first sight, you should not get karma in this concrete situation
[06:31] <carlos> I'm going to file a bug to check this concrete case to check why did you get karma
[06:31] <carlos> Bluekuja: thanks for the report
[06:31] <Bluekuja> np carlos
[06:31] <carlos> Bluekuja: about the malone karma
[06:31] <carlos> let me look for some documentation that will give you the answer
[06:31] <Bluekuja> ok great
[06:32] <carlos> Bluekuja: https://wiki.launchpad.canonical.com/KarmaCalculation
[06:32] <carlos> that's the way our Karma code works
[06:33] <carlos> please, read it and if you still have any question, ping me again
[06:33] <carlos> and will try to help you
[06:34] <Bluekuja> ok,so sometimes can happen to have less karma?
[06:34] <carlos> Bluekuja: yes
[06:35] <carlos> if you stop contributing, your karma will decrease
[06:35] <Bluekuja> i know
[06:35] <Bluekuja> but the problem is
[06:35] <carlos> until it disappear completely
[06:35] <Bluekuja> i made as every day
[06:35] <Bluekuja> bug traging
[06:36] <Bluekuja> *triaging
[06:36] <Bluekuja> as  you can see
[06:36] <Bluekuja> there are some bug comments added
[06:36] <Bluekuja> of yesterday
[06:36] <carlos> well, we have here two factors
[06:37] <carlos> - one year ago you did a bunch of bug triage and it just expired.
[06:37] <carlos> and your new contributions didn't compensate it, that means, you did more work at this dates last year 
[06:38] <Bluekuja> ooh
[06:38] <carlos> - we normalize karma points between applications so we have the same amount of karma to share between rosetta, malone, soyuz, etc...
[06:39] <Bluekuja> yep
[06:39] <carlos> and perhaps malone got lots of bug changes and the malone points count less today than yesterday
[06:39] <carlos> is not exactly that way, but the idea is that one
[06:40] <carlos> we had to do it that way because we were giving a bunch of karma points to Rosetta contributions and thus people doing bug triage were not able to get the same amount of karma like translators
[06:40] <Bluekuja> yep
[06:42] <Bluekuja> ok, i was thinking that you can get less karma only without making any contribution
[06:42] <Bluekuja> thats why i was a little less schocked
[06:43] <carlos> well, if we don't remove you some karma over time, new contributors will not be able to reach your level of karma
[06:43] <Bluekuja> yes of course
[06:44] <Bluekuja> ok, thanks very much carlos
[06:44] <carlos> Bluekuja: you are welcome
[07:51] <carlos> ddaa: what should I do to get a bzr mirror in launchpad for a product that uses CVS?
[07:51] <carlos> ddaa: https://launchpad.net/products/pitivi/+branches is empty
[07:52] <carlos> ddaa: and I added all information about its CVS
[07:52] <ddaa> carlos: you set up a series with the CVS details (branch must be MAIN)
[07:52] <ddaa> then you must nag me to get through the motions
[07:52] <carlos> hmm it got a 'trunk' series by default
[07:52] <ddaa> carlos: I mean the CVS branch is MAIN
[07:52] <carlos> should I add the MAIN one by hand ?
[07:52] <carlos> oh
[07:52] <carlos> right
[07:52] <carlos> it's done
[07:52] <ddaa> != series name
[07:52] <carlos> already
[07:53] <carlos> ddaa: https://launchpad.net/products/pitivi/trunk
[07:53] <carlos> sorry, I used HEAD
[07:53] <ddaa> okay will do that right now
[07:54] <carlos> ddaa: fixed
[07:54] <ddaa> at the moment I'm the weak link in that chain, there's a need for some very serious importd work, but it's still not yet in the top 5 priorities (and probable even not top 10)
[07:55] <ddaa> grah importd failure :(
[07:58] <ddaa> shit
[07:58] <ddaa> importd needs rolling out
[08:03] <carlos> ddaa: stub left already to sleep
[08:03] <ddaa> carlos: I'm the one rolling out importd because it's a fucking mess
[08:04] <carlos> oh, ok
[08:04] <ddaa> so I usually let it run until db schema skew breaks it, but since we have no good error reporting it sometimes gets unnoticed
[08:05] <ddaa> also, it was requiring an out tree patch that only got merged late last week
[08:07] <carlos> zyga: hi
[08:13] <mdke> how come mdz has a drop down menu in malone called "Milestone", and I don't? is he speshul?
[08:13] <kiko> he is indeed
[08:13] <kiko> driver of ubuntu I believe
[08:14] <mdke> so ubuntu-drivers get that dropdown, and others don't?
[08:15] <mdz> what do you see there?  nothing?
[08:15] <mdz> I would expect there to be a read-only milestone field
[08:16] <mdke> only Status, Severity, Priority
[08:17] <mdke> if the teams within ubuntu-drivers get the drop-down, it's reasonable for only them to be able to do it, I suppose. But it doesn't work for ubuntu-docs, where basically all the bugs are managed by non-core-devs
[08:17] <mdke> and I would have thought that experienced bug triagers should have the ability too
[08:22] <kiko> carlos, how's the restore going?
[08:22] <carlos> kiko: I just uploaded the backed up files into production
[08:22] <kiko> are we all set then?
[08:23] <carlos> I think so, yes, I'm doing a double checking
[08:23] <kiko> okay, wonderful
[08:23] <carlos> just to be 100% sure
[08:32] <ifmy> Hello
[08:33] <mdke> hello ifmy 
[08:33] <ifmy> I don't receive any mail from launchpad
[08:33] <ifmy> when I subscribe to a bug
[08:33] <kiko> that's odd.
[08:33] <kiko> well, wait up
[08:33] <ifmy> I tried to change my email address
[08:33] <kiko> subscription alone doesn't get you email
[08:33] <ifmy> but I never recieve the mail to confirm
[08:34] <kiko> ah, interesting.
[08:34] <kiko> SteveA, ping?
[08:34] <kiko> ifmy, so tell me, what's your email address?
[08:34] <SteveA> kiko: ues
[08:34] <kiko> ifmy, is it possible you're dropping our emails?
[08:34] <ifmy> my current address is sim@geekbox.be
[08:34] <ifmy> no
[08:34] <SteveA> kiko: what?
[08:34] <kiko> at all. hmmmokay.
[08:35] <ifmy> and my new one is ifmy@geekbox.be
[08:35] <kiko> SteveA, ifmy doesn't get email from us. this is a recurring issue, you know?
[08:35] <SteveA> ifmy: do you use greylisting at all?
[08:35] <carlos> kiko: small report sent to launchpad
[08:35] <SteveA> or does your provider?
[08:35] <kiko> thanks carlos 
[08:35] <ifmy> my server uses blacklisting, but no mail from launchpad is logged
[08:36] <carlos> see you
[08:36] <kiko> carlos, and PMSP?
[08:36] <carlos> kiko: I was busy the whole day with this issue
[08:36] <SteveA> ifmy: we've had problems with servers that use "greylisting" where they reject the first connection by a particular SMTP relay
[08:36] <mdke> carlos: should I upload a new template to that website-index template which is broken? will it restore the previous translations?
[08:37] <SteveA> and expect the relay to reconnect shortly afterwards, if it isn't a spammer
[08:37] <ifmy> SteveA: I'll try just now, while I watch my server's logs
[08:37] <kiko> ifmy, for how long have you been trying to get email from launchpad?
[08:37] <carlos> mdke: I told you alreday that a .pot upload doesn't set the fuzzy flag for translations, that needs a fixed fr.po upload
[08:38] <ifmy> kiko: about 3 weeks ago
[08:38] <kiko> okay
[08:38] <mdke> carlos: sorry, this is another issue. The whole of ubuntu-docs/website-index has been overwritten by another template. See email to mailing list
[08:38] <kiko> SteveA, this is unlikely to be greylisting.
[08:38] <carlos> oh, didn't read it
[08:38] <mdke> carlos: all translations are gone.
[08:38] <carlos> mdke: yes, a new .pot upload will restore it
[08:39] <mdke> carlos: will it be easier for you to find the bug if I avoid doing another upload?
[08:39] <mdke> or shall I just go ahead
[08:39] <carlos> mdke: didn't you upload it there?
[08:39] <carlos> mdke: is a Rosetta error that the wrong .pot file ended there?
[08:40] <mdke> yes
[08:40] <mdke> I uploaded it, but it seems to have got confused with another upload to a different template in the same source package, and overwritten both with the same template
[08:40] <carlos> mdke: then wait until tomorrow and I will take a look
[08:40] <mdke> carlos: ok, thanks.
[08:40] <carlos> mdke: is there a bug filed for it?
[08:40] <mdke> carlos: no, just the email
[08:40] <mdke> I can file one if you like
[08:41] <carlos> yes, please, file a bug
[08:41] <mdke> ok!
[08:41] <mdke> have a nice evening
[08:41] <carlos> my mind is a bit overloaded atm...
[08:41] <carlos> mdke: thank you
[08:41] <ifmy> kiko: what's the launchpad smtp server's address ?
[08:42] <kiko> the server it sends out from?
[08:42] <ifmy> yeah
[08:42] <kiko> esperanza.ubuntu.com
[08:44] <elmo> no
[08:44] <elmo> mail from launchpad will come from adelie.ubuntu.com
[08:44] <kiko> ah
[08:44] <elmo> esperanza.ubuntu.com is lists.{ubuntu,canonical}.com
[08:44] <kiko> okay, gotcha
[08:45] <ifmy> ok, epseranza.ubuntu.com is not blacklisted at all on my server, I recieved mail from it today
[08:45] <kiko> ifmy, and adelie, as elmo pointed out?
[08:45] <ifmy> kiko: nothing from adelie
[08:45] <ifmy> nothing rejected, no lost connection, nothing accepted
[08:45] <kiko> elmo, would it be possible for you to grep for ifmy's email address on outgoing?
[08:46] <elmo> 2006-05-02 06:35:05 1FanXN-00026O-04 ** sim@geekbox.be: all relevant MX records point to non-existent hosts or (invalidly) to IP addresses
[08:47] <ifmy> ah
[08:47] <kiko> elmo, u
[08:48] <elmo> $ host -t MX geekbox.be
[08:48] <elmo> geekbox.be mail is handled by 1 213.186.45.152.
[08:48] <kiko> geekbox.de mail is handled by 10 res3.hostid.de.
[08:48] <kiko> geekbox.de mail is handled by 100 mxn.hostid.de.
[08:48] <elmo> kiko: ^-- an IP isn't valid as an MX
[08:48] <elmo> kiko: ._b_e
[08:48] <elmo> as in Belgium
[08:48] <kiko> I forgot my brain at home :-(
[08:49] <kiko> but you're right, I guess. elmo is this strictness on our side?
[08:50] <ifmy> elmo : I've to put a hostname as MX ?
[08:50] <kiko> elmo, btw, you can close out the RT requests on debbugs syncing -- they were bugs in Launchpad (isn't everything?)
[08:50] <elmo> ifmy: yes
[08:50] <ifmy> ok, I'll do it right now
[08:51] <elmo> kiko: it's a default for exim - I'm not inclined to override it, even if it can be
[08:52] <elmo> kiko: I already closed one from stub, I'll chase out the others later, thanks
[08:52] <kiko> elmo, okay. but this example underlines why getting access to bounce logs would be very good
[08:52] <elmo> yeah, I know
[08:54] <ifmy> elmo: I don't understand
[08:54] <elmo> ifmy: what don't you understand?
[08:55] <ifmy> [20:54] ifmy@ocace:/home/ifmy% host -t MX geekbox.be
[08:55] <ifmy> geekbox.be mail is handled by 10 agora.eu.org.
[08:55] <ifmy> my configuration was right, with a hostname, not an IP
[08:55] <elmo> that's not how it appears on the internet
[08:55] <SteveA> weird
[08:56] <elmo> $ dig @ns.ovh.net -t MX geekbox.be
[08:56] <elmo> ;; ANSWER SECTION:
[08:56] <elmo> geekbox.be.             86400   IN      MX      1 213.186.45.152.
[08:56] <SteveA> from my home machine, it gives a domain name
[08:56] <SteveA> from chinstrap, an IP address
[08:56] <kiko> I get an IP here
[08:56] <SteveA> from a server in bristol, an IP address
[08:56] <kiko> caching?
[08:56] <elmo> ask the NS server for the domain, it's giving an IP ATM
[08:57] <kiko> BjornT, ping?
[08:58] <ifmy> ok, I've to clean all that
[09:01] <BjornT> kiko: pong
[09:02] <kiko> BjornT, I'm on the phone now, but.. in 1h will you be around?
[09:04] <BjornT> kiko: maybe. i might go to bed soon.
[09:06] <ifmy> elmo: and now, what's the hostname you get for geekbox.be ?
[09:06] <kiko> ifmy, it's correct for me now.
[09:06] <ifmy> ok
[09:12] <ifmy> still nothing, I tried to re-send a mail from launchpad 5 minutes ago
[09:16] <ifmy> elmo: ping ?
[09:16] <elmo> ifmy: you're not going to get any mail for a while
[09:17] <elmo> there's a 37097 second TTL (time-to-live)  on your MX from the POV of our servers
[09:17] <elmo> until that expires, it's not going to be able to send you mail
[09:18] <ifmy> ok
[09:18] <ifmy> then it'll be for tomorrow morning
[09:18] <ifmy> thanks a lot
[09:19] <elmo> np
[09:34] <Burgwork> mpt, the buttons in LP are windows-wise, not gnome-wise
[09:35] <Burgwork> mpt, ie: [Yes]  [No] , not [No]  [Yes] 
[09:41] <ivoks> hi :)
[09:41] <pygi> hi 
[09:42] <ivoks> can we make a wish for one tiny feature? :)
[09:47] <bradb> ivoks, pygi: what's up?
[09:47] <ivoks> hi bradb 
[09:47] <bradb> hey
[09:47] <ivoks> i was wondering, copy buttons for translation suggestion
[09:47] <ivoks> will it be implemented in near future?
[09:48] <bradb> you'd have to ask carlos 
[09:48] <ivoks> ok, thanks
[10:29] <elmo> cprov: ?
[10:32] <ddaa> elmo: do you know what happened to neumayer and leningradskaya? The importd stuff there is now in /srv/importd.ubuntu.com, and no longer in /home/importd, also the HOME for importd is still /home/importd on those systems.
[10:32] <elmo> heh
[10:32] <elmo> ddaa: I was hoping you wouldn't notice ;-)
[10:33] <elmo> I stole them for the release, as I needed the machinepower to serve out release ISOs
[10:33] <ddaa> dude, this place is my secret lair where I breed undead, I'm bound notice changes there sooner or later ;-)
[10:34] <elmo> is there any chance you can do without those two machines, for a while longer (i.e. till June 7th) or so, or do I need to give them back to you?
[10:35] <ddaa> elmo: no problem, but I'd like if you could tell me when your doing anything with those systems that might affect importd.
[10:35] <elmo> ddaa: yes, sorry I honestly did mean to, I just forget - it happened the day before release and I was up 24 hours etc.
[10:36] <elmo> ddaa: FWIW, importd is completely untouched on those  machines, it's just that they're now sat on the wrongnetwork and won't be able to function as importds until they come back into the LAN
[10:36] <ddaa> elmo: so what exactly did you do?
[10:37] <elmo> literally just moved them outside of the LAN
[10:37] <elmo> (well, obviously also installed apache, rsync + vsftpd to serve releases stuff too)
[10:37] <ddaa> I mean, I _can_ ssh to importd@neumayer and importd@leningradskaya
[10:37] <ddaa> apparently there's a trick of sorts involved
[10:38] <elmo> yes, you can ssh in, but they won't be able to, e.g. talk to the database
[10:38] <ddaa> ow
[10:38] <ddaa> that is much, much more annoying
[10:38] <ddaa> shit man
[10:38] <elmo> well that's why I asked if you could do without them...
[10:38] <elmo> if it's a problem, I can put them back and find other machines to steal
[10:39] <ddaa> elmo I thought you tried to cover your tracks by moving the stuff to some other system, thus the change in name from /home/import to /srv/importd.ubuntu.com
[10:39] <elmo> ddaa: I don't think I did change that?
[10:40] <ddaa> well there is something certainly unusal, at least, the HOME does not match the login dir anymore
[10:40] <ddaa> not serious in itself, just weird
[10:40] <elmo> hmm, I'm confused
[10:41] <elmo> /home/importd is a symlink to /srv/importd.ubuntu.com ?
[10:41] <elmo> at least on leningradskaya
[10:42] <ddaa> mh... on marambio too...
[10:42] <ddaa> looks like we are both confused
[10:45] <ddaa> okay, I was the only one confused
[10:45] <ddaa> looks like "ssh -t screen" has some unexpected side effects
[10:47] <ddaa> elmo, if you need two big irons, what you can do that's not too disruptive for me is to give me back neumayer and take leningradskaya in place
[10:48] <ddaa> elmo: in summary, importd = galapagos neumayer marambio, cd builders = russkaya, leningradskaya
[10:48] <elmo> problem is, I need a certain amount of space, and we only have so many spare disks.  I'll keep leningradskaya and just give you neumayer back, if that's ok?
[10:49] <ddaa> hu
[10:50] <elmo> (that's why I chose neumayer, it has loads of disk.  and leningradskaya got two spares that were lieing around)
[10:50] <ddaa> let me rephrase: I want to keep galapagos and neumayer up and running because they have precious data which is a pain to migrate. But marambio, russkaya and leningradskaya have only non precious data and I only need one of those three at the moment as there is not a lot of autotest activity.
[10:50] <elmo> ok
[10:50] <elmo> I'll get znarl to plug neumayer back into the LAN tomorrow - is that soon enough?
[10:51] <ddaa> that's okay. That gives me a good excuse to postpone the importd rollout.
[11:30] <szekelyk> Hello, is there a launchpad admin?
[11:31] <szekelyk> I need help in merge my old and new account.
[11:36] <seb128> carlos: around?
[11:55] <KurtKraut> What team I have to belong to be able to close or change Support Requests priorities etc ?
[11:59] <matsubara> KurtKraut: you can't
[11:59] <matsubara> KurtKraut: currently it's only admins or the user who opened the support request can change its status
[11:59] <KurtKraut> matsubara, so the maximum help I can give thru LP is making comments to support request, right ?
[12:01] <matsubara> KurtKraut: you can reject them, but sometimes that might be un-polite.
[12:01] <matsubara> KurtKraut: or you can ask the users to close the support request themeselves
[12:02] <KurtKraut> matsubara, ok, I see. Is there a way os tracking requests that have not been replied ? It has been hard to find a request that was not replied yet.
[12:02] <KurtKraut> matsubara, Because I spend most of my time search for requests that still needs help.