=== Logan_ is now known as Guest83048 === Guest83048 is now known as Logan_ === dupondje_ is now known as dupondje === Spads_ is now known as Spads [10:08] 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] 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] and then we can get a list of all components from launchpadlib [10:09] but is there a better way? Can branches be tagged and we can then retrieve all branches with a tag, or something? [10:10] 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] 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] 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] aquarius: That's not possible. What's wrong with having people register their branch somewhere, like all other sites? [10:23] Automatically registering things is usually a pretty bad idea. [10:24] 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] Wouldn't you need a service anyway to distribute the list of branches? [10:24] 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] There is no way to do that. [10:25] And merge proposals will not work. [10:25] yeah, that's why I said merge proposals were stupid. :) [10:27] how were you intending to distribute the list, if not with a custom service? [10:28] 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] Oh, and that doesn't seem ideal for a client to be doing that directly. [10:29] teward: Staging doesn't send mail to the world at large, to avoid amusing disasters, but production should. [10:29] 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] Unless it queried every one of them, which would take more than a reasonable number of requests. [10:30] 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] Right. [10:32] 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] Yep, unless you want each query to take minutes. [10:33] making all the branches related to one tracker bug is better than merge proposals, although still a hack. [10:34] A pointless hack, since it still doesn't solve the metadata problem. [10:35] 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] something still needs to follow that link and cache the data, sure [10:35] but the fact that it is linked is stored in Launchpad rather than elsewhere [10:35] that means that the DB can be reconstituted from LP if the upstream service goes away [10:36] which is not the case if the fact that the things are linked is stored in the elsewhere service [10:37] Sure. Then it's a choice between backing up a trivial volume of data or a revolting hack :) [10:37] I'm not seeing any significant benefits in hacking bug linking or merge proposals rather than having a registration form. [10:37] And there are serious downsides. [10:38] this is why I asked about it rather than just doing it. [10:38] I was hoping for, I dunno, branch tags or similar, which don't exist. :) [10:40] Sadly not. [10:57] wgrant, cheers for the help :) [10:58] 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] the launchpad web UI will let me do it, but not, I think, programmatically. [11:02] "bzr cat" might work? [11:02] aquarius: Something like 'bzr cat lp:launchpad/lib/lp/registry/model/person.py' will work, but not terribly quickly. [11:02] heh [11:03] ooh, bzr cat works on lp urls? the help says it needs a filename. Nice. [11:03] not worried about speed; I only do it once. :) [11:03] What if it changes? [11:03] then they have to ping the service again and tell us that it changed. [11:04] Ah, right. [11:04] 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] It does not. [14:13] 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] how can I «fork» the repository in github terms, so I can upload only the difference and that create a merge-request? [14:22] you did fork when you branched it. push it and then create a merge proposal on the web site [14:27] 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] "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] Actually I think you need to resolve the lp: in the --stacked-on bit yourself, unfortunately [14:29] So "bzr push --stacked-on=bzr+ssh://bazaar.launchpad.net/~kicad-developers/kicad/doc lp:~fat-zer/kicad/doc" [14:35] 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] dobey: and how to create a remote branch where I can push to? [14:38] cjwatson: yep that seems done the trick... [14:38] cjwatson: thanks === nickoe_ is now known as nickoe [15:49] Error [15:49] Object: , name: u'clock-app' [15:50] error from where? [15:50] clock app is 'ubuntu-clock-app' [15:52] I got that when I posted a comment on bug 1388931 [15:52] bug 1388931 in Ubuntu Clock App "No setting for 12h or 24h clock format any more" [Medium,New] https://launchpad.net/bugs/1388931 [15:53] No idea why :-) [15:55] mpt: ah, probably because i originally filed the bug against clock-app, which is a deactivated project [15:56] Cool, so it [15:56] it’s a Launchpad ghost [15:56] yeah [16:15] mpt: i replied to your comment on that bug too. hopefully my suggestion makes sense and we can do that :) [16:29] Another symptom of the ghost project: when I click on ubot5’s link I get a 404 === JanC_ is now known as JanC [18:26] mpt: ugh [18:27] mpt: if you click https://launchpad.net/bugs/1388931 now, does it work right? [18:27] Launchpad bug 1388931 in Ubuntu Clock App "No setting for 12h or 24h clock format any more" [Medium,New] [18:28] 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] mpt: i cheated a bit, and deleted the clock-app task, so it /should/ be more reasonable now [18:36] cjwatson: wgrant: looks like the bug i filed about the email interface for bugs is invalid - didn't work yesterday, works today [21:43] mpt: You already reported that: bug #1278883 [21:43] bug 1278883 in Launchpad itself "Bug.default_bugtask should avoid inactive products where possible" [Low,Triaged] https://launchpad.net/bugs/1278883