[04:14] <persia> Does anyone know the current status of the idea of automatically generating candidate branches from attached patches (if they apply cleanly)?
[04:16] <mwhudson> persia: i think the current status is "hey, that's a good idea, someone should do that"
[04:17] <persia> mwhudson: Aha.  What's required to do it?  Are there infrastructure limitations?
[04:17] <mwhudson> persia: not particularly, i guess
[04:17] <mwhudson> it would a job like the one that processes emailed merge directives into branches and merge proposals
[04:18]  * persia experiences a parse failure
[04:18] <mwhudson> it wouldn't be a click and you're done by the next page load
[04:18] <mwhudson> argh
[04:18] <wgrant> Why not deprecate attaching patches?
[04:18] <mwhudson> it wouldn't be a 'click and you're done by the next page load' type thing
[04:20] <persia> wgrant: That requires lots more social work over the entirety of the community.  If we can automate patch->branch, we can stop treating patches as special.
[04:21] <persia> mwhudson: So something that ran, say, hourly, grabbed the patches, did lightweight branches of the code somewhere, applied the patch, attempted to commit, and either reported "patch application failure" or auto-submitted a merge proposal?
[04:21] <mwhudson> persia: yeah, though i'd hope it would run way more often than hourly
[04:22] <mwhudson> persia: i don't know how automated you'd want it, would you want to try to make branches out of all patches attached to all bugs?
[04:22] <persia> How often can that class of jobs run?
[04:22] <persia> Ideally, yes.
[04:22] <mwhudson> (when you can sensibly find a trunk branch anyway)
[04:22] <mwhudson> persia: up to once a minute with current infrastructure i guess
[04:22] <persia> Well, I'm narrowly interested in Ubuntu, where we usually have a known branch for the source package affected by the bug.
[04:23] <persia> once a minute is close enough to realtime that I'm unlikely to notice.
[04:23] <lifeless> you might both be interested in a proposal to have an 'import patch' in bzrlib
[04:24] <mwhudson> persia: i guess you should explain your requirements to the Launchpad Product Strategist :-)
[04:24] <persia> Ideally, I'd like a way to differentiate different classes of merge proposal, but that's something that can be handled separately (some Ubuntu patches represent code patches, and some represent candidate packages to be uploaded)
[04:24] <lifeless> which would do useful things for this discussion
[04:24] <mwhudson> unfortunately i think he's getting drunk at pycon right now
[04:24] <persia> lifeless: Very much so, to the degree that I think it's not worth implementing in LP until that feature is available.
[04:24] <persia> mwhudson: who is the "Launchpad Product Strategist"?
[04:24] <lifeless> jml:
[04:25] <persia> lifeless: Any idea when "import patch" might be implemented?
[04:25] <lifeless> nope
[04:25] <lifeless> had the idea today
[04:25] <persia> heh.
[04:25] <persia> Is it easy and just needs time, or deep?
[04:25] <mwhudson> persia: yeah, it's jml
[04:25] <lifeless> persia: easy, you could do it
[04:26] <persia> I might well take a look at that after chatting with jml then.
[04:26] <lifeless> doing it the 'best' way probably needs some bzrlib fluency. I wouldn't block on doing something launchpad for htis feature
[04:26] <lifeless> in lp, 'bzr patch' is probably enough, for a first approximation.
[04:27] <persia> Indeed, and optimisation can come later.  I'm just looking for a good solution to bug #179857 now that we have sufficient infrastructure.
[04:28] <persia> And I'm guessing there are some similar, related workflows that could be enabled using the same job.
[04:31] <persia> Next question: does anyone know if the bug has already been filed to allow anyone with upload access to a package in a distribution to sync that package from somewhere else (rather than relying on sync-source.py on a specific server)?
[04:31] <wgrant> Ah yes, good old native-source-syncing.
[04:31]  * persia doesn't see it from a quick search on malone and soyuz bugs.
[04:32] <wgrant> It's so old that there's a wiki page about it on launchpad.canonical.com.
[04:32] <wgrant> https://blueprints.edge.launchpad.net/soyuz/+spec/native-source-syncing is the spec.
[04:32] <wgrant> I think there are bugs too.
[04:33] <persia> mwhudson: Could you review that spec page, and if possible, expose it somewhere?
[04:33] <persia> "stage-one is already released in soyuz production" is a promising comment, if old.
[04:33] <wgrant> That more than likely refers to the pocket copy functionality.
[04:34] <wgrant> Most of the code is already in place, and is used by the security team for all security updates.
[04:34] <mwhudson> persia: native-source-syncing?
[04:34] <persia> How much more effort would it be to expose it in the API?
[04:34]  * persia isn't concerned about UI
[04:34] <wgrant> persia: It is already.
[04:34] <persia> mwhudson: Yes, please.
[04:34] <wgrant> The problem is permissions.
[04:34] <persia> wgrant: Could you elaborate?
[04:34] <mwhudson> persia: talking to wgrant is much more likely to be useful than talking to me :-)
[04:34] <wgrant> And a couple of other things, which the spec probably covers.
[04:35] <mwhudson> oh i see, i can copy the wiki page onto dev.lp.net
[04:35] <persia> mwhudson: The issue is that neither wgrant or I can *read* the spec, whereas I suspect you can :)
[04:35] <wgrant> persia: Archive.syncSource is the API in question.
[04:35] <persia> mwhudson: Thanks :)
[04:35] <wgrant> persia: It allows one to copy a source from one archive to another.
[04:35] <wgrant> And there happens to be an import of all Debian sources in LP.
[04:35] <wgrant> This is not a coincidence.
[04:35] <persia> So, what is the permissions issue?
[04:36] <wgrant> It doesn't know about sub-archive permissions.
[04:36] <mwhudson> persia, wgrant: https://dev.launchpad.net/Soyuz/NativeSourceSyncing
[04:36] <lifeless> I think a sync isn't quite a copy of the debian sources; still need the maintainer manglement, don't we ?
[04:36] <wgrant> lifeless: We don't mangle unmodified sources. Just modified sources and binarie.s
[04:37] <wgrant> We do mangle Changed-By, but that is probably a bug.
[04:37] <mwhudson> warning: last change to this spec was 2007-05-31
[04:37] <wgrant> And we also mangle the changelog.
[04:37] <persia> lifeless: No, we need Origin: mangling.  ubuntu-dev-scripts has a script that works, but wastes bandwidth.
[04:37]  * wgrant reads.
[04:38] <wgrant> persia: Where is Origin exposed?
[04:38] <persia> wgrant: It's in the .changes files.
[04:38] <wgrant> Right. We don't seem to store it anywhere.
[04:39] <wgrant> The first two implementation stages of that spec have been implemented, but the others have not.
[04:40] <persia> wgrant: So, what is needed for stage3?  And how does this meaningfully differ from stage4?
[04:41] <wgrant> Oh, also, syncSource skips the queue at the moment.
[04:41] <wgrant> persia: stage3 is harder than stage4. I would have swapped them.
[04:41] <wgrant> Since 3 needs version mangling.
[04:41] <persia> Aha!.
[04:41] <persia> So, what's missing for stage4 then, if we skip stage3?
[04:41]  * persia doesn't actually care about stage3
[04:42] <wgrant> https://dev.launchpad.net/VersionThreeDotO/Soyuz/Inputs mentions "Changelog repackaging for native source syncing"
[04:43] <wgrant> I'm not entirely sure on what that means.
[04:44] <wgrant> But it's probably something to do with including all the Debian changelog entries since the last Ubuntu upload.
[04:44] <wgrant> Like we do in changes files now.
[04:44] <persia> I think that someone is attempting to conflate the issue that LP-provided changelogs are wrong or useless with the sync stuff.
[04:44] <wgrant> But Soyuz screws that up horribly anyway, so it's probably not much of a concern.
[04:45] <persia> That's what I'd think.  changelogs.ubuntu.com will end up with the correct data, which is exposed in update-manager
[04:45] <wgrant> Right.
[04:45] <wgrant> So, the blockers that I see:
[04:45] <persia> So if we don't bother with changelog mangling, does it become trivial?
[04:45] <wgrant>  - syncSource permissions.
[04:45] <persia> OK.  How does this work?
[04:45] <wgrant>  - syncSource needs to go through the queue
[04:46] <persia> It doesn't now?
[04:46] <wgrant> No.
[04:46] <wgrant> It just copies the package directly, skipping all the checks and overrides.
[04:46] <wgrant> When copying from a private archive (say, the security PPA) it will respect overrides, but not the queue.
[04:46] <persia> Ah.  Is that required for any class of pocket-copy, or would it make sense to always queue-process?
[04:47] <wgrant> It's unclear.
[04:49] <persia> Who might know?
[04:49]  * persia is getting increasingly annoyed by special classes of bugs interfering with bug triager training, and feels we're close to a solution
[04:50] <wgrant> Probably a combination of bigjools and key distro people.
[04:50] <wgrant> Indeed, it would be good to get merges and syncs out of the damn bug tracker.
[04:51] <persia> syncs, yes.
[04:51] <persia> I don't mind merges so much, but I'd like to be able to just mark them "Triaged" and be done with it.
[04:51] <persia> (hence the query about automatic branch generation)
[04:53] <persia> So, I guess to sort this I need bigjools and a senior archive-admin, and separately jml.
[04:54] <persia> wgrant: mwhudson: Thanks a lot for the pointers.  I'm feeling much more confident about being able to solve this then I have in a long time.
[04:54] <wgrant> Right.
[04:54] <mwhudson> persia: no problem, happy to help
[04:56] <wgrant> Getting rid of uses of sync-source.py should make everybody happy.
[05:49] <poolie> thumper, hi, does the kernel git tree import correctly yet? or is it expected to in the next rollout, because of incremental imports?
[05:50] <thumper> poolie: mwhudson is in the process of landing the branches need for this to work
[05:50] <thumper> poolie: I'm expecting that we should have this working for 10.02
[05:50] <poolie> yay
[05:50] <thumper> poolie: there may be bugs :)
[05:50] <thumper> poolie: also, only for git imports right now
[05:50] <thumper> poolie: other fixes needed for svn and hg
[05:50] <lifeless> by 'this' you mean 'do big imports in little steps so memory bugs dont blow up in our face'
[05:51] <thumper> lifeless: yes
[05:51] <thumper> lifeless: actually it is do all git imports in little steps
[05:51] <lifeless> sure, I wasn't assuming you can tell big from small
[05:51] <thumper> lifeless: weren't you finished for the day?
[05:51] <thumper> :)
[05:52] <lifeless> I'm terrible at finishing.
[05:52]  * persia isn't convinced, given that finishing seems to happen several times a day for lifeless
[07:17] <kamalmostafa> hi launchpad folks -- is there a problem with the builders?  My package seems stuck:  https://launchpad.net/ubuntu/+source/libtifiles/1.1.2-0ubuntu2   and there are 500 jobs in the i386 queue and all the builders look idle
[07:23] <wgrant> kamalmostafa: Something has broken, and new builds are not being dispatched at the moment.
[07:23] <wgrant> I don't think there are any LOSAs around at the moment, so you may be waiting another couple of hours until London wakes up.
[07:24] <wgrant> (note, however, that most of the 500 builds in the i386 queue are language packs, so will build quickly and after yours)
[07:24] <kamalmostafa> wgrant: ok, thanks for the update.   i'm not in a big hurry, just making sure *my* package wasn't the cause of it!  ;-)
[07:25] <wgrant> kamalmostafa: It's unlikely, but we'll find out when somebody with access to logs shows up.
[07:36] <thumper> jml: still around?
[07:36] <thumper> james_w: ping
[07:43] <wgrant> kamalmostafa: The build dispatching problem has been identified. It's a bug that shows up occasionally that we really don't know the cause of.
[07:44] <Speedy2> www.search2.net
[11:35] <Laney> any LOSAs around? Please kill https://edge.launchpad.net/ubuntu/+source/ghc6/6.12.1-10/+build/1520317 and https://edge.launchpad.net/ubuntu/+source/ghc6/6.12.1-10/+build/1520318 — I suepect they are stuck, and anyway I am going to be uploadng a new revision soon.
[11:46] <persia> Does that only require a LOSA?  I thought it required special folk.
[11:47] <wgrant> LOSAs are indeed insufficiently empowered.
[11:47] <Laney> please redirect as appropriate :)
[11:52]  * persia suspects it's one magic person and hears rumours that said magic person is especially busy for a while
[11:52] <persia> But there ought be some useful queue to submit this class of requests other than IRC>
[11:53] <Laney> it doesn't matter other than tying up a buildd
[11:53] <persia> Yeah, but there's only 7 of them :)
[11:53] <persia> Which means you'll run out in a week or so.
[11:53] <persia> (never mind anyone else)
[11:54] <Laney> sure
[15:00]  * _UsUrPeR_ ti[s his hat
[15:00] <_UsUrPeR_> Hey all. I'm trying to file a bug that pertains to the mknbi package, but can't figure out what project it's attached to, or even if a project exists. Can somebody point me towards a project?
[15:00] <jml> thumper, I am now.
[15:20] <james_w> has edge *just* rolled out?
[15:22] <james_w> no, just a really odd bug
[15:51] <timtierney> He guys.
[15:52] <timtierney> I was trying to play around with lp in the staging area.  But it doesn't work.
[16:01] <nigelb> timtierney: what happens?
[16:04] <timtierney> It shows that "Please Try Again" message.
[16:25] <ZykoticK9> Who could I contact about an inappropriate post to answers.launchpad.net/ubuntu?
[16:32] <timtierney> nigelb: Its staging is working again.
[16:32] <nigelb> timtierney: okay :)
[16:32] <nigelb> ZykoticK9: ironically, you should open a question against launchpad
[16:33] <ZykoticK9> nigelb, that is both funny and sad all at the same time.  Thanks though
[16:35] <nigelb> ZykoticK9: hehe, you could post the link here and generally ask one of the Lp admins to look at it.  someone will take a look
[16:35] <nigelb> but the question should be opened anyway
[16:35] <ZykoticK9> https://answers.launchpad.net/ubuntu/+question/102018
[16:36] <nigelb> can one of the LP admins remove this offensive post ^^
[16:37] <ZykoticK9> nigelb, thank you very much BTW
[16:37] <nigelb> :)
[16:56] <FloSoft`> Hi, i've found a little bug with the bug-status
[16:57] <FloSoft`> i targeted a bug to a release
[16:57] <FloSoft`> changed it there to "invalid" - now the base project comes active again - then i changed the release-status to invalid, the base project gets "tracked in $release" again, but it will show up as "new" in the bug-list
[16:58] <mars> sinzui, ^ ?
[16:59] <sinzui> FloSoft`: I think someone form the bugs team can explain that: deryck: intellectronica?
[17:00] <FloSoft`> i now changed it to in progress and then again to invalid, now its not shown in the main project as new anymore
[17:00] <intellectronica> FloSoft`: it's new regardless of the status
[17:01] <intellectronica> but some statuses are considered 'close', and bugs in this status don't show in the list
[17:01] <intellectronica> or do you mean you get the status 'New'?
[17:02] <FloSoft`> yes i get the status "New" in the mainproject, and in the bug it says "$project: tracked in $release" "$release - invalid"
[17:03] <intellectronica> FloSoft`: which bug?
[17:03] <intellectronica> i mean, what bug #?
[17:04] <FloSoft`> 525797 - it is now shown as "In Progress" in the $project-buglist
[17:04] <FloSoft`> but it should be "invalid" so not be shown anymore
[17:04] <FloSoft`> oh sorry oops wrong nr 525185
[17:05] <ZykoticK9> 1 minute ago someone "Tom" added a novel to the bottom of https://answers.launchpad.net/ubuntu/+question/102018 -- can this still be removed?
[17:05] <FloSoft`> no it was the right one, but i left it at in progress now
[17:05] <FloSoft`> argh im confused *ggg
[17:06] <intellectronica> FloSoft`: it's 'Triaged', not 'Invalid'
[17:06] <intellectronica> oh right
[17:06] <intellectronica> FloSoft`: so what do you mean by $project-buglist?
[17:07] <FloSoft`> in the "hot bugs" section
[17:07] <intellectronica> ZykoticK9: if it's abusive or spammy you can file a question and an admin will remove it
[17:07] <FloSoft`> it was shown as new, even it was set to invalid
[17:08] <ZykoticK9> intellectronica, do you know specifically where to file the question?  Simply in https://answers.launchpad.net/ubuntu or somewhere else?
[17:08] <intellectronica> FloSoft`: i don't see it in the hot bugs list
[17:09] <intellectronica> ZykoticK9: hmmm ... usually we file such questions on the launchpad project. i don't know if there's a different procedure for ubuntu, but i think a question on launchpad will be a good start :)
[17:09] <FloSoft`> intellectronica: i changed it to in progress, so its now shown as in progress
[17:09] <intellectronica> FloSoft`: what url are you looking at?
[17:09] <FloSoft`> https://bugs.launchpad.net/s25rttr/
[17:10] <intellectronica> FloSoft`: right. i'm looking at that page and the bug you mentioned isn't there
[17:10] <intellectronica> oh, of course, it might be because i'm looking at edge :-/
[17:10] <FloSoft`> ;-)
[17:11] <intellectronica> FloSoft`: so does https://bugs.edge.launchpad.net/s25rttr look better to you? :)
[17:25] <persia> jml: Hey.  I'd like to talk about making branches automatically from patches if you have some time.
[17:27] <jml> persia, I don't right now -- next week?
[17:27] <persia> Sure.  When's good for you?
[17:28] <persia> Also, do you have time for a quick "Sure, sounds like it ought be done" / "That's going to have to be deferred for several cycles" call?
[17:28] <persia> (call as in decision, not as in telephony)
[17:33] <FloSoft`> intellectronica: it looks very old ;)
[17:35] <intellectronica> FloSoft`: but does it look 'hot'? :)
[20:16] <pablohof1> hi, is there any API for copying packages in the same PPA to different ubuntu series?. i want to upload my source package once and create copies for each distro (karmic, jaunty, intrepid) but i want to do it from a script, not using the copy packages UI.
[20:18] <micahg> pablohof1: take a look at this project: https://edge.launchpad.net/drobotik
[20:19] <maxb> Alternatively here is a minimal example: http://paste.ubuntu.com/381810/
[20:22] <pablohof1> will try that - thanks maxb & micahg