=== mpt [n=mpt@203-173-141-46.bliink.ihug.co.nz] has joined #launchpad === Martolod [n=jeremy@ARennes-257-1-16-17.w81-250.abo.wanadoo.fr] has joined #launchpad === lakin [n=lakin@S01060013101832ce.cg.shawcable.net] has joined #launchpad [01:11] Merge to devel/launchpad/: Make the mirror prober honour the http_proxy env var, change it to issue batches of 50 requests instead of all at once and some other small things. r=spiv (r1829: Guilherme Salgado) === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad === nictuku [n=yves@ubuntu/member/nictuku] has joined #launchpad [01:13] can I ask rosetta questions here? [01:15] nictuku, yes, though you'll be more likely to get an answer when either carlos or jordi are awake === Martolod [n=jeremy@ARennes-257-1-95-236.w81-48.abo.wanadoo.fr] has joined #launchpad === mpool [n=mbp@ppp112-44.static.internode.on.net] has joined #launchpad === jinty [n=jinty@76.Red-83-58-172.dynamicIP.rima-tde.net] has joined #launchpad === mpt_ [n=mpt@203.173.191.118] has joined #launchpad === jinty [n=jinty@76.Red-83-58-172.dynamicIP.rima-tde.net] has joined #launchpad === mpt__ [n=mpt@203-173-141-46.bliink.ihug.co.nz] has joined #launchpad === tambaqui [n=tambaqui@200.231.240.153] has joined #launchpad [04:33] Goooooooooooooood afternoon Launchpadders! [04:36] mpool: ping? === mpt__ is now known as mpt [04:54] Merge to devel/launchpad/: [trivial] Fix removal of unvalidated team emails (https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-04-26/D293) (r1830: Guilherme Salgado) === AlinuxOS [n=Ubuntu@d83-176-122-218.cust.tele2.it] has joined #launchpad === robotgeek [i=venkat@ubuntu/member/robotgeek] has joined #launchpad === poningru__ [n=poningru@ip68-226-0-76.ga.at.cox.net] has joined #launchpad [05:12] jamesh: ping? === robotgeek [i=venkat@ubuntu/member/robotgeek] has left #launchpad [""looking] [05:13] mpool: I was working on an improvement for the launchpad bzr branch syncing code, and had a few questions about the bzrlib APIs [05:14] the first one is whether bzrlib guarantees that the items in the parent_ids list for a revision will be unique [05:14] jamesh: revision.parent_ids you mean ? [05:14] lifeless: yeah [05:15] jamesh: are you asking if len(parent_ids) always == len(set(parent_ids)) [05:15] lifeless: yeah [05:15] it *should* but it probably may not. If not I think we should de-dup in bzrlib [05:16] the only semantic in the ordering of that list is the left-most entry [05:16] the rest is treated as a set [05:16] lifeless: ddaa had some code to remove duplicate entries dating back to October last year (I think). I was wondering whether it was necessary still [05:17] I dont recall any bugs filed on bzr [05:17] so we haven't done anything to fix that [05:17] are you saying that bzr won't necessarily maintain the order of the later parent ids? [05:18] no, I'm saying that it doesn't care what the order of the later ids is. [05:19] okay. [05:20] the second question was about testing overwriting the branch history with a shorter version that shared some history. Branch.set_revision_history() looks appropriate, but I was wondering if it is intended for public usage [05:20] we are normalising history now [05:20] what situation you want to create? [05:22] the one ddaa mentioned was the original history being something like "r1 -> r2 -> r3 ->r4" and the new history being "r1 -> r3 -> r4" (r3 having r1 and r2 as parents) [05:22] right [05:22] nowadays the pull that creates that will normalise it to r4->r4[0] ->r4[0] [0] ->r4[0] [0] [0] etc [05:23] to test it though - why do you need a branch like that, why not just inject the revision history you want to use into the relevant method ? [05:24] that's what I was thinking of doing, and wondering if Branch.set_revision_history() is the appropriate method [05:24] or whether it was considered internal only [05:24] for now it is. I'm suggesting modifying the scanner code to allow (for instance), Scanner.process_revision_history([r1, r2, r3, r4] ) [05:24] that is, make the code easier to test. [05:28] that should be possible with the current code by overwriting the BzrSync.bzr_history attribute [05:28] I might try that instead [05:29] with robust tests, its better to test the specific thing that you are changing rather than environmental aspects. [05:30] i.e. we dont want to test bzr, we want to test what the scanner does. === tambaqui [n=tambaqui@200.231.240.153] has left #launchpad [] === mpt [n=mpt@203-173-141-46.bliink.ihug.co.nz] has joined #launchpad === lakin [n=lakin@S01060013101832ce.cg.shawcable.net] has joined #launchpad === poningru [n=poningru@ip68-226-0-76.ga.at.cox.net] has joined #launchpad === welshbyte [n=welshbyt@cpc3-cwma2-0-0-cust276.swan.cable.ntl.com] has joined #launchpad [07:27] morning === stub [n=stub@ppp-58.8.3.226.revip2.asianet.co.th] has joined #launchpad [08:38] Merge to devel/launchpad/: [r=salgado] Fix bug 36058 (Bug tasks need more dates) (r1831: Brad Bollenbach) === irvin [n=irvin@ubuntu/member/irvin] has joined #launchpad === mdke_ [n=matt@81-178-218-210.dsl.pipex.com] has joined #launchpad === giftnudel [n=mb@p54B2A07D.dip0.t-ipconnect.de] has joined #launchpad [09:16] who is responsible for security related bugs in launchpad? [09:21] giftnudel: we don't have any specific person for that atm, so if you report a security related bug, please subscribe the 'launchpad' team. [09:22] ok, I will do that === mpt [n=mpt@203-173-141-46.bliink.ihug.co.nz] has joined #launchpad === carlos [n=carlos@105.Red-81-34-77.dynamicIP.rima-tde.net] has joined #launchpad [09:34] morning [09:37] BjornT: done, https://launchpad.net/products/launchpad/+bug/41835 [09:37] thanks giftnudel === mdke_ is now known as mdke === mpt_ [n=mpt@203-173-141-46.bliink.ihug.co.nz] has joined #launchpad === doko_ [n=doko@dslb-088-073-087-165.pools.arcor-ip.net] has joined #launchpad [10:13] morning [10:35] SteveA: good morning === TomaszD [n=Tomasz@xdsl-2196.elblag.dialog.net.pl] has joined #launchpad [10:37] hi, is this a lauchpad support channel? I have a question regarding rosetta [10:37] *launchpad [10:38] why gnome-cups-manager template still isn't imported to dapper? [10:38] we have like two weeks to go [10:38] and one of the main desktop apps just isn't there [10:38] how come? === mpt__ [n=mpt@203-173-141-46.bliink.ihug.co.nz] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [10:43] carlos: which missplaced upload? [10:43] jordi: is a bug, don't worry [10:45] carlos: oh, ok === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad [10:55] hello [10:55] spiv: welcome back [10:56] TomaszD: hi, sorry, didn't see your request [10:57] TomaszD: this is the right channel to ask about this kind of issues [10:57] oh [10:57] ok, so? :) [10:57] let me check... [10:57] TomaszD: it's there: https://launchpad.net/distros/ubuntu/dapper/+source/gnome-cups-manager/+pots/gnome-cups-manager [10:58] oh my [10:58] how come... [10:58] Jesus Christ [10:58] It was imported on 2006-03-20 [10:59] I'm pretty sure the launchpad.net/rosetta points to hoary... [10:59] TomaszD: how where you looking for it? [10:59] s/where/were/ [10:59] oh, that link... [10:59] mpt__: around? [10:59] mpt__: ^^^ [10:59] good morning carlos [11:00] anyhow, thanks carlos ! [11:00] mpt__, jordi: I think we should show the product list with translations from productseries to prevent this kind of confusion (talking about launchpad.net/rosetta/) === mpool [n=mbp@ppp112-44.static.internode.on.net] has joined #launchpad [11:00] TomaszD: you are welcome [11:01] TomaszD: please, use https://launchpad.net/distros/ubuntu/dapper/+translations to locate dapper translations [11:01] carlos, ok thanks! [11:01] TomaszD: you are welcome [11:04] BjornT: hello. do you know if the email bug comment notification format is as it should be in production? [11:04] i want to file a bug on a change, but i won't do so if there are still changes to land. [11:05] SteveA: there are no changes pending, so please do file a bug. [11:05] ok [11:06] carlos: what if the prodcut doesn't have series translations? [11:06] jordi: gnome-cups-manager, evolution and others [11:07] jordi: oh, sorry, I didn't read your question correctly [11:07] jordi: the suggestion is that we don't add such products on that list [11:07] people have access to it from the distro pages [11:08] nod [11:08] so the product list at launchpad.net/rosetta would became the list of products that agree to use Rosetta [11:12] SteveA: How could I define a variable with tal that gets an integer as value? [11:13] I'm using: [11:13] but I get: Warning: zope.tal.taldefs.TALError: Invalid variable name "3" in expression u'3', at line 176, column 15 [11:13] carlos: first... why do you want to do this? [11:13] this sounds like programming in a page template [11:13] and we try to not do that [11:14] the answer anyway is that any plain expression in TALES is interpreted as a "path expression" [11:14] like context/foo/bar/baz [11:14] or view/bar/baz/spoo [11:14] SteveA: It's for suggestions code, we are sharing macros between two translation forms [11:14] so, you've asked for a context called "3", rather than "view" or "context" [11:14] one has no limit and the other has a limit === mpt_ [n=mpt@203-173-141-46.bliink.ihug.co.nz] has joined #launchpad [11:14] so it doesn't work [11:15] and both uses the same view === dous [n=dous@ubuntu/member/dous] has joined #launchpad [11:15] macros have access to the view class [11:15] carlos, what do you mean by "the product list with translations from productseries"? [11:15] What's an example of the page you're talking about [11:15] mpt: https://launchpad.net/rosetta as a list of products with translation resources [11:16] mpt: but many of them come from ubuntu so people think they need to look there for ubuntu translation resources [11:16] carlos: you can say [11:16] SteveA: but the view has no way to know the kind of template we are rendering [11:16] carlos: actually it does [11:16] carlos, by "them" do you mean products, or people? [11:16] well... looking into the requested URL [11:16] and i'm going to make this a lot better in the near future [11:17] with some better view support for launchpad [11:17] mpt: translation resources [11:17] but meanwhile, i guess you can do this in TALES, although i do not like it [11:18] carlos, sorry, I don't understand the problem. Is it that people are scrolling down as far as the "Translations in Ubuntu", but not as far as "Translatable applications"? [11:18] SteveA: If you prefer to check the URL to set that value, I could do it too [11:18] no, i don't like that either [11:19] use TALES and please file a bug on me about it, indicating exactly what page template files and view classes are involved [11:19] mpt: They ignore the 'Translations in Ubuntu' section and look at 'Translatable applications' because we show there too the translations from Ubuntu [11:19] and that it is for one view class and two templates, but with these different "limit" values [11:19] mpt: if we don't have a link there people think we didn't import it yet [11:19] what is the "limit" for anyway? [11:20] is that a good variable name? [11:20] That is messed up\ [11:20] SteveA: ok === Ubugtu [n=bugbot@ubuntu/bot/ubugtu] has joined #launchpad [11:20] "The recommended target for current translation activity is Hoary gaim." Why? [11:21] SteveA: is the number of entries we are going to render, it controls the number of entries from a list that we are going to render, it acts as the 'limit' of entries [11:21] mpt: because no one is maintaining the links between products and distros [11:21] mpt: that's one of the problems, we talked about at London, do you remember? [11:21] carlos, why are we suggesting they translate distro packages at all? [11:21] mpt: menus questions abound [11:21] mpt: because Mark asked us to implement it that way [11:22] carlos: maxentriesrendered [11:22] SteveA: ok [11:22] would be more descriptive than "limit" [11:22] or just maxentries [11:22] because "limit" can apply to *anything* [11:22] so it is almost meaningless [11:22] mpt: so please join the appropriate channel [11:23] mpt: I think that feature is good to have, but that page should render only applications that upstream maintains using Rosetta [11:23] SteveA: ok [11:24] carlos, if upstream uses Rosetta, that's precisely when we should be steering people to upstream translation, not distro translation! [11:24] Fall back to distro translation if the upstream developers don't use Rosetta [11:24] mpt: that's my point, I'm suggesting to show there only the products that have the Rosetta flag set === dous [n=dous@ubuntu/member/dous] has left #launchpad [] [11:25] carlos, agreed [11:25] ok [11:25] I hope people start using the distro links after that change is done === mpt_ [n=mpt@203-173-141-46.bliink.ihug.co.nz] has joined #launchpad === heyko\afk_ is now known as heyko [12:03] SteveA: https://launchpad.net/products/rosetta/+bug/41858 [12:03] Malone bug 41858 in rosetta " should be moved to python code" [Normal,Confirmed] [12:05] ta [12:06] SteveA, lost you [12:07] carlos, how about dapper xchat? https://launchpad.net/distros/ubuntu/dapper/+source/xchat/+translations [12:08] TomaszD: Rosetta has only packages from main [12:08] TomaszD: xchat is from universe [12:08] oh [12:09] hmm, so to get the translation in place, I'd have to ask for an upload to xchat's cvs then [12:09] TomaszD: either that or ask its ubuntu maintainer [12:09] mpt: oh well [12:09] irc it is [12:09] carlos, ok thanks [12:09] we were asked by MOTUs to not import those packages [12:09] why? [12:10] because we don't have language packs for universe and is hard to them to track the updates and do new uploads so those translations are not lost [12:10] oh I get it now, xchat was in main, that's why it had a translation before (in breezy) [12:11] OK I'll see about getting some feedback from the ubuntu maintainer === stub [n=stub@ppp-58.8.3.226.revip2.asianet.co.th] has joined #launchpad [12:19] TomaszD: well, we imported universe for breezy and hoary, but the problem is the same, those translations are not being used in Ubuntu :-( === mpt [n=mpt@203-173-141-46.bliink.ihug.co.nz] has joined #launchpad === stub [n=stub@ppp-58.8.3.226.revip2.asianet.co.th] has joined #launchpad === cprov [n=cprov@201-43-145-181.dsl.telesp.net.br] has joined #launchpad === jinty [n=jinty@76.Red-83-58-172.dynamicIP.rima-tde.net] has joined #launchpad [12:58] hey stub [12:59] Morning [12:59] I'm looking at the person merging stuff for branches [01:00] I do not think you actually read the doctest: [01:00] +Branches with greater IDs will get greater numerical suffixes, so we create [01:00] +"peoplemerge" first, and it will be renamed "peoplemerge-1". The extant [01:00] +"peoplemerge-1" branch will be renamed "peoplemerge-2". [01:01] I agree that as I described it, it's difficult to implement in sql, but the annoying bit is that now the doctest is contradicting itself. [01:03] ok. So the text needs to be updated. I'm not too fussed if the renaming isn't particularly obvious - it will be extremely rare for the case to occur. [01:06] how much longer are you around today? [01:14] stub: for id, product, name in list(cur.fetchall()): [01:14] any reason you use an explicit list there? [01:15] it will end up using the iterator interface anyway [01:19] ddaa: I'll be around for another 5 hours I think [01:19] ddaa: I use list() there because I reuse the cursor in the loop [01:19] (I think) [01:19] good point [01:19] thanks === stub disappears for an hour === stub but makes a cup of tea first [01:30] stub: please review https://chinstrap.ubuntu.com/~dsilvers/paste/filebtWwvB.html === ddaa -> lunch === BjornT -> lunch === SnkBite [n=SnkBite@212.25.63.82] has joined #launchpad === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === bradb [n=bradb@modemcable092.66-130-66.mc.videotron.ca] has joined #launchpad [02:08] psycopg.OperationalError: server closed the connection unexpectedly [02:08] This probably means the server terminated abnormally [02:08] before or while processing the request. [02:08] ; used connection string 'dbname=launchpad_prod user=queued host=jubany.ubuntu.com' [02:08] cprov !!! help :p [02:09] Keybuk: uhm .. this ramdom DB unavailability again, I can't do much for you. Which tool ? [02:09] queue [02:10] so if I retry, it should work? [02:10] Keybuk: yes [02:11] Keybuk: I wonder what is going so wrong latelly with jubany, maybe the obvious, high concurrence === carlos -> lunch [02:12] see you later [02:12] cprov: now it's just being weird [02:13] I'm getting "Accepting ubuntu/dapper (NEW) 0/18" [02:13] then just "0/18 total" === lifeless_ [n=robertc@dsl-43.1.240.220.rns01-kent-syd.dsl.comindico.com.au] has joined #launchpad [02:13] oh, maybe I'm using it wrong [02:14] Keybuk: there is 18 items in NEW and your filter isn't selecting anyone for acceptation [02:14] there are ... [02:14] what's the filter supposed to be? [02:15] I put "language-pack-*" for that [02:15] name matching , i.e., queue -Q NEW accept foo [02:15] that didn't work [02:15] if I put the queue ids in, it works [02:15] (one at a tiem) [02:15] Keybuk: don't use '*' [02:15] oh, filter implied wildcards to me [02:15] Keybuk: you got that just now?? [02:15] stub: yeah [02:16] Keybuk: sorry, I didn't land wildcard support yet. Should be simple but I haven't time to investigate [02:17] ahh [02:18] Keybuk: use substring, as in a SQL LIKE %<>% [02:18] s'ok, I just did the ids :) [02:18] cprov: Is this tool connecting as user 'fiera'? [02:19] stub: queued [02:20] queued@launchpad_prod/29258 2006-04-28 13:15:55 BST LOG: unexpected EOF on client connection [02:20] Nothing else in the logs relevant [02:20] stub: config.uploadqueue.dbuser (ftpmaster config) [02:20] stub: have you seen it before in our env. ? [02:20] Nope === SteveA goes for a walk to get some sunlight [02:21] Possibly network issues, possibly something odd like the ident daemon on drescher not responding quickly enough and some timeout being triggered in the auth process. [02:22] Doesn't look like anything wrong at the PostgreSQL level though, at least as far as the logs let me know. === bradb [n=bradb@modemcable092.66-130-66.mc.videotron.ca] has joined #launchpad [02:23] stub: can you file a bug for this ? then we can track the same behavior in other situation like the publisher or the slave_scanner (I've seen the same in those lands) [02:23] I've got other 'unexpected EOF' messages for the fiera user [02:24] stub: it's the slave_scanner [02:24] And some others, like bugnotification. I suspect it is normal for a psycopg connection that isn't explicitly closed and a false alarm. [02:24] stub: or queue_builder (both are buildmaster children) [02:27] stub: maybe, if the process has already finished DB tasks it's ok, but it also happens in the middle of some intensive processes, i guess the transaction is just aborted since I've never get inconsistenses. [02:27] transaction will always be rolled back [02:28] speaking about which, once a while publisher fails on a "serialization" problem, have you observed the same issue in other applications ? === stub doubles max connections for a laugh [02:29] serialization exceptions are normal if you are using serialized transaction isolation level, which is the default with psycopg 1. Either change the transaction isolation level, or catch the exceptions and retry the transaction. [02:29] Retrying the transaction is the documented way of handling this expected case. === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad [02:30] I'd consider dropping the transaction isolation level unless the lack of read consistency will cause your program problems. [02:30] stub: how do I retry the transaction ? shouldn't we have support for this in the commit method ? [02:31] cprov: You need to redo what you where trying to do. commit can't do it automatically, as the transaction might need to do something different the second time round as the data in the database may have changed. [02:31] stub: publisher will probably failed on pending writes (publising & domination, both huges most of the time) [02:31] In fact, it almost certainly have changed as the serialization exception was triggered. [02:32] stub: wait, did you mean changed by other transaction ? [02:32] changed by another process I mean. [02:33] Your script has requested the highest possible transaction isolation level. Some other process has mucked with the data in such a way that that transaction isolation level can no longer be guaranteed. So PostgreSQL raises the exception and expects you to deal with it, generally by trying whatever you were doing again. [02:33] stub: I see, the exception will be raised when I commit or anywhere after the transaction has been started ? [02:34] I can't remember - whenever I've needed to catch it I've always wrapped the entire thing in a try: except: so haven't needed to worry. [02:35] Keybuk: did queue work for you ? [02:36] cprov: seems to be working ok [02:37] stub: right, will find sometime to play around it during the weekend. I guess a good way to reproduce it should be invoking another script to mess with DB data in question after start a transaction. Anyway will figure out === niemeyer [n=niemeyer@200.193.154.190] has joined #launchpad [02:38] Keybuk: ok, sorry for unsupported/undocummented feature, feel free to file a bug on missed wildcards functionality, it's also missing in the web UI implementation. [02:39] nah, s'ok -- was more a bug in my own docs of how to drive the tool I suspect :p [02:39] this was the first time I'd tried to accept more than one package at a time [02:40] cprov: it is a pita to reproduce, as you need to mutate the data in the right way - if it is possible for PostgreSQL to cope, it copes. lib/canonical/launchpad/webapp/ftests/test_adapter.txt has some tests for Z3 handling of it. Most scripts I've just reduced the isolation level though - generally you don't need SELECTS to guarantee the same results on repeated queries, and sometimes this behavior even makes things more difficult. [02:42] stub: I'm scared now :( [02:43] cprov: Its not really scary. Most db's don't even support this high a transaction isolation level at all. [02:45] stub: I wonder if a better approach should be identify which scripts are conflicting horrible and lockfile them. === cprov will be out for a while (10 min), going to the office. === jinty [n=jinty@142.Red-83-35-222.dynamicIP.rima-tde.net] has joined #launchpad === sfllaw_ [i=sfllaw@206-248-157-197.dsl.teksavvy.com] has joined #launchpad === cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === lucasvo [n=lucasvo@wservices.ch] has left #launchpad [] [03:35] ddaa: https://chinstrap.ubuntu.com/~dsilvers/paste/filebtWwvB.html r=stub === stub [n=stub@ppp-58.8.3.226.revip2.asianet.co.th] has joined #launchpad [03:46] carlos: Could you give me translations "Get help Online" and "Translate this application" in all languages? === stub [n=stub@ppp-58.8.3.226.revip2.asianet.co.th] has joined #launchpad === bradb [n=bradb@modemcable092.66-130-66.mc.videotron.ca] has joined #launchpad [04:07] doko: aren't you able to use the translations from gtk+ or whatever it's stored for GNOME? [04:07] carlos: OOo ... [04:08] where are the gtk/gnome ones stored? the source code that contains the english string [04:14] carlos: lunchpack-integration [04:16] doko: https://launchpad.net/distros/ubuntu/dapper/+source/launchpad-integration/+pots/launchpad-integration/+export [04:17] then, there you have the translations we have === jsgotangco [n=jsg@ubuntu/member/jsgotangco] has joined #launchpad [04:18] carlos: breezy does have more, but ok, that probably better to check this location regularily [04:19] carlos: there's one bug: I cannot download the files in GSI format ;-P [04:19] doko: I need to migrate breezy's translations to dapper, that's the reason === carlos adds a GSI string filter to xchat... :-P [04:20] doko: btw, aren't you going to add those strings to oo.org GSI files? [04:23] carlos: hmm, I should, but it seems, they are currently not ... [04:25] carlos: indeed, they are [04:39] stub, around? [04:39] salgado: yes [04:39] great [04:39] stub, so, I need some help with the migration script for shipit [04:40] basically, I need to insert empty RequestCDs objects for the new flavours [04:40] s/objects/rows [04:40] not really empty, but with quantity=0 and quantityapproved=0 [04:41] so, for every existent RequestCDs row, I need to insert two new ones, changing only the flavour column === kiko [n=kiko@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [04:41] GOOD MORNING WORLD [04:41] yo === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad === lakin [n=lakin@S01060013101832ce.cg.shawcable.net] has joined #launchpad === tambaqui [n=tambaqui@200-213-120-102-mns.cpe.vivax.com.br] has joined #launchpad [05:03] salgado: That sounds dodgy. Why store the rows with quantity=0 and quantityapproved=0 at all? Tripling the data we store doesn't sound a good solution when slightly more intelligent code would handle it fine. [05:08] stub, yes, I agree with you... the problem is that I have to pass these RequestedCds objects from browser to database code in a few different places. and I'm afraid it'll be quite some work to change all these places to handle variable numbers of RequestedCDs objects [05:09] the API can still do that [05:09] doesn't mean it needs to be that way in the database [05:09] salgado, I still think stub is right -- otherwise, what happens when you want to add more archs and products? [05:09] listen to SteveA [05:09] then, you can consider refactoring later [05:12] I was just afraid it'd make the code even more complex. I have to admit I didn't investigate it well enough, though === tambaqui [n=tambaqui@200-213-120-102-mns.cpe.vivax.com.br] has left #launchpad [] [05:13] maybe you can help me with that this afternoon, kiko? [05:13] sure! [05:13] thanks for asking [05:13] remind me [05:13] I suspect offering three flavours instead of one will more than double the number of requested cds we sent out (and double the number that end up as drinks coasters). Even with hindsight though, we will have no way of knowing for sure (as we will also get an unknown increase due to increased publicity and public awareness). [05:14] stub, we only offer one flavor per site [05:14] i.e. [05:14] the guy needs to go to shipit.edubuntu.org for edubunto CDs [05:14] edubuntu argh [05:14] so it's extra work to get more CDs [05:14] we also changed the workflow for custom requests [05:15] salgado, I'm pretty sure the checkbox is going to be important. make it a UI-only Javascript thing? [05:17] kiko, you mean, only enable the text box when the checkbox is clicked? (I'm assuming this is what we're going to use unless someone has a better idea) [05:17] yeah [05:17] do it === th1a [n=hoffman@pool-64-222-37-160.prov.east.verizon.net] has joined #launchpad === lfittl [n=lfittl@83-65-240-14.dynamic.xdsl-line.inode.at] has joined #launchpad [05:22] hi tom [05:22] Hi SteveA. [05:22] yawns [05:22] We're having a little LaunchPad problem. [05:22] what's up? [05:23] kiko, BjornT, SteveA: Any thoughts on https://wiki.launchpad.canonical.com/BugDateLastUpdated ? I was planning on putting it up for review soon. [05:23] SteveA: jinty is the "registrant" for SchoolTool, but he can't seem to elevate my role on the project. [05:24] this will allow us to do kinda roundup things, bradb [05:24] (btw, by "it", I mean the code.) [05:24] bradb, isn't there a general "bug-modified" event? [05:24] bradb, BjornT: if not, shouldn't there be? [05:24] I think an update_bug_date_last_updated event is nonsensical [05:25] There isn't such an event now. [05:25] well that'd make a lot more sense [05:25] th1a: what role is he trying to give you? [05:26] kiko: That's a pretty quick conclusion. :) [05:26] bradb, I mean, well, what do YOU think? :) [05:26] th1a: https://launchpad.net/products/schooltool/+reassign ? [05:26] SteveA: Well, I should be able to do just about everything. I'm not sure what you call that. [05:26] It's not really that simple. There are various events that can happen to consider a bug being "modified", like adding a comment, adding a watch, changing the status/assignee/etc. [05:26] th1a: maybe you want to create a team with you and brian in it [05:27] all of these, IMO, should trigger an update to the date, bradb [05:27] SteveA: I'm not sure what he did. [05:27] and then use that page to make tha tteam the owner? [05:27] Different objects being modified, and even only specific fields on those objects. [05:27] SteveA: I get permission denied when I try that [05:27] SteveA: looks like bug 41639 [05:27] jinty: when you try to use +reassign [05:27] Malone bug 41639 in launchpad "Product owner should be able to reassign ownership to another user." [Normal,Confirmed] http://launchpad.net/bugs/41639 [05:27] kiko: someone new being subscribed to a bug causing it to bump the bug up the sort order? ew. :) [05:27] SteveA: to be exact, I can view it, but not change it [05:28] i see [05:28] bradb, well, you could argue it either way.. [05:28] who do you want to be the product owners? [05:28] do you have a team, or should it just be tom? [05:28] thanks matsubara [05:30] kiko: The point of this functionality is to help steer devs into spending their time on things where something has changed, instead of having them polling bug reports. It seems highly unlikely to me that adding a subscriber (or, for example, changing a bug nickname, perhaps) is important enough to bring the bug to the devs attention. [05:30] SteveA: A team is probably better. [05:30] s/attention/attention again/ [05:31] bradb, you're somewhat right, but where do you draw the line? [05:31] kiko: At a subscriber being added, for one. :) [05:31] why? [05:31] that shows that at least one more person is interested [05:32] SteveA: And...? [05:32] well, you fix a bug depending on the number of people it affects, at least to some extent [05:32] if it affects 0 people, you need not fix it [05:32] if it affects 100% of people, you must fix it [05:33] and subscribing is an indication of interest in the resolution [05:33] which implies being affected [05:34] th1a: do you have a team in mind? [05:34] bradb, #cm [05:35] SteveA: It could be jinty and I. In theory sabdfl should be an owner, too ;-) [05:35] stub: hi, I think staging mirror is broken atm... [05:35] you should be able to create such a team for yourselves in launchpad [05:36] and give it a name like schooltool-owners [05:36] let me know when you've done that [05:36] and i'll transfer ownership of the schooltool product [05:38] ZConfig.ConfigurationSyntaxError: 'warn_about_no_published_uploads' is not a known key name (line 95 in file:///srv/launchpad.ubuntu.com/staging/launchpad/configs/staging/launchpad.conf) [05:38] Any reason why that is required? [05:40] stub, I dropped this config option, but aparently I forgot to remove it from staging's config. sorry for that [05:40] ahh... yes. I had it backwards :-) [05:47] kiko: I have the PoMsgSetPage implemented already, I'm fixing tests now [05:47] YES! [05:48] but please note the correct way to do this is... [05:48] "I have the PoMsgSetPage tests implemented already. I'm fixing the implementation now" [05:48] well, the page has impact on existing tests, SteveA [05:49] of course [05:49] which can be changed first too :-) [05:49] and some changes are rather unpredictable [05:49] but, you'd find those needed changes as you worked on the implementation [05:49] well, I'm getting test failures that should not be failing in first place... [05:50] BjornT: what's the story on getting us able to use the new test facilities in zope3.2 ? [05:50] I'm reviewing the diff to know why are they failing [05:50] if you're getting failing page tests, it may be easier to rewrite them in the new style... [05:50] if we have the new style available [05:51] is not a problem with pagetests [05:51] okay finished stuffed pqm [05:52] but with doctests [05:52] okay [05:52] going watch a movie, I'll probably be back afterwards [05:52] carlos: ping me if you need help with fixing the tests [05:52] SteveA: well, there's one rt ticket needing to be resolved, then test.py needs a small patch. after that it's possible to use it. [05:53] SteveA: will do, thanks [05:55] BjornT: what rt number, and can the patch be made conditional so it may be applied now? [05:57] SteveA: actually, the rt ticket might have been resolved already, i can't find it. the patch to test.py can be applied anyway, it just removes '.' from PYTHONPATH [05:57] please get that patch into PQM === SteveA looks in the RT web ui [05:58] do it [05:58] pop the trunk [06:03] BjornT: can't find the ticket in current or resolved RT tickets for launchpad [06:03]