=== lepingbeta_ [n=lepingbe@210.16.136.138] has joined #launchpad === lepingbeta_ [n=lepingbe@210.16.136.138] has joined #launchpad === JanC [n=janc@dD577040E.access.telenet.be] has joined #launchpad === JanC [n=janc@dD577040E.access.telenet.be] has joined #launchpad === mattl [n=mattl@gnu/webmaster/mattl] has joined #launchpad === jd_ [n=jd@wikipedia/Meanos] has joined #launchpad === mirek [n=mirek@dhcp-48-53.cnl.tuke.sk] has joined #launchpad [01:59] may i ask for help? i am new to launchpad and i would like to add new serie of drupal cms [01:59] (i added new release to old serie :-( ) [02:02] no roseta admin in here? === radamantis [n=ircap8@host-200-76-166-241.block.alestra.net.mx] has joined #launchpad === radamantis [n=ircap8@host-200-76-166-241.block.alestra.net.mx] has left #launchpad [] === asw [n=asw@karuna.med.harvard.edu] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad === rpedro [n=rpedro@87.196.0.221] has joined #launchpad === AlexMBas [n=alexandr@beigetower/alexandre] has joined #launchpad [03:00] hello all [03:00] can someone lend me a hand trying to solve a problem with Rosetta? [03:02] we're having problems with % substition on strings [03:02] https://launchpad.net/distros/ubuntu/dapper/+source/scribus/+pots/scribus/pt_BR/+translate?batch=10&show=untranslated on string 99 for instance [03:03] any rosetta developer around here ? [03:04] my guess is that those strings have been incorrectly marked as C format strings in the PO template [03:04] jamesh: true [03:04] jamesh: is this something we'd have to fix it upstream? [03:04] yeah [03:05] Rosetta performs special checks to C format strings to make sure that the translations are compatible format strings [03:05] (which isn't really desired if the string isn't a format string) [03:05] jamesh, % followed by a space character should not be identified as a C format string, shound it ? [03:05] the best fix would be to the scribus source code, telling xgettext that the string isn't a format string [03:06] AlexMBas: lemme know the outcome? I'll be doing something else [03:06] ok [03:06] thanks OgMaciel [03:06] AlexMBas: my pleasure buddy [03:07] jamesh, who should do it on scribus source code ? [03:07] we (translators) ? or should we open a bug report for the upstream package ? [03:08] AlexMBas: probably the scribus developers -- if they add a comment like /* xgettext:no-c-format */ above the string, it will fix the problem for future po templates [03:08] cool [03:08] so I'll try to contact them [03:08] I am not sure if we have a policy for unsetting c-format for existing data in Rosetta though (I don't work on that part of Launchpad) [03:08] thank yoiu very much jamesh [03:09] I'll try to contact the upstream development team === stub [n=stub@ppp-58.8.2.72.revip2.asianet.co.th] has joined #launchpad === jdong [n=jdong@ubuntu/member/jdong] has joined #launchpad [03:56] is it OK to attach deb packages to bug reports? [03:56] bandwidth/storage wise [03:57] I don't want to be abusing launchpad's generous services [03:57] jdong: should be fine. [03:57] thanks! [03:57] Assuming it's not openoffice-sized ;) [03:57] Ubuntu Backports testers are gonna love you, spiv [03:58] no, I'm not gonna upload any beasts like that! [03:58] most of them are small packages, like rhythmbox or dia [03:58] :) [03:58] this will greatly improve our testing base [04:03] btw, I forgot to say this earlier, but thanks for making bzr hosting and knits work on launchpad :) [04:04] the automatix team loves you guys for that :) [04:04] Cool :) [04:06] these canonical projects are just nothing short of amazing [04:06] in about a year you guys have made a service that rivals Sourceforge [04:06] Hmm, they don't seem to be using team branches, I wonder if that's intentional. [04:06] https://launchpad.net/products/automatix/+branches [04:06] we've got 4 team-authored branches [04:07] they're still learning how to work the bzr system [04:07] Oh, I was looking at the "Official Automatix.KDE Head" one, which is under ~mstlyevil [04:07] But I see there are some in ~automatix after all. [04:08] Excellent :) [04:08] spiv: that is a "authored by team, registered by user" branch [04:08] so ends up in the user's namespace [04:08] jamesh: Well, it's the location it was pushed to that I was interested in. [04:11] jamesh: Mostly I was wondering if the ~ directories were discoverable enough that people would use them or not. It seems they are. [04:11] spiv: will launchpad eventually get some documentation on using hosted branches? [04:12] spiv: I only figured it out because I was browsing around with a SFTP client, and came across the team folders [04:12] then I asked ddaa in #bzr about it [04:13] jdong: ddaa wrote a blog article about it (and will write a followup on team branches) [04:13] jamesh: I know that; but I don't think the average person exploring launchpad.net will figure that out [04:14] something on either the bazaar info page or the register branches, or even the +branches/ page would be cool [04:14] jdong: yep. Perhaps we should get some docs up on help.launchpad.net about it. [04:17] jdong: https://launchpad.net/bazaar has a short overview [04:17] d'oh === guilhermee [n=guilherm@20151055153.user.veloxzone.com.br] has joined #launchpad === guilhermee [n=guilherm@20151055153.user.veloxzone.com.br] has left #launchpad [] === kpgeek [n=kpgeek@59.92.205.219] has joined #launchpad === fantasai [i=fantasai@copper.takiweb.com] has joined #launchpad === fantasai pokes mpt === kpgeek [n=kpgeek@59.92.205.219] has joined #launchpad === lepingbeta [n=lepingbe@210.16.136.138] has joined #launchpad === raphink-work [n=raphink@vll06-1-82-234-166-84.fbx.proxad.net] has joined #launchpad === stub [n=stub@ppp-58.8.2.72.revip2.asianet.co.th] has joined #launchpad === Starting logfile irclogs/launchpad.log === ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog] has joined #launchpad === Topic for #launchpad: https://launchpad.net/ | developer meeting: Thu 29 Jun, 1200UTC (wiki:MeetingAgenda) | launchpad-users@lists.canonical.com (wiki:MailingLists) | Channel logs: http://tinyurl.com/72w39 === Topic (#launchpad): set by SteveA at Thu Jun 22 14:03:31 2006 === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad === dem [n=dem@d192-24-139-155.try.wideopenwest.com] has joined #launchpad === lepingbeta [n=lepingbe@210.16.136.138] has joined #launchpad === glatzor [n=sebi@ppp-82-135-65-46.dynamic.mnet-online.de] has joined #launchpad === lepingbeta [n=lepingbe@210.16.136.138] has joined #launchpad [08:06] SteveA: I don't suppose you know what airlines might offer cheap flights between London->Vilnius, Vilnius->Paris, Prague->Bucharest and Prague->London? [08:13] stub: I got an air baltic flight for london -> vilnius and back (the same flight Steve is taking) [08:18] Launchpad will be going down in 15 minutes time. Estimated downtime is 10 mins. [08:18] This is for the regular code update. [08:36] I've had to abort the update. Another attempt will be made later today. [08:37] any particular problem? [08:38] stub: what did explode? [08:40] I need to rerun a data migration script as some bad data has crept back in. === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [08:44] Znarl, elmo: Gangotri app server will be down for the next few hours so ignore the alerts === rraphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === LeeJunFan_ [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad [09:07] stub: london to vilnius and vilnius to paris: try air baltic (as james said) and lithuanian airlines (dunno what they're called nowadays. all the formerly state-owned companies have recently rebranded themselves and no one knows who is who anymore) === mpt_ [n=mpt@203-173-178-53.bliink.ihug.co.nz] has joined #launchpad [09:18] lifeless: while working on my cscvs branch, I was looking at doing a test case for changing a file to a symlink in subversion, but it seems that subversion prevents you from doing that [09:18] ahha. if you do a delete and add then of the same name, changing type ? [09:19] that's what you need to do, yes. [09:20] so we shouldn't see evil branches that trip up bzr in that respect [09:24] wel, I'd like to be sure that that sequence wont trip up cscvs still - but its good to know that bzr can represent what svn does === carlos_ [n=carlos@62.87.127.38] has joined #launchpad [09:25] morning === lepingbeta_ [n=lepingbe@210.16.136.138] has joined #launchpad [09:26] lifeless: sure. I'll make sure that the file -> symlink replace (and reverse) is tested [09:36] Launchpad will be going down in 15 minutes for its regular code update. Estimated downtime is 10 minutes. === lifeless nags jamesh about reviews [09:40] lifeless: I'm doing brad's at the moment. Thanks for the nag [09:42] stub: ping [09:45] SteveA: pong [09:45] jamesh: thanks. === JanC [n=janc@lugwv/member/JanC] has joined #launchpad === malcc [n=malcolm@host86-135-139-100.range86-135.btcentralplus.com] has joined #launchpad === glatzor [n=sebi@ppp-82-135-65-46.dynamic.mnet-online.de] has joined #launchpad [09:50] lifeless: I included some user agent stats in the analysis of the bazaar.launchpad.net logs. It looks like we only had ~ 10 people try to access it with bzr-0.7 over the 50 days [09:51] good :) [09:52] the logs should give a good indication of how people adopt new versions of bzr === mpt__ [n=mpt@203-173-178-53.bliink.ihug.co.nz] has joined #launchpad [09:59] hi lifeless. Is it possible to remove a branch from bazaar.launchpad.net? I accidentally pushed the wrong branch to lp and after canceling the transaction process my bazaar repo on lp broke. === Kamping_Kaiser [n=kgoetz@easyubuntu/docteam/KampingKaiser/x-3453498] has joined #launchpad [10:03] glatzor: no. you can repair the content using lftp and bzrlib though [10:03] jamesh: on pending-reviews, carols librarian sampledata branch shows as needs review, but AFAICT its always been in w-i-p.. any ideas ? === BjornT [n=bjorn@195.58.90.162] has joined #launchpad [10:07] stub: hmm, I just remember that I had to remember you the need to execute the migration script for my branch.... [10:07] lifeless: could you please elaborate on this? [10:08] carlos: I already had. Duplicates crept in during the migration though - however, I think I can work around it. [10:09] stub: yeah, but I guess someone was added after the initial migration [10:09] glatzor: what do you mean [10:09] carlos: I ran the script just before, and dupes crept in during the run. [10:09] lifeless: I don't even know how to fix a local repo :) === salgado [n=salgado@195.58.90.162] has joined #launchpad [10:10] you can remove the restriction, start launchpad, run the migration script and add the restriction again [10:10] glatzor: well, give some details about what is wrong [10:10] carlos: Not really, but I can work around it similarly. [10:10] ok [10:11] Not that it matters, we have had to revert to last weeks release anyway due to other problems. [10:11] lifeless: https://launchpad.net/people/glatzor/+branch/gnome-app-install/sebi [10:11] I get the same error message if I try to push === mholthaus [n=mholthau@246.249.77.83.cust.bluewin.ch] has joined #launchpad === stub [n=stub@ppp-58.8.2.72.revip2.asianet.co.th] has left #launchpad [] === stub [n=stub@ppp-58.8.2.72.revip2.asianet.co.th] has joined #launchpad === bradb [n=bradb@195.58.90.162] has joined #launchpad [10:19] lifeless: do you need more to know? [10:20] lftp to the branch url [10:20] remove the directory .bzr/branch [10:20] lifeless: I think the problem is the first item in Andrew's queue [10:20] and push again [10:21] removed it [10:21] can you run the script ? [10:27] lifeless: one little question: how can I connect using lftp? [10:27] ftp URL [10:27] erm [10:27] lftp URL === frodon_ido [n=patrick@ip-213-49-171-219.dsl.scarlet.be] has joined #launchpad === fabbione [i=fabbione@gordian.fabbione.net] has joined #launchpad === Starting logfile irclogs/launchpad.log === ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog] has joined #launchpad === Topic for #launchpad: https://launchpad.net/ | developer meeting: Thu 29 Jun, 1200UTC (wiki:MeetingAgenda) | launchpad-users@lists.canonical.com (wiki:MailingLists) | Channel logs: http://tinyurl.com/72w39 === Topic (#launchpad): set by SteveA at Thu Jun 22 14:03:31 2006 === doko [n=doko@dslb-088-073-095-235.pools.arcor-ip.net] has joined #launchpad [10:44] stub: around? [10:44] bradb: yes [10:46] stub: How hard would it be to get a query of all Ticket.title vs. the first line (i.e. up to ".") of Ticket.description? === mholthaus_ [n=mholthau@dz6330fenner-e0.fx-hfc.datazug.ch] has joined #launchpad [10:47] first line != up to ".". But not hard. [10:47] You want up to \n or up to . ? [10:48] up to ".", if possible [10:48] I should have said first sentence. [10:49] ok. [10:49] Gimme a tick [10:49] . turns up in abbreviations ;) [10:49] stub: no prob, thanks [10:59] bradb: https://chinstrap.ubuntu.com/~dsilvers/paste/fileVl8aBh.html [10:59] bradb: That ok for your needs or do you need it csv or something? [11:00] stub: that's great, thanks! [11:14] jamesh: ping [11:14] SteveA: pong [11:24] bradb: btw, you have a branch that has been sitting as merge-conditional for 48 days (bradb/launchpad/malone-smallfixes). Is there anything holding up merging it? [11:29] jamesh: Some potentially controversial changes to filebug pages. I'll try to merge it as soon as I get coding time again. [11:29] okay. Just checking to see if it had been forgotten === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad === rpedro [n=rpedro@87.196.0.221] has joined #launchpad === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad [12:06] anybody up for some quick code review? [12:19] lifeless: ping [12:19] lifeless: please run reconcile on vostok, kthxbye [12:23] ddaa: its in my todo, thanks. [12:25] I'm going to increase the timeout value for staging. It will be restored tomorrow [12:25] I need it to debug a problem there === carlos -> lunch [12:34] see you later! [12:35] stub: are you around ? [12:35] lifeless: yes [12:36] I just maied you about rolling out dyson [12:36] I thought I would prod you incase your mai was not open ;) === shenki [n=shenki@ppp147-73.lns3.adl2.internode.on.net] has joined #launchpad === fantasai [i=fantasai@copper.takiweb.com] has joined #launchpad === mongolito404 [n=pbu@faroux.info.fundp.ac.be] has joined #launchpad [12:49] ddaa: around ? [12:49] yup [12:49] reading BranchRevision stuff right now [12:50] lifeless: that's what you wanted to talk to me about, right? [12:50] the +source page requires that cvs/svn details are put in. === mongolito404 [n=pbu@faroux.info.fundp.ac.be] has left #launchpad [] [12:50] this seems buggy to me, as some products release wihtout any cvs/svn repository. [12:50] the +source page is broken on so many levels it's not funny [12:50] so I'd like us to put back in place the 'no vcs' option that was there before. [12:51] I thought it was still there [12:51] nope. [12:51] ... [12:52] also, do you know who has privilege to change the ftp details in +source (without changing the cvs/svn details) [12:53] no clue, I'd bet nobody [12:53] this page is just plain broken [12:53] nothing it does makes sense [12:54] I think that is overly harsh. [12:54] do you think the release-tarball-pattern details belong on the same page as SVN details ? [12:55] IMO SVN details and the like do not belong in product series to start with [12:55] but release-tarball stuff does, since it's about the release series [12:55] I'm avoiding that discussion right now. It is a diversion from the discussion I want to have. [12:56] It's the only honest reply I have to answer your question. [12:56] Since SVN/CVS stuff should not be in product series, and tarball details is definitely a product series thing, they should not be on the same page. [12:56] However, as long as they are both in product series, it might make sense to keep them on the same page for convenience [12:58] well the problem is [12:58] that once the CVS/SVN is certified as 'good', they cannot edit the tarball release details anymore [12:59] we can either make the check for permission more fine grained - check fields on that form, or split it out to a separate form. [01:00] I'll draft a spec, get you and mpt and keybuk to eyeball it. [01:00] I'd rather have it in a separate form, as it's heading in the direction of separating vcs-imports from product series [01:00] its not about that, really. [01:00] but as we agree on different form, thats fine. [01:01] I understand it, but it's still heading in the right direction, regardless of the motivation [01:01] food time, tchau [01:01] what about source package association? [01:01] I dont know what that means [01:01] https://launchpad.net/products/launchpad-bazaar/+bug/46240 [01:01] Malone bug 46240 in launchpad-bazaar "posting $series/+source yields a confusing warning" [High,Confirmed] [01:02] do you mean 'http://launchpad.dev/products/test/trunk/+ubuntupkg' [01:02] about everybody that tries to set up a vcs import gets this warning, and believe that the vcs details were not recorded [01:03] I have no opinion on whether the source package form should be separate from the release tarball form, but it should definitely be separate from the vcs import form. [01:06] I think there is already a separate form is my point [01:06] you will need to look at the view class and template, but I think that +ubuntupkg and the source package field on the +source form are functionally equivalent. === yvesC [n=yves@zenobi.ycombe.net] has joined #launchpad [01:07] lifeless: I would like if you could get somebody to look at it [01:08] Hi [01:08] which package is supposed contains tuxpaint locale for french ? [01:09] I can and will look at things like complete-branch-revision, but anything else that's a distraction from fixing vcs imports is out of scope for me until I can tell sabdfl I'm happy with how svn imports are doing. === mpool_ [n=mbp@ozlabs.org] has joined #launchpad === thierryn [n=thierry@modemcable122.61-131-66.mc.videotron.ca] has joined #launchpad === cprov [n=cprov@201-68-5-132.dsl.telesp.net.br] has joined #launchpad === shenki is now known as a_cricket === a_cricket is now known as shenki === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad === lincao [n=lincoln@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 === cprov [n=cprov@201-68-5-132.dsl.telesp.net.br] has joined #launchpad === doko_ [n=doko@dslb-088-073-095-235.pools.arcor-ip.net] has joined #launchpad === dda1 [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad === flacoste [n=francis@195.58.90.162] has joined #launchpad === salgado [n=salgado@195.58.90.162] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad === niemeyer [n=niemeyer@201.11.38.154] has joined #launchpad === lepingbeta [n=lepingbe@210.16.136.138] has joined #launchpad === mpt [n=mpt@203-173-178-53.bliink.ihug.co.nz] has joined #launchpad === lepingbeta [n=lepingbe@210.16.136.138] has joined #launchpad [03:35] dda1: so what do you think of complete-branch-revision === carlos [n=carlos@62.87.126.72] has joined #launchpad === sabdf1 [n=mark@195.58.90.162] has joined #launchpad [04:30] lifeless: generally, I'm okay with it. I had some discussion monday with Kinnison about the caveats and how client code (soyuz) need to deal with revisions going away from branches. [04:31] s/monday/sunday/ [04:32] right. soyuz wont link to BranchRevision, I have a todo to update the record branch revision sec to reflect this change. [04:32] BranchRevision will become just a cache [04:33] I think the use case here is to record a revision and be able to tell which branch this revision can be retrieved from. [04:34] recording the revision can be done either by a foreign key to Revision.id or by a textual revision_id [04:34] not really [04:35] there are several different use cases. [04:35] for instance, one record branch revision use case is to allow connecting the dots between source packages and products. [04:35] the big caveat is that we cannot guarantee that a revision that was in the ancestry of a branch at a time will always be. [04:35] I know [04:36] sabdf1: reply to review sent. r=me [04:36] lifeless: I thought you knew, but Kinnison wanted to be sure that you were reminded :) [04:40] "connecting the dots between source packages and products", that does not appear to require complete-branch-revision in realistic non-ambiguous cases. Having the full graph would be useful for best-effort in finding the "closest" (FSVO) relative of a branch, but that may be more that we what we would need. [04:40] I mean, finding the closest relative for ambiguous use cases. [04:40] s/use case/scenario/ [04:40] I gave you a single use case. [04:41] forgive my confused terminology, my workplace is not as quiet as it is usually [04:41] particularly, I gave you one that is also relevant for the record-source-package-release-branch=-reversion spec [04:41] ? [04:41] but there are a number of operations we have planned to do in the past like: [04:41] ETOOMANYDASHES [04:42] * where has this revision been merged? [04:42] * which of these [set] of branches is the one with the most recent code? [04:42] * can I have a pony? [04:43] that all need different queries through the graph : so having the graph cheaply available for a branch or set of branches, and the reverse graph too, is important. [04:43] lifeless: no [04:43] lifeless: okay, I already have one for tomlord on my shopping list, should I add you as well? [04:43] elmo: ? [04:43] lifeless: you can't have a pony [04:43] elmo: why would you say no to me! [04:43] lifeless: to make you cry? [04:43] I'm nice. And I'm no longer SOOO fat that I would break its back === lifeless tickles elmo [04:44] what do you mean by "reverse graph"? [04:44] lifeless: we gotta play some mao in Vilnius with a pony rule [04:45] ddaa: the relationship of revisions to branches, rather than branches to revisions. [04:46] lifeless: generally, i think that "get all revisions in the ancestry of a branch" and "get all branches that have a revision in their ancestry" is useful for a variety of nice bling. [04:46] I voiced my specific performance concerns on the mailing list. [04:47] right, which I think is already addressed. [04:47] AIUI it the constraint will be fine. [04:47] and I've already discussed performance with stub [04:47] the performance of the specific query I gave is important [04:48] well, create a table with 1 billion rows and test it :) [04:48] as pages that give detailed branch listing are already soft-timing-out sometimes. === fantasai [i=fantasai@copper.takiweb.com] has left #launchpad [] [04:48] what is the detailed branch listing page - do you have a sample url ? [04:48] https://launchpad.net/products/bzr/+branchlisting [04:49] the issue is generating the "1704 revisions, 0 in the past month." bits [04:49] you do that through two queries right ? [04:49] ATM two queries per branch [04:50] the query in the post would allow doing one query for the whole page [04:50] right [04:50] it still needs to be reasonably cheap [04:51] it might be possible that indexes can prevent non-mainline revisions from slowing it down [04:51] I just do not know [04:51] SteveA: thanks, will land when i get back from dublin, it's fine for this to roll out next week [04:51] The alternative is putting caches in Branch, that are updated by the branch-scanner or another script, but that's increased complexity in code not directly related to display that I would rather avoid [04:52] ddaa: the ratio is typically 3:1 [04:52] ddaa: i.e. under an order of magnitude - if we are going to have a problem, we'll have it anyway. [04:52] anyhomw [04:53] salgado: please, could you ping kiko? [04:53] I'm happy with that spec, esp. since you said that the branch scanner optimisation patch is already in the pipej [04:53] salgado: I need to talk with him about a change he did [04:54] hmm salgado: or at least ask him to read his email tonight, I think he did a change that would kill our performance on production === carlos prepares an email [04:56] there would still be a hole with ghost filling, but it's not a big issue, and there would be ways to deal with it (e.g. compare size of ghost-unaware ancestry with what the db says once a day) [04:57] steve and I have been talking about he branch scanner somewhat too [04:57] mh [04:57] just thought of an interesting corner case [04:57] it should be possible to generate a very fast scanner - I'm doing a spec up for consideration now [04:58] the database can know more of the ancestry than the branch [04:58] sure [05:00] so it might be useful to have branchrevision actually tell that a branch actually has revisions in its ancestry, although they are ghosts. In particular when there will be branch horizon (which expect to happen eventually). [05:00] Lets not preengineer that [05:00] sure [05:00] we can add that later at minimal cost. [05:01] We just need to make sure ATM that the branch scanner can deal with revisions turning into ghosts [05:01] so we can guarantee branchrevision tells us that a revision _can_ be checked out from a branch [05:02] and not break referential integrity when revisions start turning into ghosts [05:04] lifeless: ready for that talk whenever === mpt [n=mpt@203-173-178-53.bliink.ihug.co.nz] has joined #launchpad === ddaa goes back to beating cscvs into shape\ [05:17] carlos, pinging him now [05:17] salgado: I sent the email already [05:17] so is enough if he's able to read it today [05:18] salgado: but thanks === kiko [n=kiko@195.58.90.162] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [05:39] hey carlos [05:39] go ahead, that was crazy. === rraphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [05:43] kiko: hi [05:43] yeah, I saw your answer [05:43] cool [05:43] kiko: do you think we have any way to do 'make check' on staging to detect this kind of performance problems? [05:44] well [05:44] we could measure times it took to render certain pages [05:44] and then look at that over time. [05:44] I assume there's something that does that already though... [05:45] yeah, but that will not prevent this kind of changes to land on production... [05:45] we lack the QA part on staging [05:45] because I think that change was scheduled to land today [05:46] carlos, was it going to land today? [05:46] and didn't it? [05:47] kiko: I'm not completely sure, but it landed before friday night and stub has been rolling out all changes until friday night [05:47] kiko: the rollout was cancelled [05:47] ah. really? why? [05:47] stub had some problems [05:48] I think with the virtual hosting thing [05:48] from Stub's words [05:48] yeah, missing config item for production [05:48] Due to bugs in the recent publisher updates that cause Launchpad to just [05:48] return 500 errors [05:48] I see. [05:49] well, land the reversal and then notify stub of it. [05:49] ok [05:49] great that you caught it on staging [05:49] combined with an early version of the vhosting code [05:49] that doesn't cope well with that [05:53] kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/fileL85TI6.html [05:53] kiko: r=kiko ? [05:55] carlos, yeah. though I would say in the comment that a) ret could have many results and b) the batching system will slice the results afterwards [05:55] anyway, r=kiko [05:55] kiko: hmm I tried to note that already ;-) [05:55] but I guess if you request it I didn't clarify it enough === Ro1 [n=admin@ool-182deb25.dyn.optonline.net] has joined #launchpad [06:01] hi all === Ro1 [n=admin@ool-182deb25.dyn.optonline.net] has left #launchpad [] [06:01] carlos, it's fine, don't worry. [06:01] ok [06:14] kiko - how does launhcpad make sure that security bugs are not visible to other people than the security contact? [06:14] kiko: or does it let it be visible, but hide access to the contents ? [06:14] lifeless, private bugs are only visible to subscribers. [06:14] that's the principle [06:14] security contacts are subscribed to new security bugs [06:15] that's how they can see them [06:15] ok. *how* [06:15] sorry? [06:15] what words do I use to talk about this bit of zope machinery? [06:15] oh. [06:15] security.py mostly [06:16] it defines who can see a bug [06:16] combined with the zcml. [06:16] and this magically applies to stuff returned from sqlobject? [06:16] or only at the gap between content and view class ? [06:16] the latter. [06:17] so e.g. the view class needs to strip out returned elements from a list that are not meant to be visible, or it will get prmission errors ? [06:18] BugTaskSet.search() only returns visible items. [06:18] ok. [06:18] so the answer is yes [06:18] if you query and get back an item that you are not supposed to display and try to display it [06:18] and if it returned incorrect things by mistake the worst possible condition is 'PermissionDenied' [06:18] it will die [06:18] cool. [06:18] thanks [06:18] right. [06:18] exactly. [06:19] I'm working up a related spec [06:19] and wanted to know enough to get myself into trouble. [06:19] sure [06:20] so AuthorizationBase is subclassed, and the usedfor field gives the permission instance a context to find out data from, and a user requesting access [06:20] yep [06:21] thanks, you have been a great help. [06:21] probably will still be a bit sketchy as I haven't checked the zcml side of it yet [06:21] with zcml [06:21] you define what attributes are visible/editable with what permissions. [06:21] that's generally it [06:21] see bug.zcml for details [06:23] the bit ? [06:34] lifeless, the attributes and set_attributes bits on the bug context object. [06:36] thanks === Kamion [n=cjwatson@83-216-156-196.colinw664.adsl.metronet.co.uk] has joined #launchpad [06:39] Hello. Is there any way to delete the registration of a bzr branch in Launchpad? [06:40] not without admin help I believe. [06:41] I was hoping I might be able to work around the fact that I can't convert from an external branch to a hosted branch [06:41] because I'd like to keep using the 'ubuntu' name for branches representing current Ubuntu packages, but that name's already taken by external branches for many of my packages [06:42] https://launchpad.net/products/launchpad-bazaar/+bug/5575 says "the whole system is designed so that branches are easy to rename" but I cannot find how to rename a branch [06:43] Malone bug 5575 in launchpad-bazaar "Do we really have to name our branches in Launchpad?" [High,Confirmed] [06:43] Kamion: in theory you should be able to do it from the +edit or +admin form [06:43] not sure if the perms are set right, though [06:44] +edit doesn't have it [06:44] bug 5575 is about something else, which I started addressing in a ui branch (that's on PendingReviews) but that I never got the time to finesh. [06:44] Malone bug 5575 in launchpad-bazaar "Do we really have to name our branches in Launchpad?" [High,Confirmed] http://launchpad.net/bugs/5575 [06:44] +admin is forbidden [06:50] okay, that's a bug [06:50] ddaa: do you have any idea what my right answer would be here? I'm trying to convert to the distro procedure in https://wiki.ubuntu.com/BzrMaintainerHowto [06:50] Kamion: +admin is usually reserved for launchpad admins and 'experts' (admins with less rights) [06:50] ah, ok [06:50] branch/+admin should be allowed to the branch owner [06:50] want a bug? [06:50] admins and experts get the right to fuck with other people branches [06:50] ddaa: who else has access to +edit ? === ajmitch [n=ajmitch@203.89.166.123] has joined #launchpad [06:51] carlos: +edit and +admin for branch should have the same access [06:51] I think ATM +edit is owner-or-admin [06:51] but it makes sense to keep them separated, since +admin allows editing things that changes the URL the branch [06:51] what's the point of having two pages for the same people? [06:52] oh, I see [06:52] and the pages where the branch appear on launchpad, etc [06:52] it allows moderately antisocial changes [06:52] I'm not completely sure whether is the best option. I think most of launchpad uses +admin for non owner tasks (or at least Rosetta does it) [06:53] bug 51130 [06:53] Malone bug 51130 in launchpad-bazaar "cannot use +admin on a branch I own" [Untriaged,Unconfirmed] http://launchpad.net/bugs/51130 [06:54] ddaa: +admin should be admins only. [06:54] ddaa: +edit should ahve the functionality the branch owner needs. [06:55] I'm keen on keeping the features to change the branch owner/product/name separate from the form normally used to change the branch sumary, external URL, etc. [06:55] ddaa: its a good idea to not give people hints to URLs that they will rarely have access to, and using +admin on branch does that. [06:55] thats fine, I support that. [06:55] lifeless: is there another standard name for "form allowed to the owner to change dangerous things?" [06:56] I'm happy to call it +crocodile if nobody has a problem with that [06:56] ddaa: the reset of lp does not differentiate this AFAIK === JanC [n=janc@lugwv/member/JanC] has joined #launchpad === carlos_ [n=carlos@62.87.126.165] has joined #launchpad [06:57] salgado: your karmacontext sql needs some comments to pass DBA review - altrting you early [06:58] salgado: see TranslationUploads for an example === carlos_ -> out for 30 minutes [06:59] see you later [07:02] actually, I think branch/+spork would be a better name === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [07:03] Kamion: in the meantime, you can ask an admin to make the change for you [07:04] changing the branch name will break nothing [07:05]