[00:57] <ari-tczew> chrisccoulson: could you take a look on package syncevolution - whether can you merge, or is it sync?
[00:59] <chrisccoulson> ari-tczew, couldn't you make that judgement? syncevolution isn't something i work on, and i don't really have time to look at whether it can be sync'd or not
[01:00] <ari-tczew> chrisccoulson: upstream code has been changed a bit and I would get feedback from patch's author.
[01:00] <micahg> chrisccoulson: I think he was just asking you as the TIL person
[01:02] <chrisccoulson> i think the patch i wrote just renamed some functions to not clash with libc functions
[01:02] <chrisccoulson> you could just look at the new source and see if that's still needed, but i don't really have time to do that
[06:26] <micahg> so, backport requests with 3 rdepends, can we accept that with proper testing of the rdepends?
[06:28]  * ebroder is not authoritative, but has seen that happen before
[06:34] <micahg> can I get a sanity check on bug 674365, I want to post this response, but don't want to seem too harsh: http://pastebin.ubuntu.com/530522/
[08:13] <bilalakhtar> I will see you people on NEXT saturday as I go for Hajj
[08:13] <bilalakhtar> 20th november
[08:13] <bilalakhtar> bye!
[08:40] <dholbach> good morning!
[09:02] <quadrispro> hi dholbach !
[09:03] <dholbach> hey quadrispro
[09:11] <iulian> Morning dholbach, quadrispro.
[09:12] <quadrispro> hi iulian !
[09:12] <dholbach> hey iulian
[11:08] <ari-tczew> geser: could you comment something in main @sponsors-queue?
[11:09] <ari-tczew> I'm trying to reproduce a bug in sponsors overview
[13:09] <geser> ari-tczew: any specific bug? keep in mind that I'm an indirect member of some package set teams through DMB (e.g. ubuntu-desktop) and that the overview page is right that I can upload that package but I don't use this right
[13:18] <ScottK> micahg: With proper testing of rdepends it's ~OK (depends a bit on what it is).
[13:19] <ScottK> micahg: RE your bug comment, I'd add a "This kind of change should generally be made upstream" at the start, but otherwise I think it's good.
[13:21] <AnAnt> Hello
[15:33] <micahg> ScottK: is the testing of the rdepends something we can ask the requester of the backport to do?  The user has already done the backport of the package in the PPA?  bug 382591
[15:33] <ScottK> micahg: Yes.  Absolutely.
[15:33] <micahg> ScottK: ok, thanks
[15:34] <ScottK> It's a condition of getting the backport approved.  They can do it or not.  Their choice, but if they don't - no backport.
[15:36] <micahg> ScottK: I see on the backport documentation page that incomplete is for something not in the archive yet, should that be used as well when requesting information from a requestor?
[15:37] <ScottK> It should be used when requesting information too (just like a normal bug)
[19:14] <bcurtiswx> is there a way to test a build in pbuilder right after you build it ?
[19:30] <Daviey> Is someone free to sponsor a trivial Lucid SRU please?
[19:30] <ebroder> Daviey: For universe? Potentially
[19:30] <ebroder> What's the bug?
[19:31] <Daviey> bug #674645
[19:32] <Daviey> ebroder: ^^
[19:33] <ebroder> Looking
[19:33] <Daviey> thanks!
[19:33] <ebroder> Will you be able to handle the SRU write-up and verification and so forth?
[19:34] <ebroder> Actually, could you do an SRU write-up now before I sponsor?
[19:34] <kklimonda>  /b 13
[19:42] <ebroder> Daviey: ^^
[19:53] <Daviey> ebroder: I'm on it now
[19:53] <ebroder> Daviey: Great, thanks
[19:53] <ebroder> (Don't worry about blocking me; just let me know when you're done)
[20:37] <Daviey> ebroder: SRU paperwork done.
[20:48] <ebroder> Daviey: Thanks. I'll take a look in a second. Do you know what dannf is looking at with dnsmasq?
[20:53] <Daviey> ebroder: no idea, sorry
[20:53] <Daviey> ebroder: This one is "quite importiant" fwiw
[20:54] <ebroder> Daviey: Oh, ugh. I only looked at the dnsmasq binary package. Looks like the dnsmasq source package (and dnsmasq-base binary package) are in main, not universe, so I can't sponsor you
[20:54] <ebroder> Sorry for the mixup
[20:55] <Daviey> ebroder: sorry, i made that mistake aswell
[20:55] <Daviey> no worries
[20:55] <ebroder> If you want to move things forward at this point, proposing a merge proposal into lp:ubuntu/lucid/dnsmasq for your bzr branch would be the best thing to do
[20:55] <ebroder> It would also be nice if you could make a branch for maverick as well
[20:56] <Daviey> ebroder: i've got someone on it, thanks
[20:56] <micahg> ebroder: you know you can't merge into the stable branch, right?
[20:56] <Daviey> ebroder: yeah, lucid is my priority, with maverick a close second
[20:56] <ebroder> micahg: Yes, but unless there's been an SRU already, there's no -proposed branch to propose merging into
[20:57] <ebroder> Daviey: It's easier for everyone if you can prepare and merge-propose both branches at once
[20:57]  * micahg still thinks a merge proposal for a branch that can't be used is too much overhead
[20:58] <Daviey> ebroder: ack
[20:59] <ebroder> micahg: I think the workflow is that you branch lp:ubuntu/lucid/dnsmasq, merge-package the branch with the patch, then commit and push it to lp:ubuntu/lucid-proposed/dnsmasq. But I don't pretend to understand UDD. Or even plain old bzr for that matter
[20:59] <micahg> ebroder: you can't create a lucid-proposed branch AFAIK, hence the overhead
[21:00] <ebroder> Ah, ok. I do still like merge proposals from a sponsorship perspective, because they make it easier to see exactly what's being proposed right now, as opposed to debdiffs where there might be 3 or 4 different versions and a lot of discussion attached
[21:46] <ScottK> Funny.  I find merge proposals much more complex to deal with.
[21:46] <micahg> ScottK: me too