[00:56] Hello All, not sure if anyone is around as it's the wknd but, I want to create a BZR repo on LP where a 2 or 3 person admin team can merge to the trunk while others must provide merge proposals. Is this considered the "Decentralised with shared main line" and if so, how to I establish the trunk for the team ? [00:59] ki7mt: i think you'd push the brand new branch to lp:~teamname/project/branchname but don't quote me on that [01:00] teward, Ok, thanks, that's what I thought after reading a bit on LP. Would this main branch be created in the Team, or the project owned by the team ? [01:01] ki7mt: The team that owns the branch are the only people who can write to the branch. [01:01] ^ [01:01] For a small project, that team often owns the project as a whole too. [01:01] that too [01:01] But they can be unrelated teams or people if you desire. [01:02] wgrant, Ok, thanks. As it stands now, it is a small team, only 5 or 6, but there's the main project, then the documentation project. [01:02] and oth have teams. [01:02] .. both .. [01:03] So if I wanted and bzr brans url of say: lp: .. I would init that on my local machine, make my commits, then push the initial brach up that way? [01:04] Yep. You always create the branch locally, then push it to Launchpad -- it'll automatically create the remote branch if it doesn't already exist. [01:05] Ok, cool, now that won't include my ~username in the URL thought right? [01:06] That's the main thing Im trying to avoid, is having my ~ki7mt username in the url [01:07] Or any of the team members ~username for that matter. [01:07] if you push to lp:~teamname instead of lp:~username it should be bound to that team [01:07] but keep in mind commit logs [01:07] (they will show who committed changes, iirc) [01:07] A project branch always has a URL of the form lp:~owner/project/branch, but if it's the official project trunk it also gets the URL lp:project. [01:08] wgrant, Yes, that I am trying to establish at the moment, the official project trunk [01:08] If you push directly to lp:project and it doesn't exist yet, it'll automatically be created as lp:~your-username/project/trunk, and only you can write to it. But you can then hit "Change details" on that page to change the owner to the team so they can all write to it. [01:09] wgrant: if they push to lp:~teamname/project/branch that'll have the team name as ownership, right? [01:10] Right, but then you'd have to set the default manually (using the "Configure project branch" link on the project's homepage) [01:10] right [01:10] i think the goal of ki7mt is to get the branch itself to be team owned, not lp:~your-username [01:10] Sure [01:10] so that manual step would be needed :) [01:10] A manual step is needed either way. [01:10] indeed. [01:11] Ok, so I psuch a branch: lp:~teamname/project/branch .. then go to the home page, and Configure project branch and set it to the team ? [01:11] Set it to ~teamname/project/branch [01:12] Ok I think I got this sorted out :-) .. [01:13] Now if I balls this up, how can I remove that branch ? [01:13] wgrant: the Lucid series is 'closed' now on Launchpad for bugs, right? [01:13] 10.04 yeah, I got a lod of bug close message no long ago I know that [01:13] ki7mt: yeah i did too for packages in my radar directly, but it's still a question out there :p [01:13] just a prereq question for my next one xD [01:14] Anyways, Im gonna go try out this push to LP .. [01:14] and whether there were any substantial API changes for mass searching for all bugs in a specific target series in the Ubuntu project and closing and commenting about EOL stuff :) [01:15] Thanks for all your help [01:15] teward: Support for Ubuntu 10.04 LTS ended on April 30. [01:15] Searching, closing and commenting has been doable on the API since about 2007. [01:16] wgrant: i have a script i used... what, several months ago, I think... to mass close remaining Karmic bugs but meh [01:17] my question is whether the api changed substantially or not [01:17] lemme go dig it up, i think it's on a usb stick somewhere... [01:19] No, that part of it is in 1.0 and hasn't changed at all. [01:21] cool [01:21] lol i found a karmic bug that's still alive XD [01:22] and still a current issue xD [01:28] Another question, when I create my local branch first, does it take on the trunk, branches and tags like SVN or should the first branch name just be the app or manual name ? [01:29] Bascially I want to follow the ubuntu-manual setup: https://launchpad.net/ubuntu-manual [01:29] ki7mt: Your initial branch would usually just be named trunk. [01:29] Why do you want to follow that? [01:30] ubuntu-manual has a fairly complex setup which isn't really warranted for a small project. [01:30] Ok :-) .. what would you recommend, Im very much open to options here :-) [01:32] ki7mt: I don't know what your project is doing, so it's difficult to advise. https://help.launchpad.net/Projects/SeriesMilestonesReleases describes the model. [01:32] ubuntu-manual has a series corresponding to each Ubuntu series, but that's only useful if you're maintaining multiple lines of stable releases. [01:32] eg. releaseing 0.1.2 after 0.2 is out. [01:33] Yes, this will be doing that also, but it's following the LTS releases only. [01:33] The main project is a desktop integrate or a custom version of Mate / LXDE .. [01:34] Adn the Manual will follow those releases [01:34] Ah. [01:34] releases beaing, 14.04, 16.04 and so on, with updates only on the point releases. [01:34] So in that case you probably don't want a trunk series or branch at all -- you'll want to rename the existing trunk series to whatever the current series is called on the main project, and call the branch the same thing. [01:36] At the moment, we dont have anything in the repo, that's where Im at now, setting that portion up. [01:37] And the main project is called c4c-desktop .. [01:39] The guy that started it created a personal style branch in the c4c-project, that needs to be fixed, and it has user-name and a trunk [01:39] in the url .. which we dont really want that. [01:40] here's what he done so far: https://launchpad.net/c4c-desktop [01:41] ki7mt: You can just push a new branch and make it team-owned, or you can get the existing branch owner to make that one team-owned. [01:43] Is there a way to remove the old branch once we have the new team owend branch setup ? [01:43] Sure, the branch's owner can delete it. [01:43] Ok, cool as they added a ton of binary media in there and it's huge already :-) [01:43] Heh, never a good start. [01:43] Huge as in, GB huge [01:44] Im fairly well verese in Git and SVN, but to be honest here, I've not done whole lot of team and project work on LP, so, appreciate your patients here. [01:46] In any case, I think I have a direction to head in, thanks for all the help wgrant and teward [01:46] Great. [02:27] what is the expected time between a build finishing and me being able to upgrade to it these days? [02:31] (in a ppa) [02:31] mwhudson: Within 20 minutes. [02:31] ok [06:35] Hello All, yet another question. I have another project that I imported code from a SF Git repo. On the code Tab of the project, there is a message that states a refresh will happen in about 5hrs or so. Is this a constant feature or does it stop at some point? [06:39] ki7mt: Code imports refresh regularly as long as no errors occur. [06:40] wgrant, Ok, thanks. [08:15] Is it possible to push to imported branches? If so, what happens then, changes get overwritten at the next sync? [08:15] I tried with https://code.launchpad.net/~alkisg/ltsp/ltsp-debian-packaging and I got: "bzr: ERROR: Cannot lock LockDir(chroot-75159440:///~alkisg/ltsp/ltsp-debian-packaging/.bzr/branch/lock): Transport operation not possible: readonly transport " [08:15] ...not sure if that's the expected result, or if I did something wrong... [08:16] alkisg: No, you can't write to an imported branch. [08:16] Thank you wgrant [08:16] You can push the modified version up to a different branch, however. [08:16] Gotcha, will do that [09:56] Launchpad will be offline for a few moments in about five minutes for a database upgrade. [13:50] Launchpad qastaging/staging will be offline for about ten minutes shortly for hardware maintenance. [14:21] wgrant: re gmx.co.uk and launchpad - been in contact with them - last thing and seemingly the only thing that I will get from them contains this line "Please ask the admin of the domain to contact directly our postmaster so they can fix the issue: http://postmaster.gmx.com/en/ " [14:49] cjwatson: when might 17503 get rolled out? [14:50] bdmurray: It's being rolled out at the moment. [14:51] I was going to tell you when it was done :-) [14:51] cjwatson: Ah, thanks! [15:37] bdmurray: That's deployed now. [15:39] cjwatson: thanks [15:50] What is “paddev.net” and why is it showing up in Google search results? [15:51] Specifically, I just came across [15:54] wow, I did not know that adding blueprints to a project would add so much Karma :-) .. mine is x4 up from yesterday :-) [15:54] mpt: The non-production instances of Launchpad are gradually moving there so that they can't get hold of production cookies and suchlike. [15:54] dogfood has been there for a year or two, and git.qastaging.paddev.net was created there. [15:54] Ah, ok [15:55] I wonder if there’s a way to NOINDEX the whole domain [16:18] I just saw a message about Launchpad and the use if Git rather than BZR .. is the available to the general public? If so, can someone post a link to the setup and usage docs? [16:18] .. is this available .. [16:21] NVM, I found it: https://help.launchpad.net/Code/Git [18:56] Hi another question. I pushed a Git repo up to my project that did not have a trunk focus previously. How to change the Development Focus to the Git Master branch rather than the bzr trunk series ? [18:59] if it's possible, i guess it would be obvious in the edit page for the trunk series on the project [18:59] ki7mt: The interaction between development focus and git repositories is someting we're still working out. [18:59] ki7mt: Which project is this? [18:59] so i guess it's not :) [18:59] dobey: Not that simple. [19:00] Development focus is actually an inapplicable concept because it's per-series ... [19:00] Project: https://launchpad.net/jtsdk [19:00] ki7mt: Right, so you've already done the correct thing per our model, which is to make that repository be the "default" repository for the project. [19:01] ki7mt: We'll be improving the UI soon to take account of that in more places, and to let you say that you prefer git for this project. [19:01] I thinkso, yes, I was folling the Code/Git LP instructions. [19:02] cjwatson, Im in no rush on this, as I'm pulling it from SF anyway, but thought I'd give it a shot. [19:02] ki7mt: So just leave that as it is and the UI should gradually get better for you. :-) [19:02] Ok thank you. [19:04] per-series> I phrased that badly, I mean that the development focus for a project *is* a project series, and a project series may have a default branch associated with it. But that model doesn't quite work for git because you normally want to keep lots of branches in a single repository instead. [19:06] well, it works i think if you just consider each series to be a "fork" repository a-la github, right? [19:06] That works in theory but isn't actually what one generally wants to do. [19:06] So that's not how our model is constructed. [19:06] if i create some changes to merge into an upstream git project on LP, it's roughtly the same, no? [19:06] Forks are much more sensibly applied to a contributing user's fork of a project. [19:07] But series default branches are much more like branches within the project's default repository. [19:08] Project series are used for things like long-lived maintenance branches of a project (the canonical original example back in 2004 was Apache 1.3 vs. 2.0, IIRC), and if you look at say any GNOME repository on git.gnome.org people are not creating fork repositories for maintenance branches. [19:08] right [19:09] So we can do per-user forks, but they don't map to series. [19:09] well git.gnome.org is not managed as a gneeral code hosting thing where lots of people contribute to lots of random projects, either [19:09] Sure, but per-series fork repositories just *do not make sense* [19:09] So we're not doing them [19:10] You *can* do things that way but it isn't the natural git workflow [19:10] And the goal of hosting git on Launchpad does not include unnecessarily crowbarring it into bzr ways of thinking [19:10] well, it makes sense to create a fork where the default checked out branch is for the associated series branch for the default respository of the project [19:11] It might make sense for a series to be able to designate a particular branch in the project's default repository, yes [19:11] I don't know how useful that would be, and it's not in the model today [19:11] But it could be added [19:11] i think it makes sense for maintenance work and bug tracking [19:11] but *shrug* :) [19:12] You can still do that, it's just that LP wouldn't tell you which branch is the default, that's all [21:57] I'm having difficulty uploading to my PPA [21:57] I'm getting a failure email after uploading [21:58] What does the failure email say? [21:58] "Unable to identify .... in launchpad" [21:59] where .. is "Me " [21:59] Your changelog is misformatted, I suspect. [21:59] sounds like somehting to do with pgp keys [21:59] No. [21:59] yes, it does sound like a gpg issue [21:59] but my key appears correctly with my email host when I list keys [22:00] The end of the latest changelog entry in debian/changelog must contain a valid email address. [22:00] and I'm specifying that key with the -k option to backportpackage [22:00] You can override the address that dch uses by default using the DEBMAIL environment variable. [22:00] ah, ok [22:00] thanks [22:00] that explains it [22:02] doesn't it also have to match the pgp key though? [22:02] how long should it take to show up on LP after I upload? [22:03] I matched DEBEMAIL to my gpg key this time [22:03] a few minutes to show up after you get a success email, and then a few hours before it actually builds [22:04] it's showing up now -- thanks! [22:04] A few hours? [22:04] Normally a minute or so, though at the moment perhaps 20 minutes. [22:04] where a few = 2, in my experience [22:04] When was that experience? [22:05] 2014-12-12 [22:05] Ah, that was a long long time ago. [22:05] The queue is more than ten minutes deep for about an hour a day now, and then it barely exceeds an hour. [22:06] looks like i just got a time machine [22:06] :-) [22:07] thanks again! === mattgrif_ is now known as mattgriffin