[04:44] <jamesh> 34.5% of launchpad.net hits are from windows?
[04:46] <spiv> stub: Hello.  Can you try running http://rafb.net/paste/results/IPGxHe33.html on balleny for me?  I'm try to reproduce the bzr test failures.
[04:47] <spiv> I can't reproduce it locally (even though that script does 25 commits/sec on my laptop), but perhaps there's something different about balleny (64-bit?  different fs?) that's affecting it.
[05:00] <mpt> Gooooooooooooooooooooooood afternoon Launchpadders!
[05:06] <ruffneck> mornin
[05:06] <ruffneck> I'd need to launch a new pack of CD's
[05:07] <ruffneck> they even sent the CD's but the one I tried had an error, or the computer was broken or something
[05:07] <ruffneck> it was my sisters computer.. she was complaining about spyware with win dose
[05:07] <ruffneck> I could try to use the live CD
[05:07] <ruffneck> should I Try now... but does it have pr0n-get ?
[05:20] <jamesh> ruffneck: if you're having trouble installing Ubuntu, you'll probably get more help on #ubuntu.
[05:21] <ruffneck> oukei
[05:21] <ruffneck> well.. I'll be fine with it
[05:21] <ruffneck> I just gotta have a working CD
[05:21] <ruffneck> it was broken or something it complained.. even offered me a chanse to check CD integrity or something
[05:21] <jamesh> ruffneck: btw, with Dapper the live CD _is_ the install CD
[05:23] <jamesh> there is a non-live CD ISO that can be used for install, but last I checked it was slightly oversized
[05:35] <ruffneck> dapper?
[05:36] <ruffneck> there were 2 CD:'s in the cardboard
[05:36] <ruffneck> the other is the other and..
[05:36] <ruffneck> I tried the Live
[05:36] <jamesh> ruffneck: that's probably breezy (Ubuntu 5.10)
[05:36] <ruffneck> yeah, old
[05:36] <jamesh> ruffneck: the current release is dapper (Ubuntu 6.06)
[05:36] <ruffneck> hehe, they just sent me it after few cliking :D
[05:36] <ruffneck> this is humane :)
[05:37] <ruffneck> humane interface
[05:37] <ruffneck> Jef Raskin wrote.. I guess I should read
[05:37] <jamesh> if you are doing a new install, I'd recommend going with Dapper
[05:58] <stub> spiv: works fine on balleny
[06:30] <spiv> stub: damn.  I wonder how to reproduce it then.
[08:06] <mpt> stub, staging is down
[08:06] <stub> mpt: It is being rebuilt, as last nights auto rebuild failed.
[08:07] <mpt> ok, thanks
[08:08] <stub> mpt: Should be up in about 40 mins if it keeps to the normal timings.
[08:08] <stub> (and assuming there isn't more breakage to fix)
[08:26] <jamesh> mpt: too many or two few slashes on the end of a branch name
[08:26] <jamesh> I forget which
[08:26] <jamesh> that's just a guess though
[09:35] <lifeless> mpt: branh url is wrong
[09:35] <lifeless> (yay Hong Kong, free wifi)
[09:37] <jsgotangco> nice
[09:39] <mpt> well the URL works with bzr push...
[09:53] <lifeless> noit *cannot* work with bzr push - you dont have access to push to the rocketfuel branches.
[09:56] <mpt> lifeless, the branch is sitting on chinstrap and the pending-reviews script picked it up fine, so the URL *must* have worked with bzr push
[09:56] <lifeless> mpt: not *your* branch url. the branch you told PQM to merge into.
[09:57] <lifeless> sorry if I'm not being clear, I just got off an 11hour plane flight
[09:57] <mpt> oh, ok
[09:57] <mpt> I never tell PQM to push into any particular branch, I use a script for that
[09:58] <jamesh> mpt: what are you using to make your pqm submissions?
[09:59] <mpt> jamesh, a script called "publish", I can't remember where it's from (somewhere on the wiki, I suspect)
[09:59] <mpt> it gets the URL from .bzr/branch/parent
[10:00] <mpt> which in this case is sftp://chinstrap.canonical.com/home/warthogs/archives/rocketfuel/launchpad/devel
[10:00] <jamesh> mpt: try making that chinstrap.ubuntu.com
[10:00] <jamesh> like we always use
[10:01] <jamesh> mpt: pqm works on string equality rather than path equality for the merge target
[10:12] <mpt> ok, that was a problem in my new-branch script
[10:12] <mpt> thanks jamesh
[10:13] <jamesh> mpt: when I ran into this problem last, it was because I had an extra slash on the end of the target branch name, hence my original comment
[10:37] <sivang> morning
[11:08] <elmo> stub: can you add me back as an lpadmin please?
[11:08] <elmo> stub: kiko removed me, but my removal was conditional on certain functionality (e.g. buildd shutdown/revival) working without lpadmin, and it doesn't
[11:09] <elmo> or anyone else who's a lpadmin and is awake
[11:09] <stub> k
[11:09] <stub> You already are (?)
[11:10] <stub> yup
[11:11] <elmo> err, really?
[11:11] <stub> If you can't do something, maybe you have found a task that soyuz-dev can do but launchpad-admins can't?
[11:11] <elmo> stub: this task use to work though.  how confusing
[11:11] <elmo> sorry for wasting your time, I should have checked
[11:12] <stub> I'll add you to launchpad-buildd-admins and see what happens
[11:12] <elmo> stub: canonical sysadmins are a member of lp-buildd-admins tho, no?
[11:12] <stub> Yes. So I'm out of ideas ;)
[11:13] <stub> That seems an abuse of an existing team...
[11:14] <elmo> stub: how so?
[11:15] <stub> A team tasked with setting standards and making architectural decisions. I don't see why membership in that team should confer pretty high level rights over the buildds and other production systems.
[11:21] <samyboy> Hello. Since Launchapd is not yet released, I would like to find something similar to launchpad tu use in my company. any help ?
[11:22] <lifeless> You can use launchpad right now, just sign up for an account and login.
[11:27] <jsgotangco> maybe he meant to install it in a machine for internal use for his company?
[02:18] <maxPhoenix> someone from Italy?
[02:26] <samyboy> lifeless, I meant what jsgotangco said earlier
[02:27] <samyboy> i need a launchpad-like for internal use.
[02:28] <samyboy> When i say "launchpad-like" I mean a _good_ tool :)
[02:36] <kiko> hello hello
[02:39] <LoBoGoL> hello :)
[02:55] <LoBoGoL> Please...
[02:55] <LoBoGoL> Could somebody tell me if project Ubuntu has an open channel for users' packages and utilities suggestions?
[02:56] <salgado> can I use the email interface on staging?
[02:58] <LoBoGoL> salgado: sorry?
[03:00] <matsubara> LoBoGoL: #ubuntu maybe
[03:04] <LoBoGoL> matsubara: ok, thanks..
[03:04] <kiko> flacoste!
[03:04] <flacoste> hi kiko!
[03:04] <kiko> salgado, no, I don't think you can.
[03:09] <jamesh> kiko: so we're doing keywords/tags for bugs rather than product components?
[03:09] <kiko> jamesh, that's the current standing, yes. what do you think?
[03:10] <jamesh> kiko: it doesn't bother me much either way.
[03:11] <jamesh> kiko: I suppose the question is whether to manage a fixed set of keywords (similar to bugzilla keywords or bugzilla product components) or have them free text (like "tags")
[03:12] <jamesh> the first probably makes for easier searching but is more restrictive
[03:13] <kiko> jamesh, we were leaning for the latter last we discussed the subject.
[03:13] <flacoste> kiko: thanks for the spec review!
[03:14] <jamesh> kiko: I know mark said that if we do keywords we should call them tags :)
[03:14] <salgado> is it possible for a person without a preferred email to use the email interface?
[03:19] <kiko> salgado, not that I know of. I think it breaks at least
[03:22] <salgado> kiko, I'm asking because I want to get rid of this: https://chinstrap.ubuntu.com/~dsilvers/paste/file9pG4cu.html
[03:22] <kiko> let's see
[03:23] <kiko> salgado, why do we accept email from users with no preferred email?
[03:24] <kiko> salgado, is it just because of https://launchpad.net/products/launchpad/+bug/33427 ?
[03:24] <kiko> salgado, if so, just fix that bug and remove that crack
[03:24] <salgado> the bug is fixed
[03:25] <salgado> I'm not sure if it's only because of that bug
[03:25] <salgado> the first XXX doesn't mention the bug
[03:31] <kiko> yeah
[03:31] <kiko> bradb, do you know of bjorn?
[03:56] <carlos> hi
[03:57] <kiko> carlos1
[03:57] <kiko> bradb!
[03:57] <bradb> hey!
[03:58] <kiko> how's it going bradb 
[03:58] <kiko> so
[03:58] <kiko> I thought about our problem
[03:58] <kiko> and I think I have a plan
[03:58] <kiko> but I'd like to see what you think
[03:59] <bradb> sure
[03:59] <kiko> lessee
[03:59] <kiko> https://chinstrap.ubuntu.com/~dsilvers/paste/file2TMy90.html
[04:00] <kiko> bradb, how does that sound?
[04:01] <kiko> bradb, the nice thing is that the knob is only used in one point -- filebug.
[04:02] <bradb> kiko: Do we know of any current Launchpad user other than Landscape that will want to toggle this flag?
[04:03] <kiko> bradb, niemeyer made a case yesterday for this actually being useful in certain situations
[04:04] <bradb> My main concern with this approach is it looks like a more generic solution for a problem we've only seen once and which will, AIUI, only last for about six months.
[04:05] <niemeyer> bradb: In fact, the flag is already there.. it's only a minor extension to an existing concept..
[04:06] <bradb> niemeyer: do you really mean the flag is there?
[04:07] <niemeyer> bradb: As exposed in the ticket, "only subscribers can see" currently means "unsubscribe the bug contact".
[04:08] <niemeyer> bradb: All we need is to untie these two concepts, and add a "default_is_private" flag..
[04:08] <bradb> niemeyer: It means "don't subscribe the bug contact", fwiw.
[04:08] <niemeyer> bradb: The behavior in bugs is largely unchanged.
[04:08] <niemeyer> bradb: Ok :)
[04:09] <bradb> niemeyer: So, my main concern is bloat. This looks like a generic solution for a problem we've seen once, and which, AIUI, is only a problem until LS is officially released.
[04:10] <bradb> because we can also solve this problem without bloat, and much more quickly.
[04:10] <niemeyer> bradb: I was looking at it as something simple.. if you belive it's not worth the effort, we can of course setup our own Roundup or something.
[04:11] <bradb> niemeyer: Another way to solve this is to model the solution after the problem: a special case.
[04:11] <kiko> bradb, I wonder whether the special case will be cleaner than the fix I'm proposing, though
[04:12] <kiko> bradb, are you suggesting just doing the special case in browser code?
[04:12] <niemeyer> bradb: I was quite suprirsed when I understood that the bug contact wouldn't see the bug if you click "only for subscribers". If I'm the maintainer of a product, and someone click on that button, I basically will never get notified about it. Is it the case?
[04:12] <kiko> niemeyer, yes, but that's arguably a bug.
[04:13] <bradb> niemeyer: It is. I think we're both in strong agreement that that's a nasty bug. :)
[04:13] <bradb> there should be at least some way to file a private bug and not be the only person subscribed to it
[04:13] <kiko> right.
[04:13] <kiko> one option would be to add a text field
[04:13] <niemeyer> bradb: Ah, cool.. I wasn't getting that you agree this should be fixed.
[04:13] <kiko> another would be to add yet another checkbox
[04:13] <kiko> mpt_?
[04:14] <bradb> niemeyer: I filed that bug exactly one year ago today. :)
[04:14] <bradb> bug 1294
[04:14] <Ubugtu> Malone bug 1294 in malone "Filing a private bug requires the ability to Cc the maintainer" [Critical,Confirmed]  http://launchpad.net/bugs/1294
[04:14] <niemeyer> Wow :-)
[04:15] <kiko> niemeyer, we're discussing whether we should do the special handling for bug filing.
[04:15] <mpt_> bradb, I don't think it should be *possible* to report a private bug and be the only one subscribed to it, unless you're the maintainer
[04:15] <niemeyer> bradb: So, isn't it simple to add a "bugs_default_to_private" flag in products?
[04:15] <kiko> bradb, if it would be only browser code I am okay with adding the celebrity code.
[04:15] <kiko> bradb, I still wonder whether it'll be more or less work than doing the product db change
[04:16] <bradb> niemeyer: "simple" is a dangerous word. :) it's a feature that needs to be discussed further, spec'd, tests written, implemented, code reviewed, etc. to solve a problem that may not even exist in six months.
[04:16] <bradb> consider it this way:
[04:17] <bradb> the upside is that it would solve your use case
[04:17] <kiko> bradb, stop singing the spec/tested/etc song, because it's boring and not very true either!
[04:17] <bradb> the downsides are that 1. it will take somewhat longer than a "quick hack" solution for a quick hack problem, 2. it's solving a problem that we've only seen once, and which may not even be there in six months.
[04:18] <kiko> however
[04:18] <kiko> unless you are /ignoring me
[04:18] <kiko> I still haven't seen you confirm that the hack would be browser code only
[04:19] <bradb> kiko: in browser code only, i think, yeah.
[04:19] <kiko> then I think it's cool
[04:19] <bradb> in FileBugView
[04:19] <niemeyer> bradb: If it works, I'm not really worried about how it's implemented (you're the one who should be wearing that cap :-).
[04:19] <kiko> agreed
[04:20] <bradb> I can have the FileBugView solution tested an implemented (though I can't guarantee past pqm) before lunch.
[04:20] <kiko> well
[04:20] <kiko> there's also fixing bug 1234, which will take longer because we actually have no idea of the UI
[04:20] <kiko> mpt_, wake up
[04:21] <bradb> yeah
[04:21] <mpt_> kiko, it's 2am!
[04:21] <kiko> and at least the impression I get is that 1234 blocks the celebrities hack
[04:21] <niemeyer> mpt_: What!? And you're not working!? Absurd!
[04:21] <niemeyer> :-)
[04:21] <bradb> bug 1294, fwiw
[04:21] <Ubugtu> Malone bug 1294 in malone "Filing a private bug requires the ability to Cc the maintainer" [Critical,Confirmed]  http://launchpad.net/bugs/1294
[04:22] <mpt_> niemeyer, I am working, I'm fixing the Ubuntu Desktop Guide
[04:22] <kiko> because, well, the celebrities hack, if well-done, will also auto-subscribe the maintainers.
[04:22] <mpt_> I am not, however, Launchpadding
[04:22] <niemeyer> mpt_: Ah, ok then.. ;)
[04:23] <bradb> the simplist solution i can see is to say "if the only person subscribed to this bug would be the reporter, then subscribe the .bugcontact. if there is no .bugcontact, then subscribe the .owner"
[04:23] <bradb> there are, of course, other options
[04:23] <mpt_> bradb, that seems reasonable
[04:24] <kiko> mpt_, bradb: how do we make it clear to the end-user?
[04:25] <kiko> my only concern is that this is a special-case on top of a special-case
[04:25] <mpt_> Mind-waves-over-IP
[04:25] <mpt_> [ ]  This bug report should be private
[04:25] <mpt_>     Only the bug contact or package maintainer will be notified.
[04:26] <bradb> mpt_: the problem is that won't be true if the user clicks the security cb and there is a sec contact
[04:27] <kiko> maybe use radio buttons?
[04:27] <kiko> and have security-always-be-private?
[04:27] <mpt_>     Only the bug contact, security contact (for security bugs), or package maintainer will be notified.
[04:29] <mpt_> Are there any Bugzillas that have separate private/security checkboxes?
[04:30] <kiko> mpt_, well, in practice yes, but..
[04:30] <kiko> bugzilla permissions are way too complicated.
[04:32] <mpt_> So, can we possibly turn these from two checkboxes into one?
[04:32] <kiko> we could turn them into a radiobutton
[04:32] <bradb> Redhat's security cb is an email address :P
[04:32] <kiko> or we could turn them into a singel checkbox
[04:36] <bradb> a single cb would be nice. trying to think of how we'd be able to address all three use cases (private bug, public security bug, private security bug)
[04:36] <bradb> one way to model security in launchpad is not to model it at all
[04:36] <bradb> (er, sort of)
[04:37] <bradb> so, "security" could end up being a keyword, because it's just metadata about a bug, no more special than "branding", or "i18n"
[04:37] <bradb> the bug knob would control only visibility
[04:38] <bradb> security bugs would be emailed to security contacts, done outside of Malone, like Redhat doex
[04:38] <bradb> s/doex/does/
[04:39] <bradb> to report a security bug, you'd follow a link from +filebug, explain the procedure, whom to mail, and offering a gpg key if you're feeling extra paranoid
[04:39] <bradb> s/explain/which explains/
[04:40] <mpt_> Alternatively, trust product/package/distribution maintainers to forward security bugs to the relevant person
[04:42] <bradb> mpt_: keep in mind that the bugcontact for Ubuntu is ubuntu-bugs@ :)
[04:43] <mpt_> If that's true, what's the use of reporting a private bug right now?
[04:43] <mpt_> "This bug report will be limited to only a gazillion people"
[04:44] <bradb> mpt_: they don't see private bugs
[04:44] <kiko> mpt_, right now? we don't CC: anybody
[04:44] <mpt_> argh
[04:44] <mpt_> hence the original problem :-)
[04:44] <bradb> that's bug 1294
[04:44] <Ubugtu> Malone bug 1294 in malone "Filing a private bug requires the ability to Cc the maintainer" [Critical,Confirmed]  http://launchpad.net/bugs/1294
[04:44] <mpt_> bing bing bing
[04:45] <mpt_> So, I think this is what you get for not implementing product/package/distro subscriptions
[04:45] <mpt_> ubuntu-bugs@ should be subscribed to Ubuntu
[04:45] <mpt_> but they should not be the bug contact
[04:46] <mpt_> and should not get notified about private bugs
[04:46] <kiko> mpt_, who /should/ get notified about private bugs?
[04:46] <kiko> in the ubuntu case?
[04:47] <mpt_> The bug contact or maintainer
[04:47] <kiko> who would the bug contact be for ubuntu?
[04:47] <mpt_> some smaller trusted team, Ubuntu Drivers perhaps?
[04:47] <jamesh> ubuntu-bugs@lists.ubuntu.com is the bug contact at the moment
[04:48] <mpt_> yes, jamesh, that's what we're discussing
[04:48] <bradb> specifically, private security bugs should be sent only to the security team, i think. the idea being that an undisclosed vuln should be disclosed to as few people as possible
[04:49] <kiko> bradb, sure. we know that, and that's what happens today.
[04:49] <kiko> the question is: if it /wasn't/ a security bug, but just private, who should we email by default?
[04:49] <kiko> I think this is a moot point
[04:49] <kiko> I am coming around to thinking that security/privacy should be a single flag for ubuntu
[04:50] <kiko> and for landscape only security might be settable via +filebug
[04:50] <kiko> but that's really icing on the cake
[04:50] <mpt_> If you're odd enough to need private non-security bugs, you can be organized enough to have enough people in your maintainer team to handle all the private bugs
[04:51] <kiko> mpt_, in your security team you mean?
[04:51] <mpt_> (Disclaimer: It's nearly 3am and I'm not necessarily making any sense)
[04:51] <kiko> mpt_, then go to sleep
[04:51] <mpt_> I'm thinking of what we used to have
[04:51] <mpt_> [ ]  This bug report should be private
[04:51] <kiko> bradb, how does that sound?
[04:51] <mpt_>     For example, it's about a security vulnerability
[04:51] <kiko> [ ]  This is a security issue
[04:51] <kiko> that's the only checkbox that would appear
[04:52] <kiko> the security contact would judge whether it's a valid security issue and whether it should be private
[04:52] <bradb> kiko: you're suggesting one cb on +filebug, but still keeping two separate cb's on the bug?
[04:52] <kiko> bradb, yes.
[04:53] <kiko>     [ ]  This is a security issue
[04:53] <kiko>     * For ubuntu, marking security would make it private as well.
[04:53] <kiko>     * For landscape, all bugs would be private. Marking security would
[04:53] <kiko>       only make it security-related.
[04:53] <kiko> and s/ubuntu/any other context/
[04:53] <jamesh> kiko: would a set of checkboxes for each of the default bug contacts make sense for private bugs?
[04:54] <jamesh> kiko: to give the user an idea of who might be worth subscribing up front?
[04:54] <kiko> jamesh, like a subsidiary set of checkboxes? that sounds overcomplicated to me..
[04:54] <kiko> jamesh, I get the feeling that all security bugs should be initially private and the security contact can decide whether to disclose them or not.
[04:54] <kiko> sort of a "security triage"
[04:54] <kiko> this would solve the "nobody sees private bugs" problem
[04:55] <kiko> simplifying that -- possibly fixing bug 1294
[04:55] <Ubugtu> Malone bug 1294 in malone "Filing a private bug requires the ability to Cc the maintainer" [Critical,Confirmed]  http://launchpad.net/bugs/1294
[04:55] <kiko> bradb, talk to me
[04:55] <bradb> kiko: The issue still seems to remain about who to subscribe when that box is checked, if there is no sec contacct
[04:55] <bradb> (and make it clear to the user)
[04:55] <kiko> bradb, the maintainer. that can be made clear using text.
[04:55] <kiko> bradb, that's an easy one to answer.
[04:55] <jamesh> kiko: you need to let the reporter make a security bug public: they have the ability to disclose it anyway
[04:55] <kiko> (and I thought that's how it worked today)
[04:56] <kiko> jamesh, they can do it after the fact, sure
[04:56] <jamesh> kiko: making security bugs private by default is a good idea though
[04:56] <kiko> jamesh, I just don't think it warrants letting them do it in +filebug
[04:56] <kiko> in particular because filing private bugs makes the CC: issue complicated.
[04:56] <bradb> jamesh: that's how it works today, where "by default" means we select the privacy cb for them when they click the security cb.
[04:56] <kiko> I am arguing for not displaying the privacy cb at all in +filebug
[04:57] <kiko> and letting the security contact take care of triaging the security bugs.
[04:57] <bradb> yeah, i understand that
[04:57] <kiko> do you agree with it, though :)
[04:57] <jamesh> bradb: That's the behaviour I'd expect.  So the reporter can unselect it if the security bug is for an issue that has previously been disclosed
[04:58] <kiko> jamesh, are you arguing for making the privacy checkbox /only apply/ if security is checked?
[04:58] <kiko> jamesh, I also think that it's not a lot of work to disclose it post-report, anyway.
[04:58] <jamesh> kiko: no.  I think the current setup of two checkboxes is okay.
[04:59] <jamesh> kiko: currently javascript is used to check the private checkbox if you check the security checkbox
[04:59] <kiko> "This security bug is by default private, and only the security contact ubuntu-security@ubuntu.com has been subscribed. You can disclose the bug <a href="">in the bug edit form</a>
[04:59] <jamesh> perhaps a combo box that combines both settings would be better though
[04:59] <kiko> jamesh, I don't think the current setup of two checkboxes is okay, though. A lot of end-users get confused and we still have the issue of non-security private bugs going to limbo.
[05:00] <jamesh> kiko: do you think a combo box would be better?
[05:00] <mpt_> WARNING: "You can $FOO in the $BAR" detected. Try linking directly to the page instead.
[05:00] <mpt_> __Disclose the bug__
[05:00] <kiko> yeah yeah
[05:01] <kiko> jamesh, I think that non-security private bugs are a bad idea.
[05:02] <jamesh> kiko: do you think public bugs marked as security related are a good idea?
[05:02] <bradb> (our own LP use case can be solved by putting sensitive snippets on private servers, like chinstrap)
[05:02] <kiko> jamesh, I'm okay with that, though I think there's a weak case for catering specially for them in +filebug.
[05:04] <jamesh> bradb: btw, if you have any comments on the PythonBugTrackerCompetition wiki page, please update the wiki page or mail the list
[05:05] <kiko> bradb, wanna seal this with a phone call?
[05:05] <bradb> kiko: sure
[05:06] <jamesh> bradb: I'll see if I can get a basic import ready early next week, but I think we'll need to coordinate on some malone improvements
[05:06] <bradb> jamesh: yeah, i'm subscribed to that page
[05:06] <bradb> jamesh: cool
[05:12] <salgado> hey kiko, would you like to review my karma-context branch?
[05:13] <kiko> salgado, I guess I could
[05:36] <salgado> Znarl, kiko, how about "Choose Release if this mirror contains CD images of any of the  various releases of this distribution, or choose Archive if this mirror contains packages for this distribution and is meant to be used in conjunction with apt.", as the text under the Content drop-down box, to help people choosing the right one?
[05:37] <kiko> salgado, or we could auto-detect. have you considered that?
[05:38] <salgado> no
[05:38] <carlos> Is pqm stalled?
[05:39] <mpt_> yes
[05:39] <salgado> kiko, that won't be trivial to implement. I'd prefer to do something like this and, if it doesn't work, we can do the auto-detection
[05:40] <salgado> (I was expecting that people would know the content they're mirroring)
[05:40] <kiko> salgado, I don't think text is going to be effective, but sure, give it a try.
[05:40] <Znarl> salgado : I think it's good.
[05:40] <Znarl> And agree with you on auto-detecting not really working very well.
[05:41] <carlos> mpt_: ok, thanks for your confirmation
[05:44] <salgado> Znarl, cool...  I'm doing some tweaks to the mirrors UI; maybe you can have a look after I finished to see if everything is okay?
[05:45] <Znarl> salgado : Sure, ping me when you're ready.
[05:45] <salgado> will do!
[06:28] <sabdfl> kiko-fud: please ping cvd when you're back and we can have that call
[06:29] <SteveA> i'm around.
[06:29] <SteveA> sabdfl: want to do a quick pre-kiko catch up?
[07:41] <loko555> i have a problem with launchpad. i am not assigned to a bug nor i have subscribed to one but i still get a email-report about a bug. how can i stop this?
[07:44] <salgado> loko555, which bug?
[07:48] <loko555> https://launchpad.net/bugs/32963
[07:48] <Ubugtu> Malone bug 32963 in xserver-xorg-driver-i810 "Xv movies on 810/i945 gives horrible color, Gamma" [Unknown,Needs info]  
[07:49] <loko555> salgado: this is the bug
[07:51] <salgado> loko555, did you report bug 42349?
[07:51] <Ubugtu> Malone bug 42349 in xserver-xorg-driver-i810 "Dapper Drake - i810 - Video Color output wrong" [Medium,Fix released]  http://launchpad.net/bugs/42349
[07:51] <loko555> yes
[07:52] <loko555> but i get infos about bug 32963
[07:52] <Ubugtu> Malone bug 32963 in xserver-xorg-driver-i810 "Xv movies on 810/i945 gives horrible color, Gamma" [Unknown,Needs info]  http://launchpad.net/bugs/32963
[07:52] <loko555> but why?
[07:53] <salgado> loko555, right. you get notifications about the latter because it has the former (the one you filed) as one of its duper
[07:53] <salgado> s/duper/dupes/
[07:53] <loko555> ok, but how can i cancel the notifications?
[07:53] <salgado> there's a bug open for that, IIRC. (I'm trying to find)
[07:54] <matsubara> bug 48860
[07:54] <Ubugtu> Malone bug 48860 in malone ""Also notified" makes difficult to unsubscribe" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/48860
[07:55] <loko555> oh, and this does mean that at the moment i will get the notifications until this bug is closed?
[07:57] <flacoste> /whoami
[07:57] <flacoste> this is a big question...
[08:13] <sabdfl> SteveA, kiko-fud: calling now
[08:15] <edgy> Hi, as far as I read rosetta is not free, how much is it?
[08:15] <sabdfl> it's free to host your potemplates and pofiles
[08:16] <edgy> sabdfl: can I e.g import other distributions' files to it?
[08:16] <edgy> sabdfl: say fedora e.g specific files?
[08:18] <edgy> sabdfl: I want to use it for maintaining traslation of many open source projects that may not fit well  being uploaded to ubuntu, should I buy it or go for pootle or make a deal with canonical to translate rosetta to my lang and they allow me to use it? ;)
[08:19] <LarstiQ> edgy: there are upstream projects with translations in rosetta, not just ones in ubuntu.
[08:21] <edgy> LarstiQ: yes but as far as I understand all those upstream projects can be used in ubuntu like kde or gnome but I don't see any other distribution specific files in rosetta, is there?
[08:21] <LarstiQ> edgy: I'm not sure what you are asking for. There are other distributions in launchpad, see https://launchpad.net/distros/
[08:22] <edgy> LarstiQ: wow! this is new to me.
[08:23] <LarstiQ> edgy: launchpad is meant to make cooperation between up/down/samestreams easier. Wether that is between distros, between a given up and all their downstreams, etc.
[08:23] <LarstiQ> edgy: so it has support to track the state of a bug in all places
[08:24] <LarstiQ> edgy: I'd think the same is true for rosetta.
[08:25] <edgy> LarstiQ: nice. but  https://launchpad.net/distros/fedora/+translations contains no translation and saying: Translation policy: Doesnt use Rosetta
[08:26] <LarstiQ> edgy: you want to translate fedora specific packaging?
[08:26] <edgy> LarstiQ: yes
[08:26] <LarstiQ> edgy: I guess you would need to talk to the fedora people then
[08:27] <LarstiQ> edgy: but carlos can help you more with these questions I think
[08:27] <LarstiQ> edgy: Afaik the idea is not to use rosetta if the product/distro in question doesn't want to use it itself
[08:28] <edgy> LarstiQ: so it's just a matter of  fedora people agree but ubuntu people would have no issue about importing any open source project?
[08:28] <LarstiQ> now you confuse me
[08:29] <edgy> LarstiQ: still I am confused because kde is translated using it's cvs system and if I translate from rosetta a conflict would happen
[08:30] <edgy> some work would got thrown away in favor of the other unless an upstream update is checked daily or so
[08:30] <edgy> LarstiQ: why do I confuse you?
[08:31] <LarstiQ> sorry, had to let someone in
[08:31] <edgy> LarstiQ: fedora has different teams for each language. a maintainer of one language may like to use rosetta but others may not. so would it be decided for each team alone or for the whole distro?
[08:32] <LarstiQ> edgy: I think it would be possible on a per team basis, I believe gnome has something similar going on
[08:33] <LarstiQ> edgy: the confusion stems from me thinking you want to do packaing bits, then thinking, oh no, upstream products, and being thrown from the one to the other
[08:33] <LarstiQ> edgy: see https://launchpad.net/products/bzr , that is the upstream product, no distribution bits there
[08:34] <LarstiQ> edgy: bzr doesn't use rosetta simply because there is nothing to translate
[08:35] <LarstiQ> https://launchpad.net/products/bzr/+distributions lists the packages of bzr in distributions
[08:35] <edgy> LarstiQ: ok this is clear now
[08:37] <LarstiQ> edgy: so if there is an upstream products you want to translate, but not necessarily bound to a distro, you can do that 
[08:38] <edgy> LarstiQ: understood. thx for the clarification
[08:41] <LarstiQ> ciao
[09:23] <LarstiQ> hmm, he left already.
[09:54] <kiko-fud> bradb, note mdz's emails on the subject of our discussing this morning, but both mark and I have now green-lighted the project so it is blessed from Above :)
[09:54] <kiko-fud> BjornT_!
[09:55] <bradb> kiko-fud: I already made the change to vulnerability here.
[09:55] <bradb> So I'm on the road, speeding through the green light, creating a breeze for the pedestrians.
[09:55] <mdz> bradb: could we require that they type into a text entry box "I am not fucking around" before it will let them file a security bug?
[09:57] <kiko-fud> mdz, the current plan is moving that control to a separate page anyway
[09:57] <bradb> mdz: that might be useful, though i'd rather proceed with what kiko/mark/etc. already blessed before changing it
[09:58] <kiko-fud> fucking around might look bad on LP UI
[09:58] <bradb> cussing is for portlets
[10:13] <LarstiQ> for some reason autotools-dev is listed as a distro package for bzr. Anything I can do about that?
[10:49] <Alextremo> viva PAPASHANTY SOUND SYSTEM... !!!! Chao mis panas... Nos leemos el Lunes....5 4 3 2 1 0
[10:49] <kiko-fud> wtf
[10:49] <kiko-fud> PAPASHANTY SOUND SYSTEM?
[10:50] <Alextremo> yeah  escuchalo
[10:50] <kiko-fud> I'll give it a spin later
[10:51] <Alextremo> PAPASHANTY = Father of the peace
[10:51] <Alextremo> PAZ
[10:52] <Alextremo> buy the cd
[10:52] <Alextremo> is very nice
[10:52] <Alextremo> sorry not speak so much english
[10:54] <Alextremo> Bueno, Feliz  Fin de Semana...
[10:55] <Alextremo> Chao
[10:56] <kiko-fud> lol
[11:55] <matsubara> bradb, BjornT_, SteveA, anyone: Datetime field returns an not naive datetime object. Do you know from where it takes that timezone information?