[12:37] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: changed bug assignment statuses to the more clearly-named New, Accepted, Rejected and Fixed to overcome usability problems experienced while testing (patch-814)
[12:56] <BradB> Ouch, that <pre> change on bug messages is horrific
[01:25] <BradB> stub: dude, did you look at the <pre> change? :)
[01:26] <stub> I merged that into Rocketfuel, didn't I?
[01:27] <BradB> yeah, but i mean did you look at it in the UI? it's nasty dude.
[01:27] <BradB> because, of course, lines aren't wrapping anymore.
[01:27] <stub> Did some limited tests here. Hmm...
[01:29] <BradB> that's why i suggested only for code snippets.
[01:30] <stub> Still got the same problem. I need more CSS-fu I think :-(
[01:30] <BradB> stub: with code-only though, you only get the problem when people are stupid, which will happen from time to time, but i don't expect it to be the common case
[01:31] <BradB> e.g. i don't think pasting 100-column wide code snippets is the common case
[01:31] <stub> I feel certain that the common case will be forgetting to put in (or not even knowing) the special markup required to flag a code snippet.
[01:32] <BradB> in any case, i'm about the land a change to the default search criteria, so that it's New/Accepted. i'm leaving the other widgets alone until i've discussed them more with Mark, because he has some concern about them being difficult to handle when all the packages, products and people come into it.
[01:32] <BradB> stub: eh, you can only help the user so much, of course...
[01:33] <BradB> if you say "use <pre> for code snippets" and they don't, well...
[01:33] <BradB> it could even be a little note nearby the textarea
[01:33] <stub> If Malone does not do the right thing, people will use other systems. If we start accepting certain HTML codes, and making people escape them somehow when they want to include them, it will be yet-another-markup language and piss people off.
[01:34] <stub> And we can't fix this with documentation on the web, because of the email interface.
[01:34] <BradB> stub: it's not YAML though! it's just only allowing them to use HTML tags that we /can/ allow them to use whilst not creating a security compromise.
[01:35] <BradB> stub: email users will already be familiar with the web UI, and those that aren't should expect (and will have to) read a little tutorial on how to format their email correctly anyway.
[01:35] <stub> It is - people will be composing HTML in their text email clients, and god help the poor sods who are sending HTML mail.
[01:36] <BradB> and again, we're thinking too far ahead right now. we need some little bit of markup for code no matter which way you look at it, but we don't much care about the incoming mail UI atm, because (i hope) it won't be part of the first release anyway.
[01:36] <stub> Oh - I think I see. For the nice_pre, space should only be converted to &nbsp; at the start of the line.
[01:38] <BradB> what problem does that solve?
[01:38] <stub> I'm thinking ahead to the email interface, because I don't want all our comments to break when we switch it on (because they were assuming fixed width display, and suddenly the system chooses to render them proportional with collapsed whitespace). (Hmm... I guess at least in this case we can run through and add the 'code' marker around the entire existing messages)
[01:38] <stub> It will allow the browser to break lines I think.
[01:39] <BradB> stub: dude, i think you're assuming everybody that uses malone uses mutt.
[01:39] <BradB> stub: rest assured, this isn't the case. think of all the gnome developers, kde developers, etc.
[01:39] <stub> At the moment, it is not breaking them because I stupidly told it to *not* break them in about the most explicit way possible.
[01:41] <stub> I don't mean text clients (oh... so 90's!).  I mean text mode. All developers I know only send plain text emails (if for no other reason than the flamage they receive on public forums)
[01:42] <BradB> stub: i'd be delighted if, when writing an email, all i had to do to highlight some code was:

[01:42] <BradB> x = 1

[01:42] <BradB> the font we had seemed pretty decent, as proportional fonts go
[01:43] <BradB> mixing prop with pre-for-code would look fairly professional, like, heck, our wiki.
[01:43] <stub> Yes, And I'd be pissed off at the system if i sent 'You need to do something like '<pre><span tal:contents="foo/bar" />...</pre>' and the system decided to interpret y markup, or worse still, only *some* of my markup.
[01:44] <BradB> stub: "interpret your markup"??! huh? we wouldn't touch anything inside the <pre>, obviously
[01:45] <BradB> it's verbatim, which you'd expect.
[01:45] <BradB> and you'd understand why we do the same thing that other sites do in restricting html tags used for security reasons.
[01:46] <BradB> but anyway, gah, whatever, i'm not too arsed. i just hope we can do another rollout today, so that the statuses become more sane and the default search params become slightly more sane too.
[01:47] <BradB> stub: if sabdfl actually *likes* the look of all <pre> messages though, i'd boggle. :)
[01:48] <stub> Roundup looks like it is formatting the text server side to 80 columns (and preserving whitespace and using a monospace font)
[01:48] <stub> Actually, it looks quite fine here. You need to use a different monospace font that courier ;)
[02:15] <BradB> stub: will you be able to push up a new dogfood today?
[02:15] <stub> Yes
[02:15] <BradB> great...my patch for default search params should land any minute.
[02:16] <BradB> if i implement "Quick Searches" like at http://plone.org/collector, we can basically drop the bugs assigned to, and bug submitted by reports.
[02:16] <BradB> implement tomorrow, that is
[02:29] <stub> Sounds good.
[02:30] <stub> Get a good collection of default ones in and we won't have to bother with making used-defined quick searches either ;)
[03:15] <stub> lifeless: Does arch do anything sucky with line endings like subversion, or does it just leave them the way they were saved?
[03:53] <stub> kiko: So - Malone has this 'select a sourcepackage' requirement
[03:53] <stub> kiko: Unfortunately, there appears to be no way a user can select the correct sourcepackage without knowing the primary key id
[03:56] <stub> kiko: I suspect I either need to make UNIQUE(Sourcepackage.distro, Sourcepackage.sourcepackagename) or somehow only display a 'sane' list of sourcepackages (perhaps only displaying the sourcepackage with a given distro and name that has the latest creation date (which needs to be added))
[03:57] <kiko> hmmm
[03:57] <kiko> right.
[03:58] <kiko> There could be a problem with UNIQUE distro/name because of inherited packages, I think.
[03:58] <kiko> this part of the workflow really hasn't been considered yet, so it sucks to be you the first one to have the problem.
[03:59] <kiko> you *could* make a select distinct on them -- how do you feel about that?
[04:01] <stub> I can have multiple identical rows in the sourcepackage table, only differing by id. If I only display distinct rows, I need to know which one is 'current' and assign bugs to that, or perhaps I should always use the first one? I'm really not sure
[04:02] <kiko> can't people file bugs against old releases?
[04:02] <stub> I personally think that we either need UNIQUE(Sourcepackage.distro, Sourcepackage.sourcepackagename) or refactor the database schema - the situation seems wrong.
[04:02] <stub> kiko: If they can, they have no way of telling the old releases from the new ones at the moment.
[04:02] <stub> It isn't a database issue, it is a UI issue.
[04:03] <stub> (but I suspect the UI issue is caused by the database design, and that this design is causing problems elsewhere too)
[04:04] <stub> Do you know who would know if UNIQUE(distro, sourcepackagename) would break the model? People I've asked all suspect, but nobody can actually tell me a use case.
[04:05] <kiko> well
[04:05] <kiko> hmmmmmmm
[04:06] <stub> (we might have to move sourcepackage.maintainer into sourcepackagerelease to snapshot this historical information, but apart from that...)
[04:06] <kiko> sourcepackagename is merely a normalization table, avoiding duplicating the package name in the sourcepackage table.
[04:07] <stub> Yer - pointless optimization IMO but I havn't pushed it too hard ;)
[04:07] <kiko> the issue is that you can have multiple sourcepackages with the same name but representing different packages 
[04:08] <kiko> so you could have a web browser called firebird and a database called firebird
[04:08] <kiko> however I do think that you can't have firebird the browser and firebird the database in the same distribution as it would, well, not work, right?
[04:09] <stub> That is what I think. If anything, the issue would be that if Ubuntu had firebird-the-browser in warty, and firebird-the-database in hoary.
[04:09] <stub> That might be our pathalogical use case?
[04:10] <stub> (If so, it indicates to me that sourcepackage should be related to distrorelease rather than distro)
[04:10] <stub> I'm not sure if the Manifest causes trouble - it isn't documented so I'm not sure about it.
[04:12] <stub> The other Malone alternative might be to assign bugs to a (distro, sourcepackagename) or a (distrorelease,sourcepackagename) instead of to a sourcepackage.
[04:13] <stub> Hmm... if that *is* our pathalogical use case, we might need to prevent it from happening anyway because an Ubuntu user upgrading that package might get a nasty surprise ;)
[04:47] <kiko> exactly
[04:48] <kiko> I think over a whole distro you need the sourcepackagename to be unique.
[04:48] <kiko> you'll need mark to confirm, though, because none of this is complicated unless we consider derivative distros, and that's where my knowledge endgs
[04:48] <kiko> ends
[04:49] <kiko> I really don't like sourcepackagename very much and I've said it often -- I don't think it brings us anything at all 
[04:50] <stub> I need to dig up a database design book which explains why sourcepackagename is wrong - I've gotten too used to relying on my intuition and not having to rationalize my decisions to anyone else ;)
[04:53] <stub> Mark seemed to think the existing design on sourcepackage was required for some reason but was unable to come up with a use case - suggested it was discussed at the conference but I was hoping to have the UI fixed before then ;)
[04:55] <kiko> yeah.
[04:55] <kiko> so the use case you have is the user is trying to say in what package he's encountering the bug?
[08:01] <stub> lifeless: pqm hung
[08:01] <stub> elmo: pqm hung
[09:12] <stub> lifeless: pqm is hung
[09:13] <elmo> fixed
[09:37] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: made New and Accepted the default statuses in the bug listing search (patch-815)
[09:47] <sabdfl> hey stub
[09:48] <sabdfl> stub: sourcepackagename is partly because a lot of the actual pointers in the real world are to sourcepackagename, not to a specific sourcepackage
[09:48] <sabdfl> the debian bug system, for example, assigns bugs to a sourcepackage name
[09:49] <sabdfl> even if we move sourcepackagename back into sourcepackage, you still have the basic problem that a sourcepackage with a given name is not unique
[09:50] <sabdfl> stub: can i merge the corrected BugMessage refactoring?
[09:50] <sabdfl> I added:
[09:50] <sabdfl> ALTER TABLE Message
[09:50] <sabdfl>     ALTER COLUMN id SET DEFAULT nextval('message_id_seq');
[09:51] <stub> yes - go for it.
[09:52] <stub> Keeping sourcepackagename in a seperate table makes sense when you factor in those references I guess (the arguments for become stronger and against less clear anyway).
[09:52] <sabdfl> it's a shitty situation, but we're trying to model a difficult problem
[09:53] <sabdfl> i'm thinking of refactoring Malone to assign bugs to (distro, sourcepackagename) rather than sourcepackage
[09:54] <stub> Yup - that would be a solution. I've just been poking people trying to workout the best solution, and if there is an underlying problem with the data model.
[09:56] <stub> I think we need to come up with the most pathalogical case we plan on supporting - the firebird one above seems pretty good, but I don't know if we want to support that behaviour or prevent it.
[09:59] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: nice_pre CSS implementation for dogfooding (patch-816)
[10:24] <Kinnison> Dudes.
[10:35] <sabdfl> morning Kinnison
[10:36] <Kinnison> hey sabdfl 
[10:37] <Kinnison> sabdfl: Assuming kiko and cprov agree; I'd like to have cprov working with me from Monday. Does that sound okay to you?
[10:38] <sabdfl> absolutely
[10:38] <sabdfl> stretch cprov a little
[10:38] <sabdfl> stub: ok, i'm using patch 4-10-0
[10:41] <sabdfl> easy on the quartering
[10:43] <Kinnison> Can I at least draw him?
[10:44] <sabdfl> steady on
[10:44] <sabdfl> he might take that personally
[10:44] <Kinnison> True; I'd best stick to keeping this purely professional
[10:47] <stub> Now PQM is awake again, I'll do a dogfood update. Yell now if people have patches they want rolled out today that aren't yet committed.
[10:54] <Kinnison> morning elmo
[10:54] <Kinnison> sabdfl: I did a very rough time-plan last night; I'm going through it now making sure it seems sane
[11:15] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: bugmessage refactoring (patch-817)
[11:20] <Kinnison> sabdfl: Unfortunately every time I think I'm done; I think of another thing to get gina to do :-)
[11:23] <sabdfl> stub: did that bugmessage refactoring make it into the dogfood update?
[11:23] <stub> It will - just shutdown the existing services when I saw the dillys message
[11:24] <sabdfl> thanks!
[11:55] <Kinnison> cprov: is Kiko around?
[11:58] <sabdfl> SteveA: congrats on getting the ZODBAnnotations service up and running
[12:01] <SteveA> thx
[12:03] <SteveA> with the ftp server, I think we might want to put a try:except: around the callbacks
[12:03] <SteveA> and log errors at that point
[12:03] <Kinnison> SteveA: sounds like a sensible precaution
[12:07] <SteveA> stub: I just read the email about a simpler way to restore backups.  Is the "wisdom of the dba" being recorded anywhere other than the mailing list?
[12:09] <stub> Not at present. Something like an FAQ may be appropriate.
[12:10] <stub> Procedures that exist are documented in launchpad/database/schema/README, but that is more for acting-dba's.
[12:10] <cprov> Kinnison: no, I think 
[12:13] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: bugassignment renumbering (patch-818)
[12:13] <Kinnison> cprov: Any idea when he normally turns up?
[12:15] <cprov> Kinnison: sorry, but today I have no idea, maybe within this hour . may I help you ?
[12:16] <Kinnison> cprov: I need to talk with you and him ;-)
[12:17] <Kinnison> cprov: sabdfl has agreed to let me ask for your time on lucille :-)
[12:17] <Kinnison> cprov: Which will give you a chance to see how things work from the other end of the package process in soyuz ;-)
[12:29] <sabdfl> cprov: would you like to take on some of the deeper challenges in the package management system behind soyuz?
[12:30] <cprov> sabdfl: yes
[12:30] <Kinnison> Hurrah
[12:31] <sabdfl> cprov: excelle nt
[12:31] <cprov> sabdfl: I'm just getting a kind of lost helping SteveA and Brad to have "better output on failed tests" <wink>
[12:31] <sabdfl> you've done a great job on the front end so far
[12:32] <sabdfl> remember all those questions about "how uploads happen" and "what happens when a new package arrives" that I said not to worry about?
[12:32] <sabdfl> now's the time to start thinking about them :-)
[12:32] <sabdfl> Kinnison has made a good start and will lead  this work
[12:32] <sabdfl> you will work for Kinnison on tasks he assigns
[12:33] <sabdfl> he knows exctly what he wants done, and can help you when you get stuck
[12:33] <cprov> sabdfl: thanks, but I feel I can do more on it ... just need more "time" (48 hours day would be nice) 
[12:33] <sabdfl> together you two need to get the back-end stuff working for the end of es-conf
[12:33] <cprov> sabdfl: great !
[12:35] <Kinnison> cprov: My plan involves getting you into the lucille stuff starting on Monday. That gives you today and tomorrow to finish of the stuff you're working on and hand off anything to other people. Does that sound enough or do you want more time than that? (sabdfl: Do you want cprov to be exclusively on lucille or partially on lucille until es-conf?)
[12:36] <sabdfl> Kinnison: i think lucille should remain your baby
[12:36] <sabdfl> give cprove related tasks with a lower learning curve
[12:36] <sabdfl> to start with
[12:36] <Kinnison> sabdfl: Yeah; my plan had that kind of ramp-up
[12:37] <sabdfl> so, for example, the build system integration
[12:37] <Kinnison> sabdfl: I have a identified quite a bit to do on gina for now ;-)
[12:37] <sabdfl> ok
[12:37] <cprov> Kinnison: 2 days to finish my current tasks will be enough
[12:37] <Kinnison> sabdfl: I think the build-system integration is actually quite a deep thing. I have a curve mostly planned out for now ;-)
[12:39] <sabdfl> ok
[12:48] <cprov> Kinnison: sabdfl: I'm very happy to work on this, let's book a meeting soon to talk about your plans and the targets
[12:48] <Kinnison> cprov: Yes; I'd like to make sure kiko is happy with all this too
[12:52] <cprov> Kinnison: let me help you with a simple phone call :)
[12:53] <cprov> Kinnison: done, in few minutes he will arrive
[12:53] <Kinnison> hi kiko
[12:53] <kiko> minutes!
[12:53] <kiko> hey everybody
[12:53] <kiko> today is "I hate SSL certificates" day!
[12:54] <Kinnison> kiko: To bring you up to speed... sabdfl and I had a meeting yesterday and we decided that it would be good to get cprov on board with me as a lucille developer. cprov is interested in this and we've basically agreed that he will start working with me on Monday. Is this okay with you?
[12:54] <cprov> kiko: sorry I should say "seconds" ...
[12:54] <kiko> Kinnison, sounds good to me -- cprov has been wanting to get his hands dirty on it for a while already I suspect.
[12:55] <kiko> I was actually curious because yesterday you said an extra pair of hands would be good
[12:55] <Kinnison> kiko: Excellent ;-)
[12:55] <kiko> I was going to offer but since the topic died out I thought you had reconsidered.
[01:04] <sabdfl> kiko: ssl certificates are paying for this little gig :-)
[01:05] <kiko> Kinnison, tell me more about where lucille is going
[01:05] <kiko> sabdfl, jesus, good point, you could give me some hints, openssl is kicking my ass.
[01:05] <sabdfl> hold on, this is really soyuz, not lucille
[01:05] <sabdfl> lucille is one component of soyuz
[01:05] <stub> Mmm.... SSL certificates. Although I did get a $25 amazon gift certificate in thanks for calling Thawte extortionists in a survey. Sorry Mark :-)
[01:05] <sabdfl> lucille manages APT archives for distros - ubuntu and derivatives
[01:06] <Kinnison> sabdfl: Lucille manages a tad more than that to be fair
[01:06] <sabdfl> stub: dude, i think they started that after i left
[01:06] <sabdfl> vrsn
[01:06] <Kinnison> sabdfl: She also manages the queues. She's the *archive manager*
[01:06] <kiko> excuses, excuses
[01:06] <sabdfl> what we are talking about is extending cprov's work to include more of the workflow of package management
[01:06] <Kinnison> sabdfl: Indeed; so queue stuff; upload handling etc.
[01:06] <kiko> including the web-presented side of it, I expect?
[01:07] <Kinnison> kiko: Yes; I hope so
[01:07] <sabdfl> from upload, through build, through publishing, and including offering the package to derivatives
[01:07] <sabdfl> kiko: especially :-)
[01:07] <sabdfl> Kinnison has a really good understanding of how that workflow should look
[01:08] <sabdfl> we need to give him a second pair of hands, and also someone with web / zope flair, so cprov sprung to mind
[01:08] <kiko> if this means we can finally fix the "Pending" feature in source package, I want to donate to the effort
[01:08] <sabdfl> kiko: yes it does
[01:09] <kiko> sabdfl, today's our first day running ubuntu diskless at async
[01:09] <sabdfl> kiko: ltsp?
[01:09] <kiko> we encountered a few tricky issues but all in all it's excellent.
[01:10] <kiko> no, ltsp runs apps on the server -- we run apps on the client. it's pure NFS.
[01:10] <sabdfl> can we sanely fold that into hoary as a standard feature?
[01:10] <kiko> I'd need to ask salgado, but there are a few package tweaks that would need to be done.
[01:11] <kiko> the issue is that what we do is install ubuntu into a directory on the server and export that via NFS
[01:11] <kiko> we use a custom-built kernel, and some init.d hacks
[01:11] <kiko> I wonder if this would be a "package" to install on the server or something else.
[01:11] <kiko> it's currently a tarball.
[01:12] <Kinnison> Sounds like ideally it'd be a debootstrap following by a chroot and an install of a few choice patching packages
[01:12] <kiko> (it would be an 800MB package)
[01:12] <kiko> Kinnison, let's talk a bit about this in spain, I'd like to package it nicely
[01:12] <Kinnison> s.following.followed.
[01:12] <Kinnison> kiko: make sure you note down to talk about it or I'll forget
[01:12] <kiko> sure thing
[01:24] <SteveA> carlos: we have a meeting in 5 minutes
[01:31] <stub> sabdfl: Should everyone with a chinstrap account be allowed to access a launchpad_dogfood backup?
[01:35] <elmo> stub: no
[01:37] <stub> elmo: Is there a group I can use? There is a request on launchpad@ to get a copy of the dumps for development work and I either need a drop point for people without accounts on mawson or deny it.
[01:37] <carlos> SteveA: I'm here
[01:37] <elmo> stub: who needs it who doesn't have an account on mawson?
[01:37] <carlos> elmo: I
[01:38] <elmo> anyone else?
[01:38] <stub> carlos requested it. I have no idea if there are others.
[01:38] <elmo> carlos: congratulations you now have an account
[01:39] <elmo> thanks for playing "Lucky Account Lotto"
[01:39] <carlos> X-)
[01:39] <stub> Ta elmo.
[01:39] <carlos> elmo: thanks
[01:49] <SteveA> daf: ???
[01:57] <SteveA> carlos: I have another meeting later, and other things to do today.  Let's talk anyway.  Daf can read later.
[01:57] <carlos> ok
[01:57] <carlos> here or #canonical-meeting?
[02:00] <stub> Do bzipped files rsync well?
[02:01] <SteveA> ok.  Is the rosetta alpha running on the dogfood system?
[02:02] <kiko> stub, well, not efficiently, but it works
[02:03] <carlos> SteveA: seems like some data is still pending of upload, but I'm not sure
[02:03] <carlos> SteveA: I know daf was uploading files already
[02:04] <SteveA> when we talked about it yesterday, we all thought that it could be done by the end of yesterday.
[02:04] <SteveA> what happened?
[02:06] <carlos> SteveA: I'm not sure, but I think the scripts we have to import the files were not updated with latest changes we hace when moving to the common infrastructure
[02:06] <SteveA> what, exactly, is left to do?
[02:07] <carlos> SteveA: guessing here (I was not able to talk with daf, I left to sleep before he finished). Import the files into launchpad
[02:07] <carlos> I think I got an account in mawson today, so I could help now daf 
[02:07] <carlos> on this task
[02:08] <SteveA> ok.  I wish daf were here.
[02:08] <SteveA> daf: buy yourself a big alarm clock that has no "snooze" button.
[02:08] <carlos> :-P
[02:09] <SteveA> let's assume that the dogfood stuff will be done a bit later today.
[02:09] <carlos> ok
[02:09] <SteveA> next, we have two important things
[02:09] <SteveA> 1. get more people using rosetta
[02:10] <SteveA> 2. the rosetta team needs to lead the rest of launchpad in internationalizing the application
[02:10] <SteveA> before I went on vacation, I emailed a list of resources on how to internationalize applications in python and zope
[02:10] <SteveA> did you read these?
[02:11] <carlos> not in depth
[02:11] <carlos> but I got the idea
[02:11] <SteveA> did you start to apply what you had learned to the rosetta code?
[02:12] <carlos> not yet
[02:12] <carlos> I was working fixing bugs more than adding new feature
[02:12] <carlos> s
[02:12] <carlos> yesterday I started adding new features
[02:12] <SteveA> this is an important feature for dogfooding rosetta
[02:12] <carlos> so I will do it now
[02:12] <carlos> I mean, from now
[02:13] <SteveA> ok, great.  there are three parts to this.
[02:13] <SteveA> 1. start internationalizing rosetta
[02:13] <SteveA> 2. get the pot files into the rosetta dogfood system for translation
[02:14] <SteveA> 3. write up how to do this so that others on the launchpad team can see what they need to do to existing code, and what they need to do with new code.
[02:14] <SteveA> the rosetta team are the "internationalization csars" for launchpad.
[02:14] <carlos> :-)
[02:15] <carlos> SteveA: should we add projects to translate as we decide? (outside the list we already were talking about)
[02:16] <SteveA> you mean in addition to stuff from ubuntu, zope3, plone, zwiki ?
[02:16] <carlos> hmm, with all ubuntu resources we have already a big tasks
[02:17] <carlos> I was talking about which ubuntu resources should we add
[02:17] <carlos> until we could automatice the import
[02:18] <carlos>  /s/automatice/automate/
[02:18] <SteveA> okay
[02:19] <SteveA> the thing to consider is whether you can get more people using rosetta by adding a particular project
[02:20] <carlos> ok
[02:20] <carlos> and how are we going to translate ubuntu's website?
[02:21] <carlos> not sure if it will be handled by rosetta
[02:21] <SteveA> that doesn't have anything to do with rosetta at this point
[02:22] <carlos> ok
[02:26] <carlos> SteveA: anything else?
[02:27] <SteveA> that's it for now, at least until daf turns up and we can talk about the dogfood
[02:27] <carlos> ok
[02:27] <SteveA> keep me informed about how the internationalization stuff is going
[02:27] <SteveA> I can help out if you have questions
[02:28] <carlos> ok
[02:28] <carlos> will do
[02:29] <SteveA> thanks
[02:41] <carlos> SteveA: sorry, but I'm not able to find the links you sent about zope i18n, I read them but seems like I forgot to add a bookmark
[02:41] <carlos> do you have them around?
[02:44] <carlos> I think I found it: http://zope.org/Wikis/DevSite/Projects/ComponentArchitecture/HowToDoI18nAndL10nForZope3/Zope3Internationalization
[02:51] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: No more unused imports in soyuz app components. BugAssignmentStatus ajustment. (patch-819)
[03:01] <SteveA> carlos: I have sent you another copy
[03:01] <carlos> SteveA: thanks
[03:04] <BradB> morning
[03:07] <Kinnison> Hey brad
[03:11] <carlos> SteveA: ok, I know why I didn't found it, it's inside my inbox folder instead of the folder I have with your mails ..
[03:13] <cprov> BradB: please, tell me the RIGHT way to set a customized "optionflags" for a set of python tests 
[03:37] <BradB> cprov: canonical.functional.FunctionalDocFileSuite has an example of how to do it.
[04:04] <carlos> BradB: how is your css knowledge?
[04:05] <BradB> carlos: limited
[04:05] <carlos> hmm
[04:05] <BradB> why?
[04:05] <carlos> who knows css in launchpad team?
[04:05] <carlos> BradB: we have a problem with css in rosetta
[04:06] <carlos> Kinnison: could you look at http://localhost:8086/rosetta/projects/gnome/evolution/evolution-2.0/translate ?
[04:06] <carlos> Kinnison: from your local launchpad installation?
[04:06] <Kinnison> is that part of the default data?
[04:06] <carlos> we are showing check buttons and they are expanded because some css magic...
[04:07] <carlos> Kinnison: yes
[04:07] <carlos> you need default data
[04:07] <Kinnison> how do I load default data?
[04:07] <carlos> a make inside database/schema should be enough
[04:08] <carlos> launchpad/database/schema
[04:08] <Kinnison> okay
[04:09] <Kinnison> user/password?
[04:09] <carlos> carlos@canonical.com
[04:09] <carlos> test
[04:09] <carlos> or foo.bar@canonical.com and same password
[04:09] <Kinnison> okay; I can see the page
[04:09] <carlos> look under the language name
[04:10] <carlos> that's a check button
[04:10] <Kinnison> woah
[04:10] <carlos> that has the same size of the entry text
[04:10] <Kinnison> and you want to know why yes?
[04:10] <carlos> well, know why and fix it :-)
[04:14] <carlos> Kinnison: my X server died
[04:15] <Kinnison> The problem appears to be that the checkbox is inside a <label> tag
[04:16] <carlos> let me check it...
[04:16] <sabdfl> erk
[04:16] <sabdfl> i need some charset help / fu
[04:17] <sabdfl> any experts out there? stevea?
[04:19] <carlos> Kinnison: same problem moving the checkbox out of the label
[04:20] <carlos> Kinnison: the template is potemplate-translate.pt
[04:20] <Kinnison> where is that?
[04:20] <carlos> lib/canonical/launchpad/templates
[04:21] <carlos> Kinnison: http://gollum.pemas.net:8085/rosetta/projects/gnome/evolution/evolution-2.0/translate <- My local launchpad server
[04:23] <sabdfl> how do i make sure a string is unicode before sending it to the db?
[04:24] <sabdfl> i'm trying to put a bunch of emails into the db, and i hit one with 8-bit characters... BOOM
[04:24] <kiko> sabdfl, heh, same problem as in gina.
[04:24] <kiko> you can use my horrible-hack from it
[04:24] <sabdfl> ok, where's the code?
[04:25] <kiko> l/c/lp/scripts/gina/database.py:ensure_string_format()
[04:25] <Kinnison> carlos: Okay, I can fix it with an explicit style rule
[04:25] <Kinnison> carlos: add to your css the following:
[04:25] <SteveA> sabdfl: when you say "putting a bunch of emails in the database", is this a script?
[04:26] <carlos> Kinnison: ok
[04:26] <Kinnison> fieldset.message-strings input[type=checkbox]  { width: auto !important; }
[04:26] <Kinnison> carlos: try that
[04:30] <carlos> hmm
[04:30] <Kinnison> did that do it?
[04:30] <carlos> Kinnison: I added it to the end of launchpad.css
[04:30] <carlos> and I don't see any change
[04:30] <Kinnison> shift+ctrl+alt+hyper+meta+uber+reload?
[04:30] <Kinnison> In case mozilla has it cached
[04:31] <carlos> ok, that's the problem
[04:31] <carlos> it worked now
[04:31] <carlos> thanks
[04:31] <Kinnison> You're welcome
[04:31] <sabdfl> SteveA: yes it is a script
[04:31] <carlos> Kinnison: ;-)
[04:32] <sabdfl> i'm rewriting the debbugs-bugzilla syncer that mdz wrote, for malone-debbugs sync
[04:32] <sabdfl> Kinnison: wow, that's quite a memory
[04:33] <Kinnison> sabdfl: I needed to understand the CSS box model a while ago; so I forced myself to remember as much of CSS as I could
[04:33] <Kinnison> sabdfl: Unfortunately I'm reasonably sure that I forgot how to make spaghetti bolognese in the process
[04:33] <Kinnison> blasted limited-capacity poorly-designed brain
[04:35] <BradB> sabdfl: got a moment to chat about the search widgets?
[04:35] <BradB> sabdfl: namely, i want to know if it's worth the effort to set defaults on the result of the widgets, based on the user's context.
[04:35] <SteveA> sabdfl: the general rule for writing code that interacts with things outside the system is, convert textual data into unicode as soon as you get it.
[04:35] <BradB> because if they're going away, or are going to be modified significantly, it may be wasted effort.
[04:36] <SteveA> sabdfl: or, decide that it is "opaque data", and store it as "bytes" in the database not as text.
[04:36] <sabdfl> SteveA: here's the challenge
[04:36] <sabdfl>  - take several hundred thousand emails in the debbugs system, and import them to the Message table
[04:36] <sabdfl> we have to be able to do this
[04:37] <sabdfl> elmo: what's the ETA on a genuine upload facility that does not require a chinstrap account for hoary uploads?
[04:38] <sabdfl> BradB: if we used wizard-style forms this would be easier, right?
[04:38] <sabdfl> because we get to develop the context over a few page loads
[04:39] <BradB> sabdfl: heck no. that would take too much effort.
[04:41] <elmo> sabdfl: if I go home tonight, I'll should be able to do it tomorrow
[04:41] <sabdfl> elmo: great
[04:41] <BradB> sabdfl: when do we get to see a serious go at a combo box widget that can handle, say, 20,000 items?
[04:41] <sabdfl> thanks!
[04:41] <sabdfl> SteveA: i'm using the std library stuff to parse the emails fine
[04:42] <sabdfl> BradB: it's not going to be possible client-side
[04:42] <sabdfl> BradB: we need either a popup, or a behind-the-scenes query with JS
[04:44] <BradB> sabdfl: ok. it doesn't sound like it's worth it for me to do much more with setting things on the existing widgets then. this widget will be critical for launch. when do we get someone to have a serious go at making a popup that can work for the bug listing screen?
[04:45] <cprov> BradB: thanks
[04:47] <BradB> sabdfl: heck, i think a killer MonsterSelect widget would really help sell launchpad to developers. i for one get a kick out of using apps that do little things that make me go "whoa, now /that/ is neat."
[04:48] <BradB> which is what i did the other day when i saw the combo box thing in bugzilla
[04:48] <sabdfl> BradB: ok, want to have a stab at it?
[04:48] <BradB> sure
[04:49] <sabdfl> my preferred approach is a behind-the-scenes query that returns a JS array
[04:49] <BradB> ok
[04:49] <sabdfl> and keep this all inside the form, in an expanding fieldset
[04:49] <sabdfl> initial state shows search form
[04:49] <sabdfl> enter text and press "find"
[04:50] <sabdfl> fieldset expands to show text search field and list of up to 10 matches
[04:50] <sabdfl> click on a match, and fieldset collapses to show just that selected item, with a "change selection" option to search again
[04:51] <Kinnison> dafydd.
[04:51] <BradB> it needs to handle multi-selects too, of course (a common case in the bug listing)
[04:52] <daf> Daniel.
[04:52] <Kinnison> daf: sleep well?
[04:53] <daf> yes, thank you
[04:57] <carlos> daf: hey!
[04:58] <Kinnison> c'y'all in about 45 mins again
[05:01] <sabdfl> blush... what's the login for foo again?
[05:01] <sabdfl> foo.bar@~canonical.com, test?
[05:01] <carlos> sabdfl: yes
[05:01] <carlos> without the ~
[05:02] <sabdfl> carlos: doesn't work for me
[05:03] <carlos> sabdfl: I think it's only available with sample data
[05:03] <carlos> the dogfood server does not have it
[05:17] <sabdfl> carlos: ah, thanks :-)
[05:20] <BradB> um, why in the HELL am i seeing a bunch of messages like "rm: /mach_kernel: Operation not permitted" when i try to restore a dogfood backup with: bunzip2 -c /Users/bradb/launchpad_dogfood.20041118.sql.bz2 | psql -d launchpad_dev
[05:22] <BradB> rm: /dev: Operation not permitted. um, jesus fuck.
[05:23] <kiko> heh
[05:23] <kiko> dude, that's not good.
[05:24] <daf> !
[05:25] <daf> BradB: you want bunzip2 -cd, surely?
[05:25] <daf> oh, no, never mind
[05:25] <kiko> you redundant welshie
[05:26] <BradB> i saw lots of garbage like "invalid command \n" or "invalid command \N" earlier in the run
[05:26] <BradB> and then this thing starts running launchpad ftests and such, which is thoroughly unexpected.
[05:26] <carlos> BradB: MacOSX is not unix ;-)
[05:27] <carlos> BradB: you just need to execut "ls -l /" to see it
[05:28] <carlos> daf: I'm leaving to go to the university in some minutes, should we talk about anything that cannot wait?
[05:28] <daf> we should
[05:28] <daf> but I don't know of anything that can't wait
[05:28] <kiko> SteveA, yo?
[05:29] <carlos> daf: btw, elmo gave me an account in mawson today so I suppose I could help you with the data import
[05:29] <carlos> daf: ok, I will be back in about 3 hours
[05:29] <daf> carlos: ok, I've been having some problems with the import scripts
[05:30] <carlos> daf: anything else than recent code changes?
[05:31] <daf> mostly database stuff
[05:31] <carlos> daf: ok, will see it when I'm back
[05:31] <carlos> later!
[05:32] <kiko> where's the SteveA 
[05:34] <debonzi> SteveA, ping
[05:36] <kiko> dude, it's RAINING.
[05:42] <BradB> eh, didn't i have a .txt file somewhere explaining how to use batching? I wonder if someone removed that.
[05:46] <BradB> sabdfl: hm, i wonder. is it reasonable to require that a launchpad user's browser supports DOM mutation?
[05:47] <BradB> which i guess just means supports DOM...
[05:47] <sabdfl> BradB: what's the coverage of that?
[05:47] <sabdfl> i think LP in lynx would be painful :-)
[05:47] <Kinnison> rehi
[05:47] <sabdfl> kiko: dude, it's POURING over here
[05:47] <sabdfl> and it's dark too
[05:47] <sabdfl> and 16:48
[05:50] <BradB> hm, no idea which browsers don't support DOM, but i guess most do
[05:52] <kiko> ack
[05:52] <kiko> winters in europe.
[05:52] <kiko> BradB, all modern browsers do, but text browsers don't. does that mean no filing bugs from lynx?
[05:54] <BradB> i think that's acceptable.
[05:55] <daf> I thought there was at least one text-based browser that support JavaScript
[05:55] <kiko> links does somewhat.
[05:56] <kiko> I don't know -- Bugzilla has always supported lynx as policy and I've used it on occasion.
[06:03] <elmo> not supporting lynx is CRACK
[06:04] <BradB> i didn't say it wasn't going to be supported, but that i'm ignoring it for now.
[06:04] <kiko> ignoring it for now means ignoring it forever, no?
[06:05] <BradB> yes
[06:05] <daf> so it't not going to be supported?
[06:06] <BradB> heh
[06:22] <SteveA> hi kiko, debonzi, cprov
[06:22] <SteveA> sorry I'm later
[06:22] <kiko> I'm about to skip out, too
[06:23] <kiko> how about we zap through?
[06:23] <debonzi> Hi SteveA
[06:24] <SteveA> ok.
[06:25] <SteveA> in soyuz/distroapp.py there are examples of what is arguably database code
[06:25] <SteveA> for exampe
[06:25] <SteveA>         self.roles=DistroReleaseRole.selectBy(distroreleaseID=self.release.id) 
[06:25] <SteveA> that is, rather than use what this method / instance has
[06:25] <SteveA> (in this case, a release)
[06:25] <SteveA> or use stuff got via a utility
[06:26] <SteveA> it is using the database stuff directly.  rather than using operations specified on an interface, it is calling "selectBy" directly.
[06:26] <SteveA> so, it is great that it is there and getting the job done
[06:26] <SteveA> but, I'd like stuff that is this closely linked to the database to be within canonical/launchpad/database/
[06:27] <kiko> let's look at that code
[06:27] <SteveA> It may be that a DistroRelease object needs to grow certain extra methods
[06:27] <SteveA> to allow what this class we're looking at needs
[06:27] <SteveA> that would be one way to fix it
[06:27] <SteveA> I'm looking at class DistroReleaseApp
[06:27] <SteveA> around line 75 in distroapp.py
[06:27] <SteveA> what do you guys think about all this?
[06:29] <kiko> sounds like the right way to go about it
[06:30] <kiko> let me get my tree updated, one moment.
[06:30] <debonzi> SteveA, you mean: I should be a method inside DistroRelease SQLObject that return the selectBy result. right ?
[06:30] <SteveA> one of the reasons I want all the database stuff to be in one place is because I'm working on the advanced security stuff right now.
[06:30] <SteveA> when this is checked in, the most important parts to consider the security of are the database classes
[06:30] <debonzi> s/I/It
[06:31] <kiko> SteveA, we should not use SQLObject-specific API outside of database.py, IMO. Agreed there?
[06:31] <SteveA> debonzi: yes.  so, the DistroReleaseApp code has a reference to a particular DistroRelease object.  It is called 'release'
[06:31] <SteveA> It needs to get the result of calling "DistroReleaseRole.selectBy(distroreleaseID=self.release.id)"
[06:32] <SteveA> so, DistroRelease can grow a method "getRoles" perhaps
[06:32] <SteveA> kiko: I agree.  Not database.py of course, but the database package
[06:32] <kiko> doh, yes, database/*.py.
[06:32] <SteveA> the exception is in stand-alone scripts
[06:32] <kiko> such as gina.
[06:33] <SteveA> yeah
[06:33] <debonzi> SteveA, Is classmethods ok for it too?
[06:33] <kiko> there's not much in the way of a security framework gina can work with anyway, I suspect.
[06:33] <SteveA> debonzi: classmethods are a problem, because they are not really represented in the interface to an object
[06:33] <SteveA> you have to make an assumption about what the object's class is
[06:33] <SteveA> and that breaks the encapsulation
[06:34] <SteveA> so, the public api should be instance methods, described by interfaces
[06:34] <kiko> I dislike classmethods personally
[06:34] <kiko> in this case there is a good reason not to use one too (self.release.id)
[06:34] <SteveA> note that we're working with interfaces
[06:34] <SteveA> an interface doesn't really say whether something is implemented by an instance method or a class method or what
[06:34] <SteveA> but, seeing as we have a release object, and that object is an instance
[06:35] <SteveA> it is natural to use instance methods to implement the operations needed by the interface
[06:35] <SteveA> does that make sense?
[06:35] <kiko> yes, though there are some weird exceptions in SourcePackage. I'd need to look at that code carefully.
[06:36] <SteveA> if it makes enough sense for the majority of the code, we can convert that to the new way, and look again at any weird things
[06:36] <kiko> my tree is bonkers :-/
[06:36] <kiko> yes, indeed.
[06:36] <SteveA> There is something odd with my tree at the moment I think.  I'm getting a test that always fails, and a test that always hangs.
[06:36] <kiko> this is the way we should go, for sure
[06:36] <SteveA> but I can still merge into RF
[06:37] <kiko> I can't star-merge, I get bucketloads of conflicts and no undo love.
[06:37] <kiko> SteveA, did you get my Zope patch from salgado?
[06:37] <SteveA> I did
[06:37] <SteveA> I read the email, but I haven't thought about it yet
[06:37] <kiko> okay. it's really trivial -- and follows what the code does in that part anyway.
[06:39] <SteveA> ok
[06:39] <SteveA> I'll think about it soon
[06:39] <SteveA> so, who is going to do what with the database code in the soyuz package?
[06:39] <kiko> debonzi and I can handle it
[06:40] <kiko> (if my tree unfuxors itself)
[06:40] <SteveA> ok, cool.  when can you start?
[06:41] <SteveA> daf: around?
[06:42] <daf> SteveA: yes
[06:43] <kiko> SteveA, lemme check current statuspile
[06:43] <SteveA> can we have a chat about rosetta stuff?  did you read what carlos and I talked about earlier today?
[06:43] <daf> I did
[06:43] <SteveA> any comments?
[06:43] <kiko> SteveA, starting monday we can do a review and rehack of these bits
[06:44] <kiko> SteveA, if you want some of it done tomorrow, we can drop the ball on other things
[06:45] <daf> SteveA: I've been working on the import, but have been having problems with the import script which mean it is not done yet
[06:45] <SteveA> kiko: it can be done on monday.
[06:45] <kiko> okay, scheduled
[06:45] <debonzi> SteveA, nice
[06:45] <SteveA> thanks guys
[06:45] <SteveA> daf: what's up?
[06:45] <kiko> debonzi, can you file a bug for me while I unfutz my tree
[06:45] <debonzi> kiko, yep
[06:45] <kiko> thanks.
[06:45] <daf> well, there were some database changes which the scripts hadn't been updated to reflect
[06:46] <daf> and now I am getting error messages which I am still in the process of diagnosing
[06:47] <SteveA> can anyone help you with this?
[06:48] <daf> Carlos might be able to, but he isn't around at the moment
[06:49] <SteveA> can you describe what the first problem is in some more detail?
[06:50] <cprov> BradB: finally something good, do you have time to analize the results of my task ?
[06:50] <daf> Traceback (most recent call last):
[06:50] <daf>   File "./poimport.py", line 168, in ?
[06:50] <daf>     options.potemplate, options.language, True)
[06:50] <daf>   File "./poimport.py", line 95, in update_stats
[06:50] <daf>     poFile = poTemplate.poFile(languageCode)
[06:50] <daf>   File "/home/daf/launchpad-devel/launchpad/lib/canonical/launchpad/database/pofile.py", line 263, in poFile
[06:50] <daf>     raise KeyError, language_code
[06:50] <daf> KeyError: "Couldn't find record in database"
[07:08] (SteveA/#launchpad) daf: do what you think will work best.  but definitely use the debugger
[07:09] (SteveA/#launchpad) is the language table in dogfood the same as the one in rosetta alpha
[07:09] (SteveA/#launchpad) ?
[07:09] (daf/#launchpad) yes, probably
[07:09] (daf/#launchpad) I'll try reporoducing it on my machine
[07:10] (SteveA/#launchpad) why not do a query, and check that they are in fact the same?
[07:10] (SteveA/#launchpad) you have access to both databases
[07:12] <fabbione> ping
[07:12] <fabbione> ok
[07:12] <fabbione> sorry for the introdusion :-)
[07:12] <fabbione> introsion
[07:26] (BradB/#launchpad) damn, looks like i'll be reinstalling. the db restore done verbatim as describe in the email to lp@ blew away all my applications.
[07:26] (kiko/#launchpad) that's crazy
[07:27] (kiko/#launchpad) how did that happen?
[07:27] (BradB/#launchpad) not the faintest clue...
[07:27] (daf/#launchpad) crazy!
[07:50] (lulu/#launchpad) night all :o)
[07:51] (elmo/#launchpad) quick hands up, who's still working?
[07:51] (elmo/#launchpad) seriously, I need to reboot some of the remaining boxes,including mawson, macquarie and emperor - any objections if I do it now? 
[07:51] (kiko/#launchpad) me
[07:51] (kiko/#launchpad) not me
[07:59] (daf/#launchpad) elmo: hmm, should be OK, I think
[08:06] (kiko/#launchpad) daf, what does it mean when tla update sits for hours writing to unlinked files in /tmp?
[08:07] (daf/#launchpad) I don't know
[08:07] (daf/#launchpad) sounds pretty broken, though
[08:07] (kiko/#launchpad) time to nuke my tree?
[08:07] (daf/#launchpad) hmm, perhaps
[08:08] (daf/#launchpad) try asking somebody who knows tla better first, maybe
[08:10] (kiko/#launchpad) hmmm
[08:16] <carlos> hi
[08:21] (elmo/#launchpad) mawson rebooting
[08:27] (kiko/#launchpad) * searching ancestor revision in library in archive kiko@async.com.br
[08:27] (kiko/#launchpad) corrupt library (failed inode signature validation)
[08:27] (kiko/#launchpad)     archive: daniel.debonzi@canonical.com
[08:27] (kiko/#launchpad)     revision: launchpad--devel--0--patch-229
[08:27] (kiko/#launchpad) this is lots of fun!
[08:27] (daf/#launchpad) lies! lies!
[08:28] <carlos> kiko: :-P
[08:29] <carlos> daf: ;-)
[08:29] (kiko/#launchpad) hmmm
[08:29] <carlos> daf: I will be available to talk in about 15 minutes, is it ok for you?
[08:29] (kiko/#launchpad) interesting, it's refueling my revlibs
[08:29] (daf/#launchpad) carlos: ok
[08:34] (elmo/#launchpad) macquarie/emperor 
[08:34] (elmo/#launchpad) + done
[08:35] (kiko/#launchpad) whee
[08:38] (kiko/#launchpad) SteveA, ping?
[08:38] (kiko/#launchpad) daf, do you know why psycopgda and sqlos aren't links to sourcecode?
[08:39] (kiko/#launchpad) or SteveA?
[08:39] (kiko/#launchpad) or carlos 
[08:39] (kiko/#launchpad) or anyone else
[08:40] (kiko/#launchpad) Kinni!
[08:40] (daf/#launchpad) kiko: because they are not compiled?
[08:41] (kiko/#launchpad) hmmm
[08:41] (kiko/#launchpad) is that the only reason? is it a good one?
[08:42] (daf/#launchpad) I think it's reasonable
[08:42] (daf/#launchpad) I don't see any major disadvantages
[08:43] (elmo/#launchpad) it's CRACK
[08:43] (daf/#launchpad) elmo: ?
[08:44] (elmo/#launchpad) it's the same CRACK as people who copy library source into their own projects rather than just linking with it
[08:44] (kiko/#launchpad) it's bizarre to me -- I always need to special-case psycopgda and sqlos into the directory.
[08:44] (elmo/#launchpad) CRACK CRACK CRACK
[08:44] (daf/#launchpad) elmo: they are in separate arch categories
[08:45] (elmo/#launchpad) daf: is psycopg modified at all?
[08:46] (elmo/#launchpad) if not - WTF is it in there?
[08:46] (daf/#launchpad) not psycopg
[08:46] (daf/#launchpad) psycopgda
[08:47] (kiko/#launchpad) I'm more curious about the consistency issue that arises from having bits in sourcecode and bits in lib
[08:47] (kiko/#launchpad) linked to sourcecode
[08:47] (kiko/#launchpad) and other bits not linked
[08:47] (kiko/#launchpad) ugh
[08:47] (daf/#launchpad) consistency is good
[08:47] (sabdfl/#launchpad) BradB|lunch: how do you mean, blew away your applications?
[08:47] (sabdfl/#launchpad) i've found that working with a backup of the dogfood db on my local machine i need to make sure
[08:48] (sabdfl/#launchpad) that i apply the patches to bring the db schema in line with my code
[08:48] (sabdfl/#launchpad) SELECT * FROM launchpaddatabaserevision;
[08:48] (sabdfl/#launchpad) then apply the patches needed to bring the revision up to the level of your code
[08:49] (kiko/#launchpad) daf, in this case, apparent lack of consistency :)
[08:49] (daf/#launchpad) well, if you can fix it, I say go ahead
[08:50] (kiko/#launchpad) I'd move sqlos and psycopgda into sourcecode and link it too. wouldn't you?
[08:53] (kiko/#launchpad) corrupt library (failed inode signature validation)
[08:53] (kiko/#launchpad)     archive: daniel.debonzi@canonical.com
[08:53] (kiko/#launchpad)     revision: launchpad--devel--0--patch-302
[08:53] (kiko/#launchpad) You should remove this revision from your library.
[08:53] (kiko/#launchpad) whee!
[08:54] (sabdfl/#launchpad) wow#
[08:54] (sabdfl/#launchpad) did you know you can tla add a file that does not exist?
[08:54] (sabdfl/#launchpad) and it works?
[08:54] (daf/#launchpad) which definiton of "works" are we using here?
[08:54] (elmo/#launchpad) guys - chinstrap's going down - anyone need it desperately right now ?
[09:00] <carlos> elmo: as soon as it's back soon... ;-)
[09:00] <carlos> daf: I'm ready to talk
[09:01] (elmo/#launchpad) carlos: it's back...
[09:01] <carlos> elmo: perfect, thanks
[09:07] (kiko-fud/#launchpad) lifeless, the email to launchpad is probably one of those you'll say "bah, that's easy" I suspect
[09:16] (SteveA/#launchpad) kiko-fud: we agreed in a launchpad meeting a while ago that these things were going to move into "sourcecode" and out of "launchpad/lib"
[09:17] (SteveA/#launchpad) I never got around to it.  Thanks for bringing it up now.
[09:17] (lifeless/#launchpad) sabdfl: can't do that in baz :)
[09:17] (lifeless/#launchpad) sabdfl: why are u not using baz ?
[09:17] (lifeless/#launchpad) :)
[09:18] (SteveA/#launchpad) daf: how are the imports going?
[09:19] (daf/#launchpad) still trying to reproduce the error on my machine
[09:19] (daf/#launchpad) I have an import running right now
[09:22] (SteveA/#launchpad) did you investigate the error on the server, so that you know exactly what the problem is?
[09:23] (daf/#launchpad) no
[09:23] (SteveA/#launchpad) it would be good to do that -- work out exactly what is wrong on the server.  fix and test on your machine.  that's my suggestion.
[09:23] (SteveA/#launchpad) you can't expect to solve a problem until you know what is wrong.
[09:24] (SteveA/#launchpad) is this something where I can help you, via screen ?
[09:24] (daf/#launchpad) I dont't know how I can test it on my machine before I can get it to fail on my machine
[09:25] (SteveA/#launchpad) it will be easy to get it to fail on your machine once we know exactly what is failing
[09:26] (BradB/#launchpad) sabdfl: in OS X, each user has some kind of copy in their home dir (in ~/Library/Applications or ~/Applications or something) of the apps they install. those all got blown away.
[09:26] (sabdfl/#launchpad) bradb: by what?
[09:26] (BradB/#launchpad) elmo: do netgear 802.11g cards work in powerbooks?
[09:26] (BradB/#launchpad) sabdfl: rm :)
[09:26] (sabdfl/#launchpad) ah
[09:26] (sabdfl/#launchpad) by one of our scripts?
[09:26] (BradB/#launchpad) sabdfl: from following the instructions verbatim to restore a dogfood db
[09:26] (sabdfl/#launchpad) oops
[09:27] (elmo/#launchpad) BradB: I don't know - it's just whether they work on Linux tho - not powerbook specific
[09:27] (BradB/#launchpad) elmo: what do you use?
[09:27] (elmo/#launchpad) cisco aironet
[09:27] (SteveA/#launchpad) elmo: have you prodded the ftp server yet?
[09:28] (elmo/#launchpad) $$$ tho, and it's not 100% on Linux/PowerPC
[09:28] (elmo/#launchpad) SteveA: no, been at the DC all day
[09:28] (elmo/#launchpad) I'll look at it tomorrow, when I'm home
[09:28] (SteveA/#launchpad) ok.  let me know if you have questions about it.
[09:28] (SteveA/#launchpad) daf: I really want the rosetta imports fixed soon. consider me to be at your disposal to help get it sorted, until I go to sleep tonight.
[09:29] (elmo/#launchpad) BradB: looks like modern WG511 uses Atheros chipset, which is the same as the onboard one on modern powerbook's, which means BZZT 
[09:29] (elmo/#launchpad) bradb: (btw, by not 100% don't get me wrong, it works just fine for me, but some features are missing, like the ability to hot plug the card :)
[09:30] (elmo/#launchpad) stevea: will do
[09:30] (BradB/#launchpad) elmo: ah
[09:30] (BradB/#launchpad) hmph
[09:30] (elmo/#launchpad) BradB: mark has some card that limi got working that isn't cisco
[09:31] (elmo/#launchpad) (s/got working/'just works in warty' apparently)
[09:31] (BradB/#launchpad) the place i bought it from mentioned sommet
[09:31] (elmo/#launchpad) I don't recall what  it is tho
[09:31] (BradB/#launchpad) s/bought it/bought my powerbook/
[09:31] (BradB/#launchpad) sabdfl: did you try the store instructions in linux?
[09:32] (daf/#launchpad) SteveA: if I get stuck, I will ask for help
[09:32] (BradB/#launchpad) sabdfl: see, what was really fux0red is that in doing this restore, it ran the test suite more than once too...did all kinds of bizarre things, including blowing away my Applications folder on OS X. I don't even have a bloody terminal anymore, and sshd ain't running, so i can't come in from the outside.
[09:33] (SteveA/#launchpad) daf: I'd like to get involved, and understand what's going on, so I'm ready to help when needed.  what do you think of setting up a screen session?
[09:33] (daf/#launchpad) well, I think I just found the cause of the problem
[09:35] (SteveA/#launchpad) cool!
[09:37] (daf/#launchpad) carlos: around?
[09:43] <carlos> daf: yes
[09:45] (daf/#launchpad) can we discuss POFile.updateStatistics?
[09:47] <carlos> sure
[09:47] (BradB/#launchpad) elmo: can i use my pbg4's not-wireless internet card fine in ubuntu?
[09:48] <carlos> daf: what happens there?
[09:48] <carlos> BradB: the ethernet ?
[09:48] <carlos> BradB: it works here
[09:48] (elmo/#launchpad) BradB: the wired port?  sure
[09:48] <carlos> BradB: the only problem with new powerbooks is the bradcom wireless 
[09:49] (elmo/#launchpad) carlos: and the modem
[09:49] <carlos> elmo: well, I never remember the modem...
[09:49] (elmo/#launchpad) but yeah they got suspend/resume now \o/
[09:49] <carlos> elmo: isn't there a driver to use it?
[09:49] <carlos> a propietary one, I know
[09:49] (BradB/#launchpad) well, the machine i'm on is completely hosed. if i close this instance of x-chat i won't be able to reopen it.
[09:49] (elmo/#launchpad) carlos: only for i386 AFAIK
[09:49] (BradB/#launchpad) everything blown away, can't even send bloody mail anymore.
[09:50] (BradB/#launchpad) going over to other machine to burn warty, which i downloaded while i was out for lunch
[09:50] <carlos> elmo: oh, I thought they are for ppc machines...
[09:51] (daf/#launchpad) carlos: first of all, I'm not clear on the newImport flag
[09:51] (daf/#launchpad) carlos: can you try explaining it to me?
[09:53] <carlos> daf: ?
[09:53] (daf/#launchpad) s/flag/parameter/
[09:54] <carlos> daf: without it, the "current" count will be broken
[09:54] <carlos> because it will take in account the msgsets that where moved from fuzzy to "complete"
[09:55] <carlos> or the ones that were moved from untranslated to fuzzy or  complete
[09:55] (daf/#launchpad) hmm, you're saying things, but my brain is not working
[09:55] <carlos> with it we can control that it will only change when we are importing a new pofile
[09:55] <carlos> daf: X-)
[09:55] <carlos> blah, blah, blah, blah...
[09:56] <carlos> daf: should I improve the explanation?
[09:56] <carlos> or just wait for your brain?
[09:56] (daf/#launchpad) what does "current" mean?
[09:56] <carlos> pofile.current
[09:57] <carlos> the number of translated strings in last .po import
[09:57] (daf/#launchpad) biab, workraving
[09:58] <carlos> ok
[10:15] (daf/#launchpad) let's try again
[10:16] (daf/#launchpad) so, we have thre states?
[10:16] (daf/#launchpad) current, updated, rosetta?
[10:16] <carlos> yep
[10:17] <carlos> and updated is not working correctly with current schema (or I don't know how to fix it)
[10:17] <carlos> current == translated messages from latest .po imported
[10:17] (daf/#launchpad) oh, is there a bug open about that?
[10:17] <carlos> updated == messages that were already translated but were updated from rosetta
[10:18] <carlos> rosetta == messages that were fuzzy or untranslated and we finished them from rosetta (and they were not imported again with a new po import)
[10:18] <carlos> daf: no, I just noticied after read my comment in the code
[10:18] (daf/#launchpad) and these states are mutually exclusive?
[10:18] <carlos> no
[10:19] <carlos> current and rosetta are
[10:19] <carlos> current and updated are not
[10:19] <carlos> hmm
[10:19] <carlos> sorry
[10:19] <carlos> forget that
[10:19] <carlos> yes, the states are mutually excusive
[10:19] (daf/#launchpad) ok, could you add a comment saying so?
[10:19] <carlos> a updated string cannot be in rosetta
[10:20] <carlos> daf: in the fields declaration or in the updateStatistics method?
[10:20] (daf/#launchpad) either, both
[10:20] <carlos> ok
[10:20] (daf/#launchpad) the code, for sure
[10:20] <carlos> I think it's defined in the interface
[10:20] <carlos> let me check
[10:21] (daf/#launchpad) or perhaps we should have more comprehensive documentation about statistics separately
[10:23] <carlos> def currentCount(language=None):
[10:23] <carlos>         """Returns the number of msgsets matched to a potemplate for this
[10:23] <carlos>         project that have a non-fuzzy translation in its PO file for this
[10:23] <carlos>         language when we last parsed it."""
[10:23] <carlos>     def updatesCount(language=None):
[10:23] <carlos>         """Returns the number of msgsets for this project where we have a
[10:23] <carlos>         newer translation in rosetta than the one in the PO file for this
[10:23] <carlos>         language, when we last parsed it."""
[10:23] <carlos>     def rosettaCount(language=None):
[10:23] <carlos>         """Returns the number of msgsets where we have a translation in rosetta
[10:23] <carlos>         but there was no translation in the PO file for this language when we
[10:23] <carlos>         last parsed it."""
[10:24] (daf/#launchpad) ok, I'm still trying to grasp this parameter
[10:25] <carlos> the main idea is
[10:25] (daf/#launchpad) when do you use it, when do you not use it?
[10:25] <carlos> when you import a new pofile, the numbers could change a lot
[10:25] <carlos> it's used only when you import a new pofile
[10:26] (daf/#launchpad) as opposed to?
[10:26] <carlos> when you translate from rosetta and add a new string
[10:26] (daf/#launchpad) is it an optimisation?
[10:26] <carlos> so you only need to recalculate updates and rosetta
[10:26] <carlos> no
[10:27] <carlos> in fact I don't think it should be called if it's not after an import 
[10:27] <carlos> I mean
[10:27] <carlos> that method should only called after a new import
[10:27] <carlos> or if the statisticis cache could be out of sync
[10:27] (daf/#launchpad) what happens if you call it and you haven't done an import?
[10:27] <carlos> in which case the argument you don't like comes in the game
[10:28] <carlos> if the argument tells you that it's not an import
[10:28] (daf/#launchpad) well, I'm not sure whether I don't like it yet, I need to understand it first :)
[10:28] <carlos> the updates and rosetta fields will be updated
[10:28] <carlos> the current field will remain the same because there were not new imports
[10:28] (daf/#launchpad) so it is an optimisation?
[10:29] <carlos> the method itself no
[10:29] <carlos> the fields, yes
[10:29] (daf/#launchpad) I mean the parameter
[10:29] <carlos> why?
[10:29] <carlos> if you execute it without a poimport the values will be broken
[10:29] (daf/#launchpad) well, you are trying to save some work by not always recalculating the current field, right?
[10:30] <carlos> no
[10:30] (daf/#launchpad) oh
[10:30] <carlos> you cannot calculate the current field when you get a new translation from rosetta
[10:30] (daf/#launchpad) why not?
[10:30] <carlos> because the information is lost
[10:30] <carlos> (the fuzzy flag)
[10:31] <carlos> you cannot know if it was fuzzy or untranslated
[10:31] <carlos> that's why I suggested to move the fuzzy flag from msgset to the sighting 
[10:31] (kiko/#launchpad) SteveA, should I file a bug on you?
[10:31] <carlos> so we don't lose that information
[10:31] (daf/#launchpad) ok, I didn't realise that
[10:31] <carlos> well, we could lose it that why also
[10:32] <carlos> but it's less usual
[10:32] <carlos>  /s/why/way/
[10:32] (daf/#launchpad) don't we have information on the origin of a translation?
[10:32] <carlos> not really
[10:32] <carlos> you add a new translation from rosetta
[10:32] <carlos> then export a po file
[10:32] <carlos> and reimport it again
[10:32] <carlos> the origin will be rosetta
[10:33] <carlos> but it was in the po file
[10:33] (daf/#launchpad) argh
[10:33] <carlos> daf: funny, isn't it?
[10:33] <carlos> :-)
[10:33] (daf/#launchpad) this is annoying :(
[10:33] (SteveA/#launchpad) kiko: sure, thanks
[10:34] <carlos> daf: do you want I work on a proposal so we don't lose any information?
[10:34] (daf/#launchpad) hmmm
[10:38] (daf/#launchpad) I don't like the fact that I have a hard time understanding our database code
[10:38] (daf/#launchpad) I would like to fix that
[10:38] (daf/#launchpad) not just the code, but the schema also
[10:39] <carlos> daf: the dia image is a good start point
[10:39] (daf/#launchpad) well
[10:39] <carlos> but I think it's obsoleted, we should update it
[10:39] (daf/#launchpad) that's a good conceptual view
[10:39] (daf/#launchpad) but if I want to know "how are statistics updated?", it's not much use
[10:40] <salgado> lifeless, rsyncing worktrees will trigger that "corrupt library" error because of the pristine tree located inside it, right?
[10:40] (daf/#launchpad) carlos: ok, let's sidetrack for a moment
[10:40] (daf/#launchpad) when you import a PO template, how are statistics updated?
[10:40] (lifeless/#launchpad) you will only have pristines inside a working tree if you don't have a greedy revlib, and everyone should have a greedy, sparse, revlib.
[10:40] <carlos> daf: well, we don't have a policy about how to update the statistics...
[10:41] (daf/#launchpad) what do you mean by "policy"?
[10:41] <carlos> daf: we need to define that procedure
[10:41] (daf/#launchpad) I mean
[10:41] <carlos> daf: I just finished the script lalo started 
[10:41] (daf/#launchpad) is there a function somewhere that updates the statistics for a template?
[10:41] <carlos> that does not mean we have documented or defined a way to update the statistics
[10:42] <carlos> daf: no
[10:42] (daf/#launchpad) ok
[10:42] <carlos> daf: and now that you talk about it...
[10:42] <carlos> daf: is not doable with the current schema
[10:43] <salgado> lifeless, ok, so i'll have no problems. I already have sparse and greedy revlibs
[10:44] (daf/#launchpad) lifeless: "{tla,baz} get" doesn't create a pristine if the revision you're getting is in the revlib?
[10:44] (lifeless/#launchpad) right
[10:44] (daf/#launchpad) carlos: why not?
[10:45] (lifeless/#launchpad) and if the revlib is greedy, it will add it to the revlib rather than making a pristine in the project tree.
[10:45] (daf/#launchpad) carlos: same sort of problem as before?
[10:45] <carlos> daf: yes, I just noticied it
[10:46] <carlos> daf: if we don't have the original data that was imported, the current value cannot be updated
[10:46] (daf/#launchpad) hmm
[10:47] (daf/#launchpad) hmm, rosetta-states.dia is a good idea, but I think it needs updating
[10:47] <carlos> rosetta-states?
[10:47] <carlos> what's that?
[10:48] (daf/#launchpad) lib/canonical/rosetta/docs/rosetta-states.dia
[10:49] <carlos> yep, it should be updated with more info
[10:49] (daf/#launchpad) suggestion: we have an RST or DocBook document in docs/ which has information on this sort of thing
[10:49] (daf/#launchpad) of course, it'll only work if we keep it up to date :)
[10:50] (daf/#launchpad) but we have some documentation in the wiki, and we have some documentation in docs/
[10:50] (daf/#launchpad) it would be good to bring it together
[10:50] (daf/#launchpad) so we can have cross-references
[10:51] <carlos> I don't know anything about RST
[10:51] (daf/#launchpad) DocBook?
[10:51] <carlos> so we move from wiki to docs/?
[10:51] <carlos> daf: yes, I know docbook
[10:51] (daf/#launchpad) yeah, me too
[10:51] (daf/#launchpad) RST is very simple, though
[10:52] (daf/#launchpad) yeah, I like the idea of keeping the docs and the code close together
[10:52] <carlos> daf: what do you think that fits better to our needs
[10:52] (daf/#launchpad) it's easier to update both at the same time, then
[10:52] <carlos> I don't have any problem learning new formats
[10:52] (daf/#launchpad) I think either format would work
[10:52] (daf/#launchpad) my personal preference is for DocBook
[10:52] <carlos> same here
[10:52] <carlos> docbook with xml templates
[10:52] (daf/#launchpad) ok, let's open a bug on this
[10:53] (daf/#launchpad) ah, except Malone is down
[10:53] (daf/#launchpad) I'll do it later
[10:53] <carlos> is down?
[10:53] (daf/#launchpad) yeah, maybe it didn't come back after the reboot
[10:54] <carlos> right, the reboot
[10:54] <carlos> :-)
[10:55] <salgado> lifeless, is it possible to share a revlib between multiple arch users, using baz?
[10:55] (daf/#launchpad) BradB|osx: who can bring the dogfood back up?
[10:56] (lifeless/#launchpad) yes and no. if the permissions on your files allows it, and you don't hit race conditions, them yes. but its not guaranteed, and not supported.
[10:56] (kiko/#launchpad) BAZ ROX
[10:56] (kiko/#launchpad) hmmm
[10:56] <salgado> kiko, so, I think it's not a good idea
[10:57] (kiko/#launchpad) lifeless, will it ever be supported? it would mean significant savings for us..
[10:57] (lifeless/#launchpad) kiko: its not possible in general. So supporting it is hard.
[10:57] (lifeless/#launchpad) its not possible because...
[10:57] (lifeless/#launchpad) say I have a file thats mode 0700.
[10:57] (lifeless/#launchpad) its in my revlib with that mode. Now, HTF can that be shared ?
[10:58] (kiko/#launchpad) I see.
[10:59] (daf/#launchpad) hmm, so it would only be possible if the on-disk permissions were separate from the revision permissions
[10:59] (kiko/#launchpad) you'd need some intelligent revlib service.
[10:59] (daf/#launchpad) well, it could be quite dumb
[10:59] <carlos> daf: ok, returning to more urgent things... can I help you with the pot/po imports?
[10:59] (kiko/#launchpad) from which you requested the files and then synthesized them into the correct perms.
[10:59] (daf/#launchpad) carlos: once I fix this bug in poimport.py, probably
[11:00] (daf/#launchpad) carlos: the bug is: it calls update_stats() when language is None
[11:00] <carlos> hmm
[11:00] <carlos> really?
[11:00] (daf/#launchpad) yeah
[11:00] <carlos> let me check I don't forgot to deactivate some "debug" changes I did...
[11:01] (lifeless/#launchpad) kiko: its doable, but it makes it a lot more complex, even for the dumb case. That said, we have to do some stuff in this area anyway, I'll certainly try not to make it worse than it is.
[11:01] <carlos> daf: ok, my fault, I forgot to commit a fix for that
[11:01] (daf/#launchpad) yeah?
[11:02] (daf/#launchpad) there are a few changes I'd like to make to that script
[11:02] <carlos> daf: could you check it this way?:
[11:02] <carlos> print "Importing %s ..." % options.file
[11:02] <carlos>             bridge.imports(person, in_f, options.project, options.product,
[11:02] <carlos>                            options.potemplate, options.language)
[11:02] <carlos>             if options.language is not None:
[11:02] <carlos>                 print "Updating %s pofile for '%s'..." % (
[11:02] <carlos>                     options.potemplate, options.language)
[11:02] <carlos>                 bridge.update_stats(options.project, options.product,
[11:02] <carlos>                                     options.potemplate, options.language, True)
[11:02] (daf/#launchpad) ah, looks good
[11:03] <carlos> daf: will you commit that change or should I do it?
[11:03] (daf/#launchpad) well, easier for you to do it, I think
[11:04] (daf/#launchpad) so go ahead
[11:04] <carlos> ok
[11:04] <BradB|osx> daf: stub
[11:04] (daf/#launchpad) garh
[11:04] (daf/#launchpad) we need to serviceify launchpad
[11:05] <BradB|osx> i've already filed a bug on that (at least the part about making it run gracefully as a deamon)
[11:06] (daf/#launchpad) groovy
[11:11] <carlos> daf: merge request sent
[11:11] (daf/#launchpad) thanks
[11:13] (daf/#launchpad) SteveA: there's a class here that inherits from PlacelessSetup -- what does that mean?
[11:22] (SteveA/#launchpad) where is "here" ?
[11:22] (SteveA/#launchpad) PlacelessSetup is a mixin class used in zope3 unit tests
[11:22] (daf/#launchpad) in lib/canonical/rosetta/scripts/poimport.py
[11:23] (SteveA/#launchpad) it sets up and tears down the framework such as the adapters service and utilities services
[11:23] (daf/#launchpad) this class is not calling its superclass's __init_ or anything
[11:23] (SteveA/#launchpad) that code is a mess
[11:24] (daf/#launchpad) yes :(
[11:24] (SteveA/#launchpad) at first glance, the PlacelessSetup is a decoy
[11:25] (daf/#launchpad) ok, I'll try removing it and seeing if it still works
[11:25] (SteveA/#launchpad) also,
[11:25] (SteveA/#launchpad) move all of the stuff in the if __name__ == '__main__': section at the end into a main() function
[11:25] (daf/#launchpad) I don't see the point of the exception munging either
[11:25] (SteveA/#launchpad) then split out the option parsing part into a parse_options() part
[11:25] (daf/#launchpad) yes, good idea
[11:25] (daf/#launchpad) I don't want to make too many changes before I've merged carlos's changes to this file
[11:26] (SteveA/#launchpad) ok
[11:26] (daf/#launchpad) (which should allow imports to work again)
[11:26] (SteveA/#launchpad) and it should be formatted more like pop8
[11:26] <carlos> daf: it's a trivial change, so it should not be too difficult
[11:26] (SteveA/#launchpad) pep8
[11:26] (daf/#launchpad) what formatting is lax?
[11:27] (SteveA/#launchpad) line 42 is too long
[11:27] (SteveA/#launchpad) line 46 is a mess
[11:27] (daf/#launchpad) right
[11:27] (SteveA/#launchpad) another issue is the try:except: around line 46
[11:27] (SteveA/#launchpad) it is around way too much
[11:28] (SteveA/#launchpad) it should be around the absolute minimum
[11:28] (daf/#launchpad) I'm thinking of getting rid of the try/except completely
[11:28] (SteveA/#launchpad) and even better, it shoudl use a check of the length of the results
[11:28] (SteveA/#launchpad) rather than half expecting an index error
[11:28] (SteveA/#launchpad) just sloppy programming
[11:29] (SteveA/#launchpad) lines 61 onwards -- bad formatting
[11:29] (SteveA/#launchpad) not sure what it's doing in the except: clause anyway
[11:29] (SteveA/#launchpad) and incoprehensible XXX comments
[11:30] (SteveA/#launchpad) there's more, but I'll stop there
[11:31] (SteveA/#launchpad) ok, so you reckon that when you're done with fixing this code, you can do the imports
[11:31] (SteveA/#launchpad) and the dogfood stuff will be done
[11:31] (daf/#launchpad) and the virtual hosting
[11:31] (SteveA/#launchpad) ok
[11:32] (SteveA/#launchpad) great
[11:33] (SteveA/#launchpad) I must go to sleep now.  please send me an email to let me know how it goes
[11:33] <carlos> SteveA: night
[11:33] <carlos> daf: if you are going to improve the script, could you do it in a way I could use importing it from other scripts?
[11:34] (daf/#launchpad) SteveA: sure, thanks
[11:34] (daf/#launchpad) carlos: yeah, I like that
[11:34] <carlos> daf: thanks
[11:38] (daf/#launchpad) hmm, the merge seems to be taking a long time...
[11:38] <carlos> it was just a line change...
[11:39] (daf/#launchpad) lifeless: did PQM come back up after the reboot?
[11:40] <carlos> daf: the merge is done here
[11:40] <carlos> I got the confirmation mail
[11:40] (daf/#launchpad) ah
[11:40] <carlos> I thought you were talking about the star-merge
[11:41] (daf/#launchpad) did dilys announce it?
[11:41] <carlos> daf: I don't think so
[11:41] (daf/#launchpad) grr
[11:42] (lifeless/#launchpad) daf: pqm is cron based, it always comes up
[11:42] <carlos> daf: dilys needs some love, he miss you since you went to NY :-P
[11:42] (daf/#launchpad) carlos: heh
[11:42] (daf/#launchpad) I'll spend some time with her later
[11:42] (daf/#launchpad) I'm going out right now
[11:43] (daf/#launchpad) I'll carry on working on the imports later
[11:43] <carlos> daf: could you CC: to me the mail about the import status?
[11:43] (daf/#launchpad) sure
[11:43] (daf/#launchpad) later!
[11:43] <carlos> Steve always asks me but I don't know what to answer because I go to sleep 
[11:43] <carlos> daf: thanks
[11:43] <carlos> daf: later!