=== heroux_ is now known as heroux [08:18] 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:19] cjwatson: or should I use git_repository.unique_name and derive the URL myself? [09:13] zyga: They're not exported. Perhaps it would be convenient if they were; feel free to file a bug (with rationale). [09:35] cjwatson: thanks for confirming that! [09:35] cjwatson: I'm working on tarmac git support now [09:40] zyga: I saw, thanks! Will reply to your mail shortly [09:40] cjwatson: thanks [09:42] 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] But if all you need is *a* valid URL then it would be close enough. [09:50] We should indeed export the URLs, but the properties need renaming first. [09:50] eg. anon_url sounds like the sensible default for anonymous access, but it's actually legacy git:// [09:51] Yeah, made sense in my head in March. [09:52] I have some changes around that in my local rework of GitRepository:+index. [09:52] I might rename and export them on the way. [09:52] git:// probably doesn't need to be exported at all. [09:52] git+ssh:// and https:// would be sufficient. [09:54] 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:55] shuf -n 2 /usr/share/dict/words says extrusions_begun, which is probably less confusing than landing_candidates. [09:56] :-P [09:56] The current names aren't obviously worse than the Bazaar equivalents, are they? [09:57] Apart from the repo vs branch stuff, nothing has changed terribly. [09:57] The current names are identical to the Bazaar equivalents. [09:57] Right, but there's no real reason we have to change them. [09:57] That I can recall. [09:57] That was my thought. [09:57] I mean, they suck but they can suck equally. [09:57] 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] And at this point I think the answer is no. [09:58] Like most things that talk about sources and targets etc., it's very easy to get into directional confusion. [09:58] Yeah [09:58] Especially for this kind of thing where it's really "merge proposals for which this branch etc. is the source" [09:58] The least confusing thing might almost be to have lp.merge_proposals... [09:59] But exporting the existing properties works. [10:03] lp.merge_proposals has the nice property that we could introduce it later without too much clutter, indeed. === jamesh__ is now known as jamesh [11:52] 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] Specifically, "Server error, please contact an administrator." [11:52] So consider yourselves contacted. :p [11:52] Yep, we're investigating a strange load issue with the master DB server. [11:52] Everything relating to commenting just.. hangs. [11:53] Cool. [11:54] Oh, all the comments just got added at the same time! [11:58] Odd_Bloke: Yep, it's all unstuck now. Let us know if you see any more issues. [12:13] 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:18] grepper: .orig.tar.gz are used for upstream projects (typically upstream releases) [12:19] grepper: for that you should keep the single, unchanged orig.tar.gz and upload new debian tarball that may contain patches [12:19] 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] grepper: still you need to make sure the version is always changed [12:20] 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:21] 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] grepper: yes [12:21] grepper: use quilt to manage debian/patches [12:22] grepper: and do setup sbuild, it takes around 10 minutes, just follow the wiki instructions [12:22] grepper: and then each test is 'sbuild' in the source directory [12:22] grepper: https://wiki.debian.org/sbuild [12:23] 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] I will have a look a sbuild as it is my project as well [12:23] If there's a new upstream tarball, you should use it, but it needs to have a new version number. [12:23] grepper: if you run into any issues just ask [12:24] You can't just republish a new thing with the same version. That's (a) forbidden by LP (b) dreadful practice anyway [12:24] oh, cjwatson can I just use something like tovid_0.35.2.orig.tar.gz --> tovid_0.35.2-1.orig.tar.gz ? [12:25] Not quite like that. Has tovid upstream released a new tarball? [12:25] yes, its a release this time [12:25] What is the new upstream version number? [12:25] grepper: 0.35.2 and 0.35.2-1 are quire different, do you know what the difference is? [12:25] Oh. Do you mean that you previously uploaded 0.35.2 but it wasn't the real upstream release? [12:25] yes [12:25] That was very naughty of you. [12:26] bad move apparently [12:26] I would do 0.35.2+real then [12:26] it was 0.35.2 branch ... [12:26] Next time, use 0.35.2~20150604 [12:26] Or similar [12:26] okay [12:26] 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] zyga: They do, mostly. [12:27] zyga: One way round. Uploads to PPAs check the main distribution archive, but not vice versa. [12:27] cjwatson: ah, so I cannot ruin someone's day by uploading 'linux-4.2.orig.tar.gz' by any chance? [12:27] Correct, you can only ruin your own. [12:27] ah, that's very sensible then [12:28] zyga: not exactly, I assume it is an patch level [12:28] 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:29] 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] 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] grepper: most of the time you'll see the 1.2.3-1 type of versions [12:29] ah, okay, so that was the wrong approch [12:29] grepper: the point is that you cannot freely move from one to another [12:30] grepper: and it's generally recommended to use non-native packages (those that have the debian version separate) [12:31] 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] Correct. [12:31] or do I need to rename the directory [12:31] okay [12:31] The directory name isn't particularly important. [12:31] You can just have the directory be "tovid". [12:31] okay [12:32] what about 0.35.2+release ? [12:32] If you like. [12:32] yeah [12:33] Just don't get the idea that you always have to append "+release"; it's just to supersede the misleading "0.35.2". [12:34] 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] Correct. [12:34] great, thanks for your help === maxb_ is now known as maxb