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