=== Diablo-D3 [i=diablod3@pool-70-105-244-199.port.east.verizon.net] has joined #launchpad [12:08] hey guys [12:08] is there any way to search all of malone for something? [12:11] Diablo-D3, seems not possible ... [12:11] no kidding === Nafallo is now known as Nafallo_away === spiv [n=andrew@adsl-66-203.swiftdsl.com.au] has joined #launchpad [12:34] Diablo-D3, there is currently no way to search all of malone or in fact, any part of LP [12:36] ... damnit. [12:37] I should be able to search for "powernow-k7" and get all bugs that have that in the summary [12:39] Diablo-D3: https://launchpad.net/malone/distros/ubuntu?field.searchtext=powernow-k7&search=Search&orderby=-priority%2C-severity ? [12:39] (search done from https://launchpad.net/malone/distros/ubuntu) [12:39] how did you do that? [12:40] Which only searches "ubuntu" bugs, rather than all of malone, but that's probably close enough to what you want. [12:40] I got to that search form from the "View Ubuntu Bugs" link on https://launchpad.net/malone [12:40] er, oh hey [12:40] theres a giant search box there === Diablo-D3 somehow missed it [12:41] proof malone's ui is too complex =/ [12:41] Yeah, it seems it's really easy for people to miss things at the moment :( === mpt [n=mpt@202.53.187.9] has joined #launchpad === jinty [n=jinty@G9e5d.g.pppool.de] has joined #launchpad === GoRoDeK [n=gorodek@p5083D932.dip.t-dialin.net] has joined #launchpad === Burgundavia [n=corey@S0106000000cc07fc.gv.shawcable.net] has joined #launchpad === Burgundavia_ [n=corey@S0106000000cc07fc.gv.shawcable.net] has joined #launchpad === mpt [n=mpt@202.53.187.9] has joined #launchpad === Diablo-D3 [i=diablod3@pool-70-105-244-199.port.east.verizon.net] has left #launchpad [] === Nafallo_away is now known as Nafallo === Nafallo is now known as Nafallo_away === thierry_ [n=thierry@modemcable051.65-131-66.mc.videotron.ca] has joined #launchpad === stub [n=stub@ppp-58.10.74.204.revip2.asianet.co.th] has joined #launchpad === mpt [n=mpt@219-89-150-86.jetstart.xtra.co.nz] has joined #launchpad [06:10] spiv: Can I get a review? https://chinstrap.ubuntu.com/~dsilvers/paste/fileTmiueF.html [06:10] I'm heading our for lunch, but will be back in about an hour [06:11] It is the celebrities optimization stuff [06:11] stub: Sure. === siretart [i=siretart@ubuntu/member/siretart] has joined #launchpad === GoRoDeK [n=gorodek@p5083D932.dip.t-dialin.net] has joined #launchpad === jinty [n=jinty@Gb5c5.g.pppool.de] has joined #launchpad === stub [n=stub@ppp-58.10.74.204.revip2.asianet.co.th] has joined #launchpad === fabbione [i=fabbione@gordian.fabbione.net] has joined #launchpad === lbm [n=lbm@cpe.atm4-0-1301006.0x50a0824e.vgnxx6.customer.tele.dk] has joined #launchpad === mpt_ [n=mpt@219-89-150-86.jetstart.xtra.co.nz] has joined #launchpad === BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad === southfoxargentin [n=fox@200-122-34-77.dsl.prima.net.ar] has joined #launchpad [08:57] hello === carlos [n=carlos@167.Red-83-53-71.dynamicIP.rima-tde.net] has joined #launchpad [08:58] morning [08:59] stub, hi, when and at what time the staging DB mirror ends? [09:00] staging db mirroring is currently disabled for publisher testing. You need it updated? [09:03] The gimp baz2bzr conversion is driving me crazy [09:03] it has been giving an estimated time left of 140 hours [09:03] stub, Oh, I assumed that as launchpad_carlos db disappear staging was being updated as usual... [09:03] for five days... [09:03] It disappeared? [09:04] I got errors while trying to connect to it [09:04] let me check again... [09:04] carlos: oh - it was likely never upgraded from 8.0 [09:04] carlos: I'll create you a fresh one [09:04] stub, thank you [09:04] stub, could you update it weekly? [09:04] to generate weekly language pack snapshots [09:05] carlos: Still not ready to trust your scripts on the production db? [09:05] stub, fixing them to move then into production [09:05] You might need to poke me until I automate the restore [09:05] that's why I want to do the snapshots [09:05] ok [09:22] Hola amigos! [09:22] blah, where's SteveA? [09:22] helo sivang [09:22] hey ddaa [09:22] siretart, morning [09:22] hey carlos ;) [09:22] s/siretart/sivang/ [09:23] anyway siretart morning ;-) [09:23] hehe :) [09:23] xchat autocompletation sucks... [09:23] you mean it's not psychic? === stub [n=stub@ppp-58.10.64.209.revip2.asianet.co.th] has joined #launchpad [09:32] ddaa: 14 hours? something must have gone wrong in the calculation there...or bad network? [09:32] No, 140 hours [09:33] and it's not bad network, it's local fs [09:33] and the calculation is fine, it's making progress [09:33] just agonizingly slow progress [09:33] ddaa: does it at at least decline in 10th factor? :) [09:34] just a combination of pathologic "baz replay" and "bzr commit" performances. Many many files, large history. [09:35] The only thing that kills me is that all bets are off for when it will actually complete. [09:35] ddaa: ah, so it's not sure it will complete even after 140hrs? [09:36] ddaa: baz replay "replays" the old branch's history ? [09:36] it applies a changeset [09:37] really, these are boringly arcane details [09:37] and it won't help you to understand the insanity of the Arch command set. [09:43] ddaa: I understand. just feel lucky for having bzr :) [09:45] when somebody has been telling you "I'll be done in six days, I think", every day for a week, how long do you keep one believing that? === ddaa -> nature [09:45] ddaa: heh [09:49] Did anybody try the new rocketfuel docs yet? [09:52] jblack: I am going to try them, *today* even if it costs me all night :) [09:52] all night? [09:52] They should be really easy to use, and be about as quick as rocketfuel can be with bazaar-ng. [09:53] jblack: ofcourse, but slow network, suddenly urgent stuff at work, can push it down until I get home :) [09:53] jblack: I am sure they're as good as they get , or at least close to that. [09:54] jblack: was at work until 2:30am last wedensday, then sick throughout weekend, only now cam back to myself [09:54] jblack: otherwise I would already have tried them :) [09:56] Hey jblack [09:56] should be the launchpad-bzr meeting soon [09:56] at least assuming SteveA manages to be back from vacation in time... [09:56] which I double since it's now meeting - 4 mins. [09:56] * which I doubt === ddaa gives TP to repairman [09:58] where? [09:58] On sunday? [09:59] TP? [10:02] It's monday here, dude [10:03] ThinkPad [10:09] daf: can pull optional-branch-title now [10:09] I do not guarantee the data will not eat your hard drive and take your grandma hostage though. === thisfred [n=thisfred@a80-127-80-154.adsl.xs4all.nl] has joined #launchpad === WaterSevenUb [n=WaterSev@195-23-238-187.nr.ip.pt] has joined #launchpad === koke [n=koke@ubuntu/member/koke] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [10:40] ddaa: heh === sivang attampts the "reversed if clause" and fails === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === koke [n=koke@ubuntu/member/koke] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [11:14] ddaa: bzr claims there's nothing to merge === southfoxargentin [n=fox@200-122-34-77.dsl.prima.net.ar] has joined #launchpad === mpt_ [n=mpt@219-89-150-86.jetstart.xtra.co.nz] has joined #launchpad === Seveaz [n=seveas@ubuntu/member/seveas] has joined #launchpad === stub [n=stub@ppp-58.10.64.209.revip2.asianet.co.th] has joined #launchpad [12:02] review meeting time [12:02] whos art here ? [12:03] i'm here [12:03] I'm here [12:05] ok [12:05] agenda - next meeting time - one week @ this time [12:05] that 30th at 1100 UTC [12:06] Fine with me. [12:06] fine with me [12:06] ok [12:06] queue status - theres 4 outstanding reviews in total [12:06] which is 'under control' IMNSHO [12:08] any new business ? [12:08] All seems good to me. [12:08] no [12:08] oustanding == merge-approved? [12:09] (maybe we should have a new segment in the meeting: silliest code I've reviewed this week ;) [12:11] daf: outstanding = needs-review [12:11] spiv: so my silliest was 'if thing and hasattr(thing, 'foo'): ...thing.foo' [12:11] looking at the Pending Branch Summary page, there's 8 branches in needs-review [12:12] rather than 'getattr(thing, 'foo', sane_default)' [12:12] daf: indeed, I miscounted [12:12] still, under control === niemeyer [n=niemeyer@200.138.131.46] has joined #launchpad [12:13] 2N ~= N? :) [12:13] lifeless: Mine was this: [12:13] + def _empty(self): [12:13] + """Foo.""" [12:13] + raise AssertionError [12:13] lifeless: I think I win ;) [12:13] Morning! [12:13] daf: FSVO 2 [12:14] spiv: unless BjornT has a new one ? [12:14] lifeless: I hope for the sake of launchpad he can't beat that :) [12:14] nope, haven't actually reviewed that much lately :) [12:14] spiv: gosh [12:18] ok, meeting over === beyond [n=beyond@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:29] good morning! [12:31] bom dia brasil! === ajmitch_ [i=ajmitch@port170-111.ubs.maxnet.net.nz] has joined #launchpad [12:36] hmm - anyone here I can talk to about something we want to use LP for, but want to figure out the best way to do ? [12:37] basically we want people to be able to request backports through launchpad.... [12:37] but dont know the best way to do it [12:37] I would suggest using a new product and filing bugs against it ? [12:37] morning matsubaram, spiv , Mez [12:38] s morning sivan === ajmitch_ is now known as ajmitch === southfoxargentin [n=fox@200-122-34-77.dsl.prima.net.ar] has joined #launchpad === Mez [n=Mez@ubuntu/member/mez] has joined #launchpad === ajmitch_ [i=ajmitch@port163-249.ubs.maxnet.co.nz] has joined #launchpad [01:32] Mez: Hmm, you mean backports of bug fixes from one upstream branch to another, or backports of new releases from e.g. dapper to breezy? [01:33] spi: we want people to be able to request new backports [01:33] as in - what we currently do ... [01:33] dapper rebuilt for breezy etc etc [01:34] thinking of ust setting up a new product and using bugs on that [01:37] Mez: I guess that works, although maybe a seperate ubuntu-backports distro would be a better solution. [01:38] Mez: Try asking bradb when he's around, or mail the launchpad-users list about it. [01:38] spiv: is that possible to do? [01:38] spiv: though that still doesnt give us somewhere to request - but actually makes life a lot easier for support ;) [01:39] If you had a seperate distro, you could then mirror the warty/hoary/breezy/dapper release structure in it, and use those for targetting your bugs. [01:39] very true [01:40] and then can file bugs on packages within the "distro" [01:40] But I'm not certain that's the best route, so see what brad thinks :) [01:40] Right. [01:40] does it matter that it's not self contained? [01:40] In some sense, the backports are just a derivate of ubuntu, so registering a deriviative distro of ubuntu for them makes sense. [01:41] spiv: true, but backports isnt self contained... [01:41] It relys on links to current ubuntu [01:41] But I suspect we'll hit some rough edges no matter what we do, because you'd be the first to do this, however we do it :) [01:41] Right, that's more-or-less the idea of a "derivative" distro. [01:42] We want to make it easy for people to make variations of ubuntu where 99% of the packages are the same, but a few select ones are customised. [01:42] spiv: oh... I thought you meant derivative as in ubuntu being a debian derivatie [01:42] spiv: then surely backports would be the best start for a stomping ground? [01:43] s/stomping/testing/ [01:43] I think so. [01:44] hmm [01:44] sounds like a good plan [01:44] and would be quite useful for us tbh [01:44] Yeah, it seems to make good sense. [01:44] E.g., if I'm looking at a breezy bug, and I see in launchpad that it's fixed in "ubuntu-backports (breezy)", then that's good to know. [01:45] sort of ;) [01:45] lol [01:45] actually [01:45] It means that I know I could grab the backports package to fix my problem, rather than waiting for dapper :) [01:45] thats a good way of linking them [01:45] yes [01:45] ;) [01:45] hmm [01:45] this could be interesting [01:45] This is the sort of thing we always wanted malone to do :) [01:45] hehe [01:45] yeah [01:46] or, if we see it as fixed in dapper, but not in breezy, we can try and backport it ;) [01:46] Although typically we've been thinking more about package maintainers than users (e.g. if an ubuntu maintainer sees that gentoo has fixed a bug, then they can look at their fix and include it in the ubuntu package). [01:46] Heh, if you like ;) [01:47] spi: yeah - I've heard the spiel from mark about LP many a time (and read the interviews too!) [01:47] Ah, cool. [01:48] I think it's a great (and he explained it really well in a LXF issue somewhere!) [01:48] and at LRL [01:48] and everywhere else [01:48] but yeah - I think thats actually a good way of doing it [01:48] a REALLY good idea [01:49] I mean - we have them currently registered as a "project" and "products" for each ubuntu release [01:49] but doing it that way would be even easier === mick__ [n=mick@adsl-2-50-137.mia.bellsouth.net] has joined #launchpad [01:49] though I'm not too sure how we'd get stuff linked in (like it knowing what packages etc are in it) [01:50] Yeah, me either :) [01:50] It depends on where the derivatives code in launchpad is at. [01:50] It might be that for now products are the best we can do, and we can migrate it later when we can do it better. === carlos -> lunch === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has joined #launchpad === jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #launchpad [01:52] evening bradb ;) [01:53] before I start - you can blame spiv for all this ;) [01:53] hey Mez [01:53] I have a timeout error that I think might be a duplicate of 28528. [01:53] Mm, no, that one referes to translation. [01:53] jbailey: What's the oops id? [01:54] bradb - we've been looking at a new way of processing requests for backports - and we wass originally looking at using the support system. [01:54] spiv: is OOPS-23A312. [01:54] Hmm, it hasn't rsynced to chinstrap yet... [01:54] At the moment - I think thats a little too primitive... and was looking at using malone for it - but making a new package for requests doesnt seem right - nor does mixing it with current actual problems === spiv twiddles thumbs === jsgotangco [n=jsg@125.212.109.69] has joined #launchpad [01:55] I asked in here if anyone had any ideas on how to do it [01:55] and spiv came up with the idea of making backports a derivative distro in LP [01:55] spiv: For background, I was searching for the evolution source package so that I could search it for bugs. [01:55] This was the search for packages timing out. [01:55] bradb: which would work out really well for us - it'd make managing things a lot easier for us. [01:55] bradb: what do you think? [01:55] Mez: For backport fixes, use the "Target Fix to Releases" link. [01:56] bradb ... ? [01:56] Mez: He means target it to releases of real Ubuntu [01:57] I dont get what you mean though [01:57] bradb: I'm not sure that's quite right in this case, because e.g. breezy is released and will never change (well, except for security bugs). [01:57] spiv: Not really true. [01:57] spiv: We fix important bugs in breezy through breezy-updates, too [01:57] Mez: e.g https://launchpad.net/distros/ubuntu/+source/openoffice.org2-amd64/+bug/24000, the "Target Fix to Releases" is designed specifically for managing backport/security bug fixes. [01:57] Malone bug 24000: "Unable to open the linked document ( ACPI specification )" Fix req. for: openoffice.org2-amd64 openoffice.org2-writer (Ubuntu), Severity: Normal, Assigned to: Matthias Klose, Status: Unconfirmed [01:57] jbailey: Ok, security and high-priority bugs :) [01:58] spiv: Specifically, I will occasionally upload fixes that I've done for clients anyway, since I've had to do the QA work on the fix anyway. [01:58] jbailey: There's some sort of distinction between the backports project and breezy-updates/breezy-security. [01:58] I guess the question is how to represent that in malone (if at all) [01:58] spiv: Right. backports is as many packages from dapper as they can sanely map onto breezy. [01:58] i.e. the former isn't enabled by default in peoples' systems === tuxmaniac [n=tuxmania@60.254.67.17] has joined #launchpad [01:59] I don't know what the community around backports is like. [01:59] bradb: I dont think you've got the point of it. We want people to be able to request new backports [01:59] Like, if there's a bug in a breezy-backport that doesn't appear in breezy and doesn't appear in dapper, do they care? [01:59] It's basically keeping them up to the bleeding edge... those people that want the latest of everything now === tuxmaniac [n=tuxmania@60.254.67.17] has left #launchpad ["Konversation] [02:00] jbailey: the backports team do - but cant do much about it [02:00] Mez: Does that change when we switch to Soyuz? [02:00] jbailey: I've no idea [02:00] jbailey: well, another case is "the bug is in 'ubuntu (breezy), but fixed in ubuntu (dapper) and ubuntu (backports)". [02:01] We've basically been told "well - we dont know - we;ll see later" [02:01] Mez: Are you asking how to take bug #NNNN and say "backport this fix to Breezy"? [02:01] bradb: not at all [02:01] jbailey: In that case, as a user looking at the bug report (because it just happened to me), it's useful to know that it's fixed in backports. [02:01] spiv: Mmm, right. For people who really need a bug gone and are willing to take some risk with it. [02:01] bradb: currently, backports is technically a derivative of ubuntu - yes? [02:01] jbailey: So I know I have the option to try a backport of just one package before I upgrade to the bleeding edge dapper :) [02:01] Mez: Does your question deal with bug reports? [02:02] well - people come along every day and ask us to backport things to breezy [02:02] jbailey: Exactly. [02:02] spiv: Makes sense, then. [02:02] bradb: not exactly [02:02] but vaguley yes [02:02] bradb: Well, "I wish version 1.7 of frobnosticator was available for breezy" is sort of like a bug ;) [02:03] ah, ok [02:03] spiv: as is "well this annoying bug here is in breezy but not in dapper- can you backport it please" [02:03] spiv: FWIW, a second query for evolution takes a while but does succeed. [02:03] Mez: Right. [02:03] jbailey: Must be on the edge of the timeout, so it depends on luck if the db is too busy or not :/ [02:03] we get so many people requesting backports all the time - [02:03] some for vanity (I want this new app now) [02:03] spiv: Fair enough. Is there anything else I can give you before this drops out of my short term memory? =) [02:04] some for the reason that it's buggy (scim in breezy is buggy as hell but fixed in dapper - cant backport but it's an example) [02:04] jbailey: How about a pony? ;) [02:04] Ah, there's the oops. [02:04] and well - we'd love a way to be able to manage those requests propler.y [02:04] spiv: http://www.hasbro.com/mylittlepony/ [02:04] spiv came up with the idea of registering backports as a distro in launchpad === daf imagines spiv riding through Sydney on a pony [02:04] then we can link all the things together - for example, if someone reports a bug in breezy [02:05] and it's fixed in dapper, then we can backport it and mark it as fixed in backports and wontfix in breezy [02:05] or similar [02:05] we're just looking for an easier way to manage the request process - and the idea spiv came up with seems a good one [02:05] jbailey: Hmm. [02:05] get it yet bradb? [02:05] Mez: If there's an existing bug report, the "Target Fix to Releases" page is designed to request a backport fix. [02:06] jbailey: It's a actually a pretty simple query that's killing it :/ [02:06] bradb: not exactly [02:06] If there's no bug report, and it's just "please backport version X.XX of package foobar", that's something different. [02:06] to me it looks liek it's there to request an "updates" [02:06] jbailey: It's using a full-text search, but otherwise is really simple, no joins or anything exciting. [02:07] bradb: the backports team get nothing to do with that link- surely that link is for security/updates team [02:07] not backports [02:08] Mez: It's designed to handle backport fix requests. What makes you think it can't handle requesting a backport fix? [02:08] bradb: It seems to me that the backports aren't producing official ubuntu packages, so targeting fixes to ubuntu releases doesn't really seem to fit. [02:09] bradb: i.e. the issue is that the bug isn't being fixed in "ubuntu (breezy)", it's being fixed somewhere else. [02:09] what spiv said :P [02:09] Ok, that makes things a little clearer. [02:09] bradb: It's a confusing world we live in :) [02:09] I vaguely remember talking with Mark and stub about this in a cab on the way to the airport in Spain. [02:10] Hah. [02:10] bradb: I think the confusion is what is meant by backports ;) [02:10] you're meaning for example, breezy-security and breezy-updates - yes? [02:11] I'm meaning https://wiki.ubuntu.com/UbuntuBackports [02:11] I guess so. But we usually use the word "backport" every time we talk about that page. === bradb reads [02:11] bradb: It's a valid use of the word ;) [02:12] but not the way I meant it ;) [02:12] It is technically backporting, yes - but when I say "backports" I meant he backports project (like backports.org for debian) [02:13] at the moment - we're using the forums for requests. [02:13] and this is major ... [02:13] *shudders* [02:14] it doesnt work [02:14] I refuse to go there [02:14] we're looking at a new way to manage the bugs for backports (all the bugs for say, breezy backports are lumped into one product) [02:15] and also a better way to manage requests [02:15] I believce this can be done easily with backports being listed as a derivatie distro [02:16] Mez: Is the backporting project a derivate distro of Ubuntu? [02:16] technically, yes [02:16] Does it have its own repo, can I order backport CDs, etc? [02:16] no. [02:16] lol [02:16] well [02:16] it's hosted on the ubuntu repos [02:16] so it has it's own repo [02:17] http://us.archive.ubuntu.com/ubuntu/breezy-backports [02:17] but they dont do CDs yet [02:18] Mez: IIUC, there are two types of backporting you're talking about: 1. Requesting that bug #NNNN get fixed in Breezy, 2. Requesting that version X.YZ of package foobar be brought into Ubuntu, correct? [02:18] 2) yes 1) sort of [02:19] 1) bug #NNNN be fixed in breezy by bringing a newer version of "package" into breezy from dapper [02:19] Any other types of backport request that relate to this? [02:20] those are the only 2 types that we deal with [02:20] ok === Bucciarati [n=buccia@host73-144.pool872.interbusiness.it] has joined #launchpad [02:20] we dont bugfix things - (well - not as backports - we can as MOTU if we want) [02:21] we basically just bring things from XtoY and test that they work [02:21] but sometimes we get bugs in stuff we'e backported [02:21] And to get bugfixes for either of #1 or #2, I have to modify my sources.list, right? [02:21] In some ways this would be clearer if the backports weren't distributed on archive.ubuntu.com ;) [02:22] bradb: yes - to get the backported packages, you have to modify your sources.list [02:24] spiv: they never used to be - but they're "official" now [02:24] official but unsupported [02:24] Mez: Yeah, that's the "problem" :) [02:25] Mez: If they were called "Jimbo's backports for Ubuntu", there'd be no confusion ;) [02:25] I don't know much about how derivatives work in Launchpad. If the backport project is very similar to a derivative, then it would make sense for it to be a derivative. If the derivative solution is more like a hack than a close model of the Real World, then it's probably not the right solution. [02:25] bradb: FWIW, I think a derivative is a very close but not quite perfect fit. [02:26] bradb: But probably a better fit that, e.g. a product for every backport release (i.e. having a ubuntu-breezy product). [02:26] Er, "ubuntu-backports-breezy" product. [02:26] spiv: thats how we do it at the moment [02:26] bradb: what do you mean more like a hack than a close model of the real world" [02:27] The main issue I see is that the backports project doesn't have full repo, they are just an auxilliary source of newer packages for some things. [02:27] spiv: yeah - we're not self contained [02:27] I'm not sure what our assumptions for derivatives are/will be, so that might be an issue. [02:27] we wont work without having ubuntu there in the background [02:28] Mez: If the backport project is not almost exactly like an Ubuntu derivative, then this would be a hack. :) [02:28] But I don't know enough about derivatives to make that call. [02:28] bradb: nor do i :D [02:28] It depends on what you're calling a derivative [02:28] But, I can email launchpad@ and get more information for you. [02:29] Do you want me to get more information for you? [02:29] I think probably the main issue would be "I want to request a backport of frobnosticator 1.7 to breezy" -- would "frobnosticator" be available in malone's view of the ubuntu-backports derivative to file a bug against? [02:30] I think derivatives in general might want that, but I'm not sure. [02:30] bradb: put simply if we importe everything from breezy into backports that we havent backported from dapper - we'd be a derivative ;) [02:30] the stuff we havent backported lies in breezy ;) [02:30] bradb: sure - can you CC: me ? [02:31] Hmm, to be clear, I mean would all packages in the parent distro be available for filing bugs against in the derivative? [02:31] Mez: Sure, I'll email launchpad@ and Cc you. [02:31] bradb: no problem :D [02:31] mez@ubuntu.com [02:32] sounds good, thanks [02:32] spiv: if so - it'd make our life easier if this were to go ahead [02:32] if not: not as easy - but still ;) [02:33] spiv: to me - we only need the packages in backports, any "requests" can be filed against backports itself [02:33] though, for general derivative distros [02:33] I think that weould be the best [02:33] Mez: It seems like the sort of problem we want launchpad to help with, but you're right on our bleeding edge :) [02:33] because well - same as with us in ubuntu [02:34] we're a derivative of debian [02:34] if we pulled a package from debian - should we just file in the debian BTS? [02:34] not really - because it could something else in ubuntu causing the bug [02:35] Mez: Yeah, that's a bit hairy -- what if the bug in a pure-debian only shows itself when used with a backport package? [02:35] yeah [02:35] lol [02:35] which is why you have it filed against the distro first and then "occurs in X" aswell [02:35] I suspect there's not one answer for that sort of thing, it depends on common sense, the relationship with the relevant debian maintainer, etc. [02:36] the whole thing maline is meant for [02:37] spiv: It's very true [02:37] spiv: but it's the same thing [02:37] jbailey: I filed https://launchpad.net/products/launchpad/+bug/29444 [02:38] Malone bug 29444: "Timeout querying DistributionSourcePackageCache when searching for the evolution source package" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed [02:38] which is why I think the parent stuff should be available in general [02:38] hmm [02:38] though I would love the ability for launchpad to auto-file a bug with the debian bts if it's marked as being a bug in debian too [02:38] (or to grab a list and see if the bugs there and link it to the bts if it is) [02:39] Mez: Yeah, although debian might love that a bit less ;) [02:39] spiv: Thanks. I've subscribed to it in case there's something more you need from me. [02:41] spi: I dont know [02:41] if it's set as being a bugoccuring in debian aswell [02:41] surely - it would be good to check the debian BTS and link to that bug [02:42] or if it's not there - file a bug? [02:43] Mez: It would be good, but it just needs some care to do it without offending debian. [02:43] true [02:44] If we accidentally make it easy to spam debian with often irrelevant or duplicate bug reports, they won't be happy. [02:44] true - but how many times have you seen a bug marked as occuring in debian ? [02:44] And possibly some maintainers will simply be disinterested in bugs reported from ubuntu, on the basis that they don't care about anything but debian, so unless a debian user reports it they're not interested. [02:44] even just the "occuring in debian" checking for a current bug [02:45] spiv, usually it's a dev that marks it as occuring in debian [02:45] And there's the need to try avoid duplicates, and also our web form tends to gather much less info than reportbug does by default. [02:46] Mez: Right. It's not a bad idea, it's just one we need to be careful to do right. [02:46] spiv: definately [02:46] espescially atm [02:47] Which will probably involve asking debian what they think, etc. We're not really there yet, but I'm sure the discussion will happen sooner or later. === koke [n=koke@ubuntu/member/koke] has joined #launchpad [02:48] well there are massive kicks going on atm to try and get ubuntu and deban closer === southfoxargentin [n=fox@200-122-34-77.dsl.prima.net.ar] has joined #launchpad === koke [n=koke@ubuntu/member/koke] has joined #launchpad === vytis_ [n=vytis@bonamens.lt] has joined #launchpad === vytis_ is now known as mantiena === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [02:54] Hi all === stub [n=stub@ppp-58.10.64.209.revip2.asianet.co.th] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #launchpad === beyond [n=beyond@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === Mez [n=Mez@ubuntu/member/mez] has joined #launchpad [03:33] BjornT, around? === Seveaz [n=seveas@ubuntu/member/seveas] has joined #launchpad [03:37] hi salgado [03:38] hi BjornT. do you have a few minutes to discuss an issue I'm having while trying to fix bug 5394? [03:38] Malone bug 5394: "Clicking on "Advanced search" should preserve simple search criteria" Fix req. for: malone (upstream), Severity: Normal, Assigned to: Guilherme Salgado, Status: In Progress http://launchpad.net/bugs/5394 [03:38] sure [03:39] cool [03:40] BjornT, so, to preserve the simple search criteria I have to stick the values returned by getExtraSearchParams() as GET parameters on the URL I'm redirecting the user to [03:41] the problem is how to construct this URL in a way that's not too fragile, like building it manually and hardcoding the field names [03:42]