[01:59] <mirek> may i ask for help? i am new to launchpad and i would like to add new serie of drupal cms
[01:59] <mirek> (i added new release to old serie :-( )
[02:02] <mirek> no roseta admin in here?
[03:00] <AlexMBas> hello all
[03:00] <OgMaciel> can someone lend me a hand trying to solve a problem with Rosetta?
[03:02] <AlexMBas> we're having problems with % substition on strings
[03:02] <OgMaciel> https://launchpad.net/distros/ubuntu/dapper/+source/scribus/+pots/scribus/pt_BR/+translate?batch=10&show=untranslated on string 99 for instance
[03:03] <AlexMBas> any rosetta developer around here ?
[03:04] <jamesh> my guess is that those strings have been incorrectly marked as C format strings in the PO template
[03:04] <OgMaciel> jamesh: true
[03:04] <OgMaciel> jamesh: is this something we'd have to fix it upstream?
[03:04] <AlexMBas> yeah
[03:05] <jamesh> Rosetta performs special checks to C format strings to make sure that the translations are compatible format strings
[03:05] <jamesh> (which isn't really desired if the string isn't a format string)
[03:05] <AlexMBas> jamesh, % followed by a space character should not be identified as a C format string, shound it ?
[03:05] <jamesh> the best fix would be to the scribus source code, telling xgettext that the string isn't a format string
[03:06] <OgMaciel> AlexMBas: lemme know the outcome?  I'll be doing something else
[03:06] <AlexMBas> ok
[03:06] <AlexMBas> thanks OgMaciel 
[03:06] <OgMaciel> AlexMBas: my pleasure buddy
[03:07] <AlexMBas> jamesh, who should do it on scribus source code ?
[03:07] <AlexMBas> we (translators) ? or should we open a bug report for the upstream package ?
[03:08] <jamesh> 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] <AlexMBas> cool
[03:08] <AlexMBas> so I'll try to contact them
[03:08] <jamesh> 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] <AlexMBas> thank yoiu very much jamesh 
[03:09] <AlexMBas> I'll try to contact the upstream development team
[03:56] <jdong> is it OK to attach deb packages to bug reports?
[03:56] <jdong> bandwidth/storage wise
[03:57] <jdong> I don't want to be abusing launchpad's generous services
[03:57] <spiv> jdong: should be fine.
[03:57] <jdong> thanks!
[03:57] <spiv> Assuming it's not openoffice-sized ;)
[03:57] <jdong> Ubuntu Backports testers are gonna love you, spiv
[03:58] <jdong> no, I'm not gonna upload any beasts like that!
[03:58] <jdong> most of them are small packages, like rhythmbox or dia
[03:58] <jdong> :)
[03:58] <jdong> this will greatly improve our testing base
[04:03] <jdong> btw, I forgot to say this earlier, but thanks for making bzr hosting and knits work on launchpad :)
[04:04] <jdong> the automatix team loves you guys for that :)
[04:04] <spiv> Cool :)
[04:06] <jdong> these canonical projects are just nothing short of amazing
[04:06] <jdong> in about a year you guys have made a service that rivals Sourceforge
[04:06] <spiv> Hmm, they don't seem to be using team branches, I wonder if that's intentional.
[04:06] <jdong> https://launchpad.net/products/automatix/+branches
[04:06] <jdong> we've got 4 team-authored branches
[04:07] <jdong> they're still learning how to work the bzr system
[04:07] <spiv> Oh, I was looking at the "Official Automatix.KDE Head" one, which is under ~mstlyevil
[04:07] <spiv> But I see there are some in ~automatix after all.
[04:08] <spiv> Excellent :)
[04:08] <jamesh> spiv: that is a "authored by team, registered by user" branch
[04:08] <jamesh> so ends up in the user's namespace
[04:08] <spiv> jamesh: Well, it's the location it was pushed to that I was interested in.
[04:11] <spiv> jamesh: Mostly I was wondering if the ~<teamname> directories were discoverable enough that people would use them or not.  It seems they are.
[04:11] <jdong> spiv: will launchpad eventually get some documentation on using hosted branches?
[04:12] <jdong> spiv: I only figured it out because I was browsing around with a SFTP client, and came across the team folders
[04:12] <jdong> then I asked ddaa in #bzr about it
[04:13] <jamesh> jdong: ddaa wrote a blog article about it (and will write a followup on team branches)
[04:13] <jdong> jamesh: I know that; but I don't think the average person exploring launchpad.net will figure that out
[04:14] <jdong> something on either the bazaar info page or the register branches, or even the +branches/ page would be cool
[04:14] <jamesh> jdong: yep.  Perhaps we should get some docs up on help.launchpad.net about it.
[04:17] <spiv> jdong: https://launchpad.net/bazaar has a short overview
[04:17] <spiv> d'oh
[08:06] <stub> 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] <jamesh> stub: I got an air baltic flight for london -> vilnius and back (the same flight Steve is taking)
[08:18] <stub> Launchpad will be going down in 15 minutes time. Estimated downtime is 10 mins.
[08:18] <stub> This is for the regular code update.
[08:36] <stub> I've had to abort the update. Another attempt will be made later today.
[08:37] <jamesh> any particular problem?
[08:38] <fabbione> stub: what did explode?
[08:40] <stub> I need to rerun a data migration script as some bad data has crept back in.
[08:44] <stub> Znarl, elmo: Gangotri app server will be down for the next few hours so ignore the alerts
[09:07] <SteveA> 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)
[09:18] <jamesh> 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] <lifeless> ahha. if you do a delete and add then of the same name, changing type ?
[09:19] <jamesh> that's what you need to do, yes.
[09:20] <jamesh> so we shouldn't see evil branches that trip up bzr in that respect
[09:24] <lifeless> 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
[09:25] <carlos_> morning
[09:26] <jamesh> lifeless: sure.  I'll make sure that the file -> symlink replace (and reverse) is tested
[09:36] <stub> Launchpad will be going down in 15 minutes for its regular code update. Estimated downtime is 10 minutes.
[09:40] <jamesh> lifeless: I'm doing brad's at the moment.  Thanks for the nag
[09:42] <SteveA> stub: ping
[09:45] <stub> SteveA: pong
[09:45] <lifeless> jamesh: thanks.
[09:50] <jamesh> 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] <lifeless> good :)
[09:52] <jamesh> the logs should give a good indication of how people adopt new versions of bzr
[09:59] <glatzor> 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.
[10:03] <lifeless> glatzor: no. you can repair the content using lftp and bzrlib though
[10:03] <lifeless> jamesh: on pending-reviews, carols librarian sampledata branch shows as needs review, but AFAICT its always been in w-i-p.. any ideas ?
[10:07] <carlos> stub: hmm, I just remember that I had to remember you the need to execute the migration script for my branch....
[10:07] <glatzor> lifeless: could you please elaborate on this?
[10:08] <stub> carlos: I already had. Duplicates crept in during the migration though - however, I think I can work around it.
[10:09] <carlos> stub: yeah, but I guess someone was added after the initial migration
[10:09] <lifeless> glatzor: what do you mean
[10:09] <stub> carlos: I ran the script just before, and dupes crept in during the run.
[10:09] <glatzor> lifeless: I don't even know how to fix a local repo :)
[10:10] <carlos> you can remove the restriction, start launchpad, run the migration script and add the restriction again
[10:10] <lifeless> glatzor: well, give some details about what is wrong
[10:10] <stub> carlos: Not really, but I can work around it similarly.
[10:10] <carlos> ok
[10:11] <stub> Not that it matters, we have had to revert to last weeks release anyway due to other problems.
[10:11] <glatzor> lifeless: https://launchpad.net/people/glatzor/+branch/gnome-app-install/sebi
[10:11] <glatzor> I get the same error message if I try to push
[10:19] <glatzor> lifeless: do you need more to know?
[10:20] <lifeless> lftp to the branch url
[10:20] <lifeless> remove the directory .bzr/branch
[10:20] <jamesh> lifeless: I think the problem is the first item in Andrew's queue
[10:20] <lifeless> and push again
[10:21] <lifeless> removed it
[10:21] <lifeless> can you run the script ?
[10:27] <glatzor> lifeless: one little question: how can I connect using lftp?
[10:27] <lifeless> ftp URL
[10:27] <lifeless> erm
[10:27] <lifeless> lftp URL
[10:44] <bradb> stub: around?
[10:44] <stub> bradb: yes
[10:46] <bradb> 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?
[10:47] <stub> first line != up to ".". But not hard.
[10:47] <stub> You want up to \n or up to . ?
[10:48] <bradb> up to ".", if possible
[10:48] <bradb> I should have said first sentence.
[10:49] <stub> ok.
[10:49] <stub> Gimme a tick
[10:49] <lifeless> . turns up in abbreviations ;)
[10:49] <bradb> stub: no prob, thanks
[10:59] <stub> bradb: https://chinstrap.ubuntu.com/~dsilvers/paste/fileVl8aBh.html
[10:59] <stub> bradb: That ok for your needs or do you need it csv or something?
[11:00] <bradb> stub: that's great, thanks!
[11:14] <SteveA> jamesh: ping
[11:14] <jamesh> SteveA: pong
[11:24] <jamesh> 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] <bradb> jamesh: Some potentially controversial changes to filebug pages. I'll try to merge it as soon as I get coding time again.
[11:29] <jamesh> okay.  Just checking to see if it had been forgotten
[12:06] <salgado> anybody up for some quick code review?
[12:19] <ddaa> lifeless: ping
[12:19] <ddaa> lifeless: please run reconcile on vostok, kthxbye
[12:23] <lifeless> ddaa: its in my todo, thanks.
[12:25] <carlos> I'm going to increase the timeout value for staging. It will be restored tomorrow
[12:25] <carlos> I need it to debug a problem there
[12:34] <carlos> see you later!
[12:35] <lifeless> stub: are you around ?
[12:35] <stub> lifeless: yes
[12:36] <lifeless> I just maied you about rolling out dyson
[12:36] <lifeless> I thought I would prod you incase your mai was not open ;)
[12:49] <lifeless> ddaa: around ?
[12:49] <ddaa> yup
[12:49] <ddaa> reading BranchRevision stuff right now
[12:50] <ddaa> lifeless: that's what you wanted to talk to me about, right?
[12:50] <lifeless> the +source page requires that cvs/svn details are put in.
[12:50] <lifeless> this seems buggy to me, as some products release wihtout any cvs/svn repository.
[12:50] <ddaa> the +source page is broken on so many levels it's not funny
[12:50] <lifeless> so I'd like us to put back in place the 'no vcs' option that was there before.
[12:51] <ddaa> I thought it was still there
[12:51] <lifeless> nope.
[12:51] <ddaa> ...
[12:52] <lifeless> also, do you know who has privilege to change the ftp details in +source (without changing the cvs/svn details)
[12:53] <ddaa> no clue, I'd bet nobody
[12:53] <ddaa> this page is just plain broken
[12:53] <ddaa> nothing it does makes sense
[12:54] <lifeless> I think that is overly harsh.
[12:54] <lifeless> do you think the release-tarball-pattern details belong on the same page as SVN details ?
[12:55] <ddaa> IMO SVN details and the like do not belong in product series to start with
[12:55] <ddaa> but release-tarball stuff does, since it's about the release series
[12:55] <lifeless> I'm avoiding that discussion right now. It is a diversion from the discussion I want to have.
[12:56] <ddaa> It's the only honest reply I have to answer your question.
[12:56] <ddaa> 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] <ddaa> 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] <lifeless> well the problem is
[12:58] <lifeless> that once the CVS/SVN is certified as 'good', they cannot edit the tarball release details anymore
[12:59] <lifeless> 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] <lifeless> I'll draft a spec, get you and mpt and keybuk to eyeball it.
[01:00] <ddaa> 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] <lifeless> its not about that, really.
[01:00] <lifeless> but as we agree on different form, thats fine.
[01:01] <ddaa> I understand it, but it's still heading in the right direction, regardless of the motivation
[01:01] <lifeless> food time, tchau
[01:01] <ddaa> what about source package association?
[01:01] <lifeless> I dont know what that means
[01:01] <ddaa> https://launchpad.net/products/launchpad-bazaar/+bug/46240
[01:01] <Ubugtu> Malone bug 46240 in launchpad-bazaar "posting $series/+source yields a confusing warning" [High,Confirmed]  
[01:02] <lifeless> do you mean 'http://launchpad.dev/products/test/trunk/+ubuntupkg'
[01:02] <ddaa> about everybody that tries to set up a vcs import gets this warning, and  believe that the vcs details were not recorded
[01:03] <ddaa> 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] <lifeless> I think there is already a separate form is my point
[01:06] <lifeless> 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.
[01:07] <ddaa> lifeless: I would like if you could get somebody to look at it
[01:08] <yvesC> Hi
[01:08] <yvesC> which package is supposed contains tuxpaint locale for french ?
[01:09] <ddaa> 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.
[03:35] <lifeless> dda1: so what do you think of complete-branch-revision
[04:30] <dda1> 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] <dda1> s/monday/sunday/
[04:32] <lifeless> right. soyuz wont link to BranchRevision, I have a todo to update the record branch revision sec to reflect this change.
[04:32] <lifeless> BranchRevision will become just a cache 
[04:33] <dda1> 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] <ddaa> recording the revision can be done either by a foreign key to Revision.id or by a textual revision_id
[04:34] <lifeless> not really
[04:35] <lifeless> there are several different use cases.
[04:35] <lifeless> for instance, one record branch revision use case is to allow connecting the dots between source packages and products.
[04:35] <ddaa> 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] <lifeless> I know
[04:36] <SteveA> sabdf1: reply to review sent.  r=me
[04:36] <ddaa> lifeless: I thought you knew, but Kinnison wanted to be sure that you were reminded :)
[04:40] <ddaa> "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] <ddaa> I mean, finding the closest relative for ambiguous use cases.
[04:40] <ddaa> s/use case/scenario/
[04:40] <lifeless> I gave you a single use case.
[04:41] <ddaa> forgive my confused terminology, my workplace is not as quiet as it is usually
[04:41] <lifeless> particularly, I gave you one that is also relevant for the record-source-package-release-branch=-reversion spec
[04:41] <ddaa> ?
[04:41] <lifeless> but there are a number of operations we have planned to do in the past like:
[04:41] <ddaa> ETOOMANYDASHES
[04:42] <lifeless>  * where has this revision been merged?
[04:42] <lifeless>  * which of these [set]  of branches is the one with the most recent code?
[04:42] <lifeless>  * can I have a pony?
[04:43] <lifeless> 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] <elmo> lifeless: no
[04:43] <ddaa> lifeless: okay, I already have one for tomlord on my shopping list, should I add you as well?
[04:43] <lifeless> elmo: ?
[04:43] <elmo> lifeless: you can't have a pony
[04:43] <lifeless> elmo: why would you say no to me!
[04:43] <elmo> lifeless: to make you cry?
[04:43] <lifeless> I'm nice. And I'm no longer SOOO fat that I would break its back
[04:44] <ddaa> what do you mean by "reverse graph"?
[04:44] <ddaa> lifeless: we gotta play some mao in Vilnius with a pony rule
[04:45] <lifeless> ddaa: the relationship of revisions to branches, rather than branches to revisions.
[04:46] <ddaa> 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] <ddaa> I voiced my specific performance concerns on the mailing list.
[04:47] <lifeless> right, which I think is already addressed.
[04:47] <lifeless> AIUI it the constraint will be fine.
[04:47] <lifeless> and I've already discussed performance with stub
[04:47] <ddaa> the performance of the specific query I gave is important
[04:48] <lifeless> well, create a table with 1 billion rows and test it :)
[04:48] <ddaa> as pages that give detailed branch listing are already soft-timing-out sometimes.
[04:48] <lifeless> what is the detailed branch listing page - do you have a sample url ?
[04:48] <ddaa> https://launchpad.net/products/bzr/+branchlisting
[04:49] <ddaa> the issue is generating the "1704 revisions, 0 in the past month." bits
[04:49] <lifeless> you do that through two queries right ?
[04:49] <ddaa> ATM two queries per branch
[04:50] <ddaa> the query in the post would allow doing one query for the whole page
[04:50] <lifeless> right
[04:50] <ddaa> it still needs to be reasonably cheap
[04:51] <ddaa> it might be possible that indexes can prevent non-mainline revisions from slowing it down
[04:51] <ddaa> I just do not know
[04:51] <sabdf1> SteveA: thanks, will land when i get back from dublin, it's fine for this to roll out next week
[04:51] <ddaa> 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] <lifeless> ddaa: the ratio is typically 3:1
[04:52] <lifeless> ddaa: i.e. under an order of magnitude - if we are going to have a problem, we'll have it anyway.
[04:52] <ddaa> anyhomw
[04:53] <carlos> salgado: please, could you ping kiko?
[04:53] <ddaa> I'm happy with that spec, esp. since you said that the branch scanner optimisation patch is already in the pipej
[04:53] <carlos> salgado: I need to talk with him about a change he did
[04:54] <carlos> 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
[04:56] <ddaa> 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] <lifeless> steve and I have been talking about he branch scanner somewhat too
[04:57] <ddaa> mh
[04:57] <ddaa> just thought of an interesting corner case
[04:57] <lifeless> it should be possible to generate a very fast scanner - I'm doing a spec up for consideration now
[04:58] <ddaa> the database can know more of the ancestry than the branch
[04:58] <lifeless> sure
[05:00] <ddaa> 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] <lifeless> Lets not preengineer that
[05:00] <ddaa> sure
[05:00] <lifeless> we can add that later at minimal cost.
[05:01] <ddaa> We just need to make sure ATM that the branch scanner can deal with revisions turning into ghosts
[05:01] <ddaa> so we can guarantee branchrevision tells us that a revision _can_ be checked out from a branch
[05:02] <ddaa> and not break referential integrity when revisions start turning into ghosts
[05:04] <SteveA> lifeless: ready for that talk whenever
[05:17] <salgado> carlos, pinging him now
[05:17] <carlos> salgado: I sent the email already
[05:17] <carlos> so is enough if he's able to read it today
[05:18] <carlos> salgado: but thanks
[05:39] <kiko> hey carlos 
[05:39] <kiko> go ahead, that was crazy.
[05:43] <carlos> kiko: hi
[05:43] <carlos> yeah, I saw your answer
[05:43] <kiko> cool
[05:43] <carlos> kiko: do you think we have any way to do 'make check' on staging to detect this kind of performance problems?
[05:44] <kiko> well
[05:44] <kiko> we could measure times it took to render certain pages
[05:44] <kiko> and then look at that over time.
[05:44] <kiko> I assume there's something that does that already though...
[05:45] <carlos> yeah, but that will not prevent this kind of changes to land on production...
[05:45] <carlos> we lack the QA part on staging
[05:45] <carlos> because I think that change was scheduled to land today
[05:46] <kiko> carlos, was it going to land today?
[05:46] <kiko> and didn't it?
[05:47] <carlos> 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] <carlos> kiko: the rollout was cancelled
[05:47] <kiko> ah. really? why?
[05:47] <carlos> stub had some problems
[05:48] <carlos> I think with the virtual hosting thing
[05:48] <carlos> from Stub's words
[05:48] <SteveA> yeah, missing config item for production
[05:48] <carlos> Due to bugs in the recent publisher updates that cause Launchpad to just
[05:48] <carlos> return 500 errors
[05:48] <kiko> I see.
[05:49] <kiko> well, land the reversal and then notify stub of it.
[05:49] <carlos> ok
[05:49] <kiko> great that you caught it on staging
[05:49] <SteveA> combined with an early version of the vhosting code
[05:49] <SteveA> that doesn't cope well with that
[05:53] <carlos> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/fileL85TI6.html
[05:53] <carlos> kiko: r=kiko ?
[05:55] <kiko> 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] <kiko> anyway, r=kiko
[05:55] <carlos> kiko: hmm I tried to note that already ;-)
[05:55] <carlos> but I guess if you request it I didn't clarify it enough
[06:01] <Ro1> hi all
[06:01] <kiko> carlos, it's fine, don't worry.
[06:01] <carlos> ok
[06:14] <lifeless> kiko - how does launhcpad make sure that security bugs are not visible to other people than the security contact?
[06:14] <lifeless> kiko: or does it let it be visible, but hide access to the contents ?
[06:14] <kiko> lifeless, private bugs are only visible to subscribers.
[06:14] <kiko> that's the principle
[06:14] <kiko> security contacts are subscribed to new security bugs
[06:15] <kiko> that's how they can see them
[06:15] <lifeless> ok. *how*
[06:15] <kiko> sorry?
[06:15] <lifeless> what words do I use to talk about this bit of zope machinery?
[06:15] <kiko> oh.
[06:15] <kiko> security.py mostly
[06:16] <kiko> it defines who can see a bug
[06:16] <kiko> combined with the zcml.
[06:16] <lifeless> and this magically applies to stuff returned from sqlobject?
[06:16] <lifeless> or only at the gap between content and view class ?
[06:16] <kiko> the latter.
[06:17] <lifeless> 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] <kiko> BugTaskSet.search() only returns visible items.
[06:18] <lifeless> ok.
[06:18] <kiko> so the answer is yes
[06:18] <kiko> if you query and get back an item that you are not supposed to display and try to display it
[06:18] <lifeless> and if it returned incorrect things by mistake the worst possible condition is 'PermissionDenied'
[06:18] <kiko> it will die
[06:18] <lifeless> cool.
[06:18] <lifeless> thanks
[06:18] <kiko> right.
[06:18] <kiko> exactly.
[06:19] <lifeless> I'm working up a related spec
[06:19] <lifeless> and wanted to know enough to get myself into trouble.
[06:19] <kiko> sure
[06:20] <lifeless> 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] <kiko> yep
[06:21] <lifeless> thanks, you have been a great help.
[06:21] <lifeless> probably will still be a bit sketchy as I haven't checked the zcml side of it yet
[06:21] <kiko> with zcml
[06:21] <kiko> you define what attributes are visible/editable with what permissions.
[06:21] <kiko> that's generally it
[06:21] <kiko> see bug.zcml for details
[06:23] <lifeless> the <!-- Bug --> bit ?
[06:34] <kiko> lifeless, the attributes and set_attributes bits on the bug context object.
[06:36] <lifeless> thanks
[06:39] <Kamion> Hello. Is there any way to delete the registration of a bzr branch in Launchpad?
[06:40] <LarstiQ> not without admin help I believe.
[06:41] <Kamion> 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] <Kamion> 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] <Kamion> 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] <Ubugtu> Malone bug 5575 in launchpad-bazaar "Do we really have to name our branches in Launchpad?" [High,Confirmed]  
[06:43] <ddaa> Kamion: in theory you should be able to do it from the +edit or +admin form
[06:43] <ddaa> not sure if the perms are set right, though
[06:44] <Kamion> +edit doesn't have it
[06:44] <ddaa> 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] <Ubugtu> 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] <Kamion> +admin is forbidden
[06:50] <ddaa> okay, that's a bug
[06:50] <Kamion> 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] <carlos> Kamion: +admin is usually reserved for launchpad admins and 'experts' (admins with less rights)
[06:50] <Kamion> ah, ok
[06:50] <ddaa> branch/+admin should be allowed to the branch owner
[06:50] <Kamion> want a bug?
[06:50] <ddaa> admins and experts get the right to fuck with other people branches
[06:50] <carlos> ddaa: who else has access to +edit ?
[06:51] <ddaa> carlos: +edit and +admin for branch should have the same access
[06:51] <ddaa> I think ATM +edit is owner-or-admin
[06:51] <ddaa> but it makes sense to keep them separated, since +admin allows editing things that changes the URL the branch
[06:51] <carlos> what's the point of having two pages for the same people?
[06:52] <carlos> oh, I see
[06:52] <ddaa> and the pages where the branch appear on launchpad, etc
[06:52] <ddaa> it allows moderately antisocial changes
[06:52] <carlos> 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] <Kamion> bug 51130
[06:53] <Ubugtu> Malone bug 51130 in launchpad-bazaar "cannot use +admin on a branch I own" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/51130
[06:54] <lifeless> ddaa: +admin should be admins only.
[06:54] <lifeless> ddaa: +edit should ahve the functionality the branch owner needs.
[06:55] <ddaa> 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] <lifeless> 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] <lifeless> thats fine, I support that.
[06:55] <ddaa> lifeless: is there another standard name for "form allowed to the owner to change dangerous things?"
[06:56] <ddaa> I'm happy to call it +crocodile if nobody has a problem with that
[06:56] <lifeless> ddaa: the reset of lp does not differentiate this AFAIK
[06:57] <lifeless> salgado: your karmacontext sql needs some comments to pass DBA review - altrting you early
[06:58] <lifeless> salgado: see TranslationUploads for an example
[06:59] <carlos_> see you later
[07:02] <ddaa> actually, I think branch/+spork would be a better name
[07:03] <ddaa> Kamion: in the meantime, you can ask an admin to make the change for you
[07:04] <ddaa> changing the branch name will break nothing
[07:05] <Kamion> hmm, there are a lot of them; is anyone willing to rename ~30 branches for me?
[07:06] <ddaa> Kamion: note that, as a convention, we like vcs-imports to be named the same as their series
[07:07] <Kamion> ok, I don't need to rename any imports though
[07:08] <ddaa> lifeless: can you accomodate Kamion?
[07:15] <salgado> lifeless, thanks for alerting me. we're still working on that
[07:16] <salgado> lifeless, anyway, is it just some comments on the new columns?
[07:53] <lifeless-lithuan> Kamion: what do you need done ?
[08:05] <kiko> lifeless-lithuan, lifeless-lt perhaps? 
[08:34] <Keybuk> cprov, Kinnison: I have another example of the uploader failing an upload that should have been approved
[08:34] <Keybuk> do you want it?
[08:34] <cprov> Keybuk: yes, anywhere in chinstrap would be fine
[08:34] <Keybuk> would drescher not be fine? :p
[08:36] <Keybuk> cprov: chinstrap:~scott/upload-20060627-102715-005864/
[08:37] <Keybuk> note that the changes and dsc are both signed by the key that is associated with that user in launchpad
[08:37] <Keybuk> and that he is a member of the right team
[08:37] <crimsun> cprov: / Keybuk: to note, I recently (two days ago) bumped forward the expiration date on that key and reuploaded it to wwwkeys.eu.pgp.net.
[08:38] <cprov> Keybuk: wait, this is all about a previously expired key ?
[08:39] <Keybuk> ah
[08:39] <Keybuk> crimsun: it's not showing up as not-expired for me
[08:40] <Keybuk> or, it's showing up as expired
[08:41] <Keybuk> gpg: requesting key C88ABDA3 from hkp server subkeys.pgp.net
[08:41] <Keybuk> gpg: key C88ABDA3: "Daniel T. Chen (new) <crimsun@fungus.sh.nu>" not changed
[08:41] <Keybuk> pub   1024D/C88ABDA3 2003-06-23 [expired: 2006-06-27] 
[08:41] <crimsun> so the newer key simply hasn't synced yet
[08:41] <Keybuk> crimsun: hasn't sync'd anywhere yet
[08:41] <Keybuk> cprov: sorry to bother you
[08:42] <cprov> Keybuk: np, anytime
[09:14] <lifeless-lithuan> kiko: lifeless-lt would syggest less than lifeless
[09:59] <cntb> hi anyone?
[10:30] <kbrooks> Is there a bug open related to the CoC?
[10:34] <matsubara> kbrooks: could you be more specific?
[10:34] <kbrooks> never mind/
[11:36] <cguima> boa noite
[11:38] <cguima> algum me pode dar uma informao?
[11:40] <matsubara> cguima: sim eu posso, mas este  um canal em ingls.
[11:40] <cguima> devo ento escrever em ingls?
[11:41] <matsubara> cguima:  melhor. voc tem mais chances de ter sua pergunta respondida
[11:42] <cguima> obrigada
[11:42] <cguima> my problem is with the wireless
[11:43] <cguima> i want to work with linux
[11:43] <cguima> but i  can't work with my wireless device
[11:44] <matsubara> cguima: try asking on #ubuntu or #ubuntu-br
[11:44] <cguima> do you know where to find drivers
[11:44] <cguima> ok, thanks