=== flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has left #launchpad ["Bye"] === jd_ is now known as cadavre === cadavre is now known as jd_ === mdke_ [n=matt@unaffiliated/matt/x-000000001] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [01:35] good morning === mdz [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net] has joined #launchpad === rpedro [n=rpedro@87-196-98-154.net.novis.pt] has joined #launchpad [02:44] yawn [02:47] =) === stub [n=stub@ppp-58.8.2.91.revip2.asianet.co.th] has joined #launchpad [05:30] Gooooooooooooooooooood afternoon Launchpadders! [05:43] lifeless: I need to merge upstream Z3 changes from sftp://chinstrap/home/warthogs/archives/stub/zope/devel into our Zope. Do you want to handle it or should I? === root__ [n=root@200.241.108.195] has joined #launchpad [05:55] Aqui o Canal da distribuio para Linux Ubuntu? === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === mpt_ [n=mpt@203-173-177-223.bliink.ihug.co.nz] has joined #launchpad [07:23] stub: if you can, please do. EP is keeping me plenty busy [07:57] "(Use your email address and Launchpad password create an account.)" [08:01] mpt_: I've mailed the admins about that. [08:03] ok :-) [08:03] At least it's an improvement [08:03] Yeah. === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad === rpedro_ [n=rpedro@87-196-10-127.net.novis.pt] has joined #launchpad === carlos [n=carlos@208.Red-83-33-192.dynamicIP.rima-tde.net] has joined #launchpad [08:57] morning === mdke_ is now known as mdke [09:00] morn [09:01] hello === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [09:08] So if I break out Product.name, Distribution.name and Project.name into a PillarName table there will be a lot of nasty performance fallout. Most of this could be fixed using prejoins, but identifying all the call sites will take time and cause disruptions due to increased page timeouts. [09:09] Alternatively, I could keep the product, distribution and project tables as they are, and maintain uniqueness in other ways. [09:09] I'm leaning towards keeping the existing tables as they are at the moment [09:11] I guess it depends on the alternatives. [09:11] Although perhaps changing the database in such a way that all calls to Product.name fail, I can slowly work through the failing tests. [09:11] I guess keeping the tables separate also makes it more undoable [09:14] What sort of alternatives do you have in mind? Something like having triggers that update a PillerName table, which in turn has the unique constraint? [09:14] Yes. That would be the implementation. [09:15] Doesn't seem too horrible. [09:15] The only code that would use the PillarName table would be the name validators [09:16] Right. [09:16] It is sacrificing correct design for a quick fix, although 'correct' here is arguable. [09:17] "correct" might be to use postgresql table inheritance [09:17] have product, proejct and distro inherit from a "pillar" table with a name column which has a uniqueness constraint [09:18] Perhaps. We have never done that in the past in order to ensure we could switch to a different back end if needs be. Although we could emulate that with views if necessary. [09:19] Well, we already have portability issues because we have the plpython routines. [09:19] sure. It is a way to ensure uniqueness though. [09:20] There isn't too much PostgreSQL specific stuff to worry about. The most annoying to work around would be the PostgreSQL SQL extensions we are using in a few places because performing those queries without the extensions would be expensive [09:20] I guess table inheritance wouldn't be major provided we don't go crazy. [09:21] the above usage is basically just to enforce a constraint [09:21] I'm sure we could find other ways to enforce the constraint with other dbs (if we ever decided to move away from pg) [09:22] jamesh: We would also use the base table to check if the constraint is about to be violated in the validation code, to avoid needing to do 3 queries. [09:22] Yup. Same result really as using triggers to maintain PillarName, but without the triggers so it will be cleaner and faster. [09:23] DB patch will be a bitch though - all those foreign key constraints to rebuild :P [09:25] could you actually do it as a db patch? [09:25] doesn't it involve recreating all those tables? [09:25] It can be done as a DB patch. I only need to recreate the Product, Distribution and Project tables. All the related tables can be handled with ALTER TABLE. === stub tries to recall if ER diagrams have a syntax for table inheritance [09:27] UML does ... [09:27] UML wasn't invented when I was doing those subjects ;) [09:28] Hmm, the branch-scanner is getting a heap of ForbiddenAttribute: ('last_scanned', ) errors. === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad [09:33] mpt_: ping [09:36] stub: what about an updatable view that looks like e.g. product, but has the name coming from PillarName ? [09:36] stub: that should stop sqlobject being stupid [09:38] spiv: weird. I wonder why the tests didn't pick that up? [09:38] local configuration vs production server configuration perhaps [09:38] was security.py updated correctly, and do the tests run the scanner as the right db user ? [09:38] erm, security.cfg [09:40] lifeless: branchscanner user has select,insert,update perms on the Branch table. That exception would be from Zope security framework [09:41] interesting [09:41] so we have a sec proxy in the way [09:42] well, the scanner uses utilities to get and create branches,etc === mpt [n=mpt@203-173-177-223.bliink.ihug.co.nz] has joined #launchpad [09:44] lifeless: Updatable views are a pita to create, although I'll look into that too. [09:47] updatable views would need to be updated after each modification to the underlying table [09:53] spiv, lifeless: ForbiddenAttributet is a Zope security wrapper exception - nothing to do with the DB. [09:54] morning ! [09:59] jamesh: so, there are two things, why do the tests miss this, and lets fix it :) [10:04] lifeless: it might be easiest to move the bzrsync code out of lib/importd and have it run by the LP test runner [10:04] jamesh: is it not run by the lp test runner already ?t [10:04] jamesh: anyway, I think that is fine,and sensible [10:05] lifeless: lib/importd/tests/harness.py does some custom setup (see ZopelessUtilitiesHelper), which probably doesn't setup the security stuff [10:07] jamesh: I trust you :). === malcc [n=malcolm@host86-135-139-100.range86-135.btcentralplus.com] has joined #launchpad [10:25] spiv: hmm. Branch.last_scanned is defined with Attribute() in the interface. Could that be the problem? [10:27] jamesh: That should be fine. [10:31] spiv, jamesh: Attribute could be the problem. Attributes don't get security declarations if you use set_schema [10:32] BjornT: ... and branch.zcml uses set_schema [10:32] I guess that answers the question [10:33] Oh, huh. I didn't know that. === doko_ [n=doko@dslb-088-073-100-163.pools.arcor-ip.net] has joined #launchpad [11:11] We use Attribute too much because we are lazy. We should replace them with genuine schema definitions as we go (most of them would be name = Object(IFoo) or one of the more complex schema field types I suspect). [11:48] lifeless: Do you have any issues with migrating Balleny to Dapper? [11:56] we should not use set_schema [11:56] it's like "chmod 666" === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad [12:37] stub: Do It [12:38] can a product owner change their RCS source, or is that only available to LP admins? [12:39] for vcs-imports? [12:40] https://launchpad.net/products/silva/trunk [12:40] they moved from CVS to SVN [12:40] https://launchpad.net/products/silva/trunk/+source should allow that methinks [12:44] I get a perission denied, so I don't know [12:44] I mailed him === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad === mpt_ [n=mpt@203-173-177-223.bliink.ihug.co.nz] has joined #launchpad === mpt [n=mpt@203-173-177-223.bliink.ihug.co.nz] has joined #launchpad === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] 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 === lincao [n=lincoln@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad === carlos -> lunch [02:32] see you later === rodarvus [n=rodarvus@ubuntu/member/rodarvus] has joined #launchpad [03:02] hi there [03:03] I tried to upload a package to upload.ubuntu.com 20 minutes ago, but can see any sign of it in the Edgy queue (nor any email is sent to edgy-changes) [03:03] some debugging: [03:03] - package name is 'x11proto-damage' [03:03] - I have my gpg key uploaded to LP *and* I used rodarvus@ubuntu.com as uploader email [03:04] - I am on the relevant LP group (ubuntu-core-dev) [03:04] is there any place I can check to see what went wrong with the upload? [03:05] rodarvus, I guess cprov will be able to help you === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad [03:05] rodarvus: I can see your upload in the failed folder, I'm just checking why now [03:06] malcc, in this case shouldn't it also show up on the Rejected Edgy queue? (in LP) [03:06] rodarvus: No. Rejected is for uploads which the system understood and managed to import, and which the administrator later decided to reject. [03:07] rodarvus: This is what happens when the code breaks while trying to read your upload into the database [03:07] oh, right === jd_ [n=jd@wikipedia/Meanos] has joined #launchpad [03:13] malcc, I got the rejection mail now, thanks! [03:13] rodarvus: Great! === niemeyer [n=niemeyer@201.11.40.211] has joined #launchpad === jgi [n=jgilli@251.9.39-62.rev.gaoland.net] has joined #launchpad [03:41] hello everyone [03:42] I'm one of WengoPhone"s developers. I've created a launchpad project a while ago, but I can't use rosetta. I sent an e-mail to an administrator about this but I got no answer so far. [03:42] How should I proceed to be able to use Rosetta? [03:46] jgi: have you seen https://help.launchpad.net/RosettaFAQ ? [03:47] carlos, jordi: ^^ [03:49] matsubara: yes [03:50] sorry, last minute meeting, brb [03:54] carlos, around? === jd_ is now known as jd_away === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad === rodarvus [n=rodarvus@ubuntu/member/rodarvus] has left #launchpad ["Leaving"] [04:17] morning! [04:18] flacoste, thanks for the answer -- and yes, insightful. Do you think the issue is HTTPS non-caching? [04:19] SteveA, why is it difficult to fix the zope3 logger to DTRT for us? [04:19] kiko-zzz: HTTPS non-caching, that might be possible [04:19] SteveA, lifeless, do you know if that's the case? [04:21] matsubara: in https://help.launchpad.net/RosettaNewImportPolicy , it says "Contact the upstream authors of the product, and tell them about his plans. We suggest using the mail template at the end of this page." [04:21] matsubara: and then "If they agree to use Rosetta as their infrastructure for translation, the product will be marked as "Rosetta official"," [04:21] matsubara: but what happens in between? How rosetta admins know that the project mantainer agreed? [04:22] matsubara: I thought it was supposed to be done my emailing rosetta@launchpad.net [04:22] matsubara: I did send an e-mail few weeks ago, and I never got any response [04:22] kiko-zzz: Pages accessed by HTTPS can never be cached in a shared cache. Since the conversation between browser and server is encrypted, intermediate caches are unable to see the content to cache it. Worse, some browsers will not even cache HTTPS documents in their local per-user caches. [04:22] that comes from http://www-uxsup.csx.cam.ac.uk/~jw35/courses/using_https/html/x191.html [04:23] (found by googling https caching) [04:23] flacoste, I thought that firefox would cache the HTTPS content. Don't you? [04:23] flacoste, I think perhaps our Javascript is being wonky [04:23] i don't know if firefox is included in 'some browsers' - it represents 50% of our browsers [04:23] jgi: you probably want to chat with jordi or carlos, but they apparently aren't available now. [04:25] jgi: kiko-zzz might also help. [04:25] matsubara, not right now, I can't :) [04:25] kiko-zzz: ok. [04:27] kiko-zzz: well the PNG aren't cached (according to Page info) so I don't think the CSS/JS is [04:28] matsubara: ok, thank you very much [04:28] flacoste, the PNGs aren't cached? we reload every single one of them every page load? waaah [04:29] well, that would explain the statistics [04:29] 70% of the requests are non-HTML [04:29] i.e. 29.9 are dynamic URL the rest is static content [04:30] cprov, Kinnison, malcc: argh, we're getting spammed by sync requesters [04:30] cprov, Kinnison, malcc: should we add a mailing list contact, or should we use a separate team for upload admins? [04:30] kiko-zzz: the pngs are cached [04:30] kiko-zzz: but people hit 'ctrl-f5' [04:30] or ctrl-R [04:31] kiko-zzz: putting a proxy cache in front of the app servers (where static content could be cached) would offload processing these requests from the app server but that wouldn't solve the bandwitdh issue [04:31] and that will always do a full request for every item. [04:31] lifeless: according to Page Info in my browser, it doesn't cache them [04:32] oh, I was tracing locally. Https will force all documents to not cache in some browsers [04:32] what browser are you using [04:32] Firefox [04:32] from Dapper [04:32] IIRC that has that behaviour [04:32] this is a reason to have pngs served via http [04:32] lifeless, that gives the end-user the broken lock icon. [04:32] exactly [04:33] probably the right solution is to use SSL just for the login page and redirect back. [04:33] let me check something [04:33] kiko-zzz: except for private data like security bugs [04:33] I think this will have a serious performance benefit for us, fwiw [04:33] lifeless, *shrug* [04:34] kiko-zzz: I agree we need to do something [04:34] http will perform better, as long as we are careful about it I am fully supportive of that [04:40] jgi: hi [04:40] carlos: hello [04:40] jgi: you did the right thing [04:40] carlos: ok :-) [04:40] I guess jordi missed your email [04:40] no problem [04:40] jgi: which product are we talking about? [04:41] kiko-zzz: yes, there should be an options in team subscription to avoid it [04:41] carlos: WengoPhone [04:41] carlos: I can send you the e-mail back [04:41] no, I found it [04:41] ok [04:41] jgi: I will ping jordi about it [04:41] jordi: ? [04:43] kiko-zzz: those emails are sent us because the sync-requester has explictly subscribed UPAA team to the bug, right ? [04:43] correct. [04:43] I confirm, Firefox doesn't really cache https [04:43] Keybuk, ping? [04:43] about:cache?device=disk doesn't contain any https link [04:43] about:cache?device=memory contains them [04:44] but the Fetch count increase by one every time I visit a launchpad page [04:44] it probably fetches once and then reuses for the elements in the page. [04:44] so, it still pulls them out on every request [04:44] you mean, if the image would appear more than one on the page, that would make sense [04:45] ff will request the pngs on every single time it is restarted, but should not during a session, unless f5 is pressed. (we'd have a worse than 70% ratio if it requested every single time) [04:45] flacoste: what headers are we serving the pngs with / [04:46] Cache-control: public, max-age=86400 [04:46] Expires: Date one day in the future [04:46] Last modified: Date of last modification [04:46] should be fine [04:46] yeah, if that is not kicking ff, there is SFA we can do [04:52] flacoste: your bug is next on the todo list btw [04:53] LarstiQ: ok, so what is your patch fixing? [04:55] flacoste: being able to do 'bzr log -r revid:francis.lacoste@contre.com-20060623145323-e01f1a4246557f3e..revid:francis.lacoste@contre.com-20060623145356-8f4ba6313ad3237d' [04:55] flacoste: that is what I understand the report to be about [04:56] LarstiQ: that is indeed an entirely different issue [04:56] flacoste: so I'll file a new bug later on and notify you about that [04:56] LarstiQ: should I post my comment as a new/different bug then? [04:56] flacoste: if you want, sure [04:56] either of us will do :) === flacoste is doing this now [05:00] carlos, ping? [05:00] salgado: pong [05:01] carlos, I'm implementing KarmaContext, and I need to check with you what the context should be in some rosetta-related callsites of IPerson.assignKarma. do you have a few minutes to talk about that now? [05:02] sure [05:02] where could I read about KarmaContex? [05:03] carlos, launchpad.canonical.com/KarmaContext [05:03] ok [05:04] I have the callsites noted down here, with what I think should be the context. I'll paste them in /query for you [05:04] matsubara: hmm, stub is not around [05:05] matsubara: I introduced a change with latest production update that needs data migration [05:05] I think stuart already did such data migration and added the unique restriction [05:05] oh, I see, that's data bug then. do you need me to report it? [05:05] matsubara: but I don't know it for sure [05:05] matsubara: it's not really a bug [05:05] it would be just that stub was doing the migration at that time [05:06] we need a confirmation from stub first [05:06] LarstiQ: bug 51980 [05:06] Malone bug 51980 in bzr "bzr log displays irrelevant log record" [Untriaged,Unconfirmed] http://launchpad.net/bugs/51980 [05:09] hmm, I did build the same binary, same version from a different source, it was sucessfully built, but I didn't get a message that it cannot enter the archive ... [05:10] flacoste: thanks [05:13] kiko-zzz: did you receive an email notification from the spec tracker about my request for comment? === flacoste wants to know if I should send MPT an email [05:14] carlos: thanks. I wrote on the report about it and asked stub to confirm if he did the data migration. [05:14] matsubara: data migration + unique restriction [05:15] he had to remove it until the data migration is done === lfittl [n=lfittl@83-65-242-161.dynamic.xdsl-line.inode.at] has joined #launchpad === mdz [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net] has joined #launchpad === glatzor [n=sebi@ppp-82-135-72-134.dynamic.mnet-online.de] has joined #launchpad [05:34] kiko-zzz: hi [05:34] back from doctor's again now === Keybuk looks at cprov-lunch ... you're just avoiding me now, aren't you [05:42] Naturally :-) [05:43] Anything I can help with? === bradb & # lunch [06:56] Kinnison: so, err [06:56] 1004 32353 0.6 0.0 5264 1160 ? D 17:03 0:20 cp -a /srv/launchpad.net/ubuntu-archive/ubuntu/dists /srv/launchpad.net/ubuntu-archive/ubuntu/dists.new [06:56] has been running for 55 minutes [06:58] Hmm [06:58] Keybuk: impressive [06:58] cron.daily is safe, yes? :) we won't get a second one starting in three minutes [06:59] it is locked [06:59] Yes, it's got super soyuz locking technology [06:59] mkdir .lock || exit 0 ? :p [07:00] WE HAVE REACHED PUBLISH-DISTRO \o/ [07:00] if ! lockfile -r1 $LOCKFILE; then [07:01] dists is only 10000 files and 4GB, it shouldn't take a long time to copy [07:02] I should have thought more about this when you said it was taking 12 minutes earlier, that seemed longer than before... [07:02] 12 minutes to 53 minutes is a bit of a jump === Keybuk wonders whether the disk is about to drop a cog [07:03] Keybuk: Now there's a worryingly possible thought [07:06] malcc: any chance of your enhanced rsync based cron.daily any time soon? [07:07] Kinnison: I'm working on it as we speak [07:07] Kinnison: But I'd rather find out why copy is taking an hour for a few gigs than rush it out, if possible [07:10] indeed [07:11] A copy of 700 megs and 400 files (what we've got in dists on mawson) takes seconds [07:12] jgiaway: hey there. [07:12] jgiaway: I'll reply to your email now, sorry about this [07:12] s/400/4000/ === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === carlos -> out [07:24] jordi: hello [07:24] jordi: no problem, thank you very much for your feedback [07:25] Kinnison: queue builder still does not appear to be working [07:25] cron.daily is finished [07:25] sequencer ran queue_builder [07:25] but it took no time, and has not queued the builds I expected it to === cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === bradb wonders where my merge request went [07:27] and of course that's when the message arrives in my inbox... [07:28] Keybuk: Hmm, I can't see why this is the case, I know for sure that if I stop the sequencer and run the queue builder it works, I'll have to ponder, but unfortunately I'm about to leave for the night [07:31] Kinnison: ok, if it continues to appear to not do anything, I'll do it by hand in a minute === Kinnison nods [07:31] remember to stop the sequencer before you do [07:40] Kinnison: given that the cron.daily from hell run actually appears to have just died, rather than completed normally ... [07:40] could you investigate that? [07:41] I'll try === Kinnison has to go in 20 minutes though [07:43] publish-distro got a db-closed error [07:44] so it died? [07:44] will it run ok in 20 minutes time? [07:45] should do === mdke_ [n=matt@ubuntu/member/mdke] has joined #launchpad [08:00] right, I gotta go [08:00] ciau [08:03] heeelo [08:04] Keybuk, so, we're getting spammed with sync requests [08:04] because ubuntu-archive is subscribed to these bugs by default === mdke__ [n=matt@81-179-220-61.dsl.pipex.com] has joined #launchpad [08:13] matsubara, timeouts and soft timeouts seem to be much better, eh? [08:14] kiko: yep. [08:14] BjornT, are you okay with me working on the process for fetching bug messages to improve perf? [08:15] kiko: sounds good, i'm not touching that code atm. [08:15] BjornT, thanks. [08:16] matsubara, is the Build.lastscore traversal error already fixed? === matsubara checks [08:17] BjornT, question 2: did you end up landing those CSS fixes we did together? [08:17] kiko: ah, no, forgot about those. [08:19] kiko: it's assigned to cprov and it's in progress. I left a comment there the last time that oops appeared in the reports. [08:19] kiko: by there I mean bug 44227 [08:19] Malone bug 44227 in soyuz "When the buildqueue_status is None +rescore page OOPS" [Medium,In progress] http://launchpad.net/bugs/44227 [08:20] matsubara, thanks a million. [08:20] BjornT, will you land them? [08:22] damn pqm doesn't like me [08:23] kiko: sure. not tonight, though. i'll file a bug so i won't forget it. [08:23] thanks! [08:24] I'm having weird test failures on bzrlib and test_CVS.py. [08:24] matsubara: sorted, bug 44277 [08:24] Malone bug 44277 in Ubuntu "nothing on ctrl alt F# (Dapper)" [Medium,Rejected] http://launchpad.net/bugs/44277 [08:24] bug 44227 [08:24] Malone bug 44227 in soyuz "When the buildqueue_status is None +rescore page OOPS" [Medium,Fix released] http://launchpad.net/bugs/44227 [08:25] cprov: thanks! [08:25] matsubara, like was discussed in the list today? [08:26] kiko: it's not exactly the same error. I sent the request twice and got 2 different failures [08:26] kiko: should I try the third? [08:26] yes [08:28] matsubara: np === milosz [n=dem@d192-24-43-158.try.wideopenwest.com] has joined #launchpad [08:31] hey i got a question about lauchpad, i've seen that this trunk branch showed up for my project (drapes) but i cannot add a bzr branch to it, only cvs or svn [08:32] let's see, milosz [08:32] or a tarball [08:32] https://launchpad.net/products/drapes/+addbranch [08:33] is the issue that you'd like to add the branch for that specific series? [08:33] i alredy have branch registered (called main) but some reason on https://launchpad.net/products/drapes it get this [08:34] trunk: The "trunk" series represents the primary line of development rather than a stable release branch. This is sometimes also called MAIN or HEAD. [08:34] and when i click on it, it tells me i don't have trunk registered, and redirects me to https://launchpad.net/products/drapes/trunk/+source ... [08:34] it's ... confusing [08:37] am i missing something? [08:44] no [08:45] it's actually very confusing === KI11obyte [i=KI11obyt@85.233.81.49] has joined #launchpad [08:51] so can i import the trunk branch or i can't? [09:00] milosz, well, I think you can just add the branch to your product. [09:00] we'll figure out later how to tie these two things together [09:00] ok [09:04] how can I access the staging database using psql? === flacoste wants to try some full text queries on tickets [09:04] flacoste, usually you can't. access there is quite restricted [09:06] kiko: ok, remove soyuz team from ubuntu-archive then [09:07] Keybuk, well, how do we handle the queue permissions then? [09:07] ubuntu-archive [09:07] and put soyuz-team in admins [09:07] (where it already is) [09:08] to look at it another way, if the soyuz-team need to be able to modify the ubuntu queue, there is something wrong [09:08] because then they also need to be a member of the queue team for every distribution on launchpad [09:11] having a different team for queue permissions than for administrativia doesn't make sense either [09:11] because then you have different people receiving the quests to those who can actually act on them [09:13] Keybuk, that doesn't help us in the practical situation we are in now, does it? [09:13] what is the situation we're in now [09:13] I must admit, I don't understand why soyuz-team needs to be in ubuntu-archive [09:13] I want to move soyuz-team out of admins. [09:13] this doesn't give me a path forwards.. [09:13] cprov, Kinnison? [09:13] but it sounds like you can't move them out of admins? [09:14] either soyuz-team has to be a member of every distribution's upload team [09:14] OR soyuz-team has to be specially privileged somehow [09:14] why do soyuz-team need to be able to use the ubuntu upload stuff? nobody in there has permission to actually approve things [09:16] I guess the question is; what do soyuz-team need to be able to do in Launchpad? [09:18] Keybuk, if they don't have those permissions, they can't actually look at the queue UI. [09:18] do they need to? [09:18] (probably a silly question, but... ) [09:18] well, if you want to be able to show them what is wrong about it, then, yes [09:18] when Guadalinex is on Launchpad, do soyuz-team need to look at their UI? [09:19] need is a hard word [09:19] but it might make things a lot easier [09:19] I suspect, for now, the right answer is either [09:19] a) soyuz-team in admins [09:19] b) soyuz-team in ubuntu-archive and procmail away the bugs [09:19] c) have a TEMPORARY ubuntu-upload-manangers team that includes ubuntu-archive and soyuz-team [09:19] with the explicit mark that c) is temporary only, and will go away when soyuz works [09:24] I think b) [09:24] kiko: as it is right now. [09:24] yes. [09:24] and procmail away [09:26] I have a suggestion for Soyuz Team, we can fix all soyuz related security adapters to grant Admin for us and avoid this management overhead, what do you think kiko ? [09:27] using a celebrity, you mean? [09:27] we still missing several sec adapters anyway, good chance to land them. [09:27] yes, of course, soyuz-team will be a celebrity [09:27] I don't like that idea very much [09:27] it sounds weird to have the team backdoored [09:28] kiko: I see, but with the current global permission systems we can't do anything better [09:28] yeah [09:28] I'm thinking [09:32] is it possible to run all tests inside launchpad/doc/? [09:38] I don't know myself [09:38] salgado: this could work: python test.py -f --test='/doc/[^/] *\.txt' [09:40] salgado: or maybe better: python test.py -f test_system_documentation [09:40] BjornT, matsubara suggested using --layer=SystemDoctestLayer. should that work too? [09:41] salgado: using SystemDoctestLayer won't run zopeless tests (i think) [09:41] hmmm. the layer thing doesn't work. it ran only 59 tests and they all passed === salgado tries the test_system_documentation this time [09:43] thanks BjornT! [09:52] salgado: what did you use to check python source file pylint? [09:53] flacoste, pyflakes! [09:54] how does it work? [09:55] no man page, pyflakes -h or --help just gives me an error [09:56] ok [09:56] cron.daily is now up to "every 3 hours" [09:56] this is getting decreasingly amusing [09:56] flacoste, pyflakes $filename [09:56] kiko: no configuration possible then i guess [09:57] flacoste, what configuration would you want? it is ultra-simple [09:57] flacoste, no, it only does some basic syntax/name checking [09:57] ok, most other lint checker i know have a bunch of configuration checks you can enable/disable [09:57] pylint has modules which can be used to test for a given coding style for example [09:58] flacoste, pyflakes only catches real errors [09:58] lol [09:58] seriously! [09:58] actually, I have pyflakes consistenly false positive-ing for me, it's very frustrating [09:59] because even pyflakes catches-almost-nothing approach is better than nothing at all [09:59] elmo, can you give examples of false-positives? [09:59] kiko: it's not LP (or even work) code === niemeyer [n=niemeyer@201.14.22.12] has joined #launchpad [09:59] but sure, if that doesn't matter [09:59] elmo, sure, but I'm still interested -- the tool should work well [10:00] here? [10:03] elmo, or in a pastebin if you have an example [10:04] it's just one line, I more meant off topicness, anyway [10:04] init_db.py:25: redefinition of unused 'daklib' from line 24 [10:04] it's all stuff like that [10:04] which comes from import daklib.utils on 24 and import daklib.database on 25 [10:04] and both of those modules are in use in the init_db.py [10:08] neither pychecker or pylint complain about this, and pyflakes does the same thing even on the bzr source (at least the version in dapper) [10:11]