=== SteveMyers [n=SteveMye@255.26.118.70.cfl.res.rr.com] has joined #launchpad === ntsjk [i=ircap751@eu85-86-12-171.clientes.euskaltel.es] has joined #launchpad [12:07] zein === ntsjk [i=ircap751@eu85-86-12-171.clientes.euskaltel.es] has left #launchpad [] === SteveMyers [n=SteveMye@255.26.118.70.cfl.res.rr.com] has left #launchpad ["Leaving"] === mpt_ [n=mpt@219-89-158-224.jetstart.xtra.co.nz] has joined #launchpad === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad === spiv [n=andrew@adsl-66-203.swiftdsl.com.au] has joined #launchpad [01:04] "Patch (Required)" [01:04] required? ! ;) [01:19] CarlFK: it is required that you either leave the checkbox checked or unchecked :) [01:29] Goooooooooooooooood afternoon Launchpadders! [01:29] jamesh, oh boy, that's a bug [01:39] heh === stub [n=stub@gb.ja.97.6.revip.asianet.co.th] has joined #launchpad === jsgotangco [n=jsg@ubuntu/member/jsgotangco] has joined #launchpad === mpt_ adds that to https://wiki.launchpad.canonical.com/FormLayout === mpt_ is now known as mpt [01:49] I can never change the people of a spec [01:49] it always times out [01:50] whoa, I take that back [01:50] it took about 25 seconds, but it worked === poningru [n=poningru@n128-227-13-13.xlate.ufl.edu] has joined #launchpad === dous [n=dous@efreet.edu.ms] has joined #launchpad === xhaker [n=xhaker@213.201.220.218] has joined #launchpad === jsgotangco [n=jsg@210.4.38.43] has joined #launchpad === ulinskie [n=yolynne@202.57.88.34] has joined #launchpad [03:46] so, MultipleJoin is really bad for pretty much any case where we'd get lots of results === ulinskie is away: visit wahoy.com, zamboanga's free online classified ads [04:00] jamesh: Yep. [04:01] jamesh: newer versions of SQLObject have SQLMultipleJoin or some-such that are better. [04:01] spiv: I noticed that. I wonder why you'd ever want to use MultipleJoin instead of SQLMultipleJoin though? [04:02] jamesh: The only reason I can think of is backwards compatibility. [04:02] if the aim is backward compatibility (i.e. don't make something start returning a SelectResults when it used to return a list), then it would probably be better to make MultipleJoin just convert the SelectResults to a list [04:03] so you still get one query [04:08] jamesh: So for MulipleJoins that are hurting us, we can either manually replace them with properties that generate the appropirate SelectResults, or perhaps look at borrowing the newer joins from upstream. [04:08] I think there's already one or two places where we've taken the ad hoc property road. [04:11] I converted a few MultipleJoins to SelectResults properties, but that wasn't performance related [04:12] that was where we had two classes implementing the same interface but one returning a list and the other returning a SelectResults [04:19] maybe we should look at upgrading our sqlobject [04:19] Definitely. [04:19] There's a bit of pain, because we've diverged a little bit. [04:20] And upstream has rearranged a lot of internals for "class sqlmeta:", so most of our patches need work to keep them applying. [04:21] Are our patches suitable for applying upstream? I can't remember much of what local changes we rely on. [04:21] Some are, some aren't. [04:22] the Table.selectFirst() and SelectResults.__nonzero__() stuff might be appropriate [04:22] E.g. our postgres-specific unicode stuff isn't. [04:22] selectOne got a mixed reception on the list, but I think if we synced it up to current upstream, they would probably take it. [04:23] They didn't like SelectResults.__len__ when I proposed that :) [04:23] do you think they'd like selectFirst()? [04:23] I can understand them not liking __len__() [04:23] I'm not sure, it's a relatively uncommon use-case, so it might be hard justify. [04:24] I think there's a reasonable argument to be made that there's something inelegant about having lots and lots of select* variants, although I can't think of any obviously better alternatives. [04:29] meh [04:30] Anyone here an expert on wpasupplicant? My Internet connection was working on Friday... [04:31] mpt: and what broke since then? why is it wpasupplicant? [04:31] ok, maybe I'm misattributing blame [04:32] What broke is that I have no Internet connection, no DNS, nothing [04:32] brave/silly enough to be running dapper? [04:32] no, 5.10 [04:33] hm [04:33] and I know it's not the AP, because if it was, you wouldn't be able to see what I'm typing on my Mac [04:34] try turning off WPA :) [04:34] If I did that, I'd break everyone else's Internet connection [04:34] or setup, anyway [04:34] ah yes, shared flat connection :) [04:39] spiv: looks like upstream sqlobject has SelectResults.getOne() [04:39] spiv: so you'd do Table.select(...).getOne() [04:40] jamesh: Hmm, instead of selectOne, it seems. [04:40] yeah [04:41] actually, you'd do Table.select(...).getOne(None) [04:41] getOne() will raise SQLObjectNotFound if you don't give a default [04:42] It would be good to get closer to upstream. [04:43] I suppose the other big change we've got is the set operations stuff for SelectResults [04:43] Yeah. [04:43] That's suitable for upstream, I think. [04:44] Although not necessarily portable to all backends, which may be a problem. [04:44] well, that's progress [04:44] dhclient works now, but still no Internet [05:09] lifeless: what's up with pqm.ubuntu.com? [05:14] lifeless: star-merge sftp://chinstrap.ubuntu.com/home/warthogs/archives/stub/psycopgda/devel/ sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/psycopgda/3.0/test [05:21] stub: pqm appears to be down... do you have access to it? [05:21] yes. pqm isn't down, but the web interface maybe [05:22] The web interface certainly is :) [05:22] And because it's not on chinstrap anymore, I can't check if it's alive with ps anymore :) [05:22] would have been the weekend sheduled outage [05:22] Yeah, I expect so. [05:23] Well, I'll just be patient then. [05:29] spiv: up [05:29] lifeless: Thanks [05:29] Hmm, where did my branch merge request go... [05:31] lifeless: I sent a request to pqm@, Message-ID: <20060213040821.GB10611@home.puzzling.org>, but have got no reply, and the web interface says the queue is empty. [05:31] spiv: bzrlib.errors.UnrelatedBranches: Branches have no common ancestor, and no base revision specified. [05:31] I got a traceback [05:32] lifeless: Oh, heh. === stub can't work out how to fire up the web ui [05:32] lifeless: Why didn't I get that traceback? [05:32] stub: cd pqm; twistd -oy pqm/ui/twisted.py [05:32] stub: I need to make an init script at some point [05:33] spiv: unhandled exception [05:33] spiv: to debug this, try doing the merge on chinstrap - make a branch from the rf psycopgda and merge into that [05:33] lifeless: Oh, I know what my snafu was. [05:34] I just want pqm fixed so I don't have to ask to find out what my embarrassing snafu was :) [05:34] spiv: oh, it will be. [05:34] I have a note now [05:38] lifeless: psycopgda was my request. I just wanted you to toss that at pqm since it tells me I don't have permissions :) [05:38] (or I could just do it manually on balleny) [05:39] lifeless: So, buildbot merge still doesn't work :) [05:41] stub: if you could do it manually right now that would be great. [05:41] spiv: details details details [05:42] lifeless: are in the mail :P [05:43] lifeless: (I'm keeping launchpad@ in the loop this time) [05:43] (or would, if I could spell "canonical"... ahem) [05:49] spiv: in the upstream sqlobject, SelectResults.__iter__() seems to evaluate every row in the result set before iterating :( [05:49] jamesh: Yuck :( [05:49] return iter(list(self.lazyIter())) [05:50] has a comment saying that it could be optimised [05:50] Ahem. [05:52] the SelectResults.lazyIter() looks like the __iter__() in our version [05:52] I wonder what tests will break (if any) if I make the obvious change... === ajmitch__ [i=ajmitch@port169-55.ubs.maxnet.net.nz] has joined #launchpad === ajmitch__ is now known as ajmitch === catnip [i=meowmix@asnet01-1-165.aus.datafoundry.com] has joined #launchpad === mpt [n=mpt@219-89-158-224.jetstart.xtra.co.nz] has joined #launchpad [06:15] jamesh: So, replacing "return iter(list(self.lazyIter()))" with "return self.lazyIter()" doesn't break any SQLObject tests in SVN (although two tests are already broken...) [06:15] But then SQLObject only has 167 tests all up. [06:16] spiv: I wonder why they changed things? [06:19] jamesh: r946, log message of "Made select results aggressively fetch objects, instead of lazily" [06:19] that doesn't help much :) [06:20] No, not really :) [06:20] I'm trying to see if any other files changed in that revision, but my svn-fu is too wek. [06:20] weak, rather. [06:20] svn diff -r 945:946 [06:20] (and "svn log -r 946" doesn't work for some reason I don't understand, and the cryptic error message doesn't help) [06:21] It's things like this that make me feel a little less worried about the little warts that bzr still has :) [06:21] only other change appears to be in docs/News.txt explaining that it now does something different :) [06:22] I wonder why. [06:22] "When iterating over select results, a list is now immediately created with the full list of instances being selected." [06:22] I suppose it's meant as an optimisation for the expected "average" use of SQLobject. [06:23] If the result set is small enough, and is going to be entirely consumed, fetching it all at once probably is a small win. [06:23] But I don't think I like the tradeoff. [06:23] And I definitely don't like the lack of tests :) [06:23] I wonder if it is a transaction isolation type issue [06:24] The history of that function has flip-flopped on this, I think. [06:24] or to cover some issue of iterating over a result set while modifying those rows [06:25] I vaguely recall there used to be a comment that actually justified the call to list(...) [06:25] Or rather, iter(list(...))) [06:27] jamesh: See dbconnection.py:635 in our sqlobject snapshot [06:27] Which sort of does the same thing, and says: [06:27] # We can't keep the cursor open with results in a transaction, [06:27] # because we might want to use the connection while we're [06:27] # still iterating through the results. [06:27] # @@: But would it be okay for psycopg, with threadsafety [06:27] # level 2? [06:28] So maybe it is to allow "for result in Foo.select(...): do_another_query(result)"? [06:28] (In which case there should be a test for it, dammit!) === mpt_ [n=mpt@219-89-158-224.jetstart.xtra.co.nz] has joined #launchpad === jsgotangco [n=jsg@210.4.38.43] has joined #launchpad === mpt__ [n=mpt@219-89-158-224.jetstart.xtra.co.nz] has joined #launchpad [06:52] whoo, I now have DNS [06:53] TCP here we come === mpt__ is now known as mpt [07:00] Average use? Toy use more like. [07:02] Although for us, if we ever actually want to call __iter__ on a SelectResults containing more than 100 items or so then our code is broken. [07:04] Cause that would indicate performance issues on the webapp. Batch jobs might have use cases, but I suspect that it would just be asking for memory bloat problems. [07:04] stub: we'd want to for /distros/ubuntu/+allpackages [07:05] or other pages primarily aimed at spiders [07:05] jamesh: We can't list all packages on one page - it is broken [07:05] jamesh: ZPT just isn't fast enough. spiders are happy following links. [07:06] I suppose so [07:06] We might have a large batch size, but no batch size is just a scalability problem waiting to be triggered. [07:06] and if we're just interested in spiders, something like google site maps might be more appropriate [07:07] spiv, jamesh: the stuff you point out about sqlobject upstream worries me [07:07] Google would be more likely to pay attention to properly batched pages anyway. A huge page full of 10,000 odd links looks like someone attempting to futz with their googlerankings. [07:07] it looks like the project is actively moving in the direction of being just for noddy applications. [07:08] stub: To be fair, that's pure speculation on my part === stub tries to work out what spiv was speculating [07:09] stub: That it was an optimisation [07:09] Or should I say, "optimisation" ;) [07:10] stub: It's possible it's meant as a way to avoid holding a cursor open when something else may want to use it in the middle of an iteration, maybe. [07:10] SteveA: on the subject of join columns, they seem to be moving to more scalable versions (SQLRelatedJoin, OneToMany, etc) [07:10] cursor sharing and iterating over results across multiple transactions seem more likely to me. [07:11] Merge to devel/launchpad/: [trivial] Updates required for serialization and deadlock handling in upstream psycopgda, and tests (r3128: Stuart Bishop) [07:11] (the answer to the first being don't be so stingy with cursors. The second is trickier if you really want to support it. We don't do it in Launchpad because it is scary) [07:15] jamesh: that's good to hear. things i'm concerned about are test coverage, leaving broken tests checked in, lack of rationale in commit logs for changes [07:16] as well as not considering large datasets [07:18] Upstream is really just the work of one developer at the moment (Oleg). Nothing to stop us contributing, although not all of our work has been wanted (we didn't convince upstream that selectOne was a good idea, them prefering to leave the burden of getting it right up to the developer) [07:18] SteveA: I suspect the tests pass with their default backend, sqlite. [07:19] stub: Oleg was ambivalent on selectOne after lots of people on this list piped up and said they wanted it [07:19] stub: there is something equivalent to selectOne() in there now [07:19] stub: And since then SelectResults has sprouted a getOne with a similar meaning [07:20] stub: rather than Table.selectOne(...), you do Table.select(...).getOne(None) === stub tries to decide what syntax he prefers [07:20] slightly more verbose, but it covers both the select() and selectBy() variants [07:20] and anything else that returns a SelectResults [07:21] SteveA: I'm being rained out. Ok if I take my public holiday next Monday? === stub sods off to lunch [07:25] stub: oleg? broyntmann? [07:25] not ian bicking anymore? [07:26] Oleg is much more active on the lists, at least. [07:26] I get the feeling Ian is a bit more of a ceremonial leader, and Oleg does more of the dirty work. Ian still does stuff, though. [07:27] i wonder if oleg lives anywhere near me [07:28] spiv, jamesh, mpt: i'd like to have a series of phone calls or skype calls with you (one at a time) to catch up with what's on your todo lists, what you're blocked on and that kind of thing === mantiena-baltix [n=vytis@bonamens.lt] has joined #launchpad [07:34] oleg is in moscow, so not *so* far away [07:35] kaip gaila, kad a nekalbu rusikai === ulinskie is back (gone 03:45:43) [07:38] SteveA, currently I'm blocked hacking-wise on https://launchpad.net/distros/ubuntu/+ticket/363 [07:39] well, push-/pull-wise, anyway === lbm [n=lbm@cpe.atm4-0-1301006.0x50a0824e.vgnxx6.customer.tele.dk] has joined #launchpad [07:53] mpt: let's spend a couple of minutes trying to get your network back up [07:53] but on a different channel [07:53] /join ##wpa-supplication === mpt [n=mpt@219-89-155-139.jetstart.xtra.co.nz] has joined #launchpad [08:25] do launchpad submissions get announced in any #channels ? [08:28] submissions? [08:28] some stuff gets announced here by dilys [08:34] what's that? [08:36] dilys is an irc bot that recieves notifications when certain things happen in launchpad [08:36] like when I post a bug - is there a bot somewhre that blerts out "Bug #31285 in synaptic (upstream): "Add repository dialog doesn't close" === mpt_ [n=mpt@219-89-153-216.jetstart.xtra.co.nz] has joined #launchpad [08:43] i just checked the logs. dilys is reporting here merges into the launchpad codebase. [08:43] i'm sure i've seen some ircbot report new bugs filed here before... [08:47] dilys used to report when new bugs were filed === mpt_ wonders what https://launchpad.net/binarypackagenames is good for [09:01] anyone know? === mpt [n=mpt@219-89-153-216.jetstart.xtra.co.nz] has joined #launchpad === irvin [n=irvin@ubuntu/member/irvin] has joined #launchpad === carlos [n=carlos@212.166.228.170] has joined #launchpad [09:23] morning [09:23] hi carlos [09:25] How can I reliably find an URL that uses a particular template? [09:26] Some templates have lp:urls associated with them in the ZCML, but many don't [09:26] in this case, binarypackagerelease-index.pt [09:28] mpt: in general... [09:28] mpt: find what the template is for [09:28] to do this, you need to grep / look inside the zcml or the browser code for that template's name [09:28] I got that far :-) [09:28] like: grep 'foo-bar.pt' zcml/*.zcml browser/*.py [09:29] if it is in zcml, then look at what kind of object the template is used for [09:29] like [09:29] it's for BinaryPackageRelease [09:29] right [09:29] so next, you need to find what URL a binary package release has [09:30] and then put the name of the page for that template on the end of that URL [09:30] well, /distros/ubuntu/hoary/i386/pmount/0.1-1 looks promising [09:30] the easiest way to do that is to look in [09:30] doc/canonical-url-examples.txt [09:30] but it turns out that's handled by distroarchreleasebinarypackagerelease-index.pt [09:30] and look for an example of an IBinaryPackageRelease === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [09:31] The text "BinaryPackageRelease" was not found. [09:32] Maybe this template isn't used at all... [09:32] then such things don't have canonical urls [09:32] another thing to do [09:33] mpt: you could always delete it, and see if any tests fail ;) [09:33] unregister the page the template is used in in zcml [09:33] and then see if tests fail [09:33] spiv: it is registered in zcml, so deleting it will stop functional tests from starting [09:33] spiv: voice call? [09:33] lunch [02:15] carlos: ok, try to work with this separated test (less moving parts) then I can help you on demmand, by copying it in my tree everytime you need me to run it for you [02:23] cprov: your test works here [02:23] so It's a matter of fixing the missing pmount package and I suppose that's all [02:23] thank you [02:23] carlos: fine, sort out the missing source [02:24] carlos: yes yes, be happy ;) === doko_ [n=doko@dslb-084-059-106-239.pools.arcor-ip.net] has joined #launchpad [02:36] could somebody enlighten me, why gcj-4.1_4.1ds8-0ubuntu8 was rejected with "Uploads to dapper are not accepted." ? [02:38] stub, around? [02:41] do that's a good one [02:41] doko_: ^^ === carlos_ [n=carlos@62.87.118.166] has joined #launchpad [02:42] cprov: hi, sorry, my line went down [02:42] Kinnison: ? [02:42] cprov: did you see my question? [02:43] doko_: when did that reject happen? [02:43] carlos_: nop, type it again, please [02:43] cprov: I checked it and I already have a pmount sourcepackage in our sample data [02:43] Kinnison: solved, that was still jackass ... [02:43] cprov: so I suppose it's missing s source upload into the system, right? [02:43] doko_: oops :-) [02:44] carlos: not for dapper, I guess [02:44] cprov: what's the table to do that? [02:44] cprov: I thought the SourcePackage object was created automatically [02:44] from the SourcePackageName and DistroRelease [02:45] carlos: uhm, nop ... there is no SourcePackage in DB world, but a SourcePackageRelease published in a given DistroRelease === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:46] cprov: ok [02:46] carlos: query SourcePackagePublishing, for a that name and that version within dapper distrorelease. [02:47] soyuz testing is really a pain in the ass.... === carlos -> lunch [02:47] will do that after lunch [02:47] cprov: thanks [02:48] carlos: I'll be here to help you [02:48] cprov: when are you going to merge your branch? [02:49] see you later === dsaa [n=dsaa@210.213.84.183] has joined #launchpad [02:49] carlos: in RF ? no established ETA yet, depends on the reviewer's === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #launchpad [02:50] so it's ready to review, right? [02:50] ok === _mvo_ [n=egon@pD951DF50.dip0.t-ipconnect.de] has joined #launchpad [02:57] salgado: pong [02:59] hi stub, I'm having some issues trying to write a sql query. can you give me some help? [03:01] salgado: sure [03:03] so, we have the MirrorProbeRecord, where we store when a mirror was last probed (together with the log file). I need to do a query to get the mirrors that need probing. these should be the mirrors that were never probed or that were probed more than N hours ago === BjornT heads out for a while [03:07] stub, https://chinstrap.ubuntu.com/~dsilvers/paste/fileJX1jTn.html is what I have so far, but I think that's not the right way to do it. apart from the fact that it won't do what I want [03:11] salgado: Does https://chinstrap.ubuntu.com/~dsilvers/paste/file1ArzpA.html give you the results you want? [03:13] use 'is true' btw instead of = true === carlos_ [n=carlos@84.76.255.40] has joined #launchpad [03:14] salgado: https://chinstrap.ubuntu.com/~dsilvers/paste/file6uGRaw.html with the 'enabled' flag check [03:16] stub, yeah, that seems to does the job. I'll write a test just to make sure. thank you! === mpool [n=mbp@57.16.168.202.velocitynet.com.au] has joined #launchpad [03:19] thanks for making the login timeouts more reasonable! === kiko [n=kiko@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [03:20] morning [03:21] hi kiko [03:21] i was just saying [03:21] "thanks for making the login timeouts more reasonable!" [03:22] anyhow, goodnight [03:24] enjoy both [03:26] stub, rollout planned for tomorrow? what revno? === LarstiQ seconds mpool [03:31] hey kiko. I think I've come up with a pretty simple macro API for keeping the search filter, than I can land (or get into code review at least) today including giving +assignedbugs the new look and feel, and possibly having time to migrate another of the reports today. should i do it, or should i still drop it? [03:31] that's interesting [03:31] if it's simple, give me an overview of how it works [03:33] the macro would expect certain variables (default nothing): status_filter_links, searchtext, package, etc. it would use tal:conditions to know which of these need to be rendered. the views could have a base mixin class for common filter criteria extraction, and could specialize as needed. [03:35] actually, it would be more like searchtext_filter_link and package_filter_link [03:35] how would the view provide these variables? [03:37] kiko: the view for +assignedbugs wouldn't bother providing package_filter_link, where the view for +packagebugs would provide it with a method, like getPackageBugsFilterLink => tal:define="package_bugs_filter_link view/getPackageBugsFilterLink" [03:37] kiko: I'm thinking of r3123 with r3128 cherry picked [03:39] bradb, it might be easier for the macro to use the view directly [03:39] kiko: But I'm open to opinions [03:39] kiko: It could do. [03:41] kiko: r3126 should probably go out too [03:41] stub, that sounds like a good plan, though I'd try to pick r3126 too -- basically let the support tracker stuff bake. [03:41] right [03:42] matsubara has a fix for bug 31158 that might be nice too, if we can land it now [03:42] malone bug 31158 in soyuz "BinaryPackageRelease page is crashing because of portlet details" [Normal,In progress] http://launchpad.net/bugs/31158 [03:54] holy shit... [03:55] the sourcepackage field in productseries is just plain wrong... [03:55] a series can be associated to multiple source packages... [03:57] see database.ProductSeries.setPackaging [03:57] what does the field link to? [03:57] it's not actually a field in the database [03:57] it's an input in the series/+source form [03:57] in the database is something that exists somewhere in the packaging tables [03:58] packaging sounds right, though [03:59] look at database.ProductSeries.setPackaging [03:59] that will update any number of existing associations, or create a new one... [04:00] looks to me like a simple text input is not the right UI for that kind of functionality... [04:00] nevermind it has nothing to do with RCS imports... === LarstiQ [n=larstiq@cust.7.157.adsl.cistron.nl] has joined #launchpad === kiko scratches head [04:01] don't scratch too hard, or you'll end up with no HEAD again ;) === kiko [n=kiko@200-171-140-32.dsl.telesp.net.br] has left #launchpad ["Left] === kiko [n=kiko@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [04:04] what happened? [04:04] anyway [04:04] bradb, I think you should leave the filter stuff for later. [04:04] kiko: ok [04:04] it sounds like it will get in the way, and if we centralize the forms it is easy to add it in to the single central location, later. [04:05] stub, are you on vacation today? [04:05] I'm removing it on a separate branch then, so that we can get the code back if needed, whilst not leaving it sit there unused in the codebase. [04:05] sounds good [04:06] bradb, what did bug 3123 actually fix? [04:06] malone bug 3123 in python-numeric "python-numeric-tutorial package does not depend on python2.3 but requires it" [Normal,Confirmed] http://launchpad.net/bugs/3123 [04:06] oops sorry [04:06] bradb, what bug did r3123 actually fix? [04:07] kiko: Just the bug in the errors report. I couldn't find a bug report open for it. [04:07] kiko: sort of [04:07] bradb, how did it happen? [04:07] a null bugtask delta? [04:08] stub, cprov wanted to ask you to do some work on mawson if you could [04:08] cprov, email stub of the details, is my suggestion, anyway [04:08] kiko: nevermind, I'm talking with him === BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad [04:09] kiko: The BinaryPackageName vocabulary was returning an int instead of the BPN object, so in the specific case where a BPN is filled in for a task, it can look like a change was made when one wasn't, and thus it gets processed through the change machinery, causing an empty task delta. [04:09] Because the code that checks if a change was really made would be comparing a BPN id to a BPN object [04:10] I see [04:10] bradb, do you think it happened when changing a bugtask's binary package name? [04:11] no, that would accidetally work correctly [04:11] i /think/ it happens when you submit a "Comment on this change" without having changed anything. [04:11] so what would crash? not changing it? :) [04:11] I see [04:12] Normally you get an error that says that you submitted a change comment without changing anything. [04:13] cprov, did Kinnison manage to finish off the work to support pockets? [04:13] non-release pockets, in particular [04:13] stub, do you know if anyone is working on the fix for boolean columns? [04:13] Kinnison: not yet, we are working on it [04:14] I see [04:15] kiko: I'm looking at that tomorrow [04:18] stub, thanks [04:27] stub, in your reply to the Vocabulary... email I sent, I had two questions [04:27] a) did you do any code changes or would you like to delegate this to salgado? [04:28] b) how do you "redo the ORDER BY" to use the index? === Alinux [n=Ubuntu@d81-211-224-82.cust.tele2.it] has joined #launchpad [04:32] stub: can you set the owner of https://launchpad.net/people/ddaa/+branch/gnome-app-install/main and https://launchpad.net/people/ddaa/+branch/update-manager/dev to mvo, please? [04:33] (using "admins" priv) [04:34] ddaa, is there no "reassign" yet? [04:34] hello, when Dapper's lauchpad import ? [04:35] kiko: you mean somethnig like bug #29863 ? [04:35] malone bug 29863 in launchpad "Workflow to transfer ownership" [Wishlist,Unconfirmed] http://launchpad.net/bugs/29863 [04:36] kiko: as far as I know, there is nothing to implement any of the use cases. === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [04:36] kiko: there is Branch.author, but it's for a different use case. === Alinux is now known as AlinuxOS [04:38] ddaa, that's what I was referring to. it would be nice to have.. [04:38] kiko: well, it's not going to happen soon since it was marked as wishlist... feel free to expand on the strawman I proposed. === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [04:39] kiko: in the meantime, an admins intervention is required. === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === ubuntulog [i=ubuntulo@trider-g7.fabbione.net] has joined #launchpad === Topic for #launchpad: Datacentre migration, services down | launchpad.net | developer meeting: Thur 16 Feb, 1200UTC (wiki:MeetingAgenda) | launchpad-users@lists.canonical.com (wiki:MailingLists) | Channel logs: http://tinyurl.com/72w39 === Topic (#launchpad): set by lifeless at Sat Feb 11 23:58:55 2006 === fabbione [i=fabbione@gordian.fabbione.net] has left #launchpad ["Ex-Chat"] [04:51] Merge to devel/launchpad/: [trivial] required MirrorProbeRecord indexes (r3132: Stuart Bishop) === fabbione [i=fabbione@gordian.fabbione.net] has joined #launchpad [04:54] mvo: your branches are set up and linked from the productseries, now you just need an admin to make you the owner of the branches. [04:54] here is the list of people you can nag: https://launchpad.net/people/admins [04:54] ddaa: thanks [04:55] I had to file like 3 or 4 new bugs related to that user's email... [04:56] mvo: can you handle replying to launchpad-users? [04:56] ddaa: hm, clicking on https://launchpad.net/products/update-manager/+series/main gives me a oops [04:57] what... the... [04:57] ddaa: I'm not on launchpad-users, sorry. my mail awaits moerations there too === ddaa cries [04:57] ddaa: OOPS-44A491 if that helps [04:57] https://chinstrap.ubuntu.com/~jamesh/oops.cgi/44A491 [04:57] I'll approve [04:58] FUCKING BUGGY PRODUCTSERIES DIE DIE DIE [04:58] here's what you get when you have functionality with no owner, no use case, and nobody who cares... [04:59] mvo: I'll clear the ProductSeries.branch, I bet that's the culprit... [04:59] I sort of believe that field was actually never used [04:59] ddaa: I answered the mail "gnome-app-install, update-manager sources?" on ubuntu-desktop/launchpad-users now [04:59] ddaa: thanks for tracking that issue [05:00] mvo: fixed [05:00] holy fuck [05:01] mvo: thanks a lot, you helped me uncover a critical bug I needed to be aware of for the bzr transition. [05:02] this transitions starts to really feel like bug slalom, or dodging bugllets, or whatever... [05:02] I mean really, all the bugs in the system are the main design constrainsts... [05:03] ddaa: thanks, I can see the bazaar branch now (but the old cvs branch is still there too) [05:04] mvo: sure, it's still being updated, I see no reason to remove it [05:04] Arguably, it should not be in the productseries, but I filed a bug about that. [05:05] ddaa: it's not used for development anymore, maybe it can be moved to a less prominent place? [05:05] ddaa: or renamed to "OLD" or something? [05:05] rename the productseries to OLD? [05:05] man, it's your main productseries... [05:06] ddaa: it isn't anymore, the main one is the bzr branch. and I seem to be unable to change that myself [05:06] it's your main productseries [05:06] productseries contains rcs import [05:06] that's a bug in my opinion [05:06] you cannot have rcs import w/o productseries [05:07] we will be able to clear up the rcs details when the bzr branch for the import is registered and published, but right now it would cause the data to just never be converted. [05:07] well, actually it's probably already converted, but won't be published [05:07] We can do that if you think it's right not to publish the bzr branch for that RCS import. [05:08] ddaa: re your bug: [05:08] "not possible" -- the UI doesn't support it? [05:08] or it's a permissions problem? [05:08] daf: which bug, which "Not possible"? [05:08] all the fuss started because CVS is no longer my main branch for u-m and g-a-i. I would be happy to change that myself in launchpad but apparently I'm unable to. so I would like to have some way to indicate that it is no longer the mainline [05:08] ddaa: bug #31308 [05:08] malone bug 31308 in launchpad "Cannot set branch associated to a productseries" [Normal,Unconfirmed] http://launchpad.net/bugs/31308 [05:08] "t's currently not possible to set the branch associated to a productseries." [05:09] daf: there's no UI for that. And actually the productserie page OOPSes when you set the branch with sql. [05:09] Will comment on the bug. [05:09] thanks [05:09] including an OOPS reference might be helpful [05:09] mvo: I understand that, but the "main branch" concept in launchpad is current braindead. [05:10] add in an importd bug [05:10] ddaa: so there is no way to change a "main branch" once it was setup? (with the current lp)? [05:10] mvo: so the only options I can give you is either leave the productseries as it is, or clear the RCS details and never have the RCS import updated again and never have it published as baz. === mvo weeps [05:11] mvo: there's no main branch concept in launchpad. There is a main productseries. [05:11] mvo: I weep too [05:11] this stuff is braindead [05:11] ok, please keep it as it is then people in gnome-cvs translate there it would be good to have that stuff importet [05:11] I just did not realise how serious it was before we had the ability to register branch... [05:12] I will add some comment in the bzr branches stuff and hope that interessted people read it and get the bzr stuff instead of the cvs one [05:13] mvo: I'm really sorry for the trouble, but when I told you the rcs import stuff was in dire shape I was not weening. I just know how seriously broken it's broken, and you just happen to hit most of road bumps (and find some new ones too). [05:13] mvo: in that sense, you are an invaluable help to me :) === Ubugtu [n=bugbot@ubuntu/member/seveas] has joined #launchpad [05:15] ddaa: ok, thanks. I'm happy that it will help fixing the issues. I will be able to work around the issues until then :) [05:26] Merge to devel/launchpad/: Fixes https://launchpad.net/products/soyuz/+bug/31158 (BinaryPackageRelease page is crashing because of portlet details) r=kiko (r3133: Diogo Matsubara) [05:30] cprov: ok, so I have the sourcepackagerelease but it's still failing [05:31] cprov: I think it's related to the manifest entry I choosed [05:31] carlos: manifest isn't really important, IFAICS [05:31] cprov: let me show you the new test [05:31] kiko: https://launchpad.net/products/launchpad/+bug/31287 Could you try to access this bug? [05:32] carlos: sure [05:32] cprov: https://chinstrap.ubuntu.com/~dsilvers/paste/file7CyY91.html [05:35] carlos: right, you have to create a Build for amd64 arch [05:35] carlos: and pass it via to the policy [05:35] how? [05:36] carlos: spr.createBuild() [05:36] ok [05:37] matsubara, targetname is forbidden to me. [05:37] carlos: also to publish the just-created sourcepackagerelease [05:37] stub, r3133 would be nice as well, soyuz topcrasher [05:37] kiko: same with me and salgado. [05:39] daf: I commented on bug 31308 [05:39] malone bug 31308 in launchpad "Cannot set branch associated to a productseries" [Normal,Unconfirmed] http://launchpad.net/bugs/31308 [05:41] bradb, can you check on permissions for bug 31287? seems busted. === bradb looks [05:43] hm, weird [05:43] not only weird, it's a bug :) [05:43] or perhaps not, but.. [05:44] yes, almost surely a bug === BjornT_ [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad === bradb tries to reproduce locally [05:45] isn't that a bug that was filed as private? [05:46] it might have been, but are there no subscribers? [05:46] it's almost surely a privacy-related bug. i'm just trying to confirm that it is what i think it is. [05:50] reproduced locally [05:50] It would have been easy to overlook before because most of us were admins. [05:50] thank god somebody decided to revert that, but matsubara and salgado were never admins that I know of [05:51] they probably weren't looking at a lot of private bugs [05:51] there aren't many for LP [05:51] tru [05:51] add test and fix and we can cherry-picketh [05:51] yeah [05:52] what would be the fix for that? (just curious) === hannosch [i=hannosch@e176104125.adsl.alicedsl.de] has joined #launchpad [05:53] This is actually already tested in the privacy stored, and perms denied is the right error here, but the perms denied appears to be happening when rendering the ZPT, instead of when traversing the URL, which causes it to spit out an exception, instead of a human-readable "not allowed here" type page. [05:54] s/privacy stored/privacy story/ [05:54] salgado: I /think/ the error may be in the page perms config, but I'm verifying that now. [05:55] right, but I'd expect that the launchpad team would've been subscribed to that bug when it was filed [05:55] salgado: Not if it were reported private. [05:55] The SecurityTeams spec is set to address this hostility. [05:55] ah, right [05:57] right, here's the problem: [05:57] for="canonical.launchpad.interfaces.IBugTask" [05:57] class="canonical.launchpad.browser.BugTaskView" [05:57] permission="zope.Public"> [05:57] name="+index" [05:57] template="../templates/bugtask-index.pt" /> [05:57] zope.Public, when it should be launchpad.View. [05:58] hey stub? [05:58] Merge to devel/launchpad/: [trivial] remove the search filter UI. plan to resurrect it at the London sprint. (r3134: Brad Bollenbach) [06:12] kiko: replied to your mail with CC to the launchpad mailing list [06:12] thanks [06:12] kiko: your suggestion was wrong, and I ended up writing a long explanation of why... I thought it would be of interest to other peopel. [06:13] saying "your suggestion was wrong" isn't a good way to garner support... === jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #launchpad [06:15] In Malone, what's the difference between "milestone" in the status field, and targetting a fix at a release? [06:15] jbailey, the latter seems to be a bad suggestion [06:16] jbailey: milestones are a forward-looking goal, targeting a fix to a release is for backport/security fixes. this ui sucks. [06:17] kiko: sorry I did not mean it to get out this way... [06:18] jbailey: Making this UI suck less is on my top 5 priorities list, among some other tasks involving making bug listings/batch/searching suck less. [06:18] Hmm,okay. [06:19] In this case I'm targetting a fix to a release because I'm uploading to -updates. [06:19] So I want to track the upload to Hoary and Breezy separately. [06:19] So it looks like I sould target a fix to the release. [06:19] kiko: put another way "registered branches cannot be a superset of authored branches because there are distinct overlapping sets". [06:19] Thanks for the help. =) [06:19] jbailey: yep, that's right. no prob. [06:20] ddaa, have you considered that it may be that the end-user does not benefit from this separation? [06:20] I have, and they do. [06:20] I can find the specific bug where that was discussed, if you want. [06:20] I've read it. I'm asking because I, as an end-user, see things in a similar manner as the user initially suggested in said bug report. === ddaa goes back to read the bug report [06:21] that going to registeredbranches and not seeing branches he registered /and/ authored is confusing. [06:21] so I'm suggesting that 3 + 2 + 4 might be a better solution [06:21] however [06:21] kiko: that's an interesting solution [06:21] I don't want to discuss this any further than this, as I have a busy Monday :-) [06:22] I'm not dismissing what you are saying now, but what you said initially. [06:23] kiko: so you suggest 1+3 for authoredbranches and 2+3+4 for registeredbranches? [06:23] Is it normal that our "Not allowed here" page shows an exception? [06:23] exactly [06:23] bradb, only for launchpad devels, I think [06:23] kiko: I'm looking at this page with the no-privs user locally. [06:24] kiko: my concern is that I think that the places where the model does not match reality are important to see easily... === bradb tests another page in production to see. [06:24] I'm not really happy with the current trade-off either. [06:24] Hm, but I'm a dev in production, so screw that. [06:24] ddaa, right, I think that /we/ as launchpad people find that distinction important, but I don't know about the end user [06:24] stub: Is it normal that our "Not allowed here" page shows an exception? [06:25] cprov: ok, next step... How could I publish the package? [06:25] it is not normal, bradb [06:25] it should only be so for launchpad devels [06:25] are you sure no-privs is not in launchpad devels? [06:26] Yeah, I checked that: No Privileges Person is not an active member of any Launchpad teams. [06:26] I'm wondering if we also have a config that says always show tb's in dev. [06:26] kiko: you have a point... I guess we'd need to ask users. You know that old rule: when in doubt, do what's most useful to you, then you know it will match the expectations of at least one user. [06:27] carlos: invoke its correspondent IDistroReleaseQueueSource.publish() [06:27] that's reasonable [06:28] carlos: then move the resulted SSPPH to status PUBLISHED [06:28] ok [06:29] kiko: ah, check it out: [06:29] # If the config says to show tracebacks, or we're on the debug port, [06:29] # or the logged in user is in the launchpad team, show tracebacks. [06:29] it all makes sense now [06:29] yeah === rraphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === rraphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [06:45] cprov: this is not working... the queue is empty [06:46] cprov: https://chinstrap.ubuntu.com/~dsilvers/paste/fileCmeZoJ.html [06:46] cprov: the for loop does not executes any iteration === rraphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [06:51] carlos: on sec [06:52] ok [06:52] carlos: you only have DRQ after perform the an upload [06:53] so I need to upload the tar.gz? [06:53] ok [06:53] dude, this is soooo complicate. The test Is getting big and big to just test a small part of the system [06:54] carlos: in fact you need, since you have shortcut the source upload process, to create the SSPPH record by hand as we do in that method I've pointed you [06:54] I suppose that the fact that I don't know the details about soyuz it's the problem here... [06:55] cprov: so what's the right way to do it? [06:56] carlos: add the the SSPPH record by hand, I think, so at the end you'll have the source published [06:56] carlos, cprov: would it be easier for carlos to put things in a directory like the sync process does? [06:56] just place them in a directory [06:56] and run process-upload for a specific policy [06:56] would that work? [06:57] kiko: he'd need real source [06:57] not if you move the source check to the policy [06:57] instead of hardcoding it [06:58] cprov: I have the real source [06:58] kiko: this is not trivial [06:58] carlos: how big ? [06:58] small [06:58] 36104 bytes [07:01] carlos: I'd not run the tools for it, it's expensive and as dificult as doing what you are doing. [07:02] ok [07:02] carlos: concentrated in what you need, as soon as you have the source published you binary upload (already done) will pass [07:02] carlos: will send the SSPPH insert for you, one sec [07:03] ok, thank you [07:03] one sec, let me go up. [07:05] BjornT: For the "API" of a ZPT macro, is it more idiomatic for it to expect certain variables to exist, or for it to expect the view to have certain methods, or does it matter? [07:10] bradb: good question, i'm not quite sure. i would say it depends on the situation, so it doesn't matter that much. choose what seems the easiest thing to do. [07:10] ok [07:16] Merge to devel/launchpad/: [trivial] fix bugtask view permissions so the 'Not allowed here' page shows the correct exception when user visits a private bug without launchpad.View permissions. (This is already tested to ensure that a 403 Forbidden is raised.) (r3135: Brad Bollenbach) [07:18] carlos, I now understand better what you are doing -- simulating a build that uploads translations to rosetta, right? [07:18] kiko: right [07:18] I thought there were tests that did that already,but there are none [07:19] kiko: if the test works, then we can start doing dapper imports [07:19] yeah, I see. [07:19] We have tests for the imports [07:19] but not for builds :) [07:19] but not for the glue between soyuz and rosetta [07:20] right [07:20] carlos: wth -> (16:19:50) carlos : I'm not here ;) [07:20] oh, sorry [07:20] carlos: don't you receive priv ? [07:21] yes, I do === jinty [n=jinty@196-28-44-233.jhb.netdial.co.za] has joined #launchpad === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has left #launchpad [] === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad === SteveA [n=steve@195.182.78.95] has joined #launchpad [07:35] ddaa, do you know if permissions are broken in https://launchpad.net/products/gnome-app-install/+series/main/+addpackage -- ? [07:35] ddaa, I'd like product owners to be able to add those links.. [07:35] dunno about this page... [07:35] but I think there's alread a package for gnome-app-install... [07:36] https://launchpad.net/products/gnome-app-install/+packages [07:37] There's a bug about this being hidden and useless: bug 31319 [07:37] malone bug 31319 in launchpad "Association between source package and product is not discoverable" [Normal,Unconfirmed] http://launchpad.net/bugs/31319 [07:38] is it useless? [07:38] or just too hidden to be useful? [07:38] useless for navigation [07:39] and, well, too hidden to be useful, too... [07:39] the table is not hyperlinked === lfittl [n=lfittl@85-125-145-79.dynamic.xdsl-line.inode.at] has joined #launchpad [07:50] cprov: ok, next step done [07:51] but I keep getting "Policy permits only one build per upload." [07:52] carlos: pass the build.id to the policy [07:52] right, I forgot that... sorry [07:53] cprov: you have admins superpowers [07:53] ddaa: yes, I have [07:54] can you give mvo ownership of https://launchpad.net/people/ddaa/+branch/update-manager/dev and https://launchpad.net/people/ddaa/+branch/gnome-app-install/main please? === mvo hugs ddaa [07:54] and maybe sets the name of the latter to "dev" for consistency, too === mpt [n=mpt@219-89-153-216.jetstart.xtra.co.nz] has joined #launchpad [08:06] cprov: hmmm... sorry but I don't see a way to link the build with the policy.... [08:06] ddaa: mvo: check it, please [08:08] carlos: one sec ... (set MockOptions().buildid = build.id [08:08] cprov: looks right, thank you [08:08] ddaa: you're welcome [08:09] carlos: you need to use buildd policy too [08:09] cprov: thanks, looks good === merriam [n=merriam@84.12.81.236] has joined #launchpad [08:11] cprov: buildd policy? [08:12] carlos: instead of anything [08:13] ok [08:13] I need to go out for 15 minutes when I'm back I will try that [08:13] cprov: thank you very much! [08:20] kiko: re product preload, I think it's just because this guy is bored. http://jarufe.monkey.cl/ [08:21] that may be [08:22] http://foros.tux.cl/viewtopic.php?p=11114&sid=e6af236771b13b61fb98ec83fef51e2e [08:23] I think this guy needs a dating site more than launchpad. [08:23] carlos: when you get back, see this test prototype -> https://chinstrap.ubuntu.com/~dsilvers/paste/filefNbWHF.html, hope it does what you want [08:24] I'm back [08:26] cprov: that's more or less what I did. Thanks! [08:26] carlos: good, did you see that test .. have isolated you tarball. [08:26] carlos: how are you going to process it now ? [08:27] carlos: don't forget to abort the transaction when you finish you test (I forgot) [08:27] cprov: we have code in place for that [08:28] so it's a matter of checking the translation import queue to know if the import was done [08:28] carlos: I'm pushing my branch, you'll need it for a small fix in DRQ interface [08:28] ok [08:29] carlos: tricky, I'm curious to see how your things will work, maybe in the next conference ;) [08:29] cprov: it's easy, Kinnison did a hook on soyuz for translations, let me check where is it... [08:29] matsubara, how's it going? [08:30] DRQC.publish() [08:30] carlos: ^^ [08:31] cprov: yes === merriam [n=merriam@84.12.81.236] has joined #launchpad [08:31] cprov: publish_ROSETTA_TRANSLATIONS [08:32] carlos: the magic is in spr.attachTranslationFiles() [08:32] oh, you want those details? [08:33] then best for the next conference, or at least not today... I wan to finish this today and stop. [08:33] kiko: wanna take a look of what I have so far? [08:33] carlos: sure, as I said, next conf ;) [08:33] matsubara, what are you working on? [08:34] carlos: let me know if you need any other help with upload-and-queue system [08:35] cprov: I don't think so, If this triggers Kinnison's hook, that's all I need. Next step is Rosetta specific [08:35] kiko: that broken traversal on build problem, and trying to fix a portlet on binary package release page [08:35] cprov: thank you very much for your help [08:35] The test is passing now [08:35] It's time to test my Rosetta stuff ;-) [08:35] carlos: anytime [08:38] carlos: good luck ! [08:38] kiko: I think I construed a convincing scenario of what happened with "prelink", and came to an interesting conclusion. [08:38] thanks! [08:38] matsubara, the broken traversal thing should be trivial [08:38] kiko: it's already fixed. [08:39] where's the patch === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad [08:41] hmm [08:41] kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/fileADvMEg.html [08:41] cprov: I need some extra help. I cannot create the entry published as the hook is executed when we publish it [08:42] hmm [08:42] carlos: ?? again, I lost the track [08:42] sorry [08:42] the source code is published [08:42] then, I upload a binary [08:42] and execute .process() [08:43] right [08:43] but the publish hook are not executed === carlos talks about queue.py code [08:44] carlos: wait you need to execute DRQ.publish() [08:44] carlos: in fact DRQC.publish() [08:44] daf, matsubara: hi guys. [08:45] instead of NascentUpload.process() ? [08:45] hi SteveA [08:45] or before it? [08:45] i have received a user-support request by email. someone needs to sign the CoC in launchpad, but is having trouble doing so. [08:45] i'll reply to the email, and cc matsubara and daf on it. okay? [08:45] you can sort out between you who will reply [08:47] carlos: no, that is right, leave it there, since you have upload an NEW bin to dapper you need to accept then the 'process-accepted' can publish it or by hand you can directly publish it [08:48] carlos: I'm extending the test for you [08:48] ok [08:50] SteveA: ok [08:54] carlos: add this before kill librarian 'queue_item.customfiles[0] .publish(MockLogger())' [08:54] carlos: spr.attachTranslationFiles() is broken [08:54] thanks [08:55] cprov: that's the point for this ... [08:55] carlos: I see :) [08:55] cprov: from where could I get queue_item? [08:55] Oh, I have it already [08:55] sorry [08:56] carlos: yup [08:57] cprov: ForbiddenAttribute: ('customfiles', ) [08:58] carlos: (17:28:11) cprov: carlos: I'm pushing my branch, you'll need it for a small fix in DRQ interface [08:58] carlos: you need my branch or fix it by hand in yours [08:58] oh [08:58] ok [08:58] that's the fix === carlos merges [09:00] carlos, buenas dias :) [09:01] when there will be Dapper in Rosetta ? :) [09:01] AlinuxOS: hola :-) [09:01] ;) === _mvo_ [n=egon@pD951DF50.dip0.t-ipconnect.de] has joined #launchpad === dsas [n=dean@host81-129-228-69.range81-129.btcentralplus.com] has joined #launchpad === mpt [n=mpt@219-89-153-216.jetstart.xtra.co.nz] has joined #launchpad [09:25] hi, there are two teams in launchpad that are seemingly the same team. One has the various members of the doc team as members, but no packages, the other has the tech board as a member but no-one else and owns the doc packages [09:26] The teams being ubuntu-doc and ubuntu-doc-lists, should the two teams be merged together? === ajmitch_ [i=ajmitch@port163-136.ubs.maxnet.co.nz] has joined #launchpad [09:33] dsas, you'd better discuss that with the members of those teams === bradb heads off, later all === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has left #launchpad [] [09:35] well Corey Burger of the docteam said it seems that it's likely, I'll ask someone from the tech board too. === Alinux [n=Ubuntu@d81-211-214-77.cust.tele2.it] has joined #launchpad === Alinux [n=Ubuntu@d81-211-214-77.cust.tele2.it] has left #launchpad ["Ex-Chat"] === cprov points the joke of the day: ... drescher.ubuntu.com (82.211.81.167): icmp_seq=13 ttl=48 time=3802 ms [10:01] Seveas: there's no need for a merge afterall, sorry. === mpt [n=mpt@219-89-153-216.jetstart.xtra.co.nz] has joined #launchpad === lfittl [n=lfittl@85-125-145-79.dynamic.xdsl-line.inode.at] has joined #launchpad === _dsas [n=dean@host81-129-228-69.range81-129.btcentralplus.com] has joined #launchpad === _dsas is now known as dsas === luka74 [n=luka74@clj46-234.dial-up.arnes.si] has joined #launchpad [10:39] Is Malone down? I get error: OOPS-44C718 when trying to submit bug [10:39] https://chinstrap.ubuntu.com/~jamesh/oops.cgi/44C718 [10:39] (or just clicking on "Choose..." for package) [10:40] luka74: known problem, that is bug 30979. [10:40] malone bug 30979 in malone "Oops in popup to select a Ubuntu package" [Normal,Fix committed] http://launchpad.net/bugs/30979 [10:41] let me see [10:41] luka74, this should be fixed in production by tomorrow noon UTC [10:42] OK, actually on "Add" bug I get different code: OOPS-44D752. [10:42] https://chinstrap.ubuntu.com/~jamesh/oops.cgi/44D752 [10:42] (I try to add bug to "linux-image" package) [10:50] Seveas: how does Ubugtu know where the traceback of an OOPS ? [10:50] godamn this annoying package thing [10:51] sivang, it just uses a hardcoded URL [10:51] Mez, what's p? [10:51] Is there a simple way in malone to import a bug from debian's PTS [10:51] kiko: pacakge was the wrong word [10:51] I meant GPG sig thing [10:51] oh. [10:51] sivang, OOPS-(?P\d+[a-z] \d+) -> https:://chinstrap.ubuntu.com/~jamesh/oops.cgi? + match.group('oops') [10:52] I don't think debzilla has been ported yet. [10:52] kiko: damn - It's annoying cause am using malone as central bug tracking - want to bring in bug from debia n -have to make it myself then link [10:53] that's annoying, yeah. I need to check with mdz what the status is on debzilla, if he needs us to port it. [10:53] Seveas, I'm assuming the OOPS lookup is meant to be protected? [10:54] BTW: submit to "linux-686" package works - strange! [10:54] protected? [10:54] kiko: looking at https://chinstrap.ubuntu.com/~jamesh/oops.cgi asks me for username and password [10:55] chinstrap is private, yeah [10:55] we need to move this stuff elsewhere [10:55] reason it's private is just that it shares responsibility with other apps === ogra [n=ogra@ubuntu/member/ogra] has joined #launchpad === dsas [n=dean@host81-129-228-69.range81-129.btcentralplus.com] has joined #launchpad === mpt [n=mpt@219-89-153-216.jetstart.xtra.co.nz] has joined #launchpad [11:26] Can somebody check out https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-13/D752 and file a bug as relevant? [11:26] BjornT or SteveA or mpt or someone? [11:27] gone! === lbm [n=lbm@x1-6-00-13-10-7a-d1-e4.k233.webspeed.dk] has joined #launchpad