| === heroux_ is now known as heroux | ||
| zyga | cjwatson: hi, looking at https://code.launchpad.net/~zyga/guacamole/+git/guacamole I see the two git-clone URLs there, are they exposed anywhere in the API? | 08:18 |
|---|---|---|
| zyga | cjwatson: or should I use git_repository.unique_name and derive the URL myself? | 08:19 |
| cjwatson | zyga: They're not exported. Perhaps it would be convenient if they were; feel free to file a bug (with rationale). | 09:13 |
| zyga | cjwatson: thanks for confirming that! | 09:35 |
| zyga | cjwatson: I'm working on tarmac git support now | 09:35 |
| cjwatson | zyga: I saw, thanks! Will reply to your mail shortly | 09:40 |
| zyga | cjwatson: thanks | 09:40 |
| cjwatson | Deriving from git_repository.unique_name is probably workable, although it won't be quite the same as the UI shows you for any repository that's a default. | 09:42 |
| cjwatson | But if all you need is *a* valid URL then it would be close enough. | 09:42 |
| wgrant | We should indeed export the URLs, but the properties need renaming first. | 09:50 |
| wgrant | eg. anon_url sounds like the sensible default for anonymous access, but it's actually legacy git:// | 09:50 |
| cjwatson | Yeah, made sense in my head in March. | 09:51 |
| wgrant | I have some changes around that in my local rework of GitRepository:+index. | 09:52 |
| wgrant | I might rename and export them on the way. | 09:52 |
| cjwatson | git:// probably doesn't need to be exported at all. | 09:52 |
| cjwatson | git+ssh:// and https:// would be sufficient. | 09:52 |
| cjwatson | wgrant: Have you thought of any better names for landing_candidates et al? Otherwise I'm inclined to export the current names on the grounds that Tarmac will need them and it's probably least confusing there for them to match Bazaar. | 09:54 |
| wgrant | shuf -n 2 /usr/share/dict/words says extrusions_begun, which is probably less confusing than landing_candidates. | 09:55 |
| cjwatson | :-P | 09:56 |
| wgrant | The current names aren't obviously worse than the Bazaar equivalents, are they? | 09:56 |
| wgrant | Apart from the repo vs branch stuff, nothing has changed terribly. | 09:57 |
| cjwatson | The current names are identical to the Bazaar equivalents. | 09:57 |
| wgrant | Right, but there's no real reason we have to change them. | 09:57 |
| wgrant | That I can recall. | 09:57 |
| cjwatson | That was my thought. | 09:57 |
| cjwatson | I mean, they suck but they can suck equally. | 09:57 |
| wgrant | It was just a "this bit of Bazaar codehosting is stupid, let's see if we can do it better before stabilising the API" | 09:57 |
| wgrant | And at this point I think the answer is no. | 09:57 |
| cjwatson | Like most things that talk about sources and targets etc., it's very easy to get into directional confusion. | 09:58 |
| wgrant | Yeah | 09:58 |
| cjwatson | Especially for this kind of thing where it's really "merge proposals for which this branch etc. is the source" | 09:58 |
| wgrant | The least confusing thing might almost be to have lp.merge_proposals... | 09:58 |
| wgrant | But exporting the existing properties works. | 09:59 |
| cjwatson | lp.merge_proposals has the nice property that we could introduce it later without too much clutter, indeed. | 10:03 |
| === jamesh__ is now known as jamesh | ||
| Odd_Bloke | I keep getting errors when trying to comment on https://code.launchpad.net/~daniel-thewatkins/charms/trusty/ubuntu-repository-cache/update_charm-helpers/+merge/260956 | 11:52 |
| Odd_Bloke | Specifically, "Server error, please contact an administrator." | 11:52 |
| Odd_Bloke | So consider yourselves contacted. :p | 11:52 |
| wgrant | Yep, we're investigating a strange load issue with the master DB server. | 11:52 |
| wgrant | Everything relating to commenting just.. hangs. | 11:52 |
| Odd_Bloke | Cool. | 11:53 |
| Odd_Bloke | Oh, all the comments just got added at the same time! | 11:54 |
| wgrant | Odd_Bloke: Yep, it's all unstuck now. Let us know if you see any more issues. | 11:58 |
| grepper | I was synching my ppa with a number of upstream changes in the same branch I was using, but it fails upload with dput because of the changes to the $project_$version.orig.tar.gz with the same name. What is the proper way to do this? Using debian/patches and the previous *orig.tar.gz ? | 12:13 |
| zyga | grepper: .orig.tar.gz are used for upstream projects (typically upstream releases) | 12:18 |
| zyga | grepper: for that you should keep the single, unchanged orig.tar.gz and upload new debian tarball that may contain patches | 12:19 |
| zyga | grepper: if that is your own project and you are working on packaging and development at the same time, you can switch to a native debian package, in that way you don't have .orig.tar.gz, just .tar.gz that is uploaded each time | 12:19 |
| zyga | grepper: still you need to make sure the version is always changed | 12:19 |
| zyga | grepper: for development you should have a sbuild installation locally as that is much faster and allows you to iterate without waiting for ppa builds or for upload queue to reach your project | 12:20 |
| grepper | zyga: so I should have left the orig.tar.gz unchanged and used debian/patches ? (assuming I don't want to mess with sbuild right now) | 12:21 |
| zyga | grepper: yes | 12:21 |
| zyga | grepper: use quilt to manage debian/patches | 12:21 |
| zyga | grepper: and do setup sbuild, it takes around 10 minutes, just follow the wiki instructions | 12:22 |
| zyga | grepper: and then each test is 'sbuild' in the source directory | 12:22 |
| zyga | grepper: https://wiki.debian.org/sbuild | 12:22 |
| grepper | okay, thanks. That's actually the way I tried the 1st time, but ran into problems and thought why not just use the new upstream tarball and sync that. Obviously the wrong choice :( | 12:23 |
| grepper | I will have a look a sbuild as it is my project as well | 12:23 |
| cjwatson | If there's a new upstream tarball, you should use it, but it needs to have a new version number. | 12:23 |
| zyga | grepper: if you run into any issues just ask | 12:23 |
| cjwatson | You can't just republish a new thing with the same version. That's (a) forbidden by LP (b) dreadful practice anyway | 12:24 |
| grepper | oh, cjwatson can I just use something like tovid_0.35.2.orig.tar.gz --> tovid_0.35.2-1.orig.tar.gz ? | 12:24 |
| cjwatson | Not quite like that. Has tovid upstream released a new tarball? | 12:25 |
| grepper | yes, its a release this time | 12:25 |
| cjwatson | What is the new upstream version number? | 12:25 |
| zyga | grepper: 0.35.2 and 0.35.2-1 are quire different, do you know what the difference is? | 12:25 |
| cjwatson | Oh. Do you mean that you previously uploaded 0.35.2 but it wasn't the real upstream release? | 12:25 |
| grepper | yes | 12:25 |
| cjwatson | That was very naughty of you. | 12:25 |
| grepper | bad move apparently | 12:26 |
| cjwatson | I would do 0.35.2+real then | 12:26 |
| grepper | it was 0.35.2 branch ... | 12:26 |
| cjwatson | Next time, use 0.35.2~20150604 | 12:26 |
| cjwatson | Or similar | 12:26 |
| grepper | okay | 12:26 |
| cjwatson | That's the sort of form you'd use for prereleases | 12:26 |
| * zyga feels PPAs should have a separate "tarball namespace" from the rest, if that's not the case already | 12:26 | |
| cjwatson | zyga: They do, mostly. | 12:26 |
| cjwatson | zyga: One way round. Uploads to PPAs check the main distribution archive, but not vice versa. | 12:27 |
| zyga | cjwatson: ah, so I cannot ruin someone's day by uploading 'linux-4.2.orig.tar.gz' by any chance? | 12:27 |
| cjwatson | Correct, you can only ruin your own. | 12:27 |
| zyga | ah, that's very sensible then | 12:27 |
| grepper | zyga: not exactly, I assume it is an patch level | 12:28 |
| cjwatson | grepper: So you probably want to make the full package version number be 0.35.2+real-1, and rename the real upstream 0.35.2 release to tovid_0.35.2+real.orig.tar.gz | 12:28 |
| zyga | grepper: 0.35.2 is the version of upstream package _or_ the version of a debian-native package (that doesn't ever have the -1 -2 -3 versions) | 12:29 |
| zyga | grepper: whereas 0.35.2-1 is the version number of the debian package, comprised of the upstream version and the debian version, separated by '-' | 12:29 |
| zyga | grepper: most of the time you'll see the 1.2.3-1 type of versions | 12:29 |
| grepper | ah, okay, so that was the wrong approch | 12:29 |
| zyga | grepper: the point is that you cannot freely move from one to another | 12:29 |
| zyga | grepper: and it's generally recommended to use non-native packages (those that have the debian version separate) | 12:30 |
| grepper | so if I use 0.35.2+real-1 the build system will automatically know to use 0.35.2+real.orig.tar.gz ? Just by using the changelog ? | 12:31 |
| cjwatson | Correct. | 12:31 |
| grepper | or do I need to rename the directory | 12:31 |
| grepper | okay | 12:31 |
| cjwatson | The directory name isn't particularly important. | 12:31 |
| cjwatson | You can just have the directory be "tovid". | 12:31 |
| grepper | okay | 12:31 |
| grepper | what about 0.35.2+release ? | 12:32 |
| cjwatson | If you like. | 12:32 |
| grepper | yeah | 12:32 |
| cjwatson | Just don't get the idea that you always have to append "+release"; it's just to supersede the misleading "0.35.2". | 12:33 |
| grepper | Right. So this way I don't need to patch up to the upstream release ? I have the new release files in my ppa directory already. | 12:34 |
| cjwatson | Correct. | 12:34 |
| grepper | great, thanks for your help | 12:34 |
| === maxb_ is now known as maxb | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!