[01:18] <mick_laptop> danilos: you in?
[01:18] <wgrant> mick_laptop: Unlikely at this hour.
[01:19] <mick_laptop> ah ok
[05:03] <jmarsden> What is the expected delay time when requesting an import of code into LP/bzr from git?  Minutes?  Hours?  Days?
[05:06] <wgrant> jmarsden: Your two should start within a few minutes. I'm not sure how big they are.
[05:06] <jmarsden> Smallish.  Thanks!
[05:06] <wgrant> jmarsden: There's a bit more load than usual at the moment, due to some fixes last week that mean more are working, so there's a bit of catching up to do.
[05:17] <wgrant> jmarsden: It may be a little while longer than I thought. There's still a backlog of around 200 imports (but it was 3k a couple of days ago, so it's just about caught up)
[05:17] <jmarsden> wgrant: Ah, OK :)  Sounds like I should find something else to do for a while :)
[05:18] <wgrant> jmarsden: The actual import should take less than a minute.
[05:19] <jmarsden> wgrant: So... 200 minutes to go before I get my turn, maybe?
[05:20] <wgrant> jmarsden: Not quite. One is running now.
[05:20] <jmarsden> Hmmm, looks like it just did something to one of them :)
[05:20] <wgrant> Although it's on an old slow machine :(
[05:20] <wgrant> Oh, and one's done already.
[05:20] <wgrant> And indeed took 40s.
[05:20] <wgrant> And the other is just finishing up.
[05:21] <jmarsden> Great.  I
[05:21] <StevenK> So the answer is "Minutes"
[05:21] <jmarsden> I'm hoping to make daily build packages for these so we get more testers of the code before an upstream source code release.
[05:23] <wgrant> jmarsden: Great! That's the purpose of daily builds :)
[05:24] <jmarsden> I would have tried this sooner, but I only realized the git-to-bzr import thing is what I needed today; I created a recipe before, but for a project where the sources were already in LP bzr...
[09:41] <Laney> is the syncSource method still not turned on?
[09:42] <Laney> (for the likes of me)
[09:48] <wgrant> Laney: For the Ubuntu primary archive? No.
[09:48] <wgrant> Laney: Copying into there is a much more difficult ordeal that PPA copying, due to overrides and announcements and queues and permissions. But it's just being finished up now.
[09:49] <bigjools> it's being done for derivatives syncing first
[09:55] <geser> I've read "derivatives" several times already but still have no idea what whose are in this context. "forks" of Ubuntu?
[10:10] <jmarsden> geser: https://wiki.ubuntu.com/DerivativeTeam/Derivatives
[10:13] <Laney> wgrant: Yeah, OK. I just looked at the devel API docs and saw it there — prompted by the localpackagediffs enablement. Maybe it's been there for ages.
[10:14] <wgrant> Laney: It's been there since 2008. It's used between PPAs and by the security team.
[10:14] <Laney> fair
[10:14] <wgrant> Laney: That page will have a sync button soon.
[10:14] <Laney> I saw the sync button on the dogfood version :-)
[10:14] <wgrant> Well, it does already, but it's not enabled yet. Announcements/permissions/overrides/timeouts aren't quite sorted yet.
[10:46] <bigjools> jmarsden: that is not a derivative in the same sense.  We're talking derivatives like Ubuntu is a derivative of Debian.
[11:20] <persia> bigjools: Many of the things listed on that page fall into that category (e.g. Fluxbuntu, Nexenta, Mint, Mepis).
[11:21] <bigjools> persia: ?
[11:22]  * persia fails at timestamps: https://wiki.ubuntu.com/DerivativeTeam/Derivatives vs. LP derivatives.  The ones I listed *could* be LP derivatives, if that was present in the past (at least Nexenta would surely have been so)
[11:23] <bigjools> ok
[11:24] <persia> Sorry: it all would have made more sense had I posted 30 minutes earlier.
[11:31] <henninge> maxb: Hi!
[11:31] <maxb> Hi henninge
[11:31] <henninge> maxb: I have a question about https://answers.launchpad.net/launchpad/+question/161575
[11:32] <henninge> maxb: The project he mentions seems to be gone. Do you know if anybody took already action?
[11:32] <maxb> afk ~15mins rightnow, will look after
[11:32] <henninge> maxb: ok, thanks
[11:32] <geser> bigjools: are there any LP derivatives currently?
[11:33] <bigjools> geser: Ubuntu!
[11:33] <wgrant> henninge: pantheon-desktop, not panthon-desktop
[11:33] <henninge> ah, theses little things
[11:33] <henninge> thanks wgrant
[11:37] <geser> bigjools: if Ubuntu is a LP derivative how does this match that LP derivates get syncSource sooner that the Ubuntu main archive? where did I misunderstood something?
[11:38] <bigjools> geser: syncSource is nothing to do with derivatives
[11:38] <bigjools> we've added a way of syncing between derivatives
[11:38] <bigjools> at some point I will make syncSource also use that way so that people can push PPA packages into the Ubuntu queue.
[11:39] <geser> ah
[11:39] <wgrant> (if the current syncSource backend still exists in 12 months I will be rather sad)
[11:40] <bigjools> geser: the upshot, though, is that the actual package copy will get done asynchronously
[11:40] <henninge> maxb: nm, it's solved
[11:40] <bigjools> right now the call returns when the synchronous copy is finished
[11:41] <bigjools> so it's a bit of a change for clients to deal with
[11:42] <wgrant> bigjools: We should probably leave the synchronous API there -- it can be changed to fire off a job and then await completion.
[11:42] <wgrant> Assuming we have a message queue...
[11:42] <bigjools> wgrant: no no no
[11:42] <bigjools> that will hold webapp threads open
[11:43] <bigjools> it needs some thought if you want that kind of api
[11:43] <wgrant> Yes.
[11:43] <wgrant> But we have to be careful if we are going to break stuff :)
[11:43] <bigjools> sometimes you gotta break some eggs
[11:57] <maxb> bigjools: making syncSource asynchronous WILL break lots of API scripts
[11:58] <maxb> So, please don't :-)
[11:58] <bigjools> maxb: exactly.  But at the same time when people whinge at me for it timing out, this is the solution :)
[11:59] <maxb> People wanting to copy 1 source from one PPA to another PPA feels like a pretty common operation, and having success/failure notification is important
[12:00] <bigjools> yes
[12:00] <bigjools> it's why I've not enabled any of it yet
[12:01] <maxb> henninge-lunch: Re "If you want to get rid of it, please turn it over (i.e. change the owner) to registry." - he won't be able to see the project any more, since it is deactivated
[12:01] <henninge-lunch> maxb: oh, I forgot about that
[12:28] <Quintasan> maxb: ping
[12:28] <maxb> pong
[12:28] <Quintasan> maxb: https://code.launchpad.net/~telepathy-kde/telepathy-kde/debian-telepathy-kde-accounts-kcm
[12:28] <Quintasan> Any idea what's wrong with that?
[12:39] <maxb> Quintasan: Leading space on the URL :-)  Fixed.
[12:39] <Quintasan> maxb: :O Thanks!
[12:48] <RAOF> Hm.  I've just got an odd rejection email from launchpad claiming I uploaded mesa/7.10.3-0ubuntu1 to the “guido-iodice-kernel-and-driver” PPA.  I'm quite certain I did not.
[12:49] <bigjools> StevenK:
[12:49] <bigjools> ^^ oops
[12:49] <bigjools> RAOF: someone else reported that bug the other day
[12:49] <wgrant> RAOF: Are you mentioned in changed-by?
[12:50] <RAOF> I uploaded the package to oneiric?
[12:51] <RAOF> Might this be triggered by someone trying to copy that package to their natty PPA?
[12:51] <RAOF> Full email is: http://paste.ubuntu.com/627920
[12:51] <bigjools> yeah probably
[12:51] <wgrant> RAOF: Ah, that's a build.
[12:51] <wgrant> RAOF: Someone copied without binaries, then quickly deleted it while the build was still going.
[12:52] <bigjools> this is the bug that steve fixed I think?
[12:52] <wgrant> This is indeed a StevenK bug.
[12:52] <RAOF> Oh, yeah.  Should have noticed the _i386.changes.
[12:52] <bigjools> or a new one?
[12:52] <wgrant> bigjools: This was introduced by the refactor.
[12:52] <wgrant> bigjools: It's meant to result in a failedtoupload build.
[12:52] <wgrant> Instead an email was sent about the upload...
[12:52] <bigjools> yep - but he fixed something to do with BFN the other day
[12:52] <wgrant> Not sure why.
[12:53] <Quintasan> maxb: bzr dailydeb still does not work with source format 3.0 quitl?
[12:53] <wgrant> He fixed something about empty recipient lists.
[12:53] <wgrant> Or was there something else?
[12:53] <bigjools> ah that was it
[12:53] <wgrant> RAOF: Could you file a bug?
[12:54] <maxb> Quintasan: I'm unaware of anything significant changing in that recently - you want to talk to james_w if you want a forecast of what will happen in the future regarding that
[12:54] <Quintasan> Oh, I see
[12:54] <maxb> New enough versions may, however, force the format to 3.0 (native) if doing so would avoid a build failure
[12:55]  * Quintasan doesnt like taking upstream work and branching it just to change source format to native
[12:56] <maxb> Quintasan: Actually, it must just work now, because we're not maintaining any of that sort of branch for the bzr daily ppa
[12:58] <adeuring> henninge: ^^^
[13:01] <henninge> adeuring: Thanks
[13:08] <wgrant> Daviey: Hi.
[13:08] <Daviey> wgrant: Hello!
[13:09] <wgrant> Daviey: "The current autogenerated diff per source package doesn't cut it for merges, as it includes the Debian changes.  I want to view just what the merge delta was."
[13:09] <wgrant> Daviey: +localpackagediffs provides diffs from base->debian and base->ubuntu. Is that not sufficient?
[13:09] <Daviey> wgrant: where base is current archive package?
[13:10] <wgrant> Daviey: No, the last common ancestor.
[13:10] <wgrant> eg. assuming we have 1.2-3ubuntu1 in Ubuntu and 1.2-4 in Debian, it will diff between 1.2-3 and each of those.
[13:10] <wgrant> So you can see the changes that were made by each distro.
[13:13] <Daviey> wgrant: Hmm, let me have another poke.
[13:14] <Daviey> wgrant: I think that is exactly what i want :)
[13:14] <Daviey> just waiting for the diffs to generate.
[13:15] <wgrant> The cron job is not quite optimally fast yet.
[13:15] <Daviey> hmm.. seems to require request per package to generate the diff, no?
[13:15] <StevenK> Yes, it does.
[13:15] <StevenK> The diffs can be quite large
[13:16] <Daviey> understood.
[13:16] <Daviey> So will it be possible for me to say, generate a diff for a Lucid merge that happend?
[13:18] <Daviey> As in, is it a oneiric and future thing.. or retrospective aswell?
[13:18] <Daviey> and posible to view delta from the common base of various uploads, rather then just current archive?
[13:18] <Daviey> Also, can i have a moon on a stick please? :)
[13:19] <Daviey> Honestly tho, I am really rather impressed with what has been done so far.
[13:19] <Daviey> Eventually, i'll be deprecated with a script.
[14:53] <Daviey> ScottK: Do you realise your discussion on ubuntu-devel regaridng the new diff feature sound awfully like, "This is shit, don't bother"?
[14:54] <Daviey> I hope/suspect that isn't the intention, but I did get that taste from it.
[14:55] <ScottK> Daviey: From the perspective of a MoM replacement it's currently completely inadequate and that's immediately obvious to the most casual observer.  I don't think the focus of the work was to replace MoM, so this isn't surprising.
[14:55] <ScottK> So I'd say 'it doesn't do this thing it wasn't meant to do' was what I was getting across.
[14:56] <ScottK> The problem isn't the page, but the email suggesting that would be a good place to leave comments about pending merges.
[14:56] <ScottK> If it's desirable for LP to replace MoM in some way then I think it's good to have a discussion about what the requirements are.
[14:57] <Daviey> ScottK: it's clearly work in process, and a first cut.
[14:57] <ScottK> That discussion needs to be more than "ScottK files bugs."
[14:57] <Daviey> ScottK: agreed, but leaving a taste of "why bother, it's useless" is not exactly motivating.
[14:57] <bigjools> :/
[14:58] <Daviey> ScottK: I agree a discussion is useful, but i don't feel you did that.
[14:58] <ScottK> If there was a 'why bother' in my reply it was why should I bother to file bugs about what it doesn't do that MoM does since it's pretty obvious.
[14:58] <Daviey> I also agree that filing bugs is not necessarily the correct solution to have a generic discussion tho.
[14:58] <Daviey> ScottK: then why not just not enter the discussion?
[14:59] <Daviey> This conversation feels like Deja vu.
[14:59] <ScottK> I'm not aware there is one.  The only response from anyone on the LP team was that I should file bugs.
[15:00] <bigjools> the intention was to make something useful for OEMs and Linaro
[15:00] <ScottK> When I tested this feature at UDS the context was about providing tools to allow people to drive their own syncs.  Being a MoM replacement wasn't discussed, IIRC.
[15:01] <ScottK> bigjools: Right, so I think it's not at all surprising it doesn't do something it wasn't meant to do.
[15:01] <bigjools> there's clearly a lot of work to do to replace MoM
[15:01] <spiv> Daviey: If the suggestion/implication from the start of the thread to leave comments on that page rather than on MoM was misguided or premature in ScottK's view, then it seems reasonable for him to say so.
[15:01] <bigjools> but I intend to supersede MoM at some point
[15:02] <ScottK> OK.  Then I think we ought to have a requirements discussion about that for some future (I assume) LEP.
[15:02] <bigjools> yup
[15:02] <Daviey> spiv: Well yes. I agree with that.. but he didn't question IF it was supposed to be a MoM replacement or not?  So surely that goal was not achieved.
[15:03] <Daviey> All i am trying to suggest is, that i felt demotivating reading that mail - and i'm not even a LP developer :)
[15:03] <spiv> Daviey: well, not demotivating valuable contributors like ScottK is important too :)
[15:04] <spiv> Daviey: I see what you mean, although my reading of those posts was less harsh than yours I think.
[15:04] <Daviey> spiv: ok, great - if i see WIP that is incomplete.. i'll let you know that it is crap.  Please can we have dak back please?
[15:05] <ScottK> Daviey: I think you're over-reacting.
[15:05] <ScottK> It's a start.
[15:05] <ScottK> Once the sync button is there it'll be a REALLY useful start for Ubuntu.
[15:28] <bigjools> ScottK: who can moderate my messages to ubuntu-devel?
[15:29] <ScottK> I'm not sure who all can, but cjwatson is one that I know can do it.
[15:29] <bigjools> ok thanks
[15:29] <ScottK> you're welcome.
[15:29] <Daviey> i can.
[15:30] <bigjools> ah ok thanks
[15:30] <apw> anyone know if you can have more than one "Release URL Pattern" for a project?  for the kernel -rcN's are dropped in a differnt place to main releases and i'd like to include both
[15:30] <Daviey> bigjools: approved
[15:30] <bigjools> Daviey: permanently? :)
[15:30] <bigjools> I might have to reply a few times
[15:31] <Daviey> bigjools: Sorry, i can't do that :(
[15:32] <bigjools> oh well
[15:32] <bigjools> Daviey: so how much of the diff stuff on your email to -devel is relevant after the earlier conversation on here?
[15:33] <nigelb> bigjools: cjwatson has the power to do that :)
[15:33] <bigjools> ah
[15:33]  * nigelb has been approved before
[15:34] <bigjools> Daviey: packagesets are done BTW, just waiting for a rollout
[15:34] <Daviey> bigjools: Being able to have historic diff data is useful.. might be out of scope?
[15:34] <Daviey> nigelb: bigjools was asking about blanket whitelisting
[15:35] <nigelb> Daviey: yes, that's what I meant.
[15:35] <bigjools> Daviey: historic debdiff or version diffs?
[15:35] <nigelb> Daviey: I've been blanket whitelisted I believe.
[15:35] <Daviey> oh.
[15:35] <nigelb> This was when I did have to mail devel frequently.
[15:36] <nigelb> But then, I sent a few mails and then got whitelisted
[16:53] <persia> What's the difference between an "ignored" package and a "non-ignored" package on the distroseries derivations page?
[17:57] <tumbleweed> any way to link bugs to specifications via the API? Looks like the UI way isn't AJAX, and $spec.bugs_collection is read-only according to the API docs
[18:00] <SudoKing> k so i meant to delete my signature w/ key from ubuntu code of conduct so I could sign it again w/ a new key and clicked deactivate... i don't seem to be able to sign it again
[18:02] <SudoKing> I think I figured it out :)
[19:25] <abentley> tumbleweed: I don't think there's a way at the moment.
[19:26] <tumbleweed> abentley: thanks for confirming that