=== wa0eir [n=ted@12-217-107-95.client.mchsi.com] has joined #launchpad [12:15] Sp4rKy: what do you want to do ? [12:16] lifeless, mainly, i want added my own package to a LP team [12:16] but packages are not in ubuntu but in a personal repository [12:17] the source for the packages, or the binaries ? [12:17] so i think i can't added them and link them to their maintainers , right ? [12:17] twice [12:17] well I dont understand quite what you are talking about yet [12:17] ok .. [12:17] so, i've create a team on launchpad [12:18] this team provide a repository for E17 [12:18] that will be at sftp://bazaar.launchpad.net/~TEAMNAME/PRODUCT [12:18] where TEAMNAME is your team name [12:19] i want add the packages which are on this repository on lp , link this with their maintainers [12:19] ok [12:19] and PRODUCT is the e17 product name in launchpad [12:19] whatever that is [12:19] can't i add the package with an other way than bazaar ? [12:19] this is what I dont understand [12:19] packages != bazaar [12:20] when you say 'package' what *precisely* do you mean [12:20] yes i know [12:20] source packages and binary packages [12:20] ok, nothing to do with bazaar directly. Ubuntu uses Bazaar to manage the *source* for the source package [12:20] if it is possible, i want added them to lp without using bazaar, [12:21] lifeless, yes, but can i add my packages without bazaar to lp [12:21] I think you probably need to talk with #ubuntu-motu [12:21] i've done [12:21] because I dont understand what 'add packages to lp' /means/ [12:21] it's unclear what you're attempting to do. [12:21] ok [12:21] i explain again [12:21] give me a URL for instance, that you want to have work which does not today [12:22] (i'm sorry i'm french and my english isn't perfect at all) [12:22] i've a repository at edevelop.org [12:22] this repository contains packages for e17 over ubuntu [12:22] what sort of repository ? [12:23] is it an APT repository ? or a bazaar repository ? [12:23] apt repository [12:23] so i would add packages which are on this repository on lp [12:23] what do you mean by 'add packages to lp' [12:23] like it's done with packages which are on ubuntu repository [12:24] lifeless, if i go on my personal lp page , i can see the list of packages i maintain in Ubuntu [12:24] https://launchpad.net/people/maxenced/+packages [12:24] Sp4rKy: ok. now we are getting somewhere. [12:24] that list is made by launchpad scanning the Ubuntu *distribution* [12:25] i would add the packages i maintain on edevelop repository in the same way [12:25] your repository is not scanned by launchpad [12:25] yes i know [12:25] and cannot be at this point [12:25] ok . [12:25] this is my question :) [12:26] so is there any other way for manage my repository on lp ? [12:26] there is a feature in development called personal package archives [12:26] where launchpad will provide build daemons and host the repository [12:26] k (raphink talked me about that) [12:27] lifeless, i don't need host and build daemon, but just manage package/ maintainers [12:28] you should talk to malcc and cprov [12:28] they are the soyuz folk === HaDeS [i=HaDeS_ha@conm200-116-102-213.epm.net.co] has joined #launchpad [12:28] are they sleeping ? [12:28] I cannot say what they are planning to do or not in the future [12:28] wenas [12:28] malcc is on uk time [12:28] ok [12:28] cprov on brazilian [12:28] :) [12:29] lifeless, ok, so at this time, there is no way to manage packages with lp ? [12:29] even with bazaar ? [12:29] if by package you mean an apt repository the only way is as a distribution [12:29] bazaar is a VCS - see bazaar-vcs.org [12:30] ok [12:30] i'd seen it [12:30] but don't really understand how i can add my apt repository [12:32] bazaar has nothing to do with apt [12:32] I dont know why you keep bring up bazaar at all. [12:32] its for managing *source code* [12:32] k [12:32] you can use it to manage the *source code* you are making [12:32] so i can't manage my repository with lp at this time [12:32] I've already answered that [12:33] lifeless, this is not the idea, [12:33] sorry, I am getting frustrated here [12:33] :) [12:33] sorry [12:33] raphink, said me i can try using bazaar for manage my package [12:33] Asking the question differently will not change the answers I have to give you [12:33] so i try to get more info :) [12:33] lifeless, i kno [12:33] w [12:33] thx for your help [12:33] Sp4rKy: yes, for when you work on the debian/ packaging [12:33] bazaar is great for managing the *source code* for your package, but nothing to do with the +packages stuff in launchpad [12:34] _not_ for the result of building a .deb [12:34] lifeless, ok [12:34] lifeless: who can I contact to change a setting in vcs-import setting for a project on LP? [12:34] oohlaf: ddaa [12:34] oohlaf: ddaa [12:34] oohlaf: who is on -users and will read it [12:34] but feel free to nag him here [12:34] oki [12:35] he's prob asleep now, he is also on CET right? [12:35] lifeless, i'll wait for personal package archive so ... [12:35] thx again === PenguinOfDoom [i=foobar@spleen.xzrq.net] has joined #launchpad [12:41] How do I search the entire bug database? === wa0eir [n=ted@12-217-107-95.client.mchsi.com] has left #launchpad ["xchat] [12:42] oh, found it [12:42] launchpad is quite a maze :P === PenguinOfDoom [i=foobar@spleen.xzrq.net] has left #launchpad [] === HaDeS is now known as HaDeS_hack === Fujitsu [n=Fujitsu@ubuntu/member/fujitsu] has joined #launchpad === lbm [n=lbm@82.192.173.92] has joined #launchpad === mpt has the unusual experience of not being permitted to view a bug report about Launchpad [02:07] Nice. [02:07] nice [02:09] score! [02:10] mpt: which one ? [02:10] lifeless, reported bug 59846 about it [02:10] uhm [02:10] it may not be abug [02:10] what bug were you trying to look at [02:11] It's probably marked private... [02:11] bug 31287 [02:11] Erm. [02:11] yup [02:11] its private [02:11] I can't see bug 59846. [02:11] and theres no subscribers [02:11] Ah. [02:11] other than spiv [02:11] It is private... === HaDeS_hack [i=HaDeS_ha@conm200-116-102-213.epm.net.co] has joined #launchpad [02:12] mpt: the security contact for lp is not subscribed to 31287 [02:12] So, that's still a bug [02:12] The security contact should still be able to view it, right? [02:12] dunno [02:13] it makes sense to me that the security contact should be able to by default [02:13] but if they are unsubscribed, why should they see it anymore ? [02:14] Why shouldn't they? [02:14] I asked first ;) [02:14] ok [02:15] Because letting them see it any more doesn't disclose it to anyone new [02:15] mmm, too much context switching [02:15] do you need access to this bug ? [02:15] I can subscribe the security contact or whatever you need [02:15] after that I' going back to deep hack mode [02:16] I can't remember why I tried to open it, and immediate access isn't the point [02:16] but thanks for clarifying the issue, I'll update my bug report [02:20] yay for Proxy Errors === ChanServ [ChanServ@services.] has joined #launchpad === Fujitsu [n=Fujitsu@ubuntu/member/fujitsu] has joined #launchpad === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad [02:41] New bug: #59846 in malone "Bug 31287 is mysteriously forbidden" [Untriaged,Unconfirmed] http://launchpad.net/bugs/59846 [02:46] lifeless, are you able to kick staging? [02:46] one sec [02:57] lifeless: you should be able to set the productseries branches for bzr on staging.launchpad.net now, btw [03:06] mpt: there are no processes running on staging [03:06] it looks deliberately shutdown [03:12] mpt: is that better ? === spiv [n=andrew@218-214-66-203.people.net.au] has joined #launchpad [03:15] lifeless, not really, https://staging.launchpad.net/ gives me an Oops :-) [03:16] I'm shutting it back down [03:16] 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] ok, thanks [03:25] you sure it wasn't in the middle of a DB restore? [03:28] fairly, but not completely [03:28] which is why its shutdown again === Fujitsu [n=Fujitsu@ubuntu/member/fujitsu] has joined #launchpad [04:25] lifeless: hopefully we'll get another report on product-release-finder today === Fujitsu [n=Fujitsu@ubuntu/member/fujitsu] has joined #launchpad === AstralJava [n=jaska@cm-062-241-239-3.lohjanpuhelin.fi] has left #launchpad [] [05:02] spiv: how was the holiday? [05:05] jamesh: fun, despite the stitches in the back of my head :) [05:05] ouch [05:10] spiv: I noticed you were on the list of contributors to SQLOS. [05:11] spiv: AYT? [05:12] Heh, am I? It's been a while... === SEJeff [n=jschroed@h253.204.28.71.ip.alltel.net] has joined #launchpad [05:13] 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] Malone bug 31925 in compiz "Please package new upstream version" [Wishlist,Unconfirmed] [05:18] SEJeff: if you click on the package name in the "Affects" table at the top, you can change the status [05:38] jamesh: thankyou === WebMaven [n=webmaven@ip72-193-220-34.lv.lv.cox.net] has joined #launchpad === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad [05:52] spiv: any progress on getting spiv/launchpad/ddaa's-branch-ui merged? === stub [n=stub@ppp-58.8.6.207.revip2.asianet.co.th] has joined #launchpad [06:52] 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] I'm interested to see if they succeed yet [07:19] jamesh: https://lists.ubuntu.com/mailman/private/launchpad-error-reports/ [07:19] The reports are in jubany's nightly.sh [07:20] https://lists.ubuntu.com/mailman/private/launchpad-error-reports/Week-of-Mon-20060904/038384.html [07:21] stub: could you approve my subscription to that list? [07:23] jamesh: done. You might want to turn off mail delivery or subscribe to only the topics you want. [07:23] thanks [07:29] 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 === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [07:59] asuka's nightly.sh is running right now [07:59] product-release-finder.py has been running for two hours now. Hopefully that is a good sign ;) === Fujitsu [n=Fujitsu@ubuntu/member/fujitsu] has joined #launchpad [08:00] does sound good [08:02] the speed could probably be improved by scanning multiple tarball repos in parallel [08:02] at the moment it is all in a single thread [08:09] I would have assumed the bottleneck was downloading [08:09] yep [08:10] 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] given the bandwidth of the datacentre [08:11] mmm [08:12] anyway, the fact that it hasn't crapped out yet is a good sign that it'll get all the way through [08:12] Will it only be the initial run that will be slow? [08:12] (for some value of slow we don't know yet ;) ) [08:13] if it starts with a clean DB every night, yes [08:13] or maybe not if the datacentre proxy caches the files between runs [08:14] once the production DB has some of this data, the staging runs won't be starting with a clean slate [08:14] so should be faster [08:19] 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] the way to test that would be to do another run on staging without a clean DB === carlos [n=carlos@84.77.102.42] has joined #launchpad [08:21] morning. Any chance to play on the new server yet? [08:22] morning === tomveens__ [n=tomveens@ztn-c-1566b.adsl.wanadoo.nl] has joined #launchpad [08:33] good morning [08:35] stub: http://www.zope.org/Collectors/Zope3-dev/706 seen it? a minor sessions infrastructure bug. [08:36] Not seen it. I've never worked out how to drive the collector and only have read access anyway. [08:37] Doesn't look like a problem worth caring about [08:38] But I can't comment as far as I can see :-( [08:39] hmm [08:39] ask jim for access sometime [08:39] or, maybe they'll be using launchpad by then ;-) [08:40] stub: what do we do nowadays if someone registers a new product, but they didn't mean to do so? [08:40] We flag it as inactive [08:40] I don't know if they can do it themselves or not - probably not. [08:41] (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] there are no bugs, support requests, translations etc. [08:41] just the product and two series [08:41] Sure. flag it as inactive. === glatzor [n=sebi@ppp-82-135-3-178.dynamic.mnet-online.de] has joined #launchpad [08:42] ok, done [08:42] what happens to its name? [08:42] One day we will have the technology to delete the simple cases, but for the time being just flag 'em as inactive. [08:42] I mean, can another product be registered with the same name? [08:42] name is still taken, so we can rename them at the same time as flagging them inactive if we need it. [08:43] 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] Although even that is scary (trashing branches might be too far) [08:43] hmm, I can't rename it, as I can't get to a URL for it [08:44] ok. So we need to remember to rename first ;0 [08:44] What name product? I'll do it on the db [08:44] would you rename the inactive product 'firebird' to 'firebird-inactive' ? [08:44] Done [08:45] or you could reactivate the old product [08:48] ta === Spads [n=crack@host-87-74-19-213.bulldogdsl.com] has joined #launchpad [08:49] jamesh: thanks for mailing about the validate() issue. I replied with a couple of things to think about. [08:49] jamesh: Can't reactivate via the web as the product page gives a 404 ;) [08:49] I haven't really thought them through , though [08:49] I wonder if either of the other options would be easier to write validate() methods for [08:49] and not make the kind of mistake you describe happening [08:52] 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] 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] ok [08:58] so in that case, maybe a standard test for forms can be [08:58] - pass into validate() a non-empty non-full dict [08:59] so a dict that doesn't match [08:59] if not D: [08:59] but that doesn't contain anything the validate() method wants [09:00] it'd be pretty easy to add that to the LaunchpadFormView test harness. [09:00] pass in a dictionary of form values, and have it test each combination of present values against the validate() routine [09:00] point out which combinations result in an exception [09:01] nice [09:01] this would be applicable even with the "missing value" object idea -- just replace entries with missing value instead of deleting them [09:04] well, I'm not sure about the value of putting "missing value" into the dict [09:05] that might just encourage people to test for None rather than consulting field.missing_value [09:05] 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] I think a standard test harness would help there [09:05] if there is no API change that would help [09:14] there's one api change that i could think of that would help, not sure if things get easier though. [09:15] 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] 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] that's an interesting idea [09:16] e.g. @validator('owner', 'product', 'name') def validate_branch_name(self, owner, product, name) === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [09:17] yeah, something like that. [09:18] the above syntax would also get rid of the direct dict lookups too [09:21] @validator(*ISchema.names()) def validate_schema(names, in, alphabetical, order): [09:24] stub: call? [09:25] i think it would be more intuitive to have the method parameters in the same order as the appear in @validator(...) === fabbione [i=fabbione@gordian.fabbione.net] has joined #launchpad === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad === Starting logfile irclogs/launchpad.log === ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog] has joined #launchpad === Topic for #launchpad: Developer meeting: Thu 14 Sep, 1200UTC (wiki:MeetingAgenda) | launchpad-users@lists.canonical.com (wiki:MailingLists) | Channel logs: http://tinyurl.com/72w39 === Topic (#launchpad): set by mpt at Fri Sep 8 07:38:50 2006 === jinty [n=jinty@132.Red-83-55-196.dynamicIP.rima-tde.net] has joined #launchpad === danilos [n=danilo@cable-87-116-150-147.dynamic.sbb.co.yu] has joined #launchpad === malcc [n=malcolm@host86-138-251-144.range86-138.btcentralplus.com] has joined #launchpad [10:19] BjornT: yes, and that's why my silly example would work (except I forgot the 'self') [10:19] because interface.names() is sorted [10:24] lifeless: is there meant to be a bzr meeting today? [10:28] 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] i think it is meant to be sorted [10:31] hmm, the interface doesn't say anything abot it [10:31] so, I guess it would need to be sorted() === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [10:37] SteveA: AFAIK yes [10:55] stub: product-release-finder is still running? === stub wonders wtf has happened with his sound today [10:58] jamesh: Yes - still running [10:58] 3% cpu, 245MB [11:01] 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] Ok. [11:10] 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] sure. Did we rollout the bug fix to stop it happening yet? [11:11] with the last rollout, all new products should have the default trunk series [11:11] (I think the query to do that is already around in database/schema/archives from last time we did this) [11:11] (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] I'm just going through the sample data now to make sure it has a product series for each product too [11:15] stub: here is the script I did: https://devpad.canonical.com/~jamesh/ensure-product-series === Spads [n=crack@217.205.109.249] has joined #launchpad [11:32] jamesh: I've run that script on production [11:33] stub: thanks === danilo_ [n=danilo@cable-87-116-150-177.dynamic.sbb.co.yu] has joined #launchpad [11:38] 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] Please do [11:40] hmm [11:40] annoying that specs require unique urls [11:40] lifeless: perhaps we need "SpecTasks" so you can assign a spec to multiple contexts :) [11:41] bazaar-vs.org/ReleaseRoadmap [11:41] that wants one spec per release attached to it [11:42] just add extra dots to the end of the domain name [11:42] heh [11:42] I've abused it differently [11:42] or http://www.bazaar-vcs.org/ vs. http://www.bazaar-vcs.org:80/ [11:42] but its a nuisance [11:43] Roadmap/../ [11:43] file a bug about getting the constraint relaxed then === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [12:50] review meeting in 10 === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad [12:54] 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] jamesh: ok [12:56] since we added the work-in-progress section, the list of branches has increased quite a bit [12:56] yah [12:56] I was wondering about that [12:56] we have viewbzr now [12:56] perhaps for wip a calculated URL on that would be better [12:57] viewbzr being different to bzr webserve? [12:57] You'd lose the "this wip has conflicts with rocketfuel" feature, but that's probably not a big deal. [12:58] I'd be happy with wip being analyzed just once a day [12:58] and pending reviews more often [12:58] pending reviews is a very important part of our workflow [12:59] wip is more about seeing how things are going, and looking at um... work in progress [12:59] yup [12:59] so daily is fine [12:59] I was thinking along that direction myself [12:59] jamesh: do you reuse the diff when its already known ? [12:59] lifeless: not currently -- that is another area that'd improve things a lot [01:00] review meeting time === lifeless grabs the agenda [01:00] although each new launchpad commit implies that most diffs will be recalculated [01:00] yes [01:00] but thats not 12 per day [01:01] or even 24 per day [01:01] I should see about getting that working [01:01] * Next meeting [01:01] * Queue status. [01:01] hi [01:02] hi BjornT [01:03] so, same time, one week ok ? [01:03] yes [01:03] I'm going to remove this from the agenda [01:04] lifeless: what's the agenda? [01:04] and instead have it always the same unless someone explicit adds it as an agenda item [01:04] SteveA: the two lines with ' * ' prefixes [01:04] lifeless: prefix it with "Agenda:" then, so it is clear [01:04] and add a "roll call" perhaps [01:05] I thought you were introducing the items, and getting through them [01:05] and I was looking for the agenda [01:05] ok [01:05] == Agenda == [01:05] * Roll call [01:05] * Next meeting [01:05] * Queue status. [01:05] is whats on the wiki page, so I'll just paste the full thing in future [01:06] spiv: are you here ? [01:06] yes [01:06] ok [01:06] so the queue this week [01:06] 5 items [01:07] oldest is 6 days with salgado [01:07] next oldest is 4 days which is just on our target service level considering the weekend === cprov-afk is now known as cprov [01:07] jamesh and bjornt both 1 item each [01:07] - except - the queue page https://devpad.canonical.com/~jamesh/pending-reviews/ - does not list the post-merge reviews [01:08] of which there are ~12 [01:08] BjornT, jamesh, spiv please look these up and use the bzr web, or bzr on devpad, to do them [01:09] salgado: are you around ? [01:09] Has anyone done any of the post merge reviews so far? [01:09] i've done one [01:10] was it appropriate to be trivial ? [01:11] yes. it was a one-line change in a test setup, so i think the [trivial] was correct to use there. [01:12] cool. [01:13] jamesh: ? [01:13] I haven't [01:13] I haven't done any of the post-merge reviews in my queue yet [01:13] what's the procedure when you've done a post-merge review? [01:13] email launchpad-reviews as per regular reviews I think === BjornT sent an email to launchpad-reviews and removed the item from PendingReviews [01:14] for both appropriate merges, and for inappropriate ones? [01:14] SteveA: I think for inappropriate ones there should be some escalation [01:15] idea: mail the reviews list, and add it to the agenda of the dev meeting [01:15] we can have a special section for this [01:15] but I'd start with a review to the list, cc'd to the committer [01:16] adding it to dev agenda sounds fine to me [01:16] lifeless: please write the process on the Pending Reviews page, or somewhere like that [01:16] so: inappropriate merges are raised in the dev meeting agenda as well as the normal review mail being sent [01:16] SteveA: sure [01:16] ta [01:17] ok [01:17] any other business ? [01:17] any phone pre-impl calls happening? [01:17] I had a kinda one with stub today [01:18] there is the "pending-reviews is slow issue", but that was mostly discussed before the meeting [01:18] although it was combined with more general management stuff [01:18] I had a call with malcc the week before I went on leave about soyuz testing. [01:20] (which wasn't exactly a pre-impl call) [01:22] ok [01:23] any other business ? [01:23] === -5- === [01:23] === -4- === [01:23] === -3- === [01:23] === -2- === [01:23] === -1- === [01:23] meeting closed [01:24] thanks for coming y'akk [01:27] SteveA: so, skype? normal phone ? [01:28] lifeless: let me check with ddaa about delaying his call by 10 mins [01:28] I'd like to have a quick call with you first [01:28] ddaa: ping [01:29] ok [01:29] ddaa: delay by 10-15 mins? [01:29] fine [01:29] ok, thanks [01:29] lifeless: try sip then fall back to POTS? [01:30] normal phone is easiest right now, microphone is not setup [01:30] ok, POTS [01:30] but if you want 3-4 minutes I'll run round and grab it [01:30]