[03:01] <michaelh1> Hi there.  What's a good way of sending all branch merge requests to a mailing list?  They currently go to the individual team members but I'd like to keep the discussion out on a list.
[03:01] <michaelh1> Should I create a fake user and add them to the branch owner group?
[03:02] <wgrant> michaelh1: If you have a separate review team you could see the team's contact address to the mailing list.
[03:02] <wgrant> michaelh1: That will send all team email (not just for reviews) to the mailing list.
[03:03] <michaelh1> wgrant: hmm.  linaro-toolchain-dev is the current team.  I could create linaro-toolchain-reviewers, add linaro-toolchain-dev, and set l-t-reviewers contact address to the list...
[03:04] <lifeless> is linaro-toolchain-dev a mailing list ?
[03:04] <michaelh1> lifeless: no, it's a team.
[03:05] <michaelh1> I guess I could skip the review team and set the linaro-t-dev contact address to the list...
[03:05] <lifeless> you could just set its contact address to your list, whereever it is
[03:05] <michaelh1> lifeless: I'll do that.  Ta.
[03:06] <wgrant> michaelh1: The team doesn't get mail for any other reason?
[03:06] <thumper> as long as the list is open to getting email...
[03:07] <michaelh1> wgrant: hmm.  No.  Will commit notices also end up on the mailing lists?  I really only want the merge requests.
[03:07] <thumper> sometimes the person sending the email has their preferred email set to something that the list doesn't understand
[03:07] <thumper> like me and some canonical lists
[03:07] <thumper> you can get spurious bounces from that
[03:08] <thumper> at least with a launchpad list, emails are accepted from any known email address
[03:08] <wgrant> michaelh1: You can configure the subscription to send only one type of mail.
[03:10] <michaelh1> wgrant: how do I do that?  (I can't find the UI for it...)
[03:10] <thumper> michaelh1: there is an edit icon next to the subscription on the branch page
[03:10] <michaelh1> thumper: that's my subscription though, not the teams
[03:11] <thumper> michaelh1: any one in the team should be able to edit it
[03:11]  * thumper thought so anyway
[03:11] <michaelh1> thumper: so if I click on 'Edit my subscription' on https://code.launchpad.net/~linaro-toolchain-dev/gcc-linaro/4.5 it will change the team subscription?
[03:11] <thumper> no
[03:12] <thumper> there is a yellow pencil icon
[03:12] <thumper> or at least there should be
[03:13] <thumper> to the right hand side of the subscriber name
[03:13] <michaelh1> thumper: hmm.  So the review team is linaro-toolchain-dev.  They're not subscribed though.  Should they be, or do they get emails by default due to being the review team?
[03:14] <thumper> kinda...
[03:14] <thumper> yes they should be subscribed
[03:14] <james_w> they won't get mail for every merge proposal, but they will for any where the proposer doesn't change from the default review team
[03:14] <thumper> that way the list will get the emails even if someone requested a review from some specific individual
[03:14] <james_w> if you want mail for every merge proposal against that branch then add the subscription
[03:14] <thumper> yeah, what james_w says
[03:14] <michaelh1> james_w: OK.  I'll try it.
[03:16] <michaelh1> Hmm.  When I subscribe a blue message box shows and disappears by the time the page finishes loading...
[03:17] <lifeless> thats a regression
[03:17] <lifeless> fix is landing today we hope
[03:19] <michaelh1> Also the confirm email page just has yes / no buttons and no banner, links, etc.  Has the footer though...
[03:24] <wgrant> michaelh1: Yeah, it's been like that for almost two years now :/
[03:24] <ripps> How do you delete posts in a bug thread. Some jerk hacked my gmail account and spammed a couple bug threads I was following in my email account.
[03:25] <wgrant> ripps: I can remove them for you.
[03:25] <wgrant> ripps: Do you have links to the comments?
[03:26] <wgrant> Those 5 from 10 minutes ago?
[03:26] <wgrant> Or older ones?
[03:27] <ripps> https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/655024
[03:28] <wgrant> Ah, I see there were 5 comments on the 7th.
[03:30] <wgrant> Although I can only see one of them...
[03:31] <wgrant> ripps: I've removed comment #69 and #70 from that bug.
[03:31] <wgrant> ripps: If there are any others, links would be helpful.
[03:32] <ripps> wgrant: I'll contact you if I find more. People have been alerting me the spam my account has spread.
[03:33] <wgrant> :(
[04:11] <ScottK> Does the fact that I'm getting stacks of ancient linked branch notifications in bugmail mean something was fixed or something was broken?
[04:12] <wgrant> ScottK: Is their Date ancient, or just the action?
[04:12] <ScottK> lookinh
[04:12] <ScottK> g
[04:13] <ScottK> Date is now.
[04:13] <ScottK> Date: Fri, 08 Apr 2011 02:52:17 -0000
[04:13] <wgrant> It's not because previously failing package imports are no longer failing?
[04:16] <ScottK> No idea, but it's an Ubuntu branch.
[04:16] <ScottK> The upload that the branch represents was Thu, 03 Jun 2010 17:10:18 -0400
[04:16] <lifeless> package imports have been fixed then
[04:17] <ScottK> LP could stand to have a "Please don't tell me about ancient crap" option.
[04:17] <lifeless> not 100% guaranteed but highly probable
[04:17] <lifeless> ScottK: the notifications filter stuff should let you say 'dont tell me about closed bugs', for instance.
[04:17] <ScottK> All the ancient remote bugzilla priority adjuments were ooohhh so useful.
[04:18] <lifeless> yeah
[04:18] <ScottK> lifeless: I couldn't in good faith tick an option like that because I need to hear about post-upload problems for bugs I've fixed.
[04:19] <lifeless> ScottK: perhaps ubuntu should use the committed/fixed split
[04:19] <ScottK> The linked branch notification mails I could just do without period.
[04:19] <ScottK> lifeless: Not sure what you mean by that?
[04:21] <lifeless> ScottK: lp has room for 'comitted to <trunk> but not released' and 'released' as separate bits. It seems to me that you need to hear about bugs in uploads most *before* the next release of ubuntu is made
[04:22] <ScottK> Ah.  Yes, although SRUs wouldn't fit that model.
[04:22] <wgrant> ScottK: -proposed = committed, -updates = released?
[04:22] <lifeless> yeah
[04:22] <ScottK> That's how it's done now.
[04:23] <ScottK> But even after it's in -updates if there's a problem, I'd want to hear about it.
[04:23] <lifeless> ScottK: up to the next point release perhaps?
[04:23] <lifeless> ScottK: e.g. 10.4.2
[04:23] <StevenK> 10.04.2
[04:23] <ScottK> Only relevant for LTS.
[04:24] <lifeless> room for thinking about
[04:24] <lifeless> be nice to DTRT thing rather than needing everyone to converge on the same custom rules
[06:31] <poolie> lifeless, how do you create a conjoined master?
[06:31] <poolie> target it to a series that's also the trunk?
[06:31] <lifeless> yes
[06:31] <poolie> and then that doesn't actually create anything?
[06:31] <poolie> urk
[06:31] <lifeless> well it does
[06:31] <lifeless> its awfully messy
[06:32] <poolie> any solution that involves needing to think about this gets marked down :)
[06:32] <poolie> so for bzr is 2.4 conjoined, or only trunk?
[06:33] <poolie> i guess we have the additional complication that 2.4 is in a different sense conjoined with trunk
[06:33] <poolie> maybe we should get rid of trunk but that seemed to have other problems
[06:33] <poolie> i think it was tried before
[06:35] <lifeless> the default series is the only one conjoined
[06:35] <lifeless> lp:bzr -> whereever that goes
[06:35] <poolie> right
[06:37] <poolie> ok, so for this to work well we would need to get rid of the trunk series and have just 2.4
[06:37] <poolie> i don't know if that will cause problems with branches
[06:37] <poolie> can lp:bzr point to lp:bzr/2.4?
[06:37] <poolie> probably it can
[06:37] <lifeless> poolie: IIRC lp requires that you have a default series
[06:38] <wgrant> lp:bzr points to whatever the development focus series is.
[06:38] <lifeless> ah, you are saying that the rules for 2.4 might need to be different to 2.3, but that that is complex to remember
[06:38] <wgrant> That can be lp:bzr/2.4.
[06:38] <lifeless> poolie: but the rules for 2.4 might be the same as for trunk
[06:38] <lifeless> poolie: in which case conjoining would make sense?
[06:39] <poolie> i think it does make some sense
[06:39] <poolie> however, it's another click, and it doesn't seem to buy us a great deal
[06:39] <poolie> mm, it would give better reporting about what was fixed in the series before it branched off
[06:40] <poolie> so this is to say we'd essentially delete 'trunk' as a series
[06:40] <poolie> and just flip the focus from 2.4 to whatever
[06:40] <lifeless> the downside is that that breaks people branches of 'trunk' every release.
[06:41] <lifeless> I really dislike working with other projects that do that
[06:41] <poolie> ah, i thought it was something like that
[06:41] <poolie> what happens specifically?
[06:41] <lifeless> (aggravated by bzr remembering the expanded url)
[06:41] <lifeless> well
[06:41] <lifeless> bzr remembers bzr+ssh://b.l.n/~bzr-pqm/bzr/trunk
[06:41] <mwhudson> less so now there's +branch/$project
[06:42] <lifeless> mwhudson: thats not the authoritative url though, is it ?
[06:42] <lifeless> anyhow, if some one has 2.4 memoised on disk
[06:42] <lifeless> and you start on 2.5
[06:42] <mwhudson> lifeless: i have no idea
[06:42] <lifeless> how will bzr tell them and get them onto it ?
[06:42] <wgrant> lifeless: bzr remembers the alias now.
[06:42] <wgrant> At least over bzr+ssh.
[06:42]  * mwhudson stops making unhelpful comments and goes away
[06:42] <wgrant> I forget if it works over HTTP too now.
[06:42] <poolie> yes it should work everywhere
[06:42] <poolie> i think it's a purely client side fix
[06:42] <poolie> imbw
[06:43] <mwhudson> i don't think it does work over http
[06:43] <lifeless> I don't understand whats interestined about stuff that was fixed before the stablisation start
[06:43] <lifeless> s
[06:43] <lifeless> bah, spelling broken
[06:43] <mwhudson> which is after a series of chases apaches fault
[06:46] <poolie> lifeless, ?
[06:47]  * mwhudson exeunt
[06:47] <spiv> The lp plugin in bzr now just resolves lp URLs to +branch/$project, I think
[06:48] <spiv> Because that avoids the SSL handshake and roundtrip to make an API or XML-RPC call.
[06:48] <spiv> But there will be plenty of old branches people have that have remembered ~bzr-pqm/bzr/bzr.dev
[06:49] <poolie> yes, that's true
[06:49] <poolie> but that's a more mild disincentive
[06:49] <spiv> I agree
[06:50] <lifeless> poolie: I mean, whats the benefit of having a new distinct series and moving the default around
[06:54] <poolie> uh, i think the payoff for changing this stuff is pretty low, so i suggest we shelve it for today
[06:54] <poolie> happy to talk by voice some time
[06:55] <lifeless> sure
[07:02] <poolie> nice analysis spiv
[07:05] <spiv> poolie: thanks!  What of?:)
[07:08] <poolie> the [...]bug
[07:08] <poolie> analysis or guess :)
[07:13] <spiv> Ah, right :)
[07:13] <spiv> Which reminds me, I had another thought about that…
[09:35] <Laney> something seems to have gone wrong with this build: https://launchpad.net/ubuntu/+source/haskell-happstack-server/0.5.0.2-1ubuntu2/+buildjob/2433813
[14:23] <james_w> jcsackett, hi, any idea what constraint this is talking about? http://paste.ubuntu.com/591236/
[14:24] <jcsackett> james_w: not off the top of my head, but let me do some digging.
[14:24] <wgrant> james_w: Try passing a list of tags instead.
[14:25] <wgrant> The docs suck here.
[14:25] <james_w> ah
[14:29] <james_w> thanks wgrant
[15:45] <james_w> does LP not include mailed in comments if they aren't signed and include what it thinks is a command?
[15:45] <james_w> I wrote some Python in a comment and LP thinks it knows what I was trying to do and sent me an error message
[15:46] <james_w> does it reject the whole message, or is it just telling me that it didn't do the commands?
[15:46] <maco> check the bug page and compare?
[15:46] <james_w> maco, I would, but that doesn't allow me to complain about it :-)
[15:47] <james_w> plus it doesn't tell you which bug in the rejection message
[15:47] <james_w> so I have to go and find the bug that this particular mail went to
[15:47] <james_w> but yes, it indeed rejects the whole message
[15:47] <wgrant> In its defense, it was written about 6 years ago and never touched again.
[15:55] <exarkun> Should I re-ask https://answers.launchpad.net/launchpad/+question/149785 or is that question sufficient for the import to be re-done eventually?
[16:01] <timrc> We're experiencing some oddness with uploading a package to a Launchpad PPA… The package 'thunderbird-locales' was uploaded to a PPA yesterday evening with apparently no error (https://pastebin.canonical.com/45865/), but the package is neither showing up in Launchpad nor the PPA Sources index.
[16:01] <maxb> exarkun: A question in the Answered status will not get any more attention. You should definitely go into it and click the "Still need an answer" button (leaving an appropriate comment)
[16:02] <wgrant> exarkun: Sorry, I forgot that (because it was Answered). I'm asking an admin to do that now.
[16:02] <exarkun> maxb, wgrant: thanks
[16:03] <bigjools> timrc: the package was either not signed properly, or it had an error
[16:04] <maxb> timrc: The usual initial troubleshooting is: 1) Was the .changes upload control file properly PGP-signed? 2) Was the signing key associated with a Launchpad user? 3) Did that user receive an email with an error report?
[16:04] <bigjools> of the kind that causes a bug where LP doesn't reply to you
[16:04] <wgrant> timrc: That doesn't look like an upload...
[16:04] <wgrant> timrc: It looks like a copy from a private to a public PPA?
[16:05] <bigjools> ha and there's the problem
[16:05] <bigjools> "Already in ACCEPTED queue"
[16:06] <wgrant> Yes.
[16:06] <wgrant> Not sure why it's not being processed, though.
[16:07] <timrc> maxb: I think I misspoke, the action is pocket copy, not upload
[16:07] <wgrant> Although it's not a public PPA that is targetted to, so I can't investigate.
[16:08] <wgrant> bigjools: ^^ Can you check the details of that PU through the API?
[16:08] <bigjools> I could if I were not busy... :)
[16:08] <bigjools> feed me a script and I'll run it
[16:10] <wgrant> timrc: So, there's nothing in the Accepted queue. Is that script available somewhere? I suspect it's doing something wrong.
[16:13] <timrc> wgrant: it is… bzr branch lp:ubuntu-qa-tools … the tool used to copy is http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/view/head:/security-tools/unembargo
[16:13] <timrc> and this is the command line that was used: https://pastebin.canonical.com/45866/
[16:15] <wgrant> ... ah.
[16:16] <wgrant> timrc: The "Already in ACCEPTED queue" was printed the first time it was run?
[16:17] <timrc> wgrant: yah
[16:17] <wgrant> Well, that's printed by a misleading exception in the script.
[16:18] <wgrant> I suspect we want to try the copy again to get the real error message.
[16:21] <timrc> wgrant: it's there now after the engineer re-tried
[16:22] <wgrant> timrc: It worked this time?
[16:23] <timrc> wgrant: I think so, at least the source package is listed in the PPA on Launchpad
[16:23] <wgrant> Great.
[16:23] <timrc> Odd that it failed the first time
[16:24] <wgrant> Was it properly published in the primary archive by that point?
[16:28] <timrc> wgrant: I unfortunately cannot say for sure
[16:28] <timrc> wgrant: I'm inclined to say yes, as the package was initially overlooked, when populating this ppa of ours
[16:30] <wgrant> Hmm
[16:39] <wgrant> exarkun: Hi.
[16:39] <wgrant> exarkun: It's imported on *qa*staging, since that's going to be erased less quickly than staging. https://bugs.qastaging.launchpad.net/pyflakes
[16:41] <exarkun> wgrant: Thanks!
[16:42] <wgrant> exarkun: Sorry about the delay.
[18:49] <maxb> Hmm, something iffy is going on here. this import https://code.launchpad.net/~mirabilos/mksh/MAIN has both "Succeeded" but "not been imported yet"
[18:50] <maxb> It's as if the branch scanner isn't being fired
[18:54] <sinzui> indeed
[18:54] <sinzui> oh, it is ext
[18:55] <sinzui> maxb: I did not think Lp supported ext
[18:55] <maxb> Why shouldn't it?
[18:55] <maxb> It's just another CVS access method
[18:58] <sinzui> maxb: There is a note on one of our wiki pages that ext and extshh  are not suported: https://help.launchpad.net/VcsImportRequests
[18:58] <maxb> ZOMG that's very out of date
[18:59] <maxb> and completely unreferenced from the *other* code imports documentation on the wiki
[19:00] <maxb> sinzui: Hmm. Well, as you can see from the logs of that import, CSCVS seems happy with :ext: now.
[19:01] <sinzui> I agree
[19:01] <sinzui> This only needed a losa to accept a the key right?
[19:01] <maxb> yes
[19:02] <maxb> hm
[19:02] <maxb> Where do code imports hide their bzr repository until they succeed properly for the first time?
[19:03] <sinzui> I have no idea
[19:03] <maxb> No such file: '/srv/bazaar.launchpad.net/mirrors/00/05/82/1c'
[19:03] <maxb> ^ What I get trying to hitchhiker to the branch
[20:54] <bjf> how would the LP team like us to report "timeout" issues? LP seems to have been getting quite a bit better of late and then we've hit a bunch of timeouts today
[20:54] <bjf> if we pop in here and let you know, is that best, or is there another way you'd like us to let you know ?
[20:55] <bjf> this is for future reference, i'll let the rest of the team know
[20:57] <sinzui> bjf: The timeout may already be reported as a bug
[20:57] <sinzui> https://bugs.launchpad.net/launchpad/+bugs?field.tag=timeout
[20:59] <bjf> sinzui, thanks
[21:05] <lifeless> bjf: if a specific thing is stopping you working, pop in here and ask for help.
[21:05] <lifeless> bjf: if it times out and gives an OOPS code, we code about it
[21:05] <lifeless> bjf:  if it times out and *does not* give an OOPS code, we don't know about it
[21:05] <lifeless> s/we code/we know/
[21:06] <bjf> lifeless, thanks, looks like you already quite a list your dealing with, but i'll pass that along
[21:20] <exarkun> Can I stop getting email about bugs like https://bugs.launchpad.net/ubuntu/+source/twisted/+bug/754984
[21:24] <lifeless> sure
[21:24] <lifeless> exarkun: twisted-dev is subscribed to that package
[21:24] <exarkun> Which package?
[21:25] <lifeless> https://bugs.launchpad.net/ubuntu/+source/twisted
[21:25] <lifeless> you should have an unsubscribed link on that page on the right hand side
[21:25] <exarkun> But the bug isn't in that package, it's merely incorrectly filed against it.
[21:25] <exarkun> I don't mind getting email about bugs in Twisted.
[21:26] <exarkun> I only have a "Subscribe" link on that page, anyway, not an "Unsubscribe"
[21:26] <lifeless> hmm
[21:27] <lifeless> ok, so you want apport to not file bugs on twistd when a tap file is execute unless the tap file is also in [a] twisted package
[21:27] <exarkun> That sounds like a reasonable thing to try, yes
[21:28] <lifeless> exarkun: Could you file a bug on apport describing this? I'm sure pitti will have some thoughts on doing it
[21:28] <exarkun> Okay
[21:45] <james_w> it's already handled for e.g. python
[21:59] <lifeless> james_w: the python catchall except handler which is what apport patches does the filtering itself to handle unpackaged programs
[22:00] <lifeless> james_w: this is slightly different in that we need to select the right package based on the tap
[22:00] <lifeless> it may be a small matter of code
[22:38] <james_w> lifeless, apport handles interpreters in a similar way to what is desired for twistd, if the executable is /bin/sh then it tries to determine the package from /proc/cmdline
[22:40] <lifeless> james_w: yes, I know - I wrote that code
[22:41] <lifeless> (not the /bin/sh case specifically)
[22:41] <lifeless> I don't think its a large problem, but I suspect it will need a little glue because its coming in via the python top level except handler not the segfault handler
[22:42] <james_w> but the code that handles interpreters is in apport when it processes the report
[22:42] <lifeless> its interpreting the dump dict
[22:42] <lifeless> thats not always completely lined up because of the different dumpers involved
[22:42] <lifeless> if that makes sense
[22:44] <lifeless> james_w: I'm sure its a small matter of code; I don't know why we're pseudo debating
[22:44] <lifeless> james_w: clearly its not doing whats desired now, and some [small] tweak is needed to make it do it
[22:44] <james_w> sure
[22:45] <james_w> but you appeared to try and correct me on something I didn't say
[22:46] <lifeless> I thought you were saying its not a bug
[22:46] <lifeless> I was trying to explain why I think it is a bug
[22:46] <james_w> I agree it's a bug
[22:47] <james_w> I was just trying to communicate that there is analogous code already present, as I hadn't seen an indication that you knew that from what was said, and I didn't realise you had written the code
[22:49] <lifeless> heh :)
[22:49] <lifeless> I wanted to add in perl support like the python interpreter support at one point
[22:49] <lifeless> turned out way too hard :(
[22:52] <lifeless> I should talk to allison about that for parrot
[23:47] <Andre_Gondim> what can I do with this error Error ID: OOPS-1924B1588
[23:57] <lifeless> hi
[23:57] <lifeless> I'll just trigger a sync so we can see