[00:50] <lool> Ahoy, I forgot how to remotely clone a git repo on the Launchpad side
[00:51] <lool> I'd like to setup a linux git repo with a patch on top, doing the initial git repo clone on the Launchpad side
[01:12] <lool> wgrant: ^ would you be able to help?
[01:56] <wgrant> lool: In general you can just push to a new repo, and if the project/package already has a default it will just work. But Linux can be set up a bit specially. Do you have a particular repo that you've cloned?
[02:43] <lool> wgrant: it was //git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/trusty
[02:43] <lool> wgrant: I havent cloned it in launchpad yet
[02:43] <lool> wgrant: I need to drop off for the day, but will read whatever you send here tomorrow
[02:44] <wgrant> lool: Pushing to lp:~lool/ubuntu/+source/linux will work fine.
=== maclin1 is now known as maclin
=== maclin1 is now known as maclin
=== kickinz1|afk is now known as kickinz1
[08:39] <stub> I'm having trouble with https://code.launchpad.net/postgresql-charm
[08:39] <stub> My git repos seem to end up in my ~stub namespace rather than the project namespace
[08:40] <stub> (I don't want to pollute the master repo with my development branches, but I'd like my development branches backed up on Launchpad)
[08:41] <stub> Do I need a team?
[09:13] <wgrant> stub: Git repositories work very similarly to Bazaar branches in terms of ownership and aliases.
[09:13] <wgrant> That is, no Git repository exists solely in the project namespace.
[09:14] <wgrant> Ah, it looks like you worked out to push to lp:postgresql-charm
[09:14] <wgrant> Just after you asked?
[09:15] <stub> I know how to push it (and now I have two repos in ~stub). I was just wondering how to get the ~stub removed, which from what you are saying needs me to add a team and use a team repo?
[09:15] <wgrant> Right, just like Bazaar all repos have an owner and may be official for the project.
[09:15] <wgrant> You probably want a team here.
[09:16] <stub> Its somewhat hidden with bazaar, since you are dealing with branches rather than repos.
[09:16] <wgrant> Hm, how do you mean?
[09:16] <wgrant> They're still just "lp:postgresql-charm"
[09:17] <stub> Right. The difference is, with bzr my main branch would be lp:postgresql-charm and I can push a bazillion other branches to ~stub/postgresql-charm/foo and not pollute anything.
[09:17] <wgrant> Ah, right.
[09:17] <wgrant> You've managed to make them separate now, though.
[09:18] <wgrant> lp:~stub/postgresql-charm was created first, and is https://code.launchpad.net/~stub/postgresql-charm/+git/postgresql-charm
[09:18] <wgrant> Then you pushed to lp:postgresql-charm, which created https://code.launchpad.net/~stub/postgresql-charm/+git/postgresql-charm-1
[09:18] <stub> Yeah, just might work on a less sucky repo name than -1 ;)
[09:18] <wgrant> You probably want to take the second one, give it to a team, and rename it to something less silly.
=== kickinz1 is now known as kickinz1|afk
=== teran_ is now known as teran
=== Michaela is now known as Ciblia
=== Ursinha_ is now known as Ursinha
[14:54] <jgdx> I'm getting some oopses (timeout) on bug reporting. Known issue? OOPS-60e35dd598b2c114c1f2b7c3d3791011 OOPS-766de5f046ed07479d376ca647bacb55
[14:54] <ubot5> https://oops.canonical.com/?oopsid=OOPS-60e35dd598b2c114c1f2b7c3d3791011
[14:54] <ubot5> https://oops.canonical.com/?oopsid=OOPS-766de5f046ed07479d376ca647bacb55
[14:56] <dobey> jgdx: new bug, or creating a task on a bug with lots of tasks already?
[14:56] <jgdx> dobey, brand spankin' new
[14:57] <dobey> jgdx: ah. maybe some continuation of the high load issues LP was having yesterday?
[14:57] <dobey> i haven't hit any timeouts today yet, though
[14:58] <jgdx> dobey, ah—there were issues yesterday? OKay, I'll be a bit more patient.
[15:02] <dobey> jgdx: yeah. maybe check with webops internally? there could be new issues of course :)
[15:09] <jgdx> dobey, it went through now, so I'll just assume all is back to normal :p
[15:10] <dobey> well, you know what they say about assumption :P
=== Guest91003 is now known as karstensrage
[19:32] <rudolfs> Does git repo allow to push changes from another team member?
[20:32] <Saviq> this build looks stuck https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-019/+build/9023705 - can anyone do something about it or will it time out on its own?
[20:42] <dobey> Saviq: i think you're supposed to ask trainguards for those; robru can cancel the job for example
[20:43] <dobey> i guess it probably won't time out
[20:44] <dobey> at least, probably not for at least another 15 hours anyway; there are some things that do legitimately take a very long time to build, so i'm not sure if there is a timeout set
[20:45] <robru> Saviq: dobey: cancelled
[20:45] <robru> was gonna say "seems like an ordinary failure to me" but then I saw "started 10 hours ago"
[20:46] <dobey> yeah
[20:46] <Saviq> robru, dobey ack, tx
[20:47] <robru> Saviq: need me to retry or will you rebuild the silo anyway?
[20:47] <Saviq> robru, s390 doesn't build anyway
[20:47] <robru> ah
[20:47] <robru> perfect then
[20:47] <Saviq> yup
[23:20] <teward> it's not possible to issue a rebuild for the ppas without uploading a new version number, right?
[23:21] <xnox> teward, only if it failed to build. if the build succeeded, one cannot "rebuild" it, as there is unique binary name constraint.
[23:21] <teward> that's what i thought
[23:22] <teward> i'll pull the packages down and upload 'rebuild' numbered ones
[23:22] <xnox> teward, dch --rebuild '' && debuild -S && dput ../*.changes -> is something i have never scripted together, nor like ever use, when like rebuilding 100s of packages for boost.
[23:23] <teward> xnox: heh
[23:28] <teward> i'll just upload the changes, for the PPA.  shouldn't be too hard since i already have automated workflow scripts which do most of the stuff I need
[23:47] <teward> do the PPAs need the full source tarball upload each time, or does it only need the .changes if the tarball is already present there (i.e. the version hasn't changed, it's just a rebuild)
[23:49] <wgrant> teward: You don't need to reupload the orig.tar.* if it already exists in the PPA or Ubuntu's primary archive. "debuild -S -sd" will exclude it, while -sa will include it.
[23:51] <teward> just making sure :)
[23:56] <teward> wgrant: based on the changelog here, though `debuild -S` in my devscripts doesn't define -sa, so it's not including the source because the version number doesn't imply it needs one; i've had to -sa before for a clean buildtests repository in the past, though, for an Ubuntu merge, but it's atypical in most of the cases I've had :)
[23:56] <teward> thanks though for confirming what I thought - that PPAs operate almost exactly like the standard repos would
[23:57] <teward> (with regards to whether the .changes or the .changes + orig.tar.* is needed :)