[12:15] <lifeless> Sp4rKy: what do you want to do ?
[12:16] <Sp4rKy> lifeless, mainly, i want added my own package to a LP team
[12:16] <Sp4rKy> but packages are not in ubuntu but in a personal repository
[12:17] <lifeless> the source for the packages, or the binaries ?
[12:17] <Sp4rKy> so i think i can't added them and link them to their maintainers , right ?
[12:17] <Sp4rKy> twice
[12:17] <lifeless> well I dont understand quite what you are talking about yet
[12:17] <Sp4rKy> ok ..
[12:17] <Sp4rKy> so, i've create a team on launchpad
[12:18] <Sp4rKy> this team provide a repository for E17 
[12:18] <lifeless> that will be at sftp://bazaar.launchpad.net/~TEAMNAME/PRODUCT
[12:18] <lifeless> where TEAMNAME is your team name
[12:19] <Sp4rKy> i want add the packages which are on this repository on lp , link this with their maintainers
[12:19] <Sp4rKy> ok
[12:19] <lifeless> and PRODUCT is the e17 product name in launchpad
[12:19] <lifeless> whatever that is
[12:19] <Sp4rKy> can't i add the package with an other way than bazaar ?
[12:19] <lifeless> this is what I dont understand
[12:19] <lifeless> packages != bazaar
[12:20] <lifeless> when you say 'package' what *precisely* do you mean
[12:20] <Sp4rKy> yes i know
[12:20] <Sp4rKy> source packages and binary packages
[12:20] <lifeless> ok, nothing to do with bazaar directly. Ubuntu uses Bazaar to manage the *source* for the source package
[12:20] <Sp4rKy> if it is possible, i want added them to lp without using bazaar, 
[12:21] <Sp4rKy> lifeless, yes, but can i add my packages without bazaar to lp
[12:21] <lifeless> I think you probably need to talk with #ubuntu-motu
[12:21] <Sp4rKy> i've done
[12:21] <lifeless> because I dont understand what 'add packages to lp' /means/
[12:21] <crimsun> it's unclear what you're attempting to do.
[12:21] <Sp4rKy> ok
[12:21] <Sp4rKy> i explain again
[12:21] <lifeless> give me a URL for instance, that you want to have work which does not today
[12:22] <Sp4rKy> (i'm sorry i'm french and my english isn't perfect at all)
[12:22] <Sp4rKy> i've a repository at edevelop.org
[12:22] <Sp4rKy> this repository contains packages for e17 over ubuntu
[12:22] <lifeless> what sort of repository ?
[12:23] <lifeless> is it an APT repository ? or a bazaar repository ?
[12:23] <Sp4rKy> apt repository
[12:23] <Sp4rKy> so i would add packages which are on this repository on lp
[12:23] <lifeless> what do you mean by 'add packages to lp'
[12:23] <Sp4rKy> like it's done with packages which are on ubuntu repository
[12:24] <Sp4rKy> lifeless, if i go on my personal lp page , i can see the list of packages i maintain in Ubuntu
[12:24] <Sp4rKy> https://launchpad.net/people/maxenced/+packages
[12:24] <lifeless> Sp4rKy: ok. now we are getting somewhere.
[12:24] <lifeless> that list is made by launchpad scanning the Ubuntu *distribution*
[12:25] <Sp4rKy> i would add the packages i maintain on edevelop repository in the same way
[12:25] <lifeless> your repository is not scanned by launchpad
[12:25] <Sp4rKy> yes i know
[12:25] <lifeless> and cannot be at this point
[12:25] <Sp4rKy> ok .
[12:25] <Sp4rKy> this is my question :)
[12:26] <Sp4rKy> so is there any other way for manage my repository on lp ?
[12:26] <lifeless> there is a feature in development called personal package archives
[12:26] <lifeless> where launchpad will provide build daemons and host the repository
[12:26] <Sp4rKy> k (raphink talked me about that)
[12:27] <Sp4rKy> lifeless, i don't need host and build daemon, but just manage package/ maintainers
[12:28] <lifeless> you should talk to malcc and cprov
[12:28] <lifeless> they are the soyuz folk
[12:28] <Sp4rKy> are they sleeping ?
[12:28] <lifeless> I cannot say what they are planning to do or not in the future
[12:28] <HaDeS> wenas
[12:28] <lifeless> malcc is on uk time
[12:28] <Sp4rKy> ok
[12:28] <lifeless> cprov on brazilian
[12:28] <Sp4rKy> :)
[12:29] <Sp4rKy> lifeless, ok, so at this time, there is no way to manage packages with lp ?
[12:29] <Sp4rKy> even with bazaar ?
[12:29] <lifeless> if by package you mean an apt repository the only way is as a distribution
[12:29] <lifeless> bazaar is a VCS - see bazaar-vcs.org
[12:30] <Sp4rKy> ok
[12:30] <Sp4rKy> i'd seen it
[12:30] <Sp4rKy> but don't really understand how i can add my apt repository
[12:32] <lifeless> bazaar has nothing to do with apt
[12:32] <lifeless> I dont know why you keep bring up bazaar at all. 
[12:32] <lifeless> its for managing *source code*
[12:32] <Sp4rKy> k
[12:32] <lifeless> you can use it to manage the *source code* you are making
[12:32] <Sp4rKy> so i can't manage my repository with lp at this time 
[12:32] <lifeless> I've already answered that
[12:33] <Sp4rKy> lifeless, this is not the idea, 
[12:33] <lifeless> sorry, I am getting frustrated here
[12:33] <Sp4rKy> :)
[12:33] <Sp4rKy> sorry
[12:33] <Sp4rKy> raphink, said me i can try using bazaar for manage my package 
[12:33] <lifeless> Asking the question differently will not change the answers I have to give you
[12:33] <Sp4rKy> so i try to get more info :)
[12:33] <Sp4rKy> lifeless, i kno
[12:33] <Sp4rKy> w
[12:33] <Sp4rKy> thx for your help
[12:33] <LarstiQ> Sp4rKy: yes, for when you work on the debian/ packaging
[12:33] <lifeless> bazaar is great for managing the *source code* for your package, but nothing to do with the +packages stuff in launchpad
[12:34] <LarstiQ> _not_ for the result of building a .deb
[12:34] <Sp4rKy> lifeless, ok
[12:34] <oohlaf> lifeless: who can I contact to change a setting in vcs-import setting for a project on LP?
[12:34] <lifeless> oohlaf: ddaa
[12:34] <LarstiQ> oohlaf: ddaa
[12:34] <lifeless> oohlaf: who is on -users and will read it
[12:34] <lifeless> but feel free to nag him here
[12:34] <oohlaf> oki
[12:35] <oohlaf> he's prob asleep now, he is also on CET right?
[12:35] <Sp4rKy> lifeless, i'll wait for personal package archive so ...
[12:35] <Sp4rKy> thx again
[12:41] <PenguinOfDoom> How do I search the entire bug database?
[12:42] <PenguinOfDoom> oh, found it
[12:42] <PenguinOfDoom> launchpad is quite a maze :P
[02:07] <Fujitsu> Nice.
[02:07] <HaDeS_hack> nice
[02:09] <lifeless> score!
[02:10] <lifeless> mpt: which one ?
[02:10] <mpt> lifeless, reported bug 59846 about it
[02:10] <lifeless> uhm
[02:10] <lifeless> it may not be  abug
[02:10] <lifeless> what bug were you trying to look at
[02:11] <Fujitsu> It's probably marked private...
[02:11] <mpt> bug 31287
[02:11] <Fujitsu> Erm.
[02:11] <lifeless> yup
[02:11] <lifeless> its private
[02:11] <Fujitsu> I can't see bug 59846.
[02:11] <lifeless> and theres no subscribers
[02:11] <Fujitsu> Ah.
[02:11] <lifeless> other than spiv
[02:11] <Fujitsu> It is private...
[02:12] <lifeless> mpt: the security contact for lp is not subscribed to 31287
[02:12] <mpt> So, that's still a bug
[02:12] <mpt> The security contact should still be able to view it, right?
[02:12] <lifeless> dunno
[02:13] <lifeless> it makes sense to me that the security contact should be able to by default
[02:13] <lifeless> but if they are unsubscribed, why should they see it anymore ?
[02:14] <mpt> Why shouldn't they?
[02:14] <lifeless> I asked first ;)
[02:14] <mpt> ok
[02:15] <mpt> Because letting them see it any more doesn't disclose it to anyone new
[02:15] <lifeless> mmm, too much context switching
[02:15] <lifeless> do you need access to this bug ?
[02:15] <lifeless> I can subscribe the security contact or whatever you need
[02:15] <lifeless> after that I' going back to deep hack mode
[02:16] <mpt> I can't remember why I tried to open it, and immediate access isn't the point
[02:16] <mpt> but thanks for clarifying the issue, I'll update my bug report
[02:20] <mpt> yay for Proxy Errors
[02:41] <Ubugtu> New bug: #59846 in malone "Bug 31287 is mysteriously forbidden" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59846
[02:46] <mpt> lifeless, are you able to kick staging?
[02:46] <lifeless> one sec
[02:57] <jamesh> lifeless: you should be able to set the productseries branches for bzr on staging.launchpad.net now, btw
[03:06] <lifeless> mpt: there are no processes running on staging
[03:06] <lifeless> it looks deliberately shutdown
[03:12] <lifeless> mpt: is that better ?
[03:15] <mpt> lifeless, not really, https://staging.launchpad.net/ gives me an Oops :-)
[03:16] <lifeless> I'm shutting it back down
[03:16] <lifeless> stub should look at this, I'm not aware of specific instructions, but I dont have cycles right now to dig into it either
[03:17] <mpt> ok, thanks
[03:25] <jamesh> you sure it wasn't in the middle of a DB restore?
[03:28] <lifeless> fairly, but not completely
[03:28] <lifeless> which is why its shutdown again
[04:25] <jamesh> lifeless: hopefully we'll get another report on product-release-finder today
[05:02] <jamesh> spiv: how was the holiday?
[05:05] <spiv> jamesh: fun, despite the stitches in the back of my head :)
[05:05] <jamesh> ouch
[05:10] <WebMaven> spiv: I noticed you were on the list of contributors to SQLOS.
[05:11] <WebMaven> spiv: AYT?
[05:12] <spiv> Heh, am I?  It's been a while...
[05:13] <SEJeff> Can I close a bug in lp if I am not the maintainer? Some glaring ones that I just commented on like this which I am trying to triage: https://launchpad.net/distros/ubuntu/+source/compiz/+bug/31925
[05:13] <Ubugtu> Malone bug 31925 in compiz "Please package new upstream version" [Wishlist,Unconfirmed]  
[05:18] <jamesh> SEJeff: if you click on the package name in the "Affects" table at the top, you can change the status
[05:38] <SEJeff> jamesh: thankyou
[05:52] <jamesh> spiv: any progress on getting spiv/launchpad/ddaa's-branch-ui merged?
[06:52] <jamesh> stub: would it be possible to see the log of the staging.lp.net product-release-finder runs done in the last few days?
[06:52] <jamesh> I'm interested to see if they succeed yet
[07:19] <stub> jamesh: https://lists.ubuntu.com/mailman/private/launchpad-error-reports/
[07:19] <stub> The reports are in jubany's nightly.sh
[07:20] <stub> https://lists.ubuntu.com/mailman/private/launchpad-error-reports/Week-of-Mon-20060904/038384.html
[07:21] <jamesh> stub: could you approve my subscription to that list?
[07:23] <stub> jamesh: done. You might want to turn off mail delivery or subscribe to only the topics you want.
[07:23] <jamesh> thanks
[07:29] <jamesh> stub: the last run doesn't appear to have been with the latest code.  I guess I'll wait til today's run is done
[07:59] <stub> asuka's nightly.sh is running right now
[07:59] <stub> product-release-finder.py has been running for two hours now. Hopefully that is a good sign ;)
[08:00] <jamesh> does sound good
[08:02] <jamesh> the speed could probably be improved by scanning multiple tarball repos in parallel
[08:02] <jamesh> at the moment it is all in a single thread
[08:09] <stub> I would have assumed the bottleneck was downloading
[08:09] <jamesh> yep
[08:10] <jamesh> and I'm sure we could download stuff from ftp.gnome.org and ftp.debian.org in half the time if done in parallel
[08:10] <jamesh> given the bandwidth of the datacentre
[08:11] <stub> mmm
[08:12] <jamesh> anyway, the fact that it hasn't crapped out yet is a good sign that it'll get all the way through
[08:12] <stub> Will it only be the initial run that will be slow?
[08:12] <stub> (for some value of slow we don't know yet ;) )
[08:13] <jamesh> if it starts with a clean DB every night, yes
[08:13] <jamesh> or maybe not if the datacentre proxy caches the files between runs
[08:14] <jamesh> once the production DB has some of this data, the staging runs won't be starting with a clean slate
[08:14] <jamesh> so should be faster
[08:19] <stub> It sounds like speed is probably not an issue then. Doesn't matter if the initial run takes a week if subsequent runs happen in an hour or less.
[08:21] <jamesh> the way to test that would be to do another run on staging without a clean DB
[08:21] <stub> morning. Any chance to play on the new server yet?
[08:22] <carlos> morning
[08:33] <SteveA> good morning
[08:35] <SteveA> stub: http://www.zope.org/Collectors/Zope3-dev/706   seen it?  a minor sessions infrastructure bug.
[08:36] <stub> Not seen it. I've never worked out how to drive the collector and only have read access anyway.
[08:37] <stub> Doesn't look like a problem worth caring about
[08:38] <stub> But I can't comment as far as I can see :-(
[08:39] <SteveA> hmm
[08:39] <SteveA> ask jim for access sometime
[08:39] <SteveA> or, maybe they'll be using launchpad by then ;-)
[08:40] <SteveA> stub: what do we do nowadays if someone registers a new product, but they didn't mean to do so?
[08:40] <stub> We flag it as inactive
[08:40] <stub> I don't know if they can do it themselves or not - probably not.
[08:41] <stub> (or else people will go around removing products they don't want to use with Launchpad, but we still want the data displayed as a registry)
[08:41] <SteveA> there are no bugs, support requests, translations etc.
[08:41] <SteveA> just the product and two series
[08:41] <stub> Sure. flag it as inactive.
[08:42] <SteveA> ok, done
[08:42] <SteveA> what happens to its name?
[08:42] <stub> One day we will have the technology to delete the simple cases, but for the time being just flag 'em as inactive.
[08:42] <SteveA> I mean, can another product be registered with the same name?
[08:42] <stub> name is still taken, so we can rename them at the same time as flagging them inactive if we need it.
[08:43] <stub> Eventually, I think we need some sort of garbage collector. eg. Product x has been inactive for 3 months so we can now safely delete all the translations, bugs, series, branches etc. associated with it.
[08:43] <stub> Although even that is scary (trashing branches might be too far)
[08:43] <SteveA> hmm, I can't rename it, as I can't get to a URL for it
[08:44] <stub> ok. So we need to remember to rename first ;0
[08:44] <stub> What name product? I'll do it on the db
[08:44] <SteveA> would you rename the inactive product 'firebird' to 'firebird-inactive' ?
[08:44] <stub> Done
[08:45] <jamesh> or you could reactivate the old product
[08:48] <SteveA> ta
[08:49] <SteveA> jamesh: thanks for mailing about the validate() issue.  I replied with a couple of things to think about.
[08:49] <stub> jamesh: Can't reactivate via the web as the product page gives a 404 ;)
[08:49] <SteveA> I haven't really thought them through , though
[08:49] <SteveA> I wonder if either of the other options would be easier to write validate() methods for
[08:49] <SteveA> and not make the kind of mistake you describe happening
[08:52] <stub> actually, that collector bug is valid. If auth credentials are stored in the session and a user walks away from their terminal for a few hours, then it may be possible to visit some urls (ones that cause a transaction abort) using the old auth and obtain a window where the auth credentials remain valid even though in theory the credentials should have expired.
[08:57] <jamesh> SteveA: I am not sure a special "missing value" entry in the data dictionary would reduce OOPS reports -- it might just change them from KeyErrors to other errors caused by not checking if the value was the special "missing value" object
[08:58] <SteveA> ok
[08:58] <SteveA> so in that case, maybe a standard test for forms can be
[08:58] <SteveA>  - pass into validate() a non-empty non-full dict
[08:59] <SteveA> so a dict that doesn't match
[08:59] <SteveA>   if not D:
[08:59] <SteveA> but that doesn't contain anything the validate() method wants
[09:00] <jamesh> it'd be pretty easy to add that to the LaunchpadFormView test harness.
[09:00] <jamesh> pass in a dictionary of form values, and have it test each combination of present values against the validate() routine
[09:00] <jamesh> point out which combinations result in an exception
[09:01] <SteveA> nice
[09:01] <jamesh> this would be applicable even with the "missing value" object idea -- just replace entries with missing value instead of deleting them
[09:04] <SteveA> well, I'm not sure about the value of putting "missing value" into the dict
[09:05] <SteveA> that might just encourage people to test for None rather than consulting field.missing_value
[09:05] <SteveA> the point is to make a change that prevents the problem you described happening, which doesn't increase what the review team have to do
[09:05] <SteveA> I think a standard test harness would help there
[09:05] <SteveA> if there is no API change that would help
[09:14] <BjornT> there's one api change that i could think of that would help, not sure if things get easier though.
[09:15] <BjornT> instead of having a general validate() function, it could be nice to register separate validate functions for each field tuple you want to validate
[09:16] <BjornT> so you could say that i want to validate field A and B, and that validate function would only be called if A and B validated properly by themselves.
[09:16] <jamesh> that's an interesting idea
[09:16] <jamesh> e.g. @validator('owner', 'product', 'name') def validate_branch_name(self, owner, product, name)
[09:17] <BjornT> yeah, something like that.
[09:18] <jamesh> the above syntax would also get rid of the direct dict lookups too
[09:21] <SteveA>  @validator(*ISchema.names()) def validate_schema(names, in, alphabetical, order):
[09:24] <SteveA> stub: call?
[09:25] <BjornT> i think it would be more intuitive to have the method parameters in the same order as the appear in @validator(...)
[10:19] <SteveA> BjornT: yes, and that's why my silly example would work (except I forgot the 'self')
[10:19] <SteveA> because interface.names() is sorted
[10:24] <SteveA> lifeless: is there meant to be a bzr meeting today?
[10:28] <BjornT> SteveA: well, interface.names() isn't sorted, is it? afaik, it simply builds a dict and return the keys, so the output should be completly unsorted.
[10:30] <SteveA> i think it is meant to be sorted
[10:31] <SteveA> hmm, the interface doesn't say anything abot it
[10:31] <SteveA> so, I guess it would need to be sorted()
[10:37] <lifeless> SteveA: AFAIK yes
[10:55] <jamesh> stub: product-release-finder is still running?
[10:58] <stub> jamesh: Yes - still running
[10:58] <stub> 3% cpu, 245MB
[11:01] <jamesh> stub: if the results look good, I guess we should run it in production at least once, so that the runs on staging don't take so long
[11:02] <stub> Ok.
[11:10] <jamesh> stub: I have a script to add "trunk" product series to all products which currently have no series.  Would it be possible to get it run on production at some point?
[11:10] <stub> sure. Did we rollout the bug fix to stop it happening yet?
[11:11] <jamesh> with the last rollout, all new products should have the default trunk series
[11:11] <stub> (I think the query to do that is already around in database/schema/archives from last time we did this)
[11:11] <jamesh> (it now gets created in the database/ code rather than the view class for one of the entry points for creating a products)
[11:13] <jamesh> I'm just going through the sample data now to make sure it has a product series for each product too
[11:15] <jamesh> stub: here is the script I did: https://devpad.canonical.com/~jamesh/ensure-product-series
[11:32] <stub> jamesh: I've run that script on production
[11:33] <jamesh> stub: thanks
[11:38] <jamesh> stub: I think I was mistaken about the automatic product series creation fix being in the current rollout.  I'll add a note about rerunning the script on the next rollout
[11:38] <stub> Please do
[11:40] <lifeless> hmm
[11:40] <lifeless> annoying that specs require unique urls
[11:40] <jamesh> lifeless: perhaps we need "SpecTasks" so you can assign a spec to multiple contexts :)
[11:41] <lifeless> bazaar-vs.org/ReleaseRoadmap
[11:41] <lifeless> that wants one spec per release attached to it
[11:42] <jamesh> just add extra dots to the end of the domain name
[11:42] <lifeless> heh
[11:42] <lifeless> I've abused it differently
[11:42] <jamesh> or http://www.bazaar-vcs.org/ vs. http://www.bazaar-vcs.org:80/
[11:42] <lifeless> but its a nuisance
[11:43] <lifeless> Roadmap/../
[11:43] <jamesh> file a bug about getting the constraint relaxed then
[12:50] <lifeless> review meeting in 10
[12:54] <jamesh> lifeless: btw, the pending-reviews script is taking quite a while these days (last run was 55 minutes) -- we might need to reduce the frequency a bit if it can't be sped up
[12:55] <lifeless> jamesh: ok
[12:56] <jamesh> since we added the work-in-progress section, the list of branches has increased quite a bit
[12:56] <lifeless> yah
[12:56] <lifeless> I was wondering about that
[12:56] <lifeless> we have viewbzr now
[12:56] <lifeless> perhaps for wip a calculated URL on that would be better
[12:57] <jamesh> viewbzr being different to bzr webserve?
[12:57] <spiv> You'd lose the "this wip has conflicts with rocketfuel" feature, but that's probably not a big deal.
[12:58] <SteveA> I'd be happy with wip being analyzed just once a day
[12:58] <SteveA> and pending reviews more often
[12:58] <SteveA> pending reviews is a very important part of our workflow
[12:59] <SteveA> wip is more about seeing how things are going, and looking at um... work in progress
[12:59] <lifeless> yup
[12:59] <SteveA> so daily is fine
[12:59] <lifeless> I was thinking along that direction myself
[12:59] <lifeless> jamesh: do you reuse the diff when its already known ?
[12:59] <jamesh> lifeless: not currently -- that is another area that'd improve things a lot
[01:00] <lifeless> review meeting time
[01:00] <jamesh> although each new launchpad commit implies that most diffs will be recalculated
[01:00] <lifeless> yes
[01:00] <lifeless> but thats not 12 per day
[01:01] <lifeless> or even 24 per day
[01:01] <jamesh> I should see about getting that working
[01:01] <lifeless>  * Next meeting
[01:01] <lifeless>  * Queue status.
[01:01] <BjornT> hi
[01:02] <lifeless> hi BjornT 
[01:03] <lifeless> so, same time, one week ok ?
[01:03] <SteveA> yes
[01:03] <lifeless> I'm going to remove this from the agenda
[01:04] <SteveA> lifeless: what's the agenda?
[01:04] <lifeless> and instead have it always the same unless someone explicit adds it as an agenda item
[01:04] <lifeless> SteveA: the two lines with ' * ' prefixes
[01:04] <SteveA> lifeless: prefix it with "Agenda:" then, so it is clear
[01:04] <SteveA> and add a "roll call" perhaps
[01:05] <SteveA> I thought you were introducing the items, and getting through them
[01:05] <SteveA> and I was looking for the agenda
[01:05] <lifeless> ok
[01:05] <lifeless> == Agenda ==
[01:05] <lifeless>  * Roll call
[01:05] <lifeless>  * Next meeting
[01:05] <lifeless>  * Queue status.
[01:05] <lifeless> is whats on the wiki page, so I'll just paste the full thing in future
[01:06] <lifeless> spiv: are you here ?
[01:06] <spiv> yes
[01:06] <lifeless> ok
[01:06] <lifeless> so the queue this week
[01:06] <lifeless> 5 items
[01:07] <lifeless> oldest is 6 days with salgado
[01:07] <lifeless> next oldest is 4 days which is just on our target service level considering the weekend
[01:07] <lifeless> jamesh and bjornt both 1 item each
[01:07] <lifeless>  - except - the queue page https://devpad.canonical.com/~jamesh/pending-reviews/ - does not list the post-merge reviews
[01:08] <lifeless> of which there are ~12
[01:08] <lifeless> BjornT, jamesh, spiv please look these up and use the bzr web, or bzr on devpad, to do them
[01:09] <lifeless> salgado: are you around ?
[01:09] <lifeless> Has anyone done any of the post merge reviews so far?
[01:09] <BjornT> i've done one
[01:10] <lifeless> was it appropriate to be trivial ?
[01:11] <BjornT> yes. it was a one-line change in a test setup, so i think the [trivial]  was correct to use there.
[01:12] <lifeless> cool.
[01:13] <lifeless> jamesh: ?
[01:13] <lifeless> I haven't
[01:13] <jamesh> I haven't done any of the post-merge reviews in my queue yet
[01:13] <SteveA> what's the procedure when you've done a post-merge review?
[01:13] <lifeless> email launchpad-reviews as per regular reviews I think
[01:14] <SteveA> for both appropriate merges, and for inappropriate ones?
[01:14] <lifeless> SteveA: I think for inappropriate ones there should be some escalation
[01:15] <SteveA> idea: mail the reviews list, and add it to the agenda of the dev meeting
[01:15] <SteveA> we can have a special section for this
[01:15] <lifeless> but I'd start with a review to the list, cc'd to the committer
[01:16] <lifeless> adding it to dev agenda sounds fine to me
[01:16] <SteveA> lifeless: please write the process on the Pending Reviews page, or somewhere like that
[01:16] <lifeless> so: inappropriate merges are raised in the dev meeting agenda as well as the normal review mail being sent
[01:16] <lifeless> SteveA: sure
[01:16] <SteveA> ta
[01:17] <lifeless> ok
[01:17] <lifeless> any other business ?
[01:17] <SteveA> any phone pre-impl calls happening?
[01:17] <SteveA> I had a kinda one with stub today
[01:18] <jamesh> there is the "pending-reviews is slow issue", but that was mostly discussed before the meeting
[01:18] <SteveA> although it was combined with more general management stuff
[01:18] <spiv> I had a call with malcc the week before I went on leave about soyuz testing.
[01:20] <spiv> (which wasn't exactly a pre-impl call)
[01:22] <lifeless> ok
[01:23] <lifeless> any other business ?
[01:23] <lifeless> [01:23] <lifeless> [01:23] <lifeless> [01:23] <lifeless> [01:23] <lifeless> [01:23] <lifeless> meeting closed
[01:24] <lifeless> thanks for coming y'akk
[01:27] <lifeless> SteveA: so, skype? normal phone ?
[01:28] <SteveA> lifeless: let me check with ddaa about delaying his call by 10 mins
[01:28] <SteveA> I'd like to have a quick call with you first
[01:28] <SteveA> ddaa: ping
[01:29] <ddaa> ok
[01:29] <SteveA> ddaa: delay by 10-15 mins?
[01:29] <ddaa> fine
[01:29] <SteveA> ok, thanks
[01:29] <SteveA> lifeless: try sip then fall back to POTS?
[01:30] <lifeless> normal phone is easiest right now, microphone is not setup
[01:30] <SteveA> ok, POTS
[01:30] <lifeless> but if you want 3-4 minutes I'll run round and grab it
[01:30] <SteveA>  /msg me your prefered number
[01:32] <lifeless> done
[01:41] <ddaa> SteveA: can futher postpone the call by one hour?
[01:43] <SteveA> ddaa: sure.  what time UTC?
[01:44] <ddaa> say, 1300 UTC
[01:44] <SteveA> ok
[02:23] <stub> carlos, danilo[out] : Do we need to support updates of POSubmission. Particularly changing POSubmission.person and POSubmission.pomsgset. Also, do we need to support updates of POMsgSet.pofile ?
[02:26] <carlos> stub: POSubmission.person, would be useful to fix some bad credit for those translations
[02:26] <carlos> stub: the others, I don't think we are going to change it ever
[02:27] <stub> So I can enforce POMsgSet.pofile never changing. That makes my life easier ;)
[02:27] <carlos> stub: I think so, yes
[02:27] <carlos> stub: do you need anything else?
[02:28] <stub> carlos: nope.
[02:28] <carlos> ok
[02:28] <carlos> later!
[02:30] <LarstiQ> SteveA: sorry to keep bothering you, but do you have any more information on the rosetta output copyright assignment?
[02:36] <SteveA> LarstiQ: nothing yet.  To make further progress, I need to talk with Mark about it.  He's traveling, but back in London next week.
[02:37] <LarstiQ> thank you.
[03:39] <WebMaven> AYT?
[03:39] <WebMaven> SteveA: AYT?
[04:06] <salgado> stub, around?
[04:07] <stub> salgado: yes
[04:10] <salgado> stub, I tried to run https://devpad.canonical.com/~andrew/paste/fileWFvar1.html on staging, but it was taking too long and matsubara had to stop it.  would it be possible to get it to run faster?
[04:14] <stub>  select count(DISTINCT POSubmission.person) FROM validpersonorteamcache,posubmission where posubmission.person = validpersonorteamcache.id; will be faster for the first one
[04:14] <stub> similar for the second
[04:14] <SteveA> stub: ping for a chat when you have time
[04:14] <stub> SteveA: pong
[04:17] <salgado> stub, cool, thanks a lot
[04:18] <heno> are there any known problems with bzr on LP ATM?
[04:23] <Spads> is there a way for me to subscribe somehow to package build/upload pages such as https://launchpad.net/distros/ubuntu/edgy/+source/xen-3.0 ?
[04:24] <malcc> Spads: No. Good idea though. If you've time, file a bug on Soyuz suggesting it?
[04:25] <Spads> malcc: I'll try
[04:25] <salgado> Spads, malcc, I think there's a bug for it already
[04:26] <malcc> salgado: Ah, bug 501 perhaps
[04:26] <Ubugtu> Malone bug 501 in soyuz "Subscribe to packages by email" [Medium,Confirmed]  http://launchpad.net/bugs/501
[04:26] <salgado> yeah, looks like that one
[04:26] <Spads> okay, good
[04:28] <oohlaf> ddaa: can you help me with https://lists.ubuntu.com/archives/launchpad-users/2006-September/000608.html
[04:38] <oohlaf> :)
[04:39] <oohlaf> the last update on the old host is a few months back, on the new host is from 2 days ago or something
[04:48] <heno> We are having some problems with https://launchpad.net/people/onboard/+branch/onboard/main 
[04:48] <heno> First it accepted a commit by someone not on the onboard team
[04:48] <heno> and now it won't update with a new commit
[04:48] <heno> The first one is esp worrying ...
[04:52] <jamesh> heno: are you sure none of the other team members pushed that change?
[04:53] <jamesh> and what error are you getting for the "now it won't update with a new commit" problem?
[04:54] <heno> jamesh: is was in fact Chris Jones who pushed the change, but from a friends computer. So his name appears differently 
[04:54] <heno> Chris Scutcher <beast@tecra> is not registered in the team
[04:54] <heno> though it came from the same IP
[04:54] <jamesh> heno: the name that appears there is the name recorded in the revision
[04:55] <jamesh> which isn't directly related to an LP user name
[04:55] <heno> jamesh: oh, I see, but he might have committed using a correct login, ok
[04:55] <heno> as for the update there was no error (AFAIK), it just hasn't been updated yet
[04:56] <ddaa> heno: the published branch has revno 24
[04:56] <jamesh> there is a time delay between changes being uploaded via SFTP and appearing via HTTP
[04:57] <ddaa> the listing on launchpad lags a bit behind what is actually published
[04:57] <heno> ddaa, jamesh: ok, thanks. That should explain both items :)
[05:17] <oohlaf> ddaa: I notice you updated the host. Cool, thank you
[05:17] <ddaa> oohlaf: look at your mail
[05:17] <ddaa> the import is still broken and I need your input
[05:18] <ddaa> also, please beat the CVS admin with some large, heavy, hard object for me.
[05:18] <oohlaf> ddaa: ok, I'll look up that file in their cvs
[05:18] <ddaa> you'll see it called yate-gtk2.conf.default
[05:19] <oohlaf> ddaa: stupid thing about their cvs is that both old and new host share the same ip
[05:19] <oohlaf> it's prob a vhost
[05:22] <ddaa> oohlaf: no trace of the .tabbed file, it's probably a case of CVS repo surgery
[05:22] <oohlaf> I'll ask in #yate
[05:23] <ddaa> oohlaf: thank you. I do not like to make people jump through hoops, but I need the cvs admins out there to understand how "renaming" breaks their users.
[05:25] <oohlaf> it's better if they just rm and add, and not try to preserve history by moving these ,v files
[05:26] <oohlaf> like http://www.eyrie.org/~eagle/notes/cvs/renaming-files.html
[05:27] <ddaa> *sigh*
[05:27] <ddaa> If I become master of the world one day, I'll get all those who post "insightful" documents like that up a wall.
[05:29] <oohlaf> hmm, #yate is a bit unresponsive at the moment
[05:30] <ddaa> oohlaf: I'm quite sure it's a case of "renaming". Please just remember to whine at the c
[05:30] <ddaa> at the cvs admin.
[05:30] <ddaa> I'm working on fixing the import now.
[05:30] <oohlaf> ok
[05:49] <tortoise_> Having a problem with this bzr branch: http://bazaar.launchpad.net/~onboard/onboard/main
[05:49] <ddaa> oohlaf: fixed now, the new stuff should be published within a day
[05:50] <oohlaf> ddaa: ok, thank you, I whined in #yate, but no response yet
[05:50] <carlos> will be back in 30 minutes
[05:50] <tortoise_> it doesn't register new revisions properly.  The commit message is show but the files arnt updated and are stuck at an old revision
[05:50] <ddaa> tortoise_: ?
[05:51] <oohlaf> ddaa: I looked at cvs log/status but could not find a trace of .tabbed
[05:51] <tortoise_> ddaa:  any ideas?
[05:51] <jamesh> tortoise_: there is a delay between the branch being uploaded via SFTP and it being published via HTTP and its revision info being displayed on the website
[05:51] <tortoise_> i've given it a good hour
[05:51] <jamesh> tortoise_: heno was just here complaining about that branch, btw :)
[05:51] <tortoise_> jamesh: oh good
[05:52] <ddaa> tortoise_: where is the commit message shown, and where are the files not upgraded?
[05:52] <jamesh> and the revision list on the website has updated since then (from rev 23 to 24)
[05:52] <tortoise_> yes but the files have not
[05:52] <tortoise_> bzr branch http://bazaar.launchpad.net/~onboard/onboard/main
[05:53] <tortoise_> gives a very old revision with some files missing too
[05:53] <ddaa> here, that gives revision 24
[05:53] <ddaa> dated today
[05:54] <ddaa> and well, the files are what is in the branch...
[05:54] <jamesh> if there are missing files, is it possible that you didn't "bzr add" them before committing?
[05:54] <tortoise_> the one I get when I branch has the old debian/rules so that's pre 09-02
[05:55] <ddaa> tortoise_: in all likelihood, launchpad just gives what people have put there
[05:55] <tortoise_> My last commit I made by branching from http://bazaar.launchpad.net/~onboard/onboard/main overwriting with the new and missing files, committing and pushing.
[05:55] <ddaa> if stuff is outdated, you should check with those people https://launchpad.net/people/onboard
[05:56] <ddaa> Ha, you're chris jones
[05:56] <ddaa> sorry
[05:56] <tortoise_> ddaa:  lol
[05:57] <ddaa> tortoise_: I do believe you have a bzr usage problem here, not related to Launchpad. You would get better help on #bv
[05:57] <ddaa> on #bzr
[05:57] <jamesh> tortoise_: you might want to read http://blogs.gnome.org/view/jamesh/2006/08/17/1
[05:58] <jamesh> tortoise_: it describes a workflow for using shared branches on bazaar.launchpad.net
[05:58] <ddaa>  tortoise_: your commit only modified one file in the bzr branch
[05:59] <ddaa> check with "bzr log -v | less"
[06:01] <ddaa> you can also get the log for only one file, for example "bzr log -v onboard/debian/rules | less"
[06:02] <tortoise_> ddaa: It should have added a whole new directory
[06:02] <ddaa> sounds like you forgot to "bzr add"
[06:03] <ddaa> "bzr status" is useful to run before committing to avoid this sort of mistake
[06:03] <tortoise_> ddaa: ahhh
[06:03] <ddaa> if you do you "bzr commit", it will run status and display the output in a text editor where you can type the commit message
[06:03] <ddaa> it's very convenient
[06:04] <tortoise_> ddaa: thanks
[06:07] <j-a-meinel> tortoise_: Another thing you may want to do is add 'commit=commit --strict' into your aliases.
[06:07] <j-a-meinel> Then 'bzr' will abort a commit if it has unknown files.
[06:08] <j-a-meinel> (you can override this with 'bzr --no-aliases commit' or with bzr >= 0.10 you can do 'bzr commit --no-strict')
[06:19] <kiko> hey there
[06:19] <kiko> how's it going
[06:19] <kiko> SteveA?
[06:22] <SteveA> kiko: hey
[06:23] <kiko> SteveA, how's it going? 
[06:23] <SteveA> kiko: I've had a good day.  about to head out.  quick call?
[07:40] <elmo> SteveA/kiko: ping?
[07:40] <kiko> elmo, pong?
[07:42] <teolemon> jordi, i've merged the files for clamwin
[07:42] <elmo> kiko: I need to take staging down and borrow some  of it's memory.  urgently.  is that ok?
[07:42] <teolemon> and uploaded them on LP
[07:43] <kiko> elmo, okay, then. is there an ETA for recovering it?
[07:43] <elmo> kiko: as soon as my supplier can ship it, late tuesday/wednesday
[07:44] <kiko> elmo, thanks. I'll email the list
[07:45] <elmo> it'll go back to the 3Gb/4Gb it use to have (I can't recall which offhand)
[07:48] <salgado> elmo, is that the appserver or the db server (or are they both running on the same machine)?
[07:48] <elmo> salgado: same machine
[07:48] <salgado> can you hold it for a few minutes? (no more than 10)
[07:49] <salgado> elmo, ^
[07:50] <salgado> elmo, it's not urgent, so it's no big deal if you can't
[07:51] <elmo> salgado: I'm not near the DC yet - that shouldn't be a problem ;-)
[09:16] <ddaa> Good night folks,
[09:18] <nessmuk> I'd like to know how to unsubscribe from launchpad so I don't receive bug reports in my email
[09:19] <kiko> nessmuk, are you subscribed to ubuntu-bugs?
[09:19] <nessmuk> yes
[09:19] <kiko> nessmuk, just unsubscribe from that list, then.
[09:20] <nessmuk> oh...I think you mean a mail list. I'm not in one of those, just registered to report bugs on the launchpad page
[09:20] <kiko> nessmuk, can you give me an example of a bug which you are receiving bugmail for?
[09:21] <nessmuk> https://launchpad.net/bugs/56452
[09:21] <Ubugtu> Malone bug 56452 in at-spi "Edgy: at-spi Crashes frequently" [Unknown,Needs info]  
[09:22] <kiko> nessmuk, why don't you just unsubscribe from that bug?
[09:22] <nessmuk> can't figure out where to do that....noobie blues!
[09:22] <kiko> heh.
[09:23] <kiko> there's an "unsubscribe" link on that (admittedly very busy) page
[09:24] <kiko> https://launchpad.net/products/at-spi/+bug/56452/+unsubscribe I believe
[09:24] <Ubugtu> Malone bug 56452 in at-spi "Edgy: at-spi Crashes frequently" [Unknown,Needs info]  
[09:24] <kiko> or maybe it's https://launchpad.net/products/at-spi/+bug/56452/+subscribe
[09:53] <elmo> ok, staging is going down now
[10:19] <elmo> and is back