| === Logan_ is now known as Guest83048 | ||
| === Guest83048 is now known as Logan_ | ||
| === dupondje_ is now known as dupondje | ||
| === Spads_ is now known as Spads | ||
| 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:08 |
|---|---|---|
| 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:09 |
| 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:10 |
| 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:17 |
| 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:18 |
| 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:23 |
| 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:24 |
| 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:25 |
| wgrant | how were you intending to distribute the list, if not with a custom service? | 10:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| wgrant | Right. | 10:31 |
| 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:32 |
| 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:33 |
| wgrant | A pointless hack, since it still doesn't solve the metadata problem. | 10:34 |
| 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:35 |
| aquarius | which is not the case if the fact that the things are linked is stored in the elsewhere service | 10:36 |
| 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:37 |
| 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:38 |
| wgrant | Sadly not. | 10:40 |
| aquarius | wgrant, cheers for the help :) | 10:57 |
| 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? | 10:58 |
| aquarius | the launchpad web UI will let me do it, but not, I think, programmatically. | 11:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| wgrant | It does not. | 11:09 |
| 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:13 |
| 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:15 |
| dobey | you did fork when you branched it. push it and then create a merge proposal on the web site | 14:22 |
| 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:27 |
| 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:28 |
| cjwatson | So "bzr push --stacked-on=bzr+ssh://bazaar.launchpad.net/~kicad-developers/kicad/doc lp:~fat-zer/kicad/doc" | 14:29 |
| 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:35 |
| Fat-Zer_ | dobey: and how to create a remote branch where I can push to? | 14:36 |
| Fat-Zer_ | cjwatson: yep that seems done the trick... | 14:38 |
| Fat-Zer_ | cjwatson: thanks | 14:38 |
| === nickoe_ is now known as nickoe | ||
| mpt | Error | 15:49 |
| mpt | Object: <lp.systemhomes.WebServiceApplication object at 0x74ddf10>, name: u'clock-app' | 15:49 |
| dobey | error from where? | 15:50 |
| dobey | clock app is 'ubuntu-clock-app' | 15:50 |
| mpt | I got that when I posted a comment on bug 1388931 | 15:52 |
| ubot5 | bug 1388931 in Ubuntu Clock App "No setting for 12h or 24h clock format any more" [Medium,New] https://launchpad.net/bugs/1388931 | 15:52 |
| mpt | No idea why :-) | 15:53 |
| dobey | mpt: ah, probably because i originally filed the bug against clock-app, which is a deactivated project | 15:55 |
| mpt | Cool, so it | 15:56 |
| mpt | it’s a Launchpad ghost | 15:56 |
| dobey | yeah | 15:56 |
| dobey | mpt: i replied to your comment on that bug too. hopefully my suggestion makes sense and we can do that :) | 16:15 |
| mpt | Another symptom of the ghost project: when I click on ubot5’s link I get a 404 | 16:29 |
| === JanC_ is now known as JanC | ||
| dobey | mpt: ugh | 18:26 |
| dobey | mpt: if you click https://launchpad.net/bugs/1388931 now, does it work right? | 18:27 |
| ubot5 | Launchpad bug 1388931 in Ubuntu Clock App "No setting for 12h or 24h clock format any more" [Medium,New] | 18:27 |
| 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:28 |
| dobey | mpt: i cheated a bit, and deleted the clock-app task, so it /should/ be more reasonable now | 18:33 |
| teward | cjwatson: wgrant: looks like the bug i filed about the email interface for bugs is invalid - didn't work yesterday, works today | 18:36 |
| wgrant | mpt: You already reported that: bug #1278883 | 21:43 |
| ubot5 | bug 1278883 in Launchpad itself "Bug.default_bugtask should avoid inactive products where possible" [Low,Triaged] https://launchpad.net/bugs/1278883 | 21:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!