[08:18] <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:19] <zyga> cjwatson: or should I use git_repository.unique_name and derive the URL myself?
[09:13] <cjwatson> zyga: They're not exported.  Perhaps it would be convenient if they were; feel free to file a bug (with rationale).
[09:35] <zyga> cjwatson: thanks for confirming that!
[09:35] <zyga> cjwatson: I'm working on tarmac git support now
[09:40] <cjwatson> zyga: I saw, thanks!  Will reply to your mail shortly
[09:40] <zyga> cjwatson: thanks
[09:42] <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:50] <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:51] <cjwatson> Yeah, made sense in my head in March.
[09:52] <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:54] <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:55] <wgrant> shuf -n 2 /usr/share/dict/words says extrusions_begun, which is probably less confusing than landing_candidates.
[09:56] <cjwatson> :-P
[09:56] <wgrant> The current names aren't obviously worse than the Bazaar equivalents, are they?
[09:57] <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:58] <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:59] <wgrant> But exporting the existing properties works.
[10:03] <cjwatson> lp.merge_proposals has the nice property that we could introduce it later without too much clutter, indeed.
[11:52] <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:53] <Odd_Bloke> Cool.
[11:54] <Odd_Bloke> Oh, all the comments just got added at the same time!
[11:58] <wgrant> Odd_Bloke: Yep, it's all unstuck now. Let us know if you see any more issues.
[12:13] <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:18] <zyga> grepper: .orig.tar.gz are used for upstream projects (typically upstream releases)
[12:19] <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:20] <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:21] <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:22] <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:23] <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:24] <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:25] <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:26] <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:27] <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:28] <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:29] <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:30] <zyga> grepper: and it's generally recommended to use non-native packages (those that have the debian version separate)
[12:31] <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:32] <grepper> what about 0.35.2+release ?
[12:32] <cjwatson> If you like.
[12:32] <grepper> yeah
[12:33] <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:34] <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