[12:23] <jordi> hey
[12:23] <jordi> lifeless: here?
[12:23] <jordi> Product series
[12:23] <jordi> Don't use this (2006-02-05)
[12:23] <jordi> Damnit, why can't I remove series in launchpad?
[12:23] <ajmitch> hey jordi 
[12:24] <jordi> I found a product with this series
[12:24] <jordi> can it be hidden? (autopackage)
[04:55] <stub> lifeless: Did you assign the librarian last-accessed update to Bjorn? If so, I'm going to take it
[04:57] <lifeless> stub: go ahead
[04:57] <lifeless> stub: AFAIK you wanted only db reviews
[04:58] <stub> lifeless: normally yes. I'm taking this one though because I suspect the implementation will cause db issues
[05:43] <mpt__> hummm
[05:43] <mpt__> My Zope book doesn't explain what traversal is
[05:43] <mpt__> spiv?
[05:43] <spiv> mpt: traversal?
[05:44] <mpt> spiv, class ProjectNavigation has a "def traverse(self, name):" in it, and I'm wondering what it's used for
[05:44] <mpt> It consists of the line "return self.context.getProduct(name)", which seems like a thinko to me
[05:45] <mpt> ohhh, maybe not
[05:45] <mpt> the same function for ProductNavigation talks about series
[05:45] <mpt> humm, so it defines how to get the name of the main subset of the thing?
[05:46] <spiv> Traversal is the name for walking the path of objects.
[05:46] <mpt> Does such a path always go downward?
[05:47] <spiv> i.e. "foo/bar/baz" will ask foo for a "bar", and the result of that for a "baz".
[05:47] <mpt> ah, ok
[05:47] <mpt> I hadn't noticed until now that projects in launchpad had no hierarchy navigation ...
[05:48] <mpt> whoo-hoo
[05:48] <mpt> that was easy :-)
[05:49] <mpt> thanks spiv
[05:51] <spiv> No worries.
[06:04] <spiv> stub: I've taken your suggestion for library-last-accessed... do I have r=stub?
[06:15] <dilys> Merge to devel/launchpad/: [r=stub]  Changes to the librarian's upload protocol: Makes the Database-Name sanity-check header mandatory, and adds an optional Debug-ID header, which triggers more server-side debugging. (r3185: Andrew Bennetts)
[06:16] <jamesh> spiv: what do you think about getting the zopeless environment to use the same database adapter code as the webapp?
[06:17] <spiv> jamesh: In general, I'm in favour of reducing the difference between zopeless and non-zopeless.
[06:18] <spiv> I'm not sure exactly how much work is involved for this particular suggestion, but anything that reduces the mess can only be a good thing.
[06:19] <jamesh> spiv: I was mainly asking w.r.t. BjornT's email about doing OOPS reports from scripts
[06:19] <jamesh> given that things like SQL statement logging is done inside the webapp's DA
[06:19] <spiv> Yeah, I saw that.  It makes good sense.
[06:20] <jamesh> spiv: I suppose part of the reason for them being separate is that execute_zcml_for_scripts() wasn't around earlier?
[06:21] <spiv> I think so.
[06:21] <spiv> And we wanted to be able to use the same database classes outside the webapp.
[06:22] <spiv> So we needed somewhere to make all those classes be connected to a database without the full webapp environment.
[06:22] <jamesh> I wonder if the statement/request timeout code we've got would make sense for scripts?
[06:22] <spiv> Perhaps for some.  I think some have intentionally long-running transactions.
[06:23] <spiv> But e.g. it wouldn't harm the librarian to have those timeouts, even though I don't expect it would ever hit them.
[06:24] <spiv> Similarly, it would make sense for the authserver I think, even though it too does mainly simple queries.
[06:35] <spiv> jamesh: the pending reviews summary page seems to be a couple of days stale for me... is the cron script broken?
[06:42] <jamesh> spiv: https://chinstrap.ubuntu.com/~jamesh/pending-reviews.new/log shows a log of it running fairly recently.
[06:42] <jamesh> spiv: I think the problem was some branches ddaa put up for review with sftp://chinstrap.ubuntu.com/ URLs rather than sftp://chinstrap/ URLs
[06:43] <jamesh> I've changed them on the wiki page, and kicked off another run
[06:43] <spiv> jamesh: Thanks
[06:45] <jamesh> you can write some interesting code by using decorators for non-decorator purposes
[06:46] <jamesh> as a way of calling functions expecting a function as their only argument
[06:47] <spiv> jamesh: Yeah, some Twisted people have noticed this.
[06:47] <spiv> @deferred.addCallback
[06:47] <spiv> def _(result): ...
[06:47] <spiv> Or something.
[06:48] <jamesh> or l = [5,4,3,2,1]  ; @l.sort
[06:48] <jamesh> def compare(a, b): ...
[06:48] <spiv> "interesting" is a polite euphemism for it :)
[06:50] <jamesh> it'd be even more useful if Python did curried functions by default
[06:51] <jamesh> @widget.connect('show'); def _(widget): ...
[07:03] <jamesh> I'd guess that the pending-reviews code will need to have some updates by the time we move on to bzr-0.8 on chinstrap
[08:44] <jamesh> spiv: pending-reviews page should be up to date again (and not spewing on branch names ending with a slash)
[08:56] <stub> spiv: Yes
[08:59] <stub> If it looks like being a sane implementation, using the Z3 DA for Zopeless stuff would be fine (as long as we can access a Python DBI connection via sqlbase.connect() or something as I find this much easier to work with when not dealing with SQLObject).
[09:00] <stub> Another benefit would be that the DA does exception sniffing, making it easy for our scripts to catch Retry exceptions and retry the transaction.
[09:01] <stub> (given the nature of Launchpad, we need to be aware that deadlock exceptions could happen at almost any point)
[09:11] <jamesh> stub: the tests in canonical/launchpad/webapp/ftests/test_adapter.txt effectively do this.
[09:12] <jamesh> calling the adapter gives you an object implementing the DB-API
[09:13] <jamesh> DB-API connection object, that is
[09:18] <stub> Thats probably a saner way of getting it, rather than the existing approach of using SQLBase._connection._connection or whatever disgusting magic we currently use.
[09:24] <stub> although it is more unusual to see dict(foo=bar) instead of {foo: bar}, it seems that the former is now officially preferred and may be the only way of spelling it in Python 3.0
[09:24] <stub> javaesqe
[09:25] <stub> along with tuple(foo for bar in baz) and list(foo for bar in baz)
[09:26] <stub> which matches set(foo for bar in baz), and one reason there is no magic punctuation for sets
[09:28] <jamesh> the lack of punctuation for sets means that you need some other sequence type to initialise them.  e.g. set([1,2,3,4] )
[09:30] <jamesh> the problem with allowing set(1,2,3,4) being that it leads to ambiguity if you want a set containing a single iterator as a member
[09:35] <stub> I don't think a set could contain an iterator, as the members of the set need to be immutable
[09:36] <jamesh> they just need to be hashable
[09:36] <jamesh> don't they?
[09:37] <stub> iterators generally aren't hashable. You would also need to support equality as the hashes are not guaranteed unique
[09:37] <stub> so technically yes, but I think it would be frowned apon like using similar objects as keys to a dictionary
[09:37] <jamesh> set([itertools.repeat(42)] )
[09:38] <jamesh> that's a nice hashable iterator
[09:43] <stub> >>> s = set([itertools.repeat(42), itertools.repeat(42)] )
[09:43] <stub> >>> s
[09:43] <stub> set([repeat(42), repeat(42)] )
[09:43] <stub> lovely :-)
[09:44] <stub> >>> s.remove(itertools.repeat(42))
[09:44] <jamesh> yay for default __hash__ implementations on user defined classes!
[09:44] <stub> Traceback (most recent call last):
[09:44] <stub>   File "<stdin>", line 1, in ?
[09:44] <stub> KeyError: repeat(42)
[10:01] <mpt> Can anyone tell me which "../rocketfuel" is being referred to in "/home/warthogs/source/bzr.integration/bzr baz-import-branch $DESTARCHIVE/c/[v/] b $SRCARCHIVE/c--b--v ../rocketfuel"?
[10:02] <mpt> Is it /home/warthogs/archives/rocketfuel?
[10:02] <jamesh> yes
[10:02] <mpt> ok, ta
[10:02] <jamesh> because you should be in /home/warthogs/archives/mpt when running that command
[10:02] <jamesh> (according to that document)
[10:03] <mpt> "/home/warthogs/archives/mpt@canonical.com/launchpad--menus--0509 is not a valid Arch branch."
[10:04] <mpt> hmm, it contains base-0/ and patch-1/ through patch-35/, but nothing else
[10:04] <jamesh> try mpt@canonical.com/launchpad--menus--0509 instead
[10:05] <jamesh> remember that baz used it's own namespace for archives rather than just filesystem paths
[10:05] <mpt> oh.
[10:05] <mpt> ... which is why we're using bzr!
[10:06] <jamesh> it's amazing how quickly you forget these things ...
[10:07] <mpt> My girlfriend keeps on accusing me of having an excellent memory
[10:07] <mpt> No, no, I only have an excellent memory *compared with her* ...
[10:08] <mpt> thanks jamesh, that looks worky
[10:27] <jamesh> mpt: I wasn
[10:28] <jamesh> 't referring to you in particular.  Whenever I go back to a baz branch, I keep on typing bzr commands by mistake
[10:28] <sivang> jamesh: I was bitten by this as well, when you get used so good to bzr, you can't imagine how you used to work with baz.
[10:29] <mpt> So, bzr is bad because it's too easy to use and dulls programmers' brains
[10:31] <jamesh> yes
[10:33] <ddaa> sivang: I perfectly remember what it was like
[10:33] <ddaa> it involved large amount of swearing and shouting at baz team folks ;)
[10:36] <ddaa> Can an admin please approve https://launchpad.net/products/f-spot
[10:39] <Kamion> mpt: still around? can I borrow you in #ubuntu-devel for a brief query on UbuntuExpress/GnomeUserInterface?
[10:44] <ddaa> daf: ping
[10:44] <daf> pong
[10:44] <ddaa> see you requested buttsource membership, can I ask you why you need it?
[10:44] <daf> eep, did I?
[10:45] <daf> I should have been doing that on localhost
[10:45] <daf> please ignore it
[10:45] <ddaa> I'll decline then.
[10:47] <daf> stub: can you tell me what was the cause of the 'olumn "official_malone" does not exist' stuff?
[10:49] <stub> daf: A bad rollout - there was code expecting database patches to have been applied that had not been.
[10:49] <stub> daf: So a temporary situation - just ignore 'em.
[10:49] <daf> ok, same as the KeyError stuff
[10:49] <daf> groovy
[10:50] <jamesh> so tomorrow's report will be more representative of problems with the latest rollout
[10:50] <daf> we had lots of KeyErros yesterday because of a missing DB update (DB schema change)
[10:51] <daf> https://chinstrap.ubuntu.com/~jamesh/oops-summaries/2006-02-21.html
[10:51] <jamesh> I noticed
[10:51] <jamesh> missing "official_malone" column, etc
[10:52] <daf> right
[10:53] <daf> ignoring rollout problems and retry exceptions, we only got about 60 exceptions yesterday
[10:54] <daf> and a fair number of those look like it was matsubara and kiko and I reproducing bugs :)
[10:55] <jamesh> I wonder how much we skew these results ...
[10:55] <daf> silly idea: make OOPS reports caused by members of the Launchpad team a different colour
[10:58] <mpt> Why? The Launchpad team are people too
[10:58] <mpt> or did you mean so they could be made higher priority?
[10:58] <jamesh> mpt: if we use the frequency of a particular exception to indicate priority to fix it, then it might be a problem
[10:59] <mpt> Well, bugs ddaa encounters should be high priority
[10:59] <mpt> same with jordi
[11:00] <ddaa> better to ask though, there's a bunch of bugs I filed 6 months ago that are not really relevant anymore
[11:00] <mpt> sshh, don't say that, or it'll become our standard way of dealing with bugs
[11:01] <daf> mpt: so that we can tell user crashes apart from developer crashes, and not be misled into giving a problem that users aren't experiencing a high priority
[11:02] <daf> well, rather, I want to be able to filter out OOPSes triggered during bug triage
[11:02] <mpt> yeah, just when reproducing bugs
[11:02] <mpt> because Oopses we experience elsewhere affect our ability to do work, including fixing other bugs
[11:03] <jamesh> daf: you could do that by using staging.launchpad.net :)
[11:05] <daf> good point :)
[11:10] <mpt> You could hack :text-to-html so that if it's being called from within bugs in products that are part of the launchpad project, launchpad.net URls could be linkified to point to staging.launchpad.net instead ...
[11:11] <stub> As long as we know the skew is there I think we can compensate.
[11:11] <jordi> mpt: ?
[11:11] <jordi> oh
[11:11] <jordi> sounds like a great idea :P
[11:15] <daf> it's not a big skew
[11:15] <daf> a few oopses per day
[11:17] <mpt> keeps the doctor away
[11:18] <mpt> but yeah, not worth worrying about imo
[11:41] <mdke> has any progress been made on allowing the distro managers to approve/disapprove breezy-updates?
[11:42] <Kinnison> they can
[11:43] <mdke> ok cool
[11:43] <Kinnison> and have been able to for a while
[11:43] <mdke> Kinnison, do they know how?
[11:43] <Kinnison> mdke: I believe kamion knows
[11:44] <mdke> great
[11:44] <Kinnison> mdke: and if he has forgotten, I can remind him easily enough if he asks
[11:45] <mdke> coolio
[11:56] <jordi> daf: carlos just phoned me, his telco just cut his ADSL or something, and he's charging his mobile phone to be able to connect via mobile for the meeting
[12:00] <daf> thanks for the notice jordi 
[12:10] <daf> spiv_: did you get my mail about optional-branch-title?
[12:11] <sivang> guys, any py guru's around? I have an IO manipulation problem. I have a program which spanws another program and read it's stderr and attempts to send commands to it based on the stderr line
[12:11] <sivang> now, this is working fine as it seems, since I'm using a code snippet I found on the net for talking to process this way.
[12:11] <sivang> however - 
[12:12] <ddaa> sivang: I know a bit about such problems, go on.
[12:12] <sivang> when I sys.stdin.readline() from the user to confirm something the spawnd program wants to do, I need to press between 3-10 CRs to make it go, and then I see the it already got my CRs but didn't show or send it to the spawnd program...
[12:13] <sivang> ddaa: I use this , to do subuprocess comm - http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554
[12:13] <ddaa> hu... can you rephrase that?
[12:13] <sivang> well, I can show you the code , but it's messy :)
[12:14] <daf> sivang: this sort of problem is common when communicating with an interactive subprocess
[12:14] <daf> sivang: it's something that's really tricky to get right, in my experience
[12:14] <sivang> daf: so what do I do? I am also using generators to be able to propogate progress information neatly to the clinet
[12:14] <ddaa> Mh... random guess
[12:14] <ddaa> sometimes proc.stdin.flush() helps
[12:14] <sivang> o..
[12:15] <sivang> ddaa: I pray this is the problem (I recall doing that in C)
[12:15] <sivang> ddaa: s/pray/?? how do you spell tht work/
[12:15] <ddaa> I think that's correct
[12:16] <ddaa> but I'm not the person you want to ask about english lenguage :)
[12:16] <daf> if you have control over the subprocess, it might be easier in the long term to use a different IPC mechanism (fd other than stdin/stdout, pipe, named pipe, socket pair, etc.)
[12:16] <daf> i.e. if you can modify the subprocess's code
[12:16] <sivang> daf: tha'ts a wise idea. How do I use an fd instead of stdio ?
[12:17] <ddaa> IME makes no significant difference
[12:17] <ddaa> pipes are just a messy IPC system
[12:17] <daf> hmm, really?
[12:17] <daf> stdio can have weird buffering behaviour in my experience
[12:18] <ddaa> well, maybe. In my experience, the buffering issues pale in front of the systemic buffering issues involved in pipes.
[12:19] <daf> hmm, I thought using a pair of pipes was fairly similar to using a socket
[12:19] <daf> then again, I've only done that in the case where I was writing the code on both ends of the pipe
[12:20] <ddaa> daf: I guess so. Except doing select portably on pipes is a real nightmare (I think I found some telling documentation in twisted about that, or in the code)
[12:20] <jamesh> daf: you can't create a pipe that you can listen() on and receive multiple connections
[12:20] <jamesh> (among other things)
[12:20] <ddaa> daf: some peope report using socketpair() to fool processes into using pipes instead of processes for stdio... and say it made things simpler... I never tried personally.
[12:21] <ddaa> s/into using pipes instead of processes/into using sockets instead of pipes/
[12:21] <daf> jamesh: right -- I was thinking about the equivalent thing using socketpair()
[12:21] <sivang> ddaa: it's a nightmare. I had originally used an own version to do that. after loosing last night's sleep over that, I am now using the module from the cookbook I've pasted the link to
[12:22] <sivang> ddaa: what's socketpair?
[12:22] <sivang> ddaa: (sounds like a solution)
[12:22] <ddaa> async subprocess...
[12:22] <ddaa> mh...
[12:22] <daf> sivang: it's a syscall like pipe(), but which returns a pair of sockets instead of the endpoints of the pipe
[12:23] <daf> sivang: with the difference that you can write to both ends of the socket
[12:23] <daf> (as opposed to pipes, which are one way)
[12:23] <ddaa> sivang: if you want async, I suggest you 1. use threads 2. use pexpect (use a tty instead of pipes) 3. use twisted, they (mostly) solved it for you
[12:23] <sivang> daf: hmm. does that circumvent the buffering issues?
[12:24] <daf> maybe
[12:24] <sivang> ddaa: you mean threads instead of subprocess.Popen ?
[12:24] <daf> this is a really tricky sort of situation
[12:24] <ddaa> No, I mean Popen within a thread
[12:24] <ddaa> so you you can put all the blocking stuff in the thread
[12:24] <ddaa> and communicated with the main thread using synchronized queues for example
[12:24] <daf> twisted seems to have magic for making this stuff work, but getting to grips with twisted can take a while if you haven't used it before
[12:25] <sivang> I haven't, no.
[12:25] <daf> pexpect might well be worth investigating
[12:25] <ddaa> pexpect, that's in the stdlib
[12:25] <sivang> btw, are any of this applied in LP? :-)
[12:25] <ddaa> hu no, that's not
[12:25] <ddaa> but that's in ubuntu :)
[12:25] <sivang> ddaa: Anything specific you know of?
[12:26] <ddaa> sivang: I did a fair bit of twisted subprocess handling voodoo back when importd was being multithreaded (lifeless thought that would be a neat idea)
[12:26] <daf> voodoo is the word
[12:27] <ddaa> actually the problem was compounded by bugs in Python and libc...
[12:27] <ddaa> don't want to think about it...
[12:28] <sivang> ddaa: re threads, everybody I asked and any doc on the net tells you to avoid threads in python. That's why my code uses generators so nicely. only when I needed a piece of code to also send stuff to the spanwed child stdin, then problem arose.
[12:28] <ddaa> but I warmly recommend twisted's subprocess, IMO it's significantly superior to subprocess. And if you care about async, it beats it hand down.
[12:28] <sivang> ddaa: (GIL and other sutff)
[12:29] <ddaa> Python threads are very useful to turn a sychronous API into an async one.
[12:29] <sivang> ddaa: but didn't twisted brought you to doing voodo? I'm afraid of voodo, it hurts when the needle stings you:)
[12:29] <ddaa> in that case, your thread is blocking or idle most of the time, so you do not mind the GIL.
[12:30] <sivang> ddaa: indeed, right. being a IO intensive operation it would.
[12:30] <Kamion> sivang: FWIW espresso has some simple async pipe handling without messing with twisted
[12:30] <jamesh> it isn't difficult to handle a pair of pipes with select()
[12:30] <jamesh> just make sure you use os.read()/os.write()
[12:30] <ddaa> besides, the GIL is overrated. Sure, it hurts you when you intended to spread python code execution over multiple processor. But if you start caring about this level of performance, there are ways around the issues (C extensions that release the GIL, multiprocessing, etc.)
[12:31] <Kamion> sivang: it's in espresso/debconffilter.py - although it's only asynchronous while reading from pipes because I have a special situation and know that writing to the pipe won't block "for long"
[12:31] <ddaa> jamesh: the difficult bit is being portable
[12:31] <jamesh> ddaa: the GIL is most painful when you want to use Python with some other code that has a global lock
[12:31] <Kamion> I too generally find threads much more painful than a half-decent state machine
[12:31] <ddaa> jamesh: I can imagine deadlocks arising...
[12:31] <jamesh> ddaa: really?
[12:32] <daf> meeting in 30
[12:32] <ddaa> jamesh: I remember seing a table that described the various combinations of readable/writable select gave for pipes in various states in various operating systems.
[12:32] <sivang> jamesh: I didn't think it would be too hard, I guess I'm inexperienced in that such that it brought be to a dead end. In any event, I'm now using an "improved" subprocess from the Cookbook, still my issue is with too buffered output / input AFAICT.
[12:33] <cprov> good morning 
[12:34] <Kamion> ddaa: are you thinking of http://www.greenend.org.uk/rjk/2001/06/poll.html
[12:34] <Kamion> ?
[12:34] <jamesh> sivang: wrapping a using a Python file object to read from a pipe will cause problems, since it retries the read on EINTR
[12:34] <Kamion> I thought those problems chiefly applied to poll(), not select()
[12:35] <jamesh> sivang: when reading from a pipe, you'll get an EINTR when there is no more to read from the pipe, at which point you probably want to select() again rather than block :)
[12:35] <ddaa> Kamion: it might be that one...
[12:35] <ddaa> mh...
[12:36] <Kamion> jamesh: whether that's a problem depends on what you're expecting, to some extent. For instance in espresso I know that I always get pretty much a line of input at a time, so whenever the input fd becomes readable I can just read a single line and then go back to selecting.
[12:36] <Kamion> For fully generic async operation, sure.
[12:37] <Kamion> (though actually I use os.read anyway ...)
[12:37] <jamesh> Kamion: in which case an os.read() call would generally give you that line
[12:37] <Kamion> yeah
[12:37] <sivang> jamesh: I see. I guess that Cookbook class has this same illness? 
[12:37] <daf> jamesh: I thought Python made EINTR invisible in most cases
[12:38] <jamesh> daf: Python file objects do, yes
[12:38] <Kamion> I needed to get at the fd anyway to give it to gobject.io_watch_fd, so there was little point bothering with a file object
[12:38] <jamesh> daf: they retry reads/writes on EINTR
[12:38] <carlos> hi
[12:38] <ddaa> Kamion: I think that was the one. I guess I was confused about the portability thing.
[12:38] <jamesh> daf: however, if you have a pipe you often don't want to retry because you'll hang
[12:38] <daf> jamesh: ah, true
[12:39] <daf> jamesh: so short reads should never happen with sync access to on-disk files, but it can happen with pipes and other types of fd?
[12:40] <jamesh> actually, the EINTR bit is a red herring.  The problem with python file objects and pipes is that they retry short reads
[12:41] <jamesh> if I issue os.read(fd, 4096), and there is only 100 bytes to read, then it will return those 100 bytes
[12:41] <jamesh> fp.read(4096) will issue a read, get 100 bytes, then issue another read for 3996 bytes
[12:42] <jamesh> not returning until it gets the full 4096 bytes
[12:42] <daf> and potentially hang if it's a pipe
[12:42] <ddaa> daf: as far as I know EINTR can also happen if your process handled a signal while it was blocking
[12:43] <matsubara> good morning!
[12:43] <ddaa> daf: that was one of the problem with Python when it was not retrying automatically, blocking on pipe occasionally caused the EINTR to bubble up as an OSError when SIGCHLD was unmasked.
[12:44] <sivang> morning matsubara 
[12:45] <matsubara> hey sivang
[12:45] <ddaa> I see no reason why it could not happen with any sort of "real" fd (except stuff like /proc files).
[12:47] <sivang> Kamion: you're code looks nice, I'd just have to see how I can incorporate it in my code though
[12:48] <jamesh> ddaa: an EINTR literally means "system call interrupted", and can occur pretty much any time an asynchronous signal is delivered to the process
[12:49] <ddaa> yup, but there's a gap from knowing the definition and telling how it applies to specific cases :)
[12:50] <ddaa> besides, it's not real clear to me what an "asynchronous signal" is in this context.
[12:53] <Kamion> ddaa: it's just another name for a Unix signal
[12:58] <kiko-zzz> morning
[12:58] <kiko> meeting in +2 minutes
[12:58] <kiko> additional agenda items to me
[12:58] <jblack> Oh that's right. You're the man
[12:59] <kiko> well, THAT goes without saying!
[12:59] <jblack> I guess we can't lie to you about whether our act..
[12:59] <jblack> lol!
[01:00] <kiko> IT IS TIME
[01:00] <kiko> --------------------------------------------------------------------
[01:00] <daf> MEETING TIME
[01:00] <kiko> welcome carlos_ 
[01:00] <kiko> who is present?
[01:00] <mpt> here
[01:00] <matsubara> here
[01:00] <kiko> here
[01:00] <salgado> me
[01:00] <daf> me
[01:00] <jamesh> me
[01:00] <jblack> me
[01:00] <carlos_> me
[01:00] <ddaa> I am.
[01:00] <BjornT> me
[01:00] <kiko> aha
[01:01] <spiv_> me
[01:01] <kiko> can someone call bradb?
[01:01] <kiko> stub?
[01:01] <jblack> I think I can call canada
[01:01] <kiko> Kinnison can participate at his discretion
[01:01] <mpt> "O, Canada..."
[01:02] <kiko> moving on, laggards be noted
[01:02] <kiko> Agenda
[01:02] <kiko>     *
[01:02] <kiko>       Roll call
[01:02] <kiko>     *
[01:02] <kiko>       Agenda
[01:02] <kiko>     *
[01:02] <kiko>       Next meeting
[01:02] <kiko>     *
[01:02] <kiko>       Activity reports
[01:02] <kiko>     *
[01:02] <kiko>       Items from last meeting
[01:02] <kiko>     *
[01:02] <kiko>       Launchpad oops milestone report (daf)
[01:02] <kiko>     *
[01:02] <kiko>       Production / staging (stub)
[01:02] <kiko>     *
[01:02] <kiko>       Keep, Bag, Change
[01:02] <kiko>     *
[01:02] <kiko>       Three sentences
[01:02] <kiko> doesn't it suck when you paste in from the wiki?
[01:02] <kiko> that was the agenda item
[01:02] <kiko> next week, same time, same place, any objections?
[01:02] <kiko> 5
[01:02] <kiko> 4
[01:02] <kiko> 3
[01:02] <kiko> 2
[01:03] <kiko> 1
[01:03] <jblack> kiko: no answer from bradb. I'm calling across a border though.
[01:03] <kiko> very well, it is done
[01:03] <bradb> doh, hi
[01:03] <kiko> hello bradb 
[01:03] <kiko> good to have you with us
[01:03] <kiko> thanks mpt 
[01:03] <mpt> wait, no, that doesn't work
[01:03] <kiko> now for a date that actually exists :)
[01:03] <kiko> my dad's birthday!
[01:03] <kiko> moving on
[01:03] <spiv> mpt: that's better :)
[01:04] <mpt> (It's Friday for me...)
[01:04] <kiko> who's an activity reporter, and who's a black hole of doom?
[01:04] <kiko> I am a reporter
[01:04] <daf> Kinnison: oi
[01:04] <salgado> I'm a reporter
[01:04] <mpt> up to date except yesterday
[01:04] <Kinnison> daf: yes?
[01:04] <jblack> I think I'm a reporter.
[01:04] <BjornT> i'm up to date
[01:04] <matsubara> up to date
[01:04] <daf> ah, you're here
[01:04] <ddaa> uptodate
[01:04] <daf> up to date
[01:04] <Kinnison> daf: I'm here, I'm up to date, I'm working on distro
[01:05] <kiko> spiv, how's your reporting?
[01:05] <carlos> I'm missing yesterday's one due problems with my network connection. Will try to send it later today
[01:05] <daf> Kinnison: *cough* right
[01:05] <spiv> I'm up to date
[01:05] <kiko> Kinnison, I'm happy to know you're not late!
[01:05] <kiko> good going spiv 
[01:05] <mpt> ... up to date
[01:05] <Kinnison> kiko: I was, <tmi>on the loo</tmi> when the meeting started :-)
[01:05] <kiko> jamesh, boos to you
[01:05] <kiko> TMI!
[01:05] <daf> cprov: oi
[01:05] <kiko> steve has not been sending in his reports either
[01:06] <kiko> moving on to more fun things
[01:06] <kiko> == Actions from last week ==
[01:06] <kiko>  * MeetingAction: Kiko to put his error/timeout debugging advice on the wiki
[01:06] <kiko>  * MeetingAction: Robert to report on Asterisk progress
[01:06] <kiko>  * MeetingAction: kiko and daf to assign oops bugs to people
[01:06] <kiko>  * MeetingAction: carlos to tell stub (and the list) the patch level when he gets optimisation code reviewed and landed
[01:06] <kiko>  * MeetingAction: daf and Kinnison to send activity reports more than once a week
[01:06] <cprov> up to date
[01:06] <kiko> first one is me, and done -- has anyone looked at CrashDebugging?
[01:06] <kiko> https://wiki.launchpad.canonical.com/CrashDebugging\
[01:06] <daf> looked at it, yes
[01:07] <carlos> mine is done too
[01:07] <kiko> daf, how does it look?
[01:07] <kiko> lifeless has not sent in any report on progress on asterisk
[01:07] <kiko> boos to him
[01:07] <daf> good
[01:07] <daf> it looks good, that is
[01:07] <kiko> daf and I did a major whack of oops reports last week
[01:07] <kiko> and yesterday again
[01:07] <jblack> lifeless is under the gun for bzr 0.8 in dapper.
[01:07] <kiko> and today we'll look into timeouts and other forgotten crashes
[01:08] <daf> better than being in front of the gun
[01:08] <kiko> jblack, he still didn't send in a report.
[01:08] <kiko> any additional tips on crashdebugging that you have, please, add to the page
[01:08] <kiko> carlos told stub the relevant patch level, but in the end we didn't roll it out because of test failures
[01:08] <kiko> such is life
[01:09] <carlos> kiko: but it's done with Tuesday's roll out
[01:09] <kiko> the code was rolled out on tuesday, yes.
[01:09] <kiko> so good work regardless
[01:09] <kiko> daf and Kinnison have been better with activity reporting daily
[01:09] <kiko> congratulations
[01:09] <kiko> it's getting close to stub's part of the show
[01:09] <kiko> can someone call him?
[01:09] <kiko> perhaps spiv or jamesh?
[01:10] <jamesh> sure, I'll just find his number
[01:10] <kiko> thanks
[01:10] <kiko> moving on
[01:10] <jamesh> (it is an international call for me as well though)
[01:10] <kiko>  * Launchpad oops milestone report (daf)
[01:10] <daf> yo
[01:10] <kiko> (jamesh, yeah, but somebody needs to do it, and you can expense it)
[01:11] <daf> so, the oops milestone has many more bugs than last week
[01:11] <daf> but that's mostly because we've assigned more bugs to it rather than many more oopses happening
[01:11] <daf> in fact, oopses are down
[01:11] <kiko> that's exactly correct
[01:11] <daf> it's good to see the work we've been doing bearing fruit
[01:12] <kiko> here's an open question
[01:12] <daf> fire
[01:12] <kiko> who has some time free or a priority to bump down to help us nail top reports today and tomorrow?
[01:12] <kiko> most of them are easy to fix and test
[01:12] <daf> "top reports" -- you mean most often?
[01:12] <kiko> yes, the most critical oopses.
[01:13] <kiko> so, nobody
[01:13] <kiko> bradb, BjornT?
[01:13] <kiko> spiv, jamesh?
[01:13] <kiko> carlos, cprov?
[01:13] <kiko> salgado?
[01:13] <carlos> kiko: well... I'm a bit behind my schedule...
[01:13] <BjornT> kiko: well, if neccessary, sure, i could help nailing down an oops or two.
[01:14] <kiko> BjornT, it would be most appreciated.
[01:14] <spiv> kiko: I can look at doing a few.
[01:14] <BjornT> i do think that reducing oops is a top priority
[01:14] <carlos> kiko: and dapper imports is my priority atm, when I finish with that, I will kill some of those bugs
[01:14] <jamesh> kiko: stub says he'll be back in about 20 minutes
[01:14] <kiko> spiv, you know, backporting *Join() would be the /most/ helpful thing you could do right now
[01:14] <kiko> carlos, okay, that's cool.
[01:14] <cprov> kiko: ehe, apart of the UI, that you told me to forget about for a while, the high priority things are performance improvement in osyuz backend  
[01:14] <bradb> there's always time for a true Quick Fix
[01:15] <kiko> cprov, I know, it was just a poke.
[01:15] <kiko> spiv, any chance for you to tackle that as a one-day-hack?
[01:15] <salgado> kiko, I guess I can
[01:15] <kiko> I can fast-track review and everything you need
[01:15] <kiko> jamesh is my second option for that one
[01:16] <kiko> jamesh, thanks for the note
[01:16] <kiko> okay, let's see how we can mangle this agenda
[01:16] <jamesh> backporting SQLRelatedJoin + SQLMultipleJoin to our SQLObject would probably be about 15 minutes + time to test things
[01:16] <spiv> kiko: Yeah, I can do that.
[01:17] <kiko> spiv, tomorrow?
[01:17] <jamesh> (it is another matter to migrate code over to them
[01:17] <spiv> kiko: As jamesh says, it looks to be fairly self-contained.
[01:17] <spiv> kiko: Yes.
[01:17] <kiko> spiv, that would /kill/ -- it would really help timeouts
[01:17] <sivang> ddaa: pexpect looks cool , thx
[01:17] <kiko> jamesh, why do you say migrate code over?
[01:17] <kiko> I see -- because some code will assume we have a list as output?
[01:18] <jamesh> yeah
[01:18] <spiv> I'd leave the existing MultipleJoins alone.
[01:18] <spiv> And backport them under a different name, I think.
[01:18] <spiv> Or just try it and see what breaks...
[01:18] <jamesh> although porting a few high profile MultipleJoins to SQLMultipleJoin would probably have a pretty big payoff without much risk
[01:19] <jamesh> e.g. source_package_caches
[01:19] <spiv> jamesh: My thinking exactly...
[01:19] <kiko> jamesh, what do you think of spiv's idea of adding the new ones with a different name?
[01:19] <jamesh> kiko: that's what has been done upstream, so that's what we should do for the backport
[01:19] <kiko> I see.
[01:20] <kiko> well, spiv, if you can land the backported versions, I can either take care or get people to take care of porting code over.
[01:20] <kiko> deal?
[01:20] <jamesh> kiko: moving further from the upstream SQLObject API is likely to cause maintenance problems down the road
[01:20] <kiko> I know, but I'm afraid we are already miles down that road
[01:21] <jamesh> well, most of our changes have been API additions
[01:21] <kiko> spiv, carlos: did the librarian 'hack' for avoiding the problem with exports get applied?
[01:21] <jamesh> which aren't as bad as changing the behaviour of existing API
[01:21] <carlos> kiko: no, I hadn't time to do that change
[01:21] <kiko> jamesh, yes, but we've failed to track tip, and our code now relies on behaviours
[01:21] <kiko> carlos, is it hard?
[01:21] <carlos> no
[01:21] <carlos> I will try to apply it before leaving on Friday
[01:21] <spiv> kiko, carlos: there's additional debugging in the server now merged.  It needs to be rolled out, and then carlos needs to trivially update the cron script to use it.
[01:21] <kiko> maybe getting it in for the next rollout would be nice
[01:22] <kiko> spiv, carlos can update the code now, and then when the rollout on tuesday happens everything works, right?
[01:22] <spiv> kiko: Incidentally, Ian Bicking announced plans for SQLObject 2.0 today.
[01:22] <kiko> I wonder if that's good or bad news :)
[01:22] <spiv> kiko: Yeah.
[01:22] <carlos> kiko: I guess I can try to do it later today
[01:22] <jamesh> spiv: what happened to 1.0? :)
[01:22] <kiko> great
[01:23] <kiko> thanks carlos 
[01:23] <carlos> and ask stub to include it with the rollout
[01:23] <kiko> okay
[01:23] <kiko> we have some slack -- does anyone want to touch base on anything?
[01:23] <mpt> I wanted to talk about an answer for the people who ask where they can download Launchpad
[01:24] <spiv> jamesh: Excellent question :)
[01:24] <mpt> or when it's going to be open sourced
[01:24] <mpt> or why it isn't
[01:24] <mpt> etc
[01:24] <kiko> mpt, I have a FAQ that will land today on exactly that topic.
[01:24] <kiko> based on a statement mark provided 
[01:24] <kiko> near-verbatim actually
[01:24] <kiko> is that an acceptable solution?
[01:24] <mpt> There's already a FAQ on it, but people don't read the FAQ so far as I can tell
[01:24] <mpt> yep, that's ok
[01:24] <kiko> the FAQ sucks
[01:24] <kiko> the new one is verbose
[01:25] <daf> for those who haven't seen it yet: http://geekz.co.uk/lovesraymond/archive/cancomical-lynchpad
[01:25] <kiko> it doesn't really explain the essential whys
[01:25] <kiko> but it does give alternatives and some rationale
[01:25] <jamesh> mpt: if it is in the FAQ, we can point people at the canned response
[01:25] <kiko> agreed
[01:25] <kiko> daf, you know OOPS-53A247? I am wondering why this still showed up in a log on wednesday
[01:25] <mpt> I actually have a list of people who have asked me to mail them when Launchpad is open sourced
[01:25] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/53A247
[01:26] <kiko> was it only fixed yesterday?
[01:26] <daf> kiko: stub says it was a rollout issue that should be gone by now
[01:26] <daf> we can ignore any official_malone stuff in today's report
[01:26] <kiko> I know, but I wonder why it still happened yesterday
[01:27] <kiko> "coisas de stub"
[01:27] <kiko> okay, anything else?
[01:27] <kiko> 5
[01:27] <kiko> 4
[01:27] <kiko> 3
[01:27] <kiko> 2
[01:27] <kiko> 1
[01:27] <kiko> let's do a super-quick keep-bag-change session
[01:27] <kiko>  * Keep, Bag, Change
[01:28] <kiko> any items you feel strongly about? say it!
[01:28] <kiko> 5
[01:28] <kiko> 4
[01:28] <kiko> Change: port SQLObject's MultipleJoin
[01:28] <kiko> Change: keep us informed of the Zope3.2 and PgSQL8.1 work
[01:28] <kiko> 3
[01:29] <daf> kiko += 2
[01:29] <kiko> Change: regular mail to the launchpad list when production is updated, bounced, or cronscripts enabled/disabled
[01:29] <kiko> 2
[01:29] <kiko> 1
[01:29] <kiko> brazilian can not run meetings
[01:29] <ddaa> Change: more planning when doing big features.
[01:29] <kiko> all right
[01:30] <kiko> ddaa, that's a surprising one. do you feel we have our heads down too much of the time?
[01:30] <ddaa> Absolutely.
[01:30] <kiko> interesting
[01:30] <kiko> perhaps you are right
[01:30] <mpt> ddaa, above our usual spec level?
[01:30] <ddaa> Trying to make specs for large changes in a few days of frantic sprints is not good.
[01:30] <mpt> We seem to be bad at big-picture specs
[01:30] <kiko> the lack of medium-term goals has indeed been a problem
[01:30] <kiko> mpt's right
[01:31] <kiko> ironically those are the specs mpt devotes more time too :)
[01:31] <ddaa> mpt: I dunno what other people's spect look like, but there's a massive amount of duplication, YAGNI, and never-implemented stuff in specs that's I'm in contact to.
[01:31] <kiko> we really should do more wiki gardening at least
[01:31] <mpt> Maybe I should spend some time on spec weeding
[01:31] <kiko> Change: more wiki gardening
[01:31] <kiko> mpt, I was going to suggest that
[01:31] <kiko> REALLY
[01:32] <ddaa> Also, I think the time I spent on writing docs and plan in the recent weeks helped me considerably to understand the big picture as well as the implementation details.
[01:32] <kiko> mpt, and send in launchpad mail when you have questions, corrections or help
[01:32] <mpt> ok
[01:32] <kiko> nice idea
[01:32] <kiko> all right
[01:32] <kiko>  * Three sentences
[01:32] <mpt> It will help me understand more of Launchpad's goolies too, which will be good
[01:32] <kiko> DO IT
[01:32] <mpt> DONE: LP page headings, bugfixes, MaloneSimplifications approval
[01:32] <mpt> TODO: bug fixing (starting with menu-related bugs), wiki gardening
[01:32] <mpt> BLOCKED: Reviews of FixingProjects, MaloneSearch, DuplicateBugHandling
[01:32] <matsubara> DONE: support to users via email and irc, finally fixed distrotask validator, triage, fixed some code that was using SR.__len__(), manually tested the processes that use gpg on staging.
[01:32] <ddaa> DONE: importd-bzr plan, basic baz2bzr, new vcs-imports gpg key
[01:32] <ddaa> TODO: bulk signing, importd changes, more baz2bzr, deploy bzr imports!
[01:32] <ddaa> BLOCKED: No (but might become if other tasks fall behind)
[01:32] <matsubara> TODO: more triage, fix oops report bugs (upstream validator and some others)
[01:32] <matsubara> BLOCKED: No
[01:32] <carlos> DONE: user support, bug #5751 and #1681, soyuz <-> Rosetta integration testing and planning, POMsgSetPage
[01:32] <carlos> TODO: merge my #1681 branch, request a review for POMsgSetPage and add tests for it, Dapper translation imports
[01:32] <carlos> BLOCKED: No
[01:32] <salgado> DONE: Finished all changes Andrew requested in my mirror-management branch and wrote a lot of tests for it, some random fixes, investigated oops reports and started ShipItForDapper
[01:32] <salgado> TODO: Get the mirror-management branch merged, more ShipItForDapper, random fixes
[01:32] <salgado> BLOCKED: No
[01:33] <spiv> DONE: Reviews, various librarian improvements, work on bugs 32105 & 32106 (to assist ddaa's deadline).
[01:33] <spiv> TODO: More for ddaa, SQLObject *Join backporting, AuthserverCaching.
[01:33] <spiv> BLOCKED: No.
[01:33] <jblack> DONE: Bzr support,advocacy, documents, wiki, lp packages
[01:33] <jblack> TODO: More of same, lp packages
[01:33] <jblack> BLOCKED: none
[01:33] <jamesh> DONE: code reviews, branch status XML-RPC code, importd error reporting
[01:33] <jamesh> TODO: code reviews, import error reporting, more stuff from ddaa's list
[01:33] <jamesh> BLOCKED: no
[01:33] <bradb> DONE: Landed backport demystification. Landed fix for search button bug. Put new bug listing and fix for bug #29176 into review.
[01:33] <Ubugtu> malone bug 29176 in malone "Changing source package doesn't notify the new bug contact about the change" [Normal,In progress]  http://launchpad.net/bugs/29176
[01:33] <BjornT> DONE: continued with BugWatches implementation. stopped pages from being rendered on redirects. landed reviewed branches.
[01:33] <bradb> TODO: Land the two branches currently in review. Optional table/list view and customizable batch sizing.
[01:33] <BjornT> TODO: finish BugWatches implementation. fix an oops or two.
[01:33] <bradb> BLOCKED: jamesh for reviews.
[01:33] <BjornT> BLOCKED: no
[01:33] <kiko> DONE: track down OOPS, clear out trees of patches, performance research, management, FAQ hacking
[01:33] <kiko> TODO: more of the above, go through timeouts, add pending FAQs, reports, plan the sprint
[01:33] <kiko> BLOCKED: not really, but would love information on Zope3.2, PgSQL8.1 from stub
[01:33] <cprov> DONE: soyuz rollout (uploade to -updates, rosetta auto-imports)
[01:33] <cprov> TODO: ftpmaster tools bug fix (porting) and fix performance issues in major soyuz components
[01:33] <cprov> BLOCKED: none
[01:34] <jamesh> bradb: I'll have the first one sent out tonight, other one tomorrow.
[01:34] <kiko> thanks jamesh 
[01:34] <bradb> jamesh: great, thanks
[01:35] <kiko> mpt, uhm, I can try doing yours, though I haven't done regular spec reviewing, I confess
[01:35] <daf> DONE: #31741, #5411, people and users doc, bug triage, oops triage
[01:35] <daf> TODO: #30957, #31381...
[01:35] <daf> BLOCKED: land optional branch title (spiv)
[01:35] <kiko> spiv?
[01:35] <mpt> kiko, MaloneSimplifications is in your queue anyway, it's been approved by SteveA
[01:36] <kiko> yeah
[01:36] <mpt> AIUI
[01:36] <kiko> okay
[01:36] <kiko> no stub yet
[01:36] <kiko> I guess we can call it a day and stub can fill us in later
[01:36] <kiko> MEETING ENDS
[01:37] <kiko> -----------------------------------------------------------------
[01:37] <spiv> daf: Sorry, was waiting for new diff from pending-reviews, which had been stalled.
[01:37] <kiko> thanks
[01:37] <spiv> daf: I'll get to it tonight before I sleep.
[01:37] <daf> spiv: ah, thanks
[01:37] <carlos> kiko: thanks
[01:37] <kiko> thanks for showering bradb 
[01:39] <jbailey> bradb: Dude, for 7am meetings, you need a board across that tub of yours and just soak through it.
[01:40] <carlos> cprov: hi
[01:41] <cprov> carlos: hi, re-enabled mawson's jobs, unfortunatelly the update-path wasn't exerciced yet 
[01:41] <carlos> cprov: let me check for a new package from the queue to test it....
[01:41] <jbailey> Attend meetings in bed but it's not with Canonic...  err.  NM.
[01:41] <cprov> carlos: ok
[01:43] <carlos> cprov: eel2
[01:44] <carlos> that's a recent upload and will help us to test updates
[01:44] <cprov> carlos: right ... today 
[01:44] <jamesh> do we own lynchpad.net yet?
[01:44] <kiko> not that I'm aware of
[01:45] <jblack> noone owns it
[01:45] <jbailey> The Canonical sponsored parody site of Canonical? =)
[01:45] <jamesh> jbailey: http://geekz.co.uk/lovesraymond/archive/cancomical-lynchpad
[01:45] <kiko> salgado, it's funny to see http://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-22/A176
[01:45] <kiko> broken browsers?
[01:45] <kiko> MSIE 5.16...
[01:45] <LarstiQ> might as well get bazaar-cvs.org
[01:46] <kiko> salgado, see the PATH_INFO for more information
[01:46] <jbailey> jamesh: Yeah, but actually registering the domain means that we're either paranoid of bad press (which would be sad), or are willing to make fun of ourselves (which would be really funny to have a "funny things people have said about us" site)
[01:46] <jamesh> kiko: that looks like a bug in our CSS
[01:46] <kiko> jamesh, it only happens very rarely. are you sure?
[01:47] <jamesh> kiko: CSS reads url('/@@/ubuntu-header-image4.png') instead of url(/@@/ubuntu-header-image4.png)
[01:48] <jamesh> kiko: actually, the CSS spec says the quotes are optional
[01:48] <kiko> jamesh, so you reckon dropping the quotes would work?
[01:48] <kiko> it appears some browsers don't like it
[01:48] <kiko> of course, the real problem is the NotFoundError
[01:48] <kiko> BjornT, would you know how to fix that oops?
[01:48] <kiko> it needs doing something inside zope
[01:48] <jamesh> kiko: dropping the quotes would be standards compliant, and probably solve the Mac IE problem
[01:48] <kiko> jamesh, I'll do that now and rs=jamesh
[01:49] <stub> yo
[01:49] <stub> today just feels like wednesday
[01:50] <ddaa> if you ask me, it feels like monday morning...
[01:50] <kiko> stub, every day feels like monday to me :-(
[01:51] <kiko> stub, tell us about production and staging, at your leisure. and then tell me about zope3.2 and pgsql 8.1 :)
[01:51] <stub> nothing really thrilling is happening on production or staging.
[01:52] <kiko> stub, any cronscripts disabled?
[01:52] <kiko> staging updates going regularly?
[01:52] <stub> Rollouts as per usual. Looks like we got some good landings today which indicates I might actually be rolling out a thursday tag instead of the fridays or saturdays that have been usual
[01:52] <stub> staging rollouts are happening daily with a full database sync
[01:52] <ddaa> Break**
[01:52] <ddaa> oops
[01:52] <stub> There are a couple of cronscripts currently disabled
[01:53] <kiko> can you tell us about them, stub, individually?
[01:53] <stub> Actually only one now - update-stats.py
[01:53] <daf> kiko: https://chinstrap.ubuntu.com/~daf/bugs/graph.png
[01:54] <stub> update-stats.py seems guaranteed to trigger lots on timeouts on production
[01:54] <BjornT> kiko: that oops is better handled stevea or stub, i seem to recall they discussing that looking up resources might have changed in zope3.2
[01:54] <stub> at least in its current form
[01:54] <kiko> stub, is that "the statistician"?
[01:54] <stub> yes - the statistician
[01:54] <kiko> daf, wow, cool!
[01:54] <kiko> stub, what does this impact in launchpad? 
[01:54] <kiko> what sort of statistics?
[01:55] <daf> jamesh: ^^^
[01:55] <kiko> BjornT, yeah, there's a bug open since forever. I wonder if you would just add a band-aid somewhere ;)
[01:55] <stub> stuff that goes in portlets I think. Total number of 'translators' - stuff like that. Language stats. I'm not fully up to speed on that code.
[01:55] <jamesh> daf: cool.  Could use some antialiasing :)
[01:56] <daf> jamesh: yeah -- trying to work out how to make gnuplot do that
[01:56] <jamesh> daf: if it has SVG output, rsvg should give pretty output
[01:56] <kiko> daf, it might be wise to note "Daily OOPS counts over time"
[01:56] <kiko> since these are grouped per-day
[01:57] <kiko> and not a continuum
[01:57] <jamesh> daf: it is good to see the #exceptions going down and the #notfounds going up correspondingly though
[01:57] <stub> zope32 is slowly getting there. Had a chance to fix more failing tests today. There are some icky looking tracebacks still that I might punt to SteveA when I've done the bulk of it, since it is in code he wrote.
[01:57] <kiko> stub, does it still look a ways off?
[01:57] <BjornT> kiko: ok, nothing i can think of now. i try to stay away from the publisher unless i have to, it's scary :)
[01:57] <stub> Haven't looked at PostgreSQL 8.1 yet. But it is next after Zope3.2
[01:57] <kiko> okay.
[01:57] <daf> kiko: good idea
[01:57] <stub> kiko: Nah - shouldn't be long
[01:57] <kiko> stub, couple of weeks?
[01:57] <stub> kiko: Not that long
[01:57] <kiko> sounds great
[01:58] <stub> kiko: Maybe land it Friday if things go well
[01:58] <kiko> wow
[01:58] <kiko> okay, excellent
[01:59] <kiko> stub, on the statistician being off: what does this impact in launchpad? 
[01:59] <salgado> kiko, what should I do with bug 3015?
[01:59] <Ubugtu> malone bug 3015 in shipit "shipit needs a robots.txt" [Normal,Unconfirmed]  http://launchpad.net/bugs/3015
[01:59] <kiko> salgado, ask mpt. :)
[01:59] <stub> I believe all that it means is that some of the stats being displayed in portlets are out of date. But I'm not 100% sure.
[01:59] <salgado> mpt, what should I do with bug 3015?
[01:59] <Ubugtu> malone bug 3015 in shipit "shipit needs a robots.txt" [Normal,Unconfirmed]  http://launchpad.net/bugs/3015
[02:00] <kiko> stub, I'll try looking at the code
[02:00] <stub> It is all stuff that can happily be 24 hours out of date. It is just a bit more than that now ;)
[02:00] <kiko> stub, would it make sense to run it at the lowest-accessed time for launchpad (sunday or something) or doesn't that exist?
[02:00] <mpt> salgado, what proportion of the ShipIt 404s are asking for robots.txt?
[02:01] <stub> It might be a good candidate for being put into autocommit mode. Last time I ran through I attempted to get more commits happening but it still is not enough obviously.
[02:01] <stub> kiko: it already is (erm.... was)
[02:01] <salgado> mpt, what is a 404 that asks for robots.txt?
[02:01] <kiko> stub, really? when was it running?
[02:01] <kiko> salgado, are you really asking that question?
[02:02] <salgado> I didn't understand mpt's question
[02:02] <daf> jamesh: that works
[02:02] <daf> jamesh: https://chinstrap.ubuntu.com/~daf/bugs/graph.png
[02:02] <stub> kiko: The nightly jobs kicked off at 5:15 UTC, and it would have been running at around 5:30 UTC
[02:03] <kiko> stub, well, I was suggesting running it once a /week/
[02:03] <stub> although I think it was taking a few hours
[02:03] <mpt> salgado, what I mean is, there's no point in having a robots.txt if the 404s we're getting are from UAs that aren't looking at robots.txt anyway.
[02:03] <jamesh> daf: much prettier
[02:03] <stub> ahh. We don't really have a low spot of the week. Just daily lows at around 6:00 UTC
[02:03] <kiko> ah nice
[02:03] <kiko> stub, bummer, man.
[02:03] <kiko> maybe try autocommit mode. :-/
[02:04] <kiko> daf, highlight tuesdays. :)
[02:04] <stub> it is an ideal candidate for a replica database, so it is definitely solvable. just a matter of engineering.
[02:04] <kiko> yeah.
[02:04] <jamesh> stub: run it against staging? :)
[02:04] <kiko> jamesh' idea is not bad
[02:04] <mpt> salgado, so if we're getting 279.3 404s per day and only 2 of those 279.3 are asking for robots.txt, adding a robots.txt won't help.
[02:04] <carlos> cprov: I need to leave now to have lunch, will be back in an hour or an hour and a half
[02:05] <stub> jamesh: Yes. Just need the script intelligent enough to do its writes against production though.
[02:05] <cprov> carlos: wait eel2 just built
[02:05] <carlos> oh!
[02:05] <carlos> ok
[02:05] <mpt> daf, those jaggy lines are crying out for rolling averages :-)
[02:05] <salgado> mpt, in the last report I can see 22 404s on shipit, and none of them are asking for robots.txt
[02:06] <mpt> ok, Rejected that bug is
[02:08] <carlos> cprov: I need to check some code, seems like the .pot is autodetected, but the .po files are not...
[02:08] <cprov> carlos: how do you mean ? didn't it work ?
[02:08] <carlos> will do after lunch, so please, don't install pkgstriptranslations on production
[02:08] <carlos> cprov: it's imported but we need to manually handle the updates
[02:09] <carlos> and that's a lot of work and means that the code is not working as it should
[02:09] <kiko> daf, is OOPS-53B588 reported and oopsed?
[02:09] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/53B588
[02:09] <kiko> I hadn't noticed it yet
[02:09] <carlos> cprov: https://dogfood.ubuntu.com/rosetta/imports
[02:09] <daf> kiko, mpt: bzr branch https://chinstrap.ubuntu.com/~daf/oops-graph/ -- I'm not going to spend any more time on this :)
[02:09] <cprov> carlos: ok, go lunch we can talk later
[02:09] <carlos> cprov: that queue has two tables. The first one is the one handled automatically by our scripts
[02:09] <kiko> just when it was getting to be fun
[02:09] <daf> kiko: yes
[02:09] <carlos> the second one needs manual edition to move the entries to the first table
[02:09] <kiko> daf, bug #? 
[02:10] <cprov> I may help you with this, but it looks like a problem in rosetta domain more than in soyuz 
[02:10] <daf> kiko: it's the "assumes published" bug
[02:10] <carlos> cprov: and eel must appear completely on the first table
[02:10] <daf> kiko: #5390, IIRC
[02:10] <daf> bug 5390
[02:10] <Ubugtu> malone bug 5390 in launchpad "DistroArchReleaseBinaryPackageRelease index template assumes it has a PUBLISHED record" [Normal,Confirmed]  http://launchpad.net/bugs/5390
[02:10] <carlos> cprov: yes, it's a Rosetta bug
[02:10] <carlos> cprov: soyuz is doing its job
[02:10] <kiko> daf, oh, that's the one. okay.
[02:10] <carlos> cprov: thanks for all.
[02:10] <cprov> carlos:  you're welcome anytime
[02:10] <daf> kiko: hmm, then again, this may be a similar but different bug
[02:11] <kiko> daf, can you look into it?
[02:11] <carlos> see you later! (I need to disconnect while having lunch to charge my mobile phone)
[02:11] <cprov> carlos: mawson will be available for you anytime today.
[02:11] <carlos> ok, it should be an easy fix
[02:11] <carlos> thanks
[02:11] <carlos> later
[02:11] <daf> kiko: same problem, different page, I think
[02:12] <daf> ah; no, it's different
[02:12] <daf> I'll file it
[02:12] <kiko> wonderful
[02:12] <kiko> jamesh, NotFoundError shouldn't be in the 404 section in the oops reports, you know
[02:13] <daf> that reminds me
[02:13] <daf> salgado: there's a SQLObjectNotFound OOPS for the +newaccount page
[02:13] <salgado> daf, in the last errors report?
[02:14] <daf> salgado: also a UnicodeEncodeError
[02:14] <salgado> (I'm reading it now)
[02:14] <kiko> I think salgado knows about it
[02:14] <daf> salgado: OOPS-53A758
[02:14] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/53A758
[02:14] <kiko> daf, when you are free again ping me.
[02:14] <daf> also: OOPS-53C33, OOPS-53A691
[02:14] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/53C33
[02:14] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/53A691
[02:15] <daf> salgado: if you don't know about any of these, I can file bugs for you
[02:15] <kiko> shipit stresses +newaccount until it bleeds
[02:15] <salgado> the first one I haven't seen before
[02:16] <salgado> the third one seems to be the same as the first
[02:17] <salgado> and the second I haven't seen either
[02:17] <daf> I'll get the elastoplast
[02:17] <salgado> I can't see them in the errors report, though
[02:18] <salgado> daf, where did you get them?
[02:18] <daf> yesterday's OOPS report
[02:19] <daf> I mean, the one James sent today
[02:19] <daf> cprov: https://launchpad.net/products/soyuz/+bug/32605
[02:19] <Ubugtu> malone bug 32605 in soyuz "BPPH listing assumes context has been superseded" [Normal,Unconfirmed]  
[02:19] <daf> salgado: are we both looking at https://chinstrap.ubuntu.com/~jamesh/oops-summaries/2006-02-22.html?
[02:19] <cprov> daf: ne sec
[02:20] <kiko> daf is like wolverine in a bar fight 
[02:20] <salgado> well, I was looking at my inbox, but that was the report I was looking at, yes
[02:20] <kiko> flinging them left and right
[02:20] <salgado> aha
[02:21] <salgado> that's the problem. the email does not contain all oops, as the first sentence on it says
[02:21] <daf> adamantium bug triage
[02:21] <cprov> daf: soyuz UI bugs goes directly to matsubara, he can confirm it 
[02:21] <kiko> matsubara, when you have your non-published binary package, we will see much bustage in our sampledata, and it will be good
[02:21] <daf> cprov: cool; noted
[02:21] <cprov> daf: thanks 
[02:21] <kiko> stub, have time for a last question?
[02:21] <daf> matsubara: https://launchpad.net/products/soyuz/+bug/32605
[02:21] <Ubugtu> malone bug 32605 in soyuz "BPPH listing assumes context has been superseded" [Normal,Unconfirmed]  
[02:22] <stub> kiko: Yes
[02:22] <kiko> stub, at what time did you fix the official_malone SQL bustage that happened in the rollout?
[02:23] <stub> I think launchpad was screwed for about 10 minutes, maybe 15.
[02:23] <kiko> stub, any clue why we saw oopses logged against 2006-02-22, then?
[02:23] <stub> If you want the actual time, I'll need to trawl my log
[02:23] <stub> s
[02:23] <kiko> no, I'm just trying to understand this
[02:23] <kiko> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-22/A247
[02:24] <stub> kiko: no idea
[02:24] <kiko> Date  	2006-02-22 12:05:03 UTC
[02:24] <kiko> is that fucked or what?
[02:24] <kiko> jamesh, any clue?
[02:26] <stub> Both trees are identical
[02:26] <kiko> stub, okay. I'll keep an eye out tomorrow -- if it still shows up, we'll look into it with more energy.
[02:28] <salgado> daf, are you filing bugs for that oopses or should I do it?
[02:28] <BjornT> kiko, stub: from the yesterday's irc log:
[02:28] <BjornT> 14:12 < daf> ProgrammingError: ERROR: column "official_malone"...
[02:29] <BjornT> 14:12 < stub> yer - I'm looking at it. I screwed up the cherry pick
[02:29] <BjornT> (UTC+2)
[02:29] <kiko> oh
[02:29] <kiko> that was cherry-picked?
[02:29] <kiko> stub, what sort of drugs are you on? share with me :)
[02:29] <kiko> BjornT, ticket 1522 was resolved on monday, wasn't it?
[02:30] <stub> kiko: 'bzr merge -r 3180' is what I find to be the intuitive syntax to charry pick r3180. Unfortunately, it doesn't do that.
[02:30] <BjornT> kiko: yes it was. i haven't tested it yet, though, i will do it now.
[02:30] <kiko> BjornT, ah, okay -- do it!
[02:30] <daf> salgado: I suspect you would do better descriptions than I, but I'm happy to do it if you're busy
[02:30] <kiko> stub, well, the mystery is solved at least ;)
[02:31] <daf> yeah, you need to do merge -r 3180:3180 :(
[02:31] <salgado> daf, I can file them for sure. just wanted to make sure you weren't on it already
[02:31] <daf> salgado: cool
[02:31] <daf> salgado: go for it
[02:34] <Riddell> is it possible to merge teams?
[02:35] <salgado> Riddell, no, not yet
[02:35] <daf> is there a bug that Riddell can subscribe to?
[02:35] <doko> kiko, carlos: how do I get translations from rosetta for openoffice.org2 (all) ?
[02:35] <kiko> that's a CarlFK question
[02:35] <kiko> daf, there is, yes.
[02:35] <daf> ah, found it
[02:35] <doko> the "Translations" is greyed out
[02:35] <daf> https://launchpad.net/products/launchpad/+bug/29177
[02:35] <Ubugtu> malone bug 29177 in launchpad "Allow merging of teams (and specifically merge ubuntu-doc and ubuntu-doc-lists)" [Normal,Confirmed]  
[02:36] <kiko> daf, DUPEME: https://launchpad.net/malone/bugs/32530
[02:36] <Ubugtu> malone bug 32530 in launchpad "Launchpad crashed" [Normal,Unconfirmed]  
[02:36] <kiko> daf, DUPEME: https://launchpad.net/malone/bugs/32533
[02:36] <Ubugtu> malone bug 32533 in launchpad "Launchpad times out when asked to list all ubuntu packages" [Normal,Unconfirmed]  
[02:37] <daf> kiko: done, done
[02:38] <kiko> daf, DUPEME: https://launchpad.net/malone/bugs/32592
[02:38] <Ubugtu> malone bug 32592 in launchpad "oops code while filing bugs" [Normal,Unconfirmed]  
[02:39] <daf> done
[02:43] <salgado> jamesh, spiv, maybe you guys can help on bug 31651
[02:43] <Ubugtu> malone bug 31651 in launchpad "IPlacelessLoginSource.getPrincipalByLogin(email) returns None with an email address that was just created" [Normal,Confirmed]  http://launchpad.net/bugs/31651
[02:43] <dilys> Merge to devel/launchpad/: [trivial, rs=jamesh]  fix Shipit (Ubuntu) CSS files to not include quotes in url() instructions, since it breaks in MacOS IE 5.16 and 5.17 (at least). Also add an opportunistic XXX (r3186: kiko)
[02:43] <kiko> rock and roll dilys 
[02:44] <doko_> CarlFK: ping
[02:47] <doko_> carlos, daf: how does rosetta hande package renames? with the next upload openoffice.org2 will become openoffice.org
[02:48] <kiko> carlos is out
[02:48] <doko_> yeah, but the log is on :)
[02:48] <kiko> heh
[02:48] <kiko> I doubt he reads it
[03:02] <daf> doko_: not sure about the details, but if the same translation domain is used things should be smooth
[03:02] <daf> doko_: best ask carlos when he's back though
[03:04] <daf> kiko: https://launchpad.net/products/soyuz/+bug/32608
[03:04] <Ubugtu> malone bug 32608 in soyuz "DistroArchReleaseBinaryPackageRelease traversal fails for non-published releases" [Normal,Unconfirmed]  
[03:04] <kiko> thanks daf 
[03:04] <daf> de nada
[03:09] <jbailey> The soyuz upload notifications - are those currently going to whoever is listed in the maintainer field?
[03:26] <mpt> "An error occurred when we tried to process your request. Rest assured, we're working to resolve the problem as soon as possible. If you were trying to make a purchase, please check Your Account to confirm that the order was placed. We apologize for the inconvenience."
[03:35] <kiko> purchase?
[03:36] <kiko> mpt, I'll be committing an updated FAQ shortly; can you take a look at it tomorrow and fix anything you think should be?
[03:36] <Kinnison> jbailey: For the gazillionth time, not necessarily
[03:37] <Kinnison> jbailey: Soyuz takes the set of the signer, the changed-by and the maintainer. It removes entries which are not in the relevant upload teams, it mails everyone left
[03:38] <kiko> Kinnison, want me to add it to the FAQ? :)
[03:38] <kiko> I've got my hands hot on it
[03:39] <Kinnison> sure
[03:39] <Kinnison> that's be great
[03:39] <mpt> kiko, sure, over time I'll replace items in the FAQ with better design of Launchpad itself
[03:39] <kiko> can you prepare a more polished answer?
[03:39] <kiko> mpt, and feel free to add new items
[03:39] <Kinnison> kiko: Erm, sure, give me a couple of mins
[03:39] <mpt> heck no
[03:39] <mpt> My ultimate goal is no FAQ :-)
[03:40] <kiko> Kinnison, with question preferably
[03:42] <kiko> mpt, do you know all the situations in which we create accounts for people?
[03:44] <kiko> jamesh, did keyringtrustanalyzer ever run? on which keyring?
[03:46] <Kinnison> kiko: biff
[03:46] <kiko> Kinnison, ummm?
[03:46] <Kinnison> kiko: "who-gets-soyuz-mail.txt" -- emailed to you
[03:47] <kiko> thanks!
[03:48] <mpt> kiko, no I have very little idea about that
[03:48] <kiko> okay mpt 
[03:48] <mpt> kiko, perhaps carlos, ddaa, and BjornT could compile a list
[03:49] <ddaa> My stuff don't create accounts for people.
[03:49] <kiko> grepping works
[03:49] <carlos> From Rosetta, we create accounts with poimports
[03:49] <mpt> ddaa, VCS imports don't create accounts?
[03:49] <ddaa> I think at some point the Arch branch stuff might have, but I'm not really sure if it was ever actually used.
[03:49] <kiko> I know carlos 
[03:50] <mpt> the Bugzilla import probably created accounts
[03:50] <kiko> it did too
[03:50] <ddaa> mpt: no, I insisted that bzr branch scanning had nothing to do with people, mostly because committer labels can be essentially free-form random junk.
[03:51] <ddaa> mpt: I do not know about what the Arch branch stuff might have done in the past, though.
[03:51] <mpt> kiko, amongst many other things, my 2006-02-headings branches changes "People registered in Launchpad" to "People Launchpad knows about"
[03:52] <kiko> cool
[03:57] <kiko> mpt, OT: should date entries be right-aligned?
[04:02] <mpt> It's 4am, kiko, I'm supposed to be asleep
[04:03] <mpt> date entries right-aligned with what?
[04:03] <kiko> mpt, <input type="text"> 
[04:03] <kiko> mpt, containing a date
[04:03] <kiko> or an entry in a GUI form
[04:04] <mpt> oh
[04:04] <kiko> should it right or left-align
[04:04] <mpt> er, left align, I guess
[04:04] <kiko> mpt, reason being?
[04:04] <mpt> because in some cases it might be acceptable to enter just a year, or just a year and a month and no date
[04:04] <kiko> what does alignment have to do with that? (sorry)
[04:05] <mpt> so if you have two kinds on one form, the years should line up with each other
[04:05] <mpt> [2006-02-24] 
[04:05] <mpt> [2006-04    ] 
[04:05] <mpt> [2006        ] 
[04:06] <kiko> you are assuming ISO date format
[04:06] <mpt> That's not a very strong reason, but I can't think of any good reasons for right aligning
[04:06] <kiko> which not all date entries will hold
[04:06] <mpt> Launchpad insists on ISO-like format
[04:06] <mpt> Ideally we'd have proper date controls and not even be having this conversation :-)
[04:07] <kiko> I'm asking generically
[04:07] <kiko> not in Launchpad necessarily
[04:08] <mpt> Generically you should have fields that are exactly wide enough for the correct number of digits, so they're neither left-aligned nor right-aligned, they just are
[04:10] <mpt> [____-__-__] , or [__/__/____] , or however you've specified as a date format in the relevant control panel in Windows or Mac OS, or however has been chosen for you by your Unix locale
[04:11] <mpt> "a date format" -> "your preferred date format"
[04:24] <kiko> thanks mpt 
[04:24] <kiko> most valuable
[04:24] <kiko> that should go to the UI HOF
[04:25] <kiko> this is ironic
[04:25] <kiko> I want to give a URL to list all OOPS reports
[04:25] <kiko> however
[04:25] <kiko> the advanced query that lists bugs against a milestone 
[04:25] <kiko> OOPSES
[04:25] <kiko> :-)
[04:26] <kiko> ridiculous
[04:26] <kiko> I'll fix both
[04:33] <jbailey> Kinnison: Given that our Maintainer fields are pretty universally incorrect, should it perhaps send the information to bug contacts instead?
[04:33] <Kinnison> jbailey: s/instead/also/ perhaps
[04:33] <kiko> < jordi> "I read about all of this COCK SIGNING PROCESS. What kind of
[04:33] <kiko>                rock stars are you?"
[04:33] <kiko> that is a timeless quote
[04:33] <jbailey> Kinnison: I guess. I find it confusing to receive initramfs-tools and cdbs uploads in Ubuntu, which I don't follow, so I would probably unsubscribe.
[04:34] <Kinnison> most people who maintain in debian and ubuntu want to receive them so they know what others are doing with their debian packages
[04:34] <kiko> jbailey, has an interesting point, but the name "bug contact" would then become incorrect.
[04:34] <Kinnison> :-)
[04:34] <jbailey> So this is, I guess, two separate issues.
[04:35] <jbailey> 1) Should bug contacts get notified of uploads.  I'd say almost certainly yes.
[04:35] <kiko> I think so as well
[04:35] <kiko> because it is relevant to them
[04:35] <kiko> "a new version is out, and it IS BUGGY"
[04:35] <jbailey> 2) Should people in the relevant fields in the control file get notified of uploads.  Open for debate.
[04:36] <jbailey> Anyone object to me filing #1 as a wishlist bug?
[04:37] <kiko> I object to nothing
[04:37] <kiko> in that line
[04:40] <Kinnison> jbailey: should they get all the accept, reject, etc notifications?
[04:40] <Kinnison> jbailey: or should they just subscribe to the distrorelease changes list and be done with it?
[04:40] <jbailey> Kinnison: I'm not interested in the volume of mail that comes from an entire list.
[04:41] <stub> There is a datetime input widget available in the Z3 SVN repository that we should look at some time.
[04:41] <salgado> that'd be great
[04:41] <jbailey> Kinnison: I think that getting the accept notifications is cool.
[04:42] <jbailey> Kinnison: The reject notifications are less useful in general, but happen rarely enough that it's not a big tradeoff.
[04:42] <Kinnison> jbailey: then I'd rather you suggested a "package subscription" concept
[04:42] <Kinnison> jbailey: because I'd rather get the mails through the list :-)
[04:43] <jbailey> Kinnison: Is there ever a case where you wouldn't want to be notified for packages where you've subscribed for bugs?
[04:44] <Kinnison> jbailey: https://wiki.launchpad.canonical.com/PackageSubscriptions
[04:44] <cprov> Kinnison: PackageSubscription seems to be far away atm, since it needs to cope with the LP-wide subscription system rather than being designed locally
[04:45] <Kinnison> cprov: aye, and in my opinion, since this is "I would like" rather than "We used to have and now we don't have" -- I think we should be aiming to do it right rather than hack it in
[04:46] <cprov> Kinnison: I agree with you, "do it once and right" concept
[04:46] <jbailey> The use cases in this spec are weak.  None of them leave me with a feeling for why someone would want these things, and what they could do that's useful with the information.
[04:46] <Kinnison> jbailey: it's still a draft spec
[04:46] <Kinnison> jbailey: If you would like to take it upon yourself to improve the spec then that'd be wonderful
[04:47] <jbailey> Kinnison: If it can't answer the "what problem am I trying to solve", I don't think it should be a spec at all.
[04:47] <cprov> jbailey: actually I'd be glad if you could colaborate with us improving the use cases, since you have the experience 
[04:47] <cprov> s\could\can
[04:47] <jbailey> I'm trying to think if my use case fits well with what's here, or if I'm asking for something tangential to it.
[04:49] <cprov> jbailey: perhaps, the spec scope was not well defined. add your comments in the "Outstanding issues" if you're not sure
[04:49] <cprov> jbailey: it need to be handled soon, next eminent conf
[05:10] <jordi> Kinnison: I know amny DDs won't like getting ubuntu-packages related email by default.
[05:20] <Kinnison> jordi: and they won't be sent mail
[05:20] <jbailey> cprov, Kinnison: I've added comments and one use case to https://wiki.launchpad.canonical.com/PackageSubscriptions
[05:20] <Kinnison> jordi: unless they are in the set of people who can upload to ubuntu
[05:20] <jbailey> Hopefully it's what you were thinking of.
[05:21] <cprov> jbailey: thanks 
[05:22] <jordi> Kinnison: cool
[05:22] <Kinnison> jordi: believe me, we're quite careful about this
[05:23] <jordi> Kinnison: I totally believe it :)
[05:23] <jordi> I remember when a few mails escaped launchpad and went to Clint
[05:23] <jordi> luckily it was Clint
[05:24] <doko> carlos: how can I determine, when rosetta was updated via import the last time?
[05:25] <carlos> We don't have any specific way to see it, but I can guess it from the .pot's header (if you want the info for a .po file, we don't have a way to see it without a direct DB query)
[05:27] <doko> carlos: could find out that for openoffice.org2 ?
[05:27] <carlos> doko: which release?
[05:28] <doko> carlos: which release do the people use, doing the kurdish translations?
[05:29] <carlos> doko: I don't know...
[05:29] <carlos> doko: breezy?
[05:29] <carlos> doko: in which case the latest import should be the latest package upload for breezy
[05:31] <doko> carlos: I really need to know that, when merging back the translations ...
[05:31] <dilys> Merge to devel/launchpad/: [trivial]  Updating the FAQ with a few new entries; fix the CSS to indent <ol>s (r3187: kiko)
[05:33] <carlos> doko: POT-Creation-Date: 2005-10-08 02:08 from the 1.9.129-0.1ubuntu4
[05:33] <carlos> doko: that's all I can give you. I suppose they are using breezy to translate it, if that's not true... I cannot guess it, could you ask them the URL they are using?
[05:36] <doko> carlos: thanks, sent mail
[05:37] <carlos> doko: ok, thanks
[06:49] <cprov-lunch> carlos: ping
[06:53] <carlos> cprov: pong
[06:53] <cprov> carlos: how is rosetta bug fix going ?
[06:54] <carlos> my current network link is slow and it's taking a lot to download an update of your branch..
[06:54] <cprov> kiko: could you please approve a mail sent to launchpad@lists ? (wrong from: cprov@gwyddion, only cprov@canonical is subscribed)
[06:55] <ddaa> kiko: ping
[06:56] <cprov> carlos: fix the code, it's not related to my branch changes, send me the patch I can handle conflicts and give you access to a mawson tree
[06:56] <kiko> cprov, I lost ALL the mailing list passwords
[06:56] <kiko> cprov, I will need to waste some time to get them back
[06:56] <kiko> they keep going bad
[06:56] <carlos> cprov: ok
[06:56] <kiko> ddaa?
[06:56] <cprov> carlos: you can enjoy "cowboying code"
[06:57] <cprov> kiko: bad, who else has maillist admin ?
[06:57] <ddaa> kiko: I just realised I needed paramiko on hoover slaves, I'm going to file a RT about that, are you able to kick its priority?
[06:58] <ddaa> I can work around in the short term, but it would be better to have it ASAP.
[06:59] <kiko> ddaa, I can, tell me the RT number later.
[06:59] <kiko> I think Znarl and elmo are fucked today though
[06:59] <kiko> cprov, I'm not sure -- steve or stub :-(
[06:59] <kiko> cprov, I think Znarl/elmo can approve
[07:00] <cprov> kiko: let's see
[07:07] <jordi> carlos: i found another file that oopses the import queue
[07:08] <jordi> carlos: barring the oopsing files, and exe which i have no idea about what to do with it, the queue is clean again
[07:08] <carlos> jordi: URL?
[07:08] <kiko> oops ID ideally
[07:08] <jordi> https://launchpad.net/rosetta/imports/769
[07:08] <jordi> wait
[07:08] <jordi> I have an oops id
[07:08] <carlos> I'm getting out of battery
[07:09] <carlos> and will lose my network link for an hour or so
[07:09] <carlos> jordi: please, give me it before my phone turns off
[07:09] <jordi> carlos seems to using African jungle connectivity :)
[07:09] <sivang> ddaa: I really need to thank you, it seems that pexepct does everything you expect :-)
[07:10] <jordi> OOPS-54D676.
[07:10] <sivang> ddaa: in my special stdout/in/err mixing case.
[07:10] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/54D676
[07:10] <jordi> carlos: same as always: fill in stuff, and try to approve
[07:10] <carlos> jordi: dude, I want to kill some stupid people from my ISP and Telefonica
[07:10] <jordi> this is policycoreutils for Indonesian
[07:10] <carlos> jordi: did rejected the new land line to have a backup DSL line
[07:10] <sivang> carlos: where are you in?
[07:10] <jordi> a Swedish file for the same pacakge also fails
[07:10] <carlos> jordi: because it's too work for them
[07:11] <sivang> (from .IL) 
[07:11] <carlos> sivang: at home
[07:11] <carlos> Spain
[07:11] <sivang> carlos: lol, sounds like you were on the moon or something with all this communication problems :)
[07:11] <carlos> jordi: oops number?
[07:11] <ddaa> sivang: you're welcome.
[07:12] <carlos> sivang: ;-)
[07:12] <sivang> ddaa: caught the Pun? ;-)
[07:12] <jordi> carlos: just said
[07:12] <jordi> 19:10 < jordi> OOPS-54D676.
[07:12] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/54D676
[07:12] <ddaa> sure, but I did not want to mention how bad a pun it was :)
[07:12] <carlos> oh, right
[07:12] <jordi> that's indonesian
[07:12] <jordi> I bet Swedish is the same bug
[07:13] <jordi> carlos: I just got rid of the plagiat file that had been in the accepted queue for ages. It didn't have any gettext header.
[07:13] <ddaa> kiko: request 3241
[07:14] <sivang> ddaa: haha
[07:16] <sivang> ah, finished at last
[07:16] <kiko> ddaa, noted.
[07:16] <kiko> I'll fix up RT priorities
[07:16] <Omni|Work> Does the bug tracker thing automatically scan other bug trackers for bugs?
[07:17] <kiko> Omni|Work, no, it doesn't. you need to add watches yourself.
[07:21] <doko> carlos: I disabled the export of the language data from openoffice.org
[07:24] <salgado> BjornT, around?
[07:26] <BjornT> salgado: yeah, i'm around
[07:28] <salgado> BjornT, do you know if in zope auto generated forms, that 'Missing input' message is generated by checking, for each widget, the .hasInput() method?
[07:31] <BjornT> salgado: no, i don't think hasInput() should cause that. getInput() will generate the message, though.
[07:31] <jordi> this is pretty amazing
[07:31] <jordi> I'm up to date on activity reports...
[07:31] <jordi> even before the week finishes
[07:33] <salgado> BjornT, I see. and if I'm using the zope widgets in a page that's not auto generated, what would be the correct approach to display the missing-input/validation errors?
[07:37] <BjornT> salgado: by using widget.error(), if its not None, display it.
[07:38] <BjornT> salgado: you can see how it's done in launchpad-widget-macros.pt
[07:39] <salgado> BjornT, right, I tried that but this is what I got: https://chinstrap.warthogs.hbd.com/~salgado/shipit-broken.jpg
[07:40] <salgado> I just removed all extra css from ubuntu, to make sure that wasn't the problem
[07:41] <BjornT> salgado: can you put up the HTML source of the page somewhere?
[07:45] <salgado> BjornT, https://chinstrap.warthogs.hbd.com/~salgado/requestcds.html
[07:50] <BjornT> salgado: ah, right. only using widget.error() isn't enough, you have to have a <div class="portalError"> and so on around the input field and error message. does it work if you do it like it's done in launchpad-widget-macros.pt?
[07:50] <BjornT> salgado: if not, you might have to add som css, and/or talk with mpt or someone who knows a lot about css and html
[07:51] <salgado> BjornT, yes, it works just fine.
[07:51] <salgado> I haven't noticed that hidden 'portalError' in that tal:attributes
[07:52] <salgado> good catch, thanks BjornT!
[07:52] <Omni|Work> It looks like launchpad is very Ubuntu-centric just now, but that the intent is that it not be.
[07:52] <BjornT> cool, np.
[07:54] <kiko> that is correct Omni|Work 
[07:55] <Omni|Work> Thanks.  I registered myself and a project of mine there.  And I'll keep stuff there up-to-date and see how things go.
[07:55] <fufounette> hi
[07:57] <kiko> ho
[07:57] <kiko> Omni|Work, let me know if you have any trouble
[07:57] <kiko> I'm just busy today fixing a bug!
[07:59] <Omni|Work> Thanks.
[07:59] <Omni|Work> Have fun all.
[08:00] <fufounette> +++
[08:11] <doko> kiko: that page doesn't have a link to the build log. any hint?  https://launchpad.net/distros/ubuntu/+source/ia32-libs/1.4ubuntu6
[08:13] <kiko> doko, I'm confused.
[08:13] <kiko> the build logs are for individual versions
[08:13] <kiko> https://launchpad.net/+builds/+build/166197
[08:13] <kiko> https://launchpad.net/+builds/+build/166196
[08:13] <kiko> those pages are linked to in the portlet on the RHS of the page you pointed out.
[08:14] <kiko> daf, ping?
[08:14] <kiko> bradb, BjornT: drive-by?
[08:14] <daf> kiko: pong
[08:14] <bradb> kiko: sure
[08:14] <kiko> daf, want to do that prioritization
[08:14] <kiko> bradb, let me pastebin a fix for bug 30957 for you.
[08:14] <Ubugtu> malone bug 30957 in malone "OOPS: BugTaskSet.search() passes milestones to sqlvalues()" [Major,Confirmed]  http://launchpad.net/bugs/30957
[08:15] <bradb> ok
[08:15] <doko> kiko: arrgh ... the window was to narrow, so you see them, but cannot click them :-(
[08:15] <kiko> doko, I know, I had to maximize mine as well. we are getting rid of the RHS portlets, bear with us.
[08:16] <kiko> bradb, https://chinstrap.ubuntu.com/~dsilvers/paste/fileViTMeW.html
[08:16] <kiko> bradb, also see my mail to launchpad
[08:20] <kiko> bradb, say the word!
[08:20] <bradb> kiko: Writing up the review now.
[08:20] <kiko> cool
[08:21] <daf> put that safety back on, cowboy
[08:21] <kiko> if you complain about dbschema.foo I will ignore you! 
[08:21] <daf> kiko: let's prioritize
[08:21] <kiko> daf, ah, yes
[08:23] <kiko> daf, bug 31381 is to me the most urgent one you could work on
[08:23] <Ubugtu> malone bug 31381 in rosetta "POMsgSet.active_texts assumes POFile.pluralforms is an int" [Normal,Confirmed]  http://launchpad.net/bugs/31381
[08:24] <kiko> matsubara, let's land that so you can get cracking on bug 5757
[08:24] <Ubugtu> malone bug 5757 in malone "OOPS: requesting an upstream fix doesn't check input for duplicates" [Normal,In progress]  http://launchpad.net/bugs/5757
[08:25] <daf> kiko: yeah, you're right there
[08:27] <daf> kiko: next after that?
[08:27] <kiko> bug 6313?
[08:27] <Ubugtu> malone bug 6313 in launchpad "Resetting a password for a team crashes." [Normal,Confirmed]  http://launchpad.net/bugs/6313
[08:27] <daf> wow, oops city
[08:28] <daf> ah, it's Mr. Agcambot
[08:28] <kiko> bradb...
[08:29] <daf> yikes, I triaged this and I can't remember ever seeing it before
[08:29] <bradb> kiko: dude, be reasonable. the last "drive by" I asked for from you took about 1.5 hours and got 4 people involved. :P
[08:30] <kiko> bradb, this is a OOPS fix
[08:30] <kiko> that's very different 
[08:30] <bradb> the other one was intended to a be a "wording fix" :)
[08:31] <kiko> you are such a situation-twister!
[08:31] <kiko> bradb, just give me instant feedback and I will update
[08:33] <bradb> kiko: sent
[08:34] <kiko> bradb, here's a proposal: I'll move the method next wednesday (when I am back from holiday) based on feedback from you and others so I can land this and go on killing oops. deal?
[08:34] <kiko> s/method/function/
[08:35] <bradb> kiko: Why not just fix it now?
[08:35] <kiko> because I want to fix bug 31380 before I leave tonight, and time is short already
[08:35] <Ubugtu> malone bug 31380 in launchpad "source package sort by version doesn't cope with invalid version numbers" [Normal,In progress]  http://launchpad.net/bugs/31380
[08:35] <bradb> It's in the wrong module and is named incorrectly, so at least something should change there.
[08:35] <kiko> stub needs to cut production
[08:36] <kiko> I take partial issue with "named incorrectly"
[08:36] <bradb> kiko: How about if you at least put it in the same module as sqlvalues, and name it to something that clearly indicates that it takes an object and spits out an id?
[08:36] <bradb> the way it's currently named makes it sound like it sanitizes an id
[08:37] <kiko> all right.
[08:37] <bradb> thanks dude
[08:39] <bradb> kiko: BTW, were there any specific OOPS you wanted me to fix, in between adding the customizable batching and list/table view toggle?
[08:40] <kiko> bradb, let me see
[08:42] <kiko> bradb, bug 6026
[08:42] <Ubugtu> malone bug 6026 in malone "Oops from changing bug's product when milestone is set" [Normal,Confirmed]  http://launchpad.net/bugs/6026
[08:43] <bradb> hm, interesting
[08:43] <BjornT> kiko: also re OOPS, if you just give me the go ahead, i can implement what i proposed in bug 2045 tomorrow, it will fix an OOPS. (i would leave the bug open, since it doesn't really resolve the bug, though)
[08:43] <kiko> bradb, and, less urgent but nice, bug 4560 and 30915
[08:43] <Ubugtu> malone bug 4560 in malone "Bugtracker display-all-watches listing is not batched, causing timeout errors" [Normal,Confirmed]  http://launchpad.net/bugs/4560
[08:43] <kiko> BjornT, I liked stub's proposal #3, actually.
[08:43] <kiko> what do you think?
[08:44] <BjornT> kiko: well, more to type, and doesn't handle teams without an email set
[08:44] <kiko> good point.
[08:44] <BjornT> i'd say start with my solution, then modify it later
[08:44] <kiko> oh.
[08:44] <kiko> sorry, I didn't catch that
[08:44] <kiko> so -- either an exact name or an exact email address?
[08:45] <BjornT> yeah
[08:45] <kiko> perfect. do it.
[08:45] <BjornT> cool, i'll do it tomorrow
[08:45] <bradb> kiko: Fixing timeouts is, for me, really hard to fix without a database dump. Do we have a dump to help fix timeout bugs?
[08:46] <bradb> s/hard to fix/hard/
[08:46] <kiko> bradb, those just need batching, period
[08:46] <kiko> no need for checking what's timing out
[08:46] <bradb> oh, ok
[08:46] <kiko> they issue 5 million queries
[08:46] <kiko> maybe it's 15 million I need to check again
[08:46] <bradb> heh
[08:50] <bradb> kiko: for bug 6026, should the milestone just be cleared, and the user warned?
[08:50] <Ubugtu> malone bug 6026 in malone "Oops from changing bug's product when milestone is set" [Normal,In progress]  http://launchpad.net/bugs/6026
[08:50] <kiko> that sounds perfect.
[08:50] <bradb> ok, cool
[09:08] <salgado>           <tal:block tal:define="widget view/recipientdisplayname_widget">
[09:08] <salgado>           <span metal:use-macro="template/macros/display_widget" />
[09:08] <salgado>           </tal:block>
[09:08] <salgado> if the macro expects a "widget" variable, isn't this supposed to work?
[09:08] <kiko> macro scopes totally confuse me
[09:08] <kiko> I thought I understood them
[09:08] <kiko> but when I tried to use them
[09:08] <kiko> I fucked it up
[09:09] <salgado> aha. I'm not alone then
[09:10] <salgado> but I'm pretty sure I've done this before, and it worked just fine
[09:10] <salgado> anyway, now it doesn't
[09:11] <BjornT> salgado: that should work. what error do you get?
[09:11] <BjornT> salgado: ah, i think i know what's wrong
[09:12] <BjornT> salgado: try tal:define="widget nocall: view/recipientdisplayname_widget"
[09:13] <BjornT> tal always call the the object, if it's callable, so widget was assigned to a string. nocall prevents TAL from calling the object
[09:13] <salgado> BjornT, right, the problem was when accessing 'widget/error', and the 'nocall:' prefix fixed it
[09:13] <salgado> but now there's another problem
[09:14] <salgado> aparently, widget/error is only set after I call it
[09:14] <salgado> so adding the 'nocall:' makes 'widget/error' always return None
[09:16] <BjornT> that's surprising. launchpad-widet-macros.pt doesn't seem to call the widget first, and it works.
[09:16] <salgado> indeed
[09:17] <salgado> but if I remove the "<span tal:condition="widget" />" line from my macro, widget/error always return None
[09:17] <salgado> (I just added that line as a workaround)
[09:18] <daf> kiko: #6313: https://chinstrap.ubuntu.com/~dsilvers/paste/file3B3pXi.html
[09:19] <kiko> daf, my only issue is with "The person...". if you can think of better wording than that, r=kiko
[09:19] <daf> where's mpt when you need him?
[09:19] <kiko> dude, cprov JUST said the same thing
[09:19] <BjornT> salgado: hmm, that's strange. is that true for all widgets, or have you just tested with one? which one?
[09:19] <daf> we need to import mpt into Europe
[09:19] <cprov> somebody said the same thing about GOD last day ;)
[09:20] <kiko> daf, but I trust you can do it
[09:20] <kiko> The account?
[09:20] <kiko> The name?
[09:20] <salgado> BjornT, only one: recipientdisplayname, in a GeneralFormView
[09:20] <kiko> You have requested a password reset for a team;
[09:21] <daf> "Your requested a password reset with an email address that belongs to a team."?
[09:21] <daf> s/Your/You/
[09:21] <kiko> daf, perhaps use "You requested to reset the password for %s. %s is a team, and teams cannot log into launchpad."
[09:22] <kiko> daf, perhaps just s/The person/The account/...
[09:22] <daf> "The email address %s belongs to a team, and teams cannot log into Launchpad."
[09:22] <daf> ?
[09:22] <daf> I'm trying to avoid the term "account"
[09:22] <kiko> well, is it always email addresses there?
[09:23] <kiko> if so your text is perfect.
[09:23] <daf> the parameter is called "email"
[09:23] <daf> I'll check the form
[09:23] <daf> (I'll admit I didn't look at it when doing the patch -- I just wrote a test)
[09:24] <daf> "Enter your e-mail address, and we will send you instructions on how to reset your password."
[09:24] <dilys> Merge to devel/launchpad/: [trivial]  Fix for bug 30957: OOPS: BugTaskSet.search() passes milestones to sqlvalues(). Properly santizes arguments supplied to any() clauses supplied to BugTaskSearchParams by using code factored into the sanitize_sql_id function (r3188: kiko)
[09:24] <kiko> yes!
[09:24] <daf> rock!
[09:24] <kiko> one less oops
[09:24] <BjornT> salgado: when do you call process_form in the template? before or after the widgets?
[09:24] <daf> another one bits the dust
[09:24] <daf> kiko: so, with updated error message, r=kiko?
[09:24] <kiko> daf, yes.
[09:25] <daf> rockin'
[09:25] <BjornT> salgado: my only guess is that widget.getInputValue() hasn't been called when you try to render the error
[09:25] <salgado> that's it
[09:25] <salgado> probably
[09:26] <salgado> I'm using this GeneralFormView in a custom template, without using the launchpad_generalform macro
[09:26] <kiko> that sounds like deep voodoo
[09:27] <kiko> the kind that lands you naked in maputo with "white power" painted over your ass
[09:28] <BjornT> the form macros probably should define a slot where the widgets are rendered automatically, so that you can fill it yourself, and place the widgets they way you like it.
[09:34] <salgado> BjornT, you mean that's something we should do or they do that already?
[09:36] <BjornT> salgado: something we should do.
[09:58] <kiko> damn
[10:03] <X1n3> hi
[10:05] <X1n3> why I did not receive all cds that ped?
[10:06] <kiko> matsubara, did pqm reject?
[10:06] <matsubara> kiko: rejected, i'm fixing the tests that failed
[10:08] <X1n3> somebody  answer my question,  irc close
[10:08] <kiko> sucks to be us matsubara, mine failed too
[10:09] <kiko> X1n3, write to info@shipit.ubuntu.com
[10:10] <X1n3> thanks
[10:14] <kiko> daf, carlos: why is bug 5751 not a dupe of bug 3991?
[10:14] <Ubugtu> malone bug 3991 in rosetta "Timeout error on translation page (+translate)" [Normal,Confirmed]  http://launchpad.net/bugs/3991
[10:15] <carlos> kiko: I guess it's because 5751 is private
[10:15] <kiko> can we fix that?
[10:15] <carlos> but I don't mind to set it as public and dup it
[10:16] <kiko> thanks
[10:16] <carlos> kiko: daf already said that perhaps we should set it as public
[10:16] <kiko> yeah, I agree with him
[10:16] <kiko> daf is a keen guy
[10:16] <kiko> he generally knows his stuff
[10:16] <kiko> even if he does dupe things randomly from time to time
[10:17] <carlos> kiko: done
[10:18] <kiko> wonderful!
[10:22] <matsubara> kiko: would you like to review bug 5757?
[10:23] <Ubugtu> malone bug 5757 in malone "OOPS: requesting an upstream fix doesn't check input for duplicates" [Normal,In progress]  http://launchpad.net/bugs/5757
[10:23] <kiko> matsubara, already? sure.
[10:31] <matsubara> https://chinstrap.ubuntu.com/~dsilvers/paste/fileYXO6Km.html
[10:31] <matsubara> kiko: ^^
[10:32] <kiko> +            'Fix already requested for %s' % product.displayname)))\
[10:32] <kiko> A fix has already been requested for XXX?
[10:33] <kiko> +But we can't change it to a existing upstream bugtask 
[10:33] <kiko> english
[10:34] <kiko> and also, probably could say what it's doing in more words
[10:34] <kiko> matsubara, that looks pretty good other than that
[10:35] <matsubara> kiko: Should I change the message from the valid_distrotask too?
[10:35] <kiko> yeah. 
[10:35] <kiko> eat that PQM!
[10:35] <cprov> carlos: I'm leaving, do you need me for tests in DF ?
[10:36] <kiko> cprov, when you leave, can you stop by here? mdz had a question
[10:36] <carlos> cprov: not yet, I will send you an email with the patch
[10:36] <cprov> kiko: sure
[10:36] <cprov> carlos: will ou work tomorrow ?
[10:36] <cprov> you
[10:36] <carlos> cprov: yes, as usual
[10:37] <cprov> carlos: good, I can sort it out definatelly tomorrow morning. take care.
[10:37] <carlos> cprov: cool, cheers
[10:38] <kiko> matsubara, fix those conflicts and get your patch in fast, because I need to create new bugs in my tests too
[10:39] <matsubara> kiko: it's already on pqm's hands again.
[10:41] <kiko> good
[10:42] <dilys> Merge to devel/launchpad/: Fix https://launchpad.net/products/malone/+bug/31872 (Target to fix does not work for package names containing dots) r=kiko (r3189: Diogo Matsubara)
[10:42] <kiko> yes!
[10:43] <matsubara> go dilys go!!!
[10:43] <matsubara> kiko: would you like to take a look again on 5757?
[10:44] <dilys> fogo na bomba!
[10:45] <kiko> matsubara, sure
[10:46] <matsubara> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/fileEkHHG2.html
[11:04] <kiko> come on pqm
[11:04] <kiko> give me good news
[11:04] <kiko> +  ...A fix has already been requested for mozilla-firefox(Ubuntu)...
[11:04] <kiko> matsubara, is there really no space there? that's ugly
[11:05] <kiko> no, that's your fault!
[11:05] <kiko> add a space before the open-parenthesis
[11:05] <kiko> matsubara, also:
[11:05] <kiko> "A fix for this bug has..."
[11:05] <kiko> I think it will be better.
[11:05] <kiko> r=kiko with those
[11:09] <kiko> matsubara?
[11:10] <matsubara> kiko: done
[11:10] <kiko> do it!
[11:10] <matsubara> kiko: running the tests again and will submit the merge request
[11:10] <kiko> cool.
[11:16] <dilys> Merge to devel/launchpad/: [r=kiko]  reject password reset requests for teams (bug #6313) (r3190: Dafydd Harries)
[11:16] <kiko> YES!
[11:16] <kiko> wow, our spree is going well
[11:16] <matsubara> :)
[11:22] <kiko> BjornT, bra...
[11:22] <kiko> grrrrrrr
[11:22] <kiko> where is bradb?
[11:29] <BjornT> kiko: did you want something important?
[11:30] <kiko> BjornT, an opinion on bug 31367 so I can work on it.
[11:30] <Ubugtu> malone bug 31367 in malone "Specifying a non-published binary package when filing a bug causes an oops" [Normal,Confirmed]  http://launchpad.net/bugs/31367
[11:30] <kiko> I forwarded email to avoid being blocked but..
[11:39] <BjornT> kiko: it's certainly better than an oops. i think it's acceptable to do what you proposed, and fix it properly later.
[11:46] <kiko> thanks.
[11:59] <dilys> Merge to devel/launchpad/: [trivial]  Fix for bug 32512: Targetting a bug to a distribution with no current release blows up. Fix and improve the codeflow in distribution.getPackageNames. Unfortunately this won't stop us from OOPSing because of bug 31367, but I'll get that next (r3191: kiko)
[12:00] <kiko> YES!
[12:00] <kiko> YES!
[12:00] <kiko> GOD EXISTS@
[12:02] <matsubara> kiko: great. :)