=== paissad_ is now known as paissad === wgrant_ is now known as wgrant [04:14] Does anyone know the current status of the idea of automatically generating candidate branches from attached patches (if they apply cleanly)? [04:16] persia: i think the current status is "hey, that's a good idea, someone should do that" [04:17] mwhudson: Aha. What's required to do it? Are there infrastructure limitations? [04:17] persia: not particularly, i guess [04:17] 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] it wouldn't be a click and you're done by the next page load [04:18] argh [04:18] Why not deprecate attaching patches? [04:18] it wouldn't be a 'click and you're done by the next page load' type thing [04:20] 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] 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] persia: yeah, though i'd hope it would run way more often than hourly [04:22] 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] How often can that class of jobs run? [04:22] Ideally, yes. [04:22] (when you can sensibly find a trunk branch anyway) [04:22] persia: up to once a minute with current infrastructure i guess [04:22] Well, I'm narrowly interested in Ubuntu, where we usually have a known branch for the source package affected by the bug. [04:23] once a minute is close enough to realtime that I'm unlikely to notice. [04:23] you might both be interested in a proposal to have an 'import patch' in bzrlib [04:24] persia: i guess you should explain your requirements to the Launchpad Product Strategist :-) [04:24] 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] which would do useful things for this discussion [04:24] unfortunately i think he's getting drunk at pycon right now [04:24] lifeless: Very much so, to the degree that I think it's not worth implementing in LP until that feature is available. [04:24] mwhudson: who is the "Launchpad Product Strategist"? [04:24] jml: [04:25] lifeless: Any idea when "import patch" might be implemented? [04:25] nope [04:25] had the idea today [04:25] heh. [04:25] Is it easy and just needs time, or deep? [04:25] persia: yeah, it's jml [04:25] persia: easy, you could do it [04:26] I might well take a look at that after chatting with jml then. [04:26] doing it the 'best' way probably needs some bzrlib fluency. I wouldn't block on doing something launchpad for htis feature [04:26] in lp, 'bzr patch' is probably enough, for a first approximation. [04:27] Indeed, and optimisation can come later. I'm just looking for a good solution to bug #179857 now that we have sufficient infrastructure. [04:27] Launchpad bug 179857 in malone "Package sponsorships involve awkward bugtracker machinations" [Low,Triaged] https://launchpad.net/bugs/179857 [04:28] And I'm guessing there are some similar, related workflows that could be enabled using the same job. [04:31] 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] 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] It's so old that there's a wiki page about it on launchpad.canonical.com. [04:32] https://blueprints.edge.launchpad.net/soyuz/+spec/native-source-syncing is the spec. [04:32] I think there are bugs too. [04:33] mwhudson: Could you review that spec page, and if possible, expose it somewhere? [04:33] "stage-one is already released in soyuz production" is a promising comment, if old. [04:33] That more than likely refers to the pocket copy functionality. [04:34] Most of the code is already in place, and is used by the security team for all security updates. [04:34] persia: native-source-syncing? [04:34] How much more effort would it be to expose it in the API? [04:34] * persia isn't concerned about UI [04:34] persia: It is already. [04:34] mwhudson: Yes, please. [04:34] The problem is permissions. [04:34] wgrant: Could you elaborate? [04:34] persia: talking to wgrant is much more likely to be useful than talking to me :-) [04:34] And a couple of other things, which the spec probably covers. [04:35] oh i see, i can copy the wiki page onto dev.lp.net [04:35] mwhudson: The issue is that neither wgrant or I can *read* the spec, whereas I suspect you can :) [04:35] persia: Archive.syncSource is the API in question. [04:35] mwhudson: Thanks :) [04:35] persia: It allows one to copy a source from one archive to another. [04:35] And there happens to be an import of all Debian sources in LP. [04:35] This is not a coincidence. [04:35] So, what is the permissions issue? [04:36] It doesn't know about sub-archive permissions. [04:36] persia, wgrant: https://dev.launchpad.net/Soyuz/NativeSourceSyncing [04:36] I think a sync isn't quite a copy of the debian sources; still need the maintainer manglement, don't we ? [04:36] lifeless: We don't mangle unmodified sources. Just modified sources and binarie.s [04:37] We do mangle Changed-By, but that is probably a bug. [04:37] warning: last change to this spec was 2007-05-31 [04:37] And we also mangle the changelog. [04:37] lifeless: No, we need Origin: mangling. ubuntu-dev-scripts has a script that works, but wastes bandwidth. [04:37] * wgrant reads. [04:38] persia: Where is Origin exposed? [04:38] wgrant: It's in the .changes files. [04:38] Right. We don't seem to store it anywhere. [04:39] The first two implementation stages of that spec have been implemented, but the others have not. [04:40] wgrant: So, what is needed for stage3? And how does this meaningfully differ from stage4? [04:41] Oh, also, syncSource skips the queue at the moment. [04:41] persia: stage3 is harder than stage4. I would have swapped them. [04:41] Since 3 needs version mangling. [04:41] Aha!. [04:41] So, what's missing for stage4 then, if we skip stage3? [04:41] * persia doesn't actually care about stage3 [04:42] https://dev.launchpad.net/VersionThreeDotO/Soyuz/Inputs mentions "Changelog repackaging for native source syncing" [04:43] I'm not entirely sure on what that means. [04:44] But it's probably something to do with including all the Debian changelog entries since the last Ubuntu upload. [04:44] Like we do in changes files now. [04:44] I think that someone is attempting to conflate the issue that LP-provided changelogs are wrong or useless with the sync stuff. [04:44] But Soyuz screws that up horribly anyway, so it's probably not much of a concern. [04:45] That's what I'd think. changelogs.ubuntu.com will end up with the correct data, which is exposed in update-manager [04:45] Right. [04:45] So, the blockers that I see: [04:45] So if we don't bother with changelog mangling, does it become trivial? [04:45] - syncSource permissions. [04:45] OK. How does this work? [04:45] - syncSource needs to go through the queue [04:46] It doesn't now? [04:46] No. [04:46] It just copies the package directly, skipping all the checks and overrides. [04:46] When copying from a private archive (say, the security PPA) it will respect overrides, but not the queue. [04:46] Ah. Is that required for any class of pocket-copy, or would it make sense to always queue-process? [04:47] It's unclear. [04:49] 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] Probably a combination of bigjools and key distro people. [04:50] Indeed, it would be good to get merges and syncs out of the damn bug tracker. [04:51] syncs, yes. [04:51] 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] (hence the query about automatic branch generation) [04:53] So, I guess to sort this I need bigjools and a senior archive-admin, and separately jml. [04:54] 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] Right. [04:54] persia: no problem, happy to help [04:56] Getting rid of uses of sync-source.py should make everybody happy. [05:49] 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] poolie: mwhudson is in the process of landing the branches need for this to work [05:50] poolie: I'm expecting that we should have this working for 10.02 [05:50] yay [05:50] poolie: there may be bugs :) [05:50] poolie: also, only for git imports right now [05:50] poolie: other fixes needed for svn and hg [05:50] by 'this' you mean 'do big imports in little steps so memory bugs dont blow up in our face' [05:51] lifeless: yes [05:51] lifeless: actually it is do all git imports in little steps [05:51] sure, I wasn't assuming you can tell big from small [05:51] lifeless: weren't you finished for the day? [05:51] :) [05:52] 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] 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] kamalmostafa: Something has broken, and new builds are not being dispatched at the moment. [07:23] 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] (note, however, that most of the 500 builds in the i386 queue are language packs, so will build quickly and after yours) [07:24] 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] kamalmostafa: It's unlikely, but we'll find out when somebody with access to logs shows up. [07:36] jml: still around? [07:36] james_w: ping [07:43] 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] www.search2.net === jamesh_ is now known as jamesh === daniloff is now known as danilos [11:35] 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] Does that only require a LOSA? I thought it required special folk. [11:47] LOSAs are indeed insufficiently empowered. [11:47] 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] But there ought be some useful queue to submit this class of requests other than IRC> [11:53] it doesn't matter other than tying up a buildd [11:53] Yeah, but there's only 7 of them :) [11:53] Which means you'll run out in a week or so. [11:53] (never mind anyone else) [11:54] sure === jtv is now known as jtv-afk === mrevell is now known as mrevell-lunch === Ursinha-afk is now known as Ursinha === mrevell-lunch is now known as mrevell === jtv-afk is now known as jtv === matsubara is now known as matsubara-lunch [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] thumper, I am now. [15:20] has edge *just* rolled out? [15:22] no, just a really odd bug [15:51] He guys. [15:52] I was trying to play around with lp in the staging area. But it doesn't work. [16:01] timtierney: what happens? [16:04] It shows that "Please Try Again" message. === matsubara-lunch is now known as matsubara [16:25] Who could I contact about an inappropriate post to answers.launchpad.net/ubuntu? [16:32] nigelb: Its staging is working again. [16:32] timtierney: okay :) [16:32] ZykoticK9: ironically, you should open a question against launchpad [16:33] nigelb, that is both funny and sad all at the same time. Thanks though [16:35] 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] but the question should be opened anyway [16:35] https://answers.launchpad.net/ubuntu/+question/102018 [16:36] can one of the LP admins remove this offensive post ^^ [16:37] nigelb, thank you very much BTW [16:37] :) [16:56] Hi, i've found a little bug with the bug-status [16:57] i targeted a bug to a release [16:57] 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] sinzui, ^ ? [16:59] FloSoft`: I think someone form the bugs team can explain that: deryck: intellectronica? [17:00] 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] FloSoft`: it's new regardless of the status [17:01] but some statuses are considered 'close', and bugs in this status don't show in the list [17:01] or do you mean you get the status 'New'? [17:02] yes i get the status "New" in the mainproject, and in the bug it says "$project: tracked in $release" "$release - invalid" [17:03] FloSoft`: which bug? [17:03] i mean, what bug #? [17:04] 525797 - it is now shown as "In Progress" in the $project-buglist [17:04] but it should be "invalid" so not be shown anymore [17:04] oh sorry oops wrong nr 525185 [17:05] 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] no it was the right one, but i left it at in progress now [17:05] argh im confused *ggg [17:06] FloSoft`: it's 'Triaged', not 'Invalid' [17:06] oh right [17:06] FloSoft`: so what do you mean by $project-buglist? [17:07] in the "hot bugs" section [17:07] ZykoticK9: if it's abusive or spammy you can file a question and an admin will remove it [17:07] it was shown as new, even it was set to invalid [17:08] intellectronica, do you know specifically where to file the question? Simply in https://answers.launchpad.net/ubuntu or somewhere else? [17:08] FloSoft`: i don't see it in the hot bugs list [17:09] 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] intellectronica: i changed it to in progress, so its now shown as in progress [17:09] FloSoft`: what url are you looking at? [17:09] https://bugs.launchpad.net/s25rttr/ [17:10] FloSoft`: right. i'm looking at that page and the bug you mentioned isn't there [17:10] oh, of course, it might be because i'm looking at edge :-/ [17:10] ;-) [17:11] FloSoft`: so does https://bugs.edge.launchpad.net/s25rttr look better to you? :) === henninge is now known as henninge-afk === jamalta is now known as jamalta-afk === jamalta-afk is now known as jamalta [17:25] jml: Hey. I'd like to talk about making branches automatically from patches if you have some time. === jamalta is now known as jamalta-afk [17:27] persia, I don't right now -- next week? [17:27] Sure. When's good for you? [17:28] 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] (call as in decision, not as in telephony) === jamalta-afk is now known as jamalta [17:33] intellectronica: it looks very old ;) [17:35] FloSoft`: but does it look 'hot'? :) === ChanServ changed the topic of #launchpad to: http://launchpad.net | Read https://help.launchpad.net for help | Recent problems browsing branches should be fixed. | Help contact: - | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: see channel #launchpad-dev === mrevell is now known as mrevell-dinner === danilos is now known as daniloff [20:16] 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] pablohof1: take a look at this project: https://edge.launchpad.net/drobotik [20:19] Alternatively here is a minimal example: http://paste.ubuntu.com/381810/ [20:22] will try that - thanks maxb & micahg === matsubara is now known as matsubara-afk === Ursinha is now known as Ursinha-afk