[10:08] <aquarius> Is there any way to find all LP branches which contain a particular file or similar? Later on today at UOS we're discussing the idea of an "Ubuntu touch component store"; something like pypi or npm for Ubuntu QML components, and we're trying to decide how to do the distribution of components. Using LP would be great.
[10:09] <aquarius> So what I thought was: anyone who wants to distribute a component creates an LP branch and puts an ubuntu_component_store.json file in it
[10:09] <aquarius> and then we can get a list of all components from launchpadlib
[10:09] <aquarius> but is there a better way? Can branches be tagged and we can then retrieve all branches with a tag, or something?
[10:10] <aquarius> I don't think I know enough here to know which questions to ask. But I'd like it to be fast, partially because that's a nicer user experience and partially to reduce load on launchpad!
[10:17] <aquarius> the idea here is that any person can put a branch of their code on LP, and then somehow get it into an automatically-generated list of "all components" without a person having to approve that change
[10:18] <aquarius> the best way I can think of to do that so far is for me to create an empty branch as a destination for merge proposals and then they propose a merge from their branch into that one (even though we have no intention of doing it); the list of components is therefore the list of merge proposals to my empty branch. But that's stupid.
[10:23] <wgrant> aquarius: That's not possible. What's wrong with having people register their branch somewhere, like all other sites?
[10:23] <wgrant> Automatically registering things is usually a pretty bad idea.
[10:24] <aquarius> wgrant, that's what I suggested, but the worry is that means building yet another service somewhere, finding somewhere to host it, etc, and others are not keen on it.
[10:24] <wgrant> Wouldn't you need a service anyway to distribute the list of branches?
[10:24] <aquarius> so I figured, for iteration 1, since all the code will be in LP *anyway*, it's worth exploring whether we can sensibly tag that code in LP.
[10:25] <wgrant> There is no way to do that.
[10:25] <wgrant> And merge proposals will not work.
[10:25] <aquarius> yeah, that's why I said merge proposals were stupid. :)
[10:27] <wgrant> how were you intending to distribute the list, if not with a custom service?
[10:28] <aquarius> use launchpadlib to, say, search for all branches with a "U-C-S" tag. But there is no such search, as you say
[10:28] <wgrant> Oh, and that doesn't seem ideal for a client to be doing that directly.
[10:29] <cjwatson> teward: Staging doesn't send mail to the world at large, to avoid amusing disasters, but production should.
[10:29] <wgrant> aquarius: I'm also not sure how it would be useful. A client could get a list of branches, but wouldn't know anything about what's in them.
[10:30] <wgrant> Unless it queried every one of them, which would take more than a reasonable number of requests.
[10:30] <aquarius> it obviously isn't long-term (and long-term the answer is clearly "build a service and host it somewhere"), but it might have been short-term. But you're right about metadata too; I can't get a list of what everything *is* without hitting every branch, which is a colossal no-no.
[10:31] <wgrant> Right.
[10:32] <aquarius> at *some* point we have to hit the branch and get metadata from it, but that only needs to happen if it changes, not every time someone queries.
[10:33] <wgrant> Yep, unless you want each query to take minutes.
[10:33] <aquarius> making all the branches related to one tracker bug is better than merge proposals, although still a hack.
[10:34] <wgrant> A pointless hack, since it still doesn't solve the metadata problem.
[10:35] <wgrant> You need a service either way, so it's a choice between "link the branch to this specific bug" and "enter the branch's name"
[10:35] <aquarius> something still needs to follow that link and cache the data, sure
[10:35] <aquarius> but the fact that it is linked is stored in Launchpad rather than elsewhere
[10:35] <aquarius> that means that the DB can be reconstituted from LP if the upstream service goes away
[10:36] <aquarius> which is not the case if the fact that the things are linked is stored in the elsewhere service
[10:37] <wgrant> Sure. Then it's a choice between backing up a trivial volume of data or a revolting hack :)
[10:37] <wgrant> I'm not seeing any significant benefits in hacking bug linking or merge proposals rather than having a registration form.
[10:37] <wgrant> And there are serious downsides.
[10:38] <aquarius> this is why I asked about it rather than just doing it.
[10:38] <aquarius> I was hoping for, I dunno, branch tags or similar, which don't exist. :)
[10:40] <wgrant> Sadly not.
[10:57] <aquarius> wgrant, cheers for the help :)
[10:58] <aquarius> hm, separate question, which is really a bzr question: can I fetch one file out of a bzr branch on LP without checking out the whole lot?
[11:01] <aquarius> the launchpad web UI will let me do it, but not, I think, programmatically.
[11:02] <Peng> "bzr cat" might work?
[11:02] <wgrant> aquarius: Something like 'bzr cat lp:launchpad/lib/lp/registry/model/person.py' will work, but not terribly quickly.
[11:02] <Peng> heh
[11:03] <aquarius> ooh, bzr cat works on lp urls? the help says it needs a filename. Nice.
[11:03] <aquarius> not worried about speed; I only do it once. :)
[11:03] <wgrant> What if it changes?
[11:03] <aquarius> then they have to ping the service again and tell us that it changed.
[11:04] <wgrant> Ah, right.
[11:04] <aquarius> unless LP has webhooks for when a new change is pushed to a file? Which I'm fairly sure it does not, but I'm happy to be surprised on this front :)
[11:09] <wgrant> It does not.
[14:13] <Fat-Zer_> Hi, I'm trying to contribute to lp:~kicad-developers/kicad/doc. I've bzr branch'ed the repository to localhost, edited and commited changes... now when I try to   bzr push lp:~fat-zer/kicad/doc the uploading process startes the pload from scratches.
[14:15] <Fat-Zer_> how can I «fork» the repository in github terms, so I can upload only the difference and that create a merge-request?
[14:22] <dobey> you did fork when you branched it. push it and then create a merge proposal on the web site
[14:27] <Fat-Zer_> dobey: when I do bzr push lp:~fat-zer/kicad/doc, It's starts to upload from the scratch: the counter states It uploaded over 20MB for a 2-line patch when I despaired and stopped it...
[14:28] <cjwatson> "bzr push --stacked-on=lp:~kicad-developers/kicad/doc lp:~fat-zer/kicad/doc" should help, I think, although you might have to delete what you've already pushed first
[14:28] <cjwatson> Actually I think you need to resolve the lp: in the --stacked-on bit yourself, unfortunately
[14:29] <cjwatson> So "bzr push --stacked-on=bzr+ssh://bazaar.launchpad.net/~kicad-developers/kicad/doc lp:~fat-zer/kicad/doc"
[14:35] <dobey> Fat-Zer_: yes, "bzr branch" doesn't create a remote branch, it pulls it locally, in the same way git clone pulls locally. there is no button on the web site to create a copy of a branch that you then pull from, like github has
[14:36] <Fat-Zer_> dobey: and how to create a remote branch where I can push to?
[14:38] <Fat-Zer_> cjwatson: yep that seems done the trick...
[14:38] <Fat-Zer_> cjwatson: thanks
[15:49] <mpt> Error
[15:49] <mpt> Object: <lp.systemhomes.WebServiceApplication object at 0x74ddf10>, name: u'clock-app'
[15:50] <dobey> error from where?
[15:50] <dobey> clock app is 'ubuntu-clock-app'
[15:52] <mpt> I got that when I posted a comment on bug 1388931
[15:53] <mpt> No idea why :-)
[15:55] <dobey> mpt: ah, probably because i originally filed the bug against clock-app, which is a deactivated project
[15:56] <mpt> Cool, so it
[15:56] <mpt> it’s a Launchpad ghost
[15:56] <dobey> yeah
[16:15] <dobey> mpt: i replied to your comment on that bug too. hopefully my suggestion makes sense and we can do that :)
[16:29] <mpt> Another symptom of the ghost project: when I click on ubot5’s link I get a 404
[18:26] <dobey> mpt: ugh
[18:27] <dobey> mpt: if you click https://launchpad.net/bugs/1388931 now, does it work right?
[18:28] <teward> cjwatson: wgrant: i see you both replied to the bug i filed - i'm going to send two known-to-be-invalid emails to edit@bugs to see if it generates the fail responses - one without GPG signature, anotheor with GPG signature but incomplete commands.  if they go through and work, then only two Karmic EOL bugs will be impacted.
[18:33] <dobey> mpt: i cheated a bit, and deleted the clock-app task, so it /should/ be more reasonable now
[18:36] <teward> cjwatson: wgrant: looks like the bug i filed about the email interface for bugs is invalid - didn't work yesterday, works today
[21:43] <wgrant> mpt: You already reported that: bug #1278883