| grepper | what would the debian policy be about including a txt2tags for python 3 that is available in the txt2tags svn repo ? Its just a single script, can I include it in my package or would I need to make a separate package for it? | 03:48 |
|---|---|---|
| george_e | I think I've got a stuck build: https://launchpad.net/~george-edison55/+archive/ubuntu/rpi2-updates/+build/7509725 | 05:12 |
| george_e | The buildlog output hasn't changed for the last 20 minutes. | 05:13 |
| george_e | ...and there's no reason "Performing Test CXX_FLAG-Wnon-virtual-dtor" should take that long. | 05:13 |
| george_e | I'm going to cancel the build and try again. | 05:22 |
| wgrant | george_e: Remember that armhf PPA builds currently use qemu-user-static, so they can be very slow and for some things not work at all. | 05:28 |
| wgrant | (we'll be moving them onto real armhf OpenStack instances in the next couple of months, but we're still working on getting the hardware set up properly) | 05:28 |
| wgrant | Multithreaded processes can be particularly problematic for qemu-user. | 05:29 |
| george_e | Ah, okay. Yeah, I had another build that was running into some issues with signals. | 05:29 |
| george_e | I'll build what I can for now and wait for the rest then. I have sbuild set up on my Pi, so I can do armhf builds on there for now. | 05:30 |
| wgrant | Yep | 05:30 |
| george_e | Perhaps I'll look into how much effort is involved in setting up an APT repository. | 05:30 |
| wgrant | As of two weeks ago we finally have a lot of virt-capable server-grade 64-bit ARM hardware in the DC, but not quite set up yet. | 05:31 |
| george_e | That'll definitely be a huge benefit. | 05:31 |
| grepper | wgrant: any comment about my question? | 05:37 |
| wgrant | grepper: There's a txt2tags package already. | 05:39 |
| wgrant | But that's an Ubuntu/Debian packaging question, not a Launchpad question -- you're not going to get the best answers from this channel. | 05:39 |
| grepper | wgrant: okay, thanks. Yes there is a txt2tags package, but not for python3, that is only in subversion atm | 05:41 |
| grepper | but I will ask in #ubuntu-packaging | 05:41 |
| wgrant | grepper: It might not be difficult for you to provide an updated txt2tags package in your PPA. | 05:42 |
| grepper | wgrant: yeah, I guess that is an option - so I would just create a new branch ? | 05:43 |
| grepper | easiest thing would be to just include the script with atribution, but I have a feeling that might be against debian policy | 05:44 |
| grepper | if any case its build-depends only , not runtime | 05:45 |
| zyga | good morning | 07:24 |
| zyga | cjwatson: hi | 09:36 |
| zyga | cjwatson: https://bugs.launchpad.net/launchpad/+bug/1462282 | 09:36 |
| ubot5 | Launchpad bug 1462282 in Launchpad itself ""ignoring relative alternative object store"" [Undecided,New] | 09:36 |
| zyga | cjwatson: is that something I should worry about? | 09:36 |
| cjwatson | zyga: No. I've marked it as a dup | 09:37 |
| zyga | cjwatson: thanks for checking | 09:37 |
| cjwatson | zyga: Could you file those bugs for features that tarmac needs? | 09:38 |
| zyga | cjwatson: yes, I will do that today, I'm still working out some things related to that | 09:39 |
| zyga | cjwatson: I'm looking at workflows now | 09:39 |
| zyga | cjwatson: will personal repositories displayed on the code project page? | 09:40 |
| zyga | cjwatson: (later down the line, I know they are not show now) | 09:40 |
| cjwatson | zyga: That's in progress at the moment, yes. | 09:40 |
| zyga | cjwatson: ok, that's good, I'm trying to understand the expected workflow, so far I'm assuming that's one repo per person, merges between personal repos and blessed project repo | 09:41 |
| cjwatson | zyga: https://code.qastaging.launchpad.net/launchpad/+git is what it will look like after the next deployment | 09:41 |
| zyga | cjwatson: ah, perfect | 09:41 |
| zyga | cjwatson: thanks | 09:41 |
| cjwatson | zyga: And soon in the code index will be switchable (currently always defaults to bzr) | 09:41 |
| cjwatson | s/in // | 09:41 |
| zyga | cjwatson: oh, that's another question I had, will it be possible to switch off bzr support for a given project? | 09:42 |
| zyga | cjwatson: or do something to prevent people making accidental bzr pushes to abandoned branches? | 09:42 |
| cjwatson | zyga: I'd normally expect each contributor would have their own repository, yes, although it's perfectly possible within a team to just push to branches in the project's default repository and merge from there | 09:42 |
| cjwatson | zyga: Don't know yet | 09:42 |
| zyga | cjwatson: yes, that's another option, I'm not sure which is best yet (easiest, most familiar to people) | 09:42 |
| cjwatson | zyga: I don't see a reason to prescribe either | 09:43 |
| zyga | cjwatson: I guess the github experience has tought everyone exposed to expect their personal repository | 09:43 |
| wgrant | Mm | 09:43 |
| cjwatson | Yeah but remember that github doesn't really do team ownership | 09:43 |
| wgrant | GitHub encourages people to work in the team repo. | 09:43 |
| wgrant | If there is a team. | 09:43 |
| zyga | cjwatson: good point | 09:43 |
| wgrant | Everywhere else works in personal repos. | 09:43 |
| zyga | cjwatson: well, kind of it exists | 09:43 |
| zyga | cjwatson: you can own a repo | 09:43 |
| zyga | cjwatson: and grant write access to others | 09:43 |
| zyga | cjwatson: it's not team but effectively, it is | 09:44 |
| zyga | cjwatson: especially if it's an organization-owned repo | 09:44 |
| cjwatson | sure, I meant that it's not really usual practice at least in the stuff I see | 09:44 |
| wgrant | For private repos it's very common. | 09:44 |
| zyga | cjwatson: I agree | 09:44 |
| wgrant | Many private repos forbid forks entirely, so all work is in the org repo. | 09:44 |
| wgrant | But there's no need for that here, because LP's model isn't quite as silly. | 09:45 |
| wgrant | Everyone outside GitHub is used to using personal repos, I think. | 09:45 |
| cjwatson | anyway, I think either all-in-one-repo and everyone-has-their-own is entirely reasonable; tarmac can easily support both (in fact it would probably have to do extra work to discriminate) | 09:45 |
| zyga | cjwatson: yes, that's true | 09:46 |
| zyga | cjwatson: right now I'll keep using the project-level API | 09:46 |
| zyga | cjwatson: so it will work for everything | 09:46 |
| cjwatson | let's get the landing_candidates stuff done asap, that's less work for you anyway | 09:47 |
| cjwatson | because it'll be precisely analogous with bzr | 09:47 |
| cjwatson | I was just waiting for you to file that bug so that I could attach the branch to it | 09:47 |
| cjwatson | (i.e. the earlier you file the bug the earlier you'll have the feature :-) ) | 09:48 |
| zyga | https://bugs.launchpad.net/launchpad/+bug/1462288 | 09:48 |
| ubot5 | Launchpad bug 1462288 in Launchpad itself "Launchpad API should expose read-only and read-write URL of each GitRepository" [Undecided,New] | 09:48 |
| zyga | that's the first one | 09:48 |
| zyga | filing the next one :) | 09:48 |
| cjwatson | Thanks | 09:49 |
| zyga | cjwatson: https://bugs.launchpad.net/launchpad/+bug/1462289 | 09:50 |
| ubot5 | Launchpad bug 1462289 in Launchpad itself "Launchpad API should expose available merge requests on GitRepository and GitRef" [Undecided,New] | 09:50 |
| zyga | cjwatson: tell me if the wording is right | 09:50 |
| zyga | I'll check my notes, I think I had something else | 09:50 |
| cjwatson | that's fine thanks | 09:50 |
| === benonsoftware is now known as MerryChristmas | ||
| === MerryChristmas is now known as benonsoftware | ||
| zyga | cjwatson: how often do you deploy to production? | 12:24 |
| cjwatson | zyga: depends what we have to do, usually a couple of times a week | 12:31 |
| cjwatson | zyga: we'll likely do the next one on Monday morning | 12:32 |
| zyga | cjwatson: will that include the extra APIs? | 12:32 |
| cjwatson | zyga: landing_candidates etc., yes | 12:33 |
| cjwatson | zyga: I haven't done the URL stuff yet but that's much easier for you to work around | 12:33 |
| zyga | cjwatson: yes | 12:33 |
| zyga | cjwatson: that's not a problem at all | 12:33 |
| zyga | cjwatson: for a hybrid project, the way to differentiate git vs bzr merge proposals, I can just test if {source,target}_branch_link is None or not, am I correct? | 12:35 |
| cjwatson | zyga: correct | 12:35 |
| cjwatson | you only need to test one of them, DB constraints ensure that everything's always in exactly one world | 12:36 |
| zyga | cjwatson: yep, I was just checking | 12:37 |
| zyga | cjwatson: is there an attribute that holds the approved revision/commit id somewhere? | 12:57 |
| zyga | cjwatson: tarmac currently handles that somehow | 12:57 |
| * zyga looks | 12:57 | |
| cjwatson | zyga: tell me what tarmac's currently using and I'll tell you if there's a git equivalent | 13:00 |
| zyga | yeah, I'm trying to find it | 13:01 |
| zyga | cjwatson: I'm thinking of the thing that shows up on the website, like "approved revision 1234" | 13:01 |
| cjwatson | zyga: That's merge_proposal.reviewed_revid; the same attribute exists for git and should contain a commit id | 13:05 |
| zyga | ah, thanks | 13:05 |
| zyga | yes, that's what tarmac is using | 13:06 |
| cjwatson | let me just check that that actually works | 13:06 |
| * zyga looks | 13:06 | |
| cjwatson | yep | 13:07 |
| cjwatson | In [9]: mp = lp.load("~cjwatson/grub/+git/qas/+merge/254313") | 13:07 |
| cjwatson | In [10]: mp.reviewed_revid | 13:07 |
| cjwatson | Out[10]: u'200dc43b9c268e405da512390efbc3aff502c7cc' | 13:07 |
| cjwatson | (on qastaging) | 13:07 |
| zyga | cjwatson: excellent | 13:07 |
| zyga | cjwatson: it's also good on current production | 13:07 |
| cjwatson | yes, that hasn't changed recently, I just didn't want to create a test MP on production | 13:08 |
| zyga | cjwatson: http://pastebin.ubuntu.com/11588045/ have a look at line 16 | 13:19 |
| * zyga has gone ahead with a standalone script, not tarmac | 13:20 | |
| zyga | at least for now | 13:20 |
| zyga | but I think in general too, but more on that later | 13:21 |
| cjwatson | zyga: You might be able to work around that by not doing fetch --all perhaps; you only need the source/target/prereq refs | 13:22 |
| cjwatson | zyga: ah, no, try using git+ssh for both | 13:23 |
| zyga | cjwatson: I'm not familiar with git at that level, can git fetch a ref without fetching everything in a remote? (i know git has packs but I assumed it needed all of them) | 13:23 |
| zyga | cjwatson: hmm, will that fail if the CI system has no way to git+ssh into the source branch as well? | 13:24 |
| cjwatson | it works fine over git+ssh, it's only https that actually breaks | 13:24 |
| * zyga tries | 13:24 | |
| zyga | cjwatson: yes, that works | 13:24 |
| zyga | cjwatson: shall I open a bug? | 13:24 |
| cjwatson | zyga: that's guaranteed to work if (a) it has an ssh key set up at all (which it must do if you're using it for the target) (b) it can read over https | 13:25 |
| cjwatson | given that we have no https auth support right now | 13:25 |
| cjwatson | so only public branches work over https at all | 13:25 |
| zyga | cjwatson: ah, so I can use git+ssh to _read_ anything? | 13:25 |
| cjwatson | zyga: anything that the user in question can see | 13:25 |
| zyga | cjwatson: hmm, this _is_ a public rbanch | 13:25 |
| cjwatson | indeed, I'm not saying it isn't | 13:25 |
| zyga | cjwatson: ah, understood, ok | 13:26 |
| cjwatson | but git+ssh can certainly read any public repository | 13:26 |
| cjwatson | zyga: no need for a new bug - it's just a more serious manifestation of the existing bug about that error | 13:26 |
| cjwatson | anyway, just use git+ssh and you won't need to care | 13:27 |
| cjwatson | why standalone and not tarmac? | 13:28 |
| cjwatson | I really want there to be a decent product that people can use as a merge robot - if you've decided not to get it into tarmac then let me know and I might well pick that up | 13:28 |
| zyga | cjwatson: more on the refs, {source,target}_git_path, the word path there is slightly misleading, I think, is path really a kind of ref? | 13:28 |
| cjwatson | it's the path of the ref | 13:29 |
| zyga | cjwatson: well, we'll see but tarmac itself is not a decent product in some ways, if anything I can support both bzr and git projects this way | 13:29 |
| zyga | cjwatson: and I'm not finished, I want to have something that works and then see if it's easier to just replace tarmac with that | 13:29 |
| zyga | cjwatson: tarmac is bound to bzr | 13:29 |
| zyga | cjwatson: to python2.7 | 13:29 |
| cjwatson | it's not really bound to bzr | 13:30 |
| cjwatson | tarmac.branch is the only significant place bzr is used | 13:30 |
| zyga | cjwatson: well, it does depend on bzr heavily | 13:30 |
| cjwatson | so it just needs a git equivalent | 13:30 |
| zyga | cjwatson: tarmac cli is based on bzr | 13:30 |
| cjwatson | if you give up on tarmac, please tell me asap so that I can pick that up | 13:30 |
| zyga | cjwatson: I haven't given up on it yet but I found that it is x10 easier to provide what tarmac provies without tarmac internals | 13:31 |
| zyga | cjwatson: I can show you the prototype | 13:31 |
| zyga | cjwatson: and we can think how to graft that onto tarmac, if you have to | 13:32 |
| cjwatson | which is only a good thing from my point of view if you actually end up doing all the stuff that tarmac does | 13:32 |
| zyga | cjwatson: but from my experience with tarmac I'd only keep the name | 13:32 |
| zyga | cjwatson: oh, absolutely | 13:32 |
| zyga | cjwatson: and more | 13:32 |
| cjwatson | because we need to be able to give a really straightforward migration path to anyone that's using tarmac today | 13:32 |
| cjwatson | it's much easier if that's just a straight upgrade | 13:32 |
| zyga | cjwatson: absoluytely | 13:32 |
| cjwatson | rather than "here is a different product you can migrate to" | 13:32 |
| zyga | cjwatson: that will have to wait for the new APIs, then we can keep using tarmac-like configs | 13:33 |
| zyga | cjwatson: but in reality tarmac has a lot of downsides that I'd like to address | 13:33 |
| cjwatson | so address those in tarmac, surely it doesn't need a rewrite | 13:33 |
| zyga | cjwatson: I don't want to relu on python2.7 | 13:33 |
| cjwatson | I'm really opposed to rewrite disease | 13:33 |
| cjwatson | so if you want to support bzr in your new thing, then that's going to either involve relying on python2 for bzrlib, or using the bzr CLI; and in the latter case, that's a change you could surely propose to tarmac itself if it was part of a path towards moving to python 3 | 13:34 |
| cjwatson | and I'm sure it's not that hard to extricate its CLI from bzrlib | 13:34 |
| zyga | cjwatson: yes | 13:35 |
| zyga | cjwatson: then you won't have anything from tarmac anymore | 13:35 |
| zyga | cjwatson: if you read the code then you surely know that | 13:35 |
| zyga | cjwatson: anyway, let's wait and see till next week | 13:35 |
| cjwatson | I disagree, it means that anyone with existing tarmac plugins and such doesn't have to do significant work to change them | 13:36 |
| cjwatson | except if they use bzrlib directly themselves | 13:36 |
| zyga | cjwatson: you are right on that point, though we'd have to ask, who are tarmac users, what plugins do they have, are those plugins a real value to them or is that a stop-gap for missing tarmac feature | 13:36 |
| zyga | cjwatson: and we can (and should) ask that question, especially within ubuntu | 13:36 |
| cjwatson | I don't want to have to ask that, because it slows down migration | 13:37 |
| cjwatson | feel free from your point of view, but my priority is to make migration easy, not interrogate users | 13:38 |
| zyga | cjwatson: yeah, I see your point of view | 13:39 |
| zyga | cjwatson: I want to make a great CI story around launchpad | 13:39 |
| zyga | cjwatson: and tarmac might not be a part of that | 13:39 |
| zyga | cjwatson: or it may, as a project | 13:39 |
| zyga | cjwatson: but in either case, I strongly believe changes are needed to achieve that | 13:39 |
| zyga | cjwatson: and those are also going to be user-visible changes | 13:39 |
| cjwatson | so, obviously I'm not stopping you doing your own thing. but if you do, all I'm asking is the courtesy of telling me in a timely fashion so that I can pick up the tarmac job | 13:40 |
| cjwatson | I don't really want to get into an extended argument about this | 13:40 |
| zyga | cjwatson: yep, I understand, let's see if I can graft this back to tarmac | 13:40 |
| zyga | cjwatson: and if so, how | 13:40 |
| zyga | cjwatson: would you oppose de-coupling tarmac from bzr | 13:40 |
| cjwatson | not at all | 13:41 |
| cjwatson | though I haven't looked in detail at how practical that is for tarmac.branch | 13:42 |
| zyga | cjwatson: then, I think, we can do this within tarmac without bigger issues, in stages | 13:42 |
| zyga | cjwatson: I think hooks are the biggest issue as they rely on all the internal API | 13:42 |
| zyga | cjwatson: perhaps we can just say that for git projects, hook api is not supported the same way | 13:42 |
| zyga | cjwatson: though I'm not sure ye | 13:42 |
| zyga | *yet | 13:42 |
| cjwatson | it's really not that deep, it's just borrowing bzrlib.hooks | 13:42 |
| cjwatson | that could easily be done directly | 13:43 |
| cjwatson | I mean, it's true that a plugin gets to do target.bzr_branch.blah, but that could be wrapped gradually | 13:44 |
| zyga | cjwatson: I assume that launchpad has some hooks | 13:45 |
| zyga | cjwatson: what do they do? | 13:45 |
| cjwatson | launchpad is using pqm today, not tarmac | 13:45 |
| cjwatson | but that definitely has to change | 13:45 |
| zyga | cjwatson: ah | 13:45 |
| zyga | cjwatson: ok | 13:45 |
| * cjwatson pushes up another batch of UI changes and goes for food etc. | 13:51 | |
| zyga | cjwatson: updated the code to fetch refs only, seems to be faster this way | 13:58 |
| cjwatson | zyga: it will depend on the repository; I would expect that git can at least sometimes send fewer packs that way | 14:34 |
| zyga | cjwatson: my rough script works now, I'll see how to put it into tarmac now | 14:34 |
| cjwatson | cool | 14:35 |
| zyga | cjwatson: does launchpad automatically detect that a merge request is merged? | 14:38 |
| cjwatson | zyga: pretty sure that's still on our to-do list | 14:38 |
| zyga | cjwatson: ah, but it did do that for bzr in the past? | 14:39 |
| cjwatson | yeah | 14:39 |
| cjwatson | I have an hour or two left of the week and am otherwise mostly at a loose end, let me see if I can work out what's involved there | 14:39 |
| zyga | cjwatson: sorry for bugging you with all the questions, I don't want to drag you away from more important things | 14:39 |
| cjwatson | not a problem, this is important | 14:40 |
| * cjwatson dives into BranchMergeProposalJob. Please send a search party if I don't emerge within an hour | 14:46 | |
| zyga | cjwatson: how big is that code on launchpad? | 14:47 |
| cjwatson | 710 lib/lp/code/model/branchmergeproposaljob.py | 14:47 |
| cjwatson | could be worse | 14:47 |
| cjwatson | Oh, it's actually in lib/lp/codehosting/scanner/mergedetection.py | 14:50 |
| cjwatson | Right, so that needs complete reimplementation for git | 14:50 |
| zyga | cjwatson: do you use trello? | 14:51 |
| zyga | cjwatson: (is there a trello board for launchpad git support?) | 14:51 |
| cjwatson | we use asana | 14:51 |
| cjwatson | https://app.asana.com/0/29290342588691/29290342588691 is the main current project there, not sure if you can see that | 14:52 |
| zyga | cjwatson: nope | 14:53 |
| * zyga mutters something about canonical internal comms hell | 14:53 | |
| cjwatson | ah, the project is public to members of Ubuntu CI | 14:55 |
| zyga | cjwatson: no, it says I don't have an account at all | 14:56 |
| cjwatson | wgrant: can we make the various LP projects public to Canonical instead? | 14:56 |
| cjwatson | zyga: yeah, but that's just a matter of signing up with your @canonical.com account | 14:56 |
| zyga | cjwatson: whoever made this asana thing didn't bother to ensure everyone in canonical is registered :/ | 14:56 |
| cjwatson | via google | 14:56 |
| zyga | cjwatson: I did | 14:56 |
| zyga | cjwatson: There isn't an Asana account associated with zygmunt.krynicki@canonical.com. Sign Up | 14:56 |
| zyga | that's what asana said | 14:56 |
| cjwatson | zyga: it's a long time since I created my account, but I believe you just need to sign up and then you're part of the Canonical organisation | 14:57 |
| * zyga tries | 14:58 | |
| cjwatson | we'll still have to change the project permissions of course | 14:59 |
| zyga | cjwatson: I'm in, I see some stuff, not sure how this works yet, thanks for the link | 15:00 |
| cjwatson | ok, must be public enough | 15:00 |
| skay | I'm getting an SSLHandshakeError when I try to get a request token for launchpadlib, http://paste.ubuntu.com/11589587/ | 15:01 |
| zyga | skay: hey :-) | 15:01 |
| skay | zyga: hiya | 15:01 |
| cjwatson | if you search for "launchpad" in the search box at the top you should see the various other projects | 15:01 |
| cjwatson | skay: works for me. how old is that launchpadlib? | 15:02 |
| zyga | cjwatson: I only see one task and it's not related to git, everything must be private for me | 15:02 |
| cjwatson | zyga: which task? | 15:02 |
| zyga | cjwatson: setup NTT something | 15:02 |
| cjwatson | zyga: oh, you mean in the search box, rather than the URL I gave? | 15:03 |
| zyga | cjwatson: he url doesn't do much, it redirects me a few times | 15:03 |
| * zyga loves web 3.0, where URLs are uuids | 15:03 | |
| skay | cjwatson: whoops, got a meeting. brb | 15:03 |
| cjwatson | ah, the Ubuntu CI team has its privacy set to "Membership by Request" rather than "Public to Organization", not sure how horrible changing that would be ... | 15:04 |
| cjwatson | ev: ^- | 15:04 |
| zyga | cjwatson: with all the talk about transparency, internally we're opaque as hell, thanks to in part, all the different TODO project trackers that each part is using :/ | 15:04 |
| cjwatson | ok, if you want me to focus on this merge detection thing could we please not have an argument about task tracking? | 15:05 |
| cjwatson | I'm trying to get actual work done here | 15:05 |
| zyga | cjwatson: I'm sorry, I wasn't really trying to argue | 15:05 |
| cjwatson | quite a few missing bits of event handling, but I think the applicable ones right now are karma on branch creation, mail on branch tip changes and maybe when removing revisions, scheduling preview diff updates when refs change, and merge detection | 15:15 |
| cjwatson | I think I'll do preview diff updates first since that's a bit easier and is earlier in the process | 15:16 |
| skay | cjwatson: it works on my laptop but not ont he server I spun u | 15:43 |
| skay | cjwatson: I'll bbl | 15:45 |
| cjwatson | 17:57 <james_w> cjwatson: ah, it seems that httplib2 bundles its own certs, so they are probably out of date | 15:46 |
| cjwatson | 18:01 <cjwatson> james_w: ah, yes, that would make sense. The Debian package carries a patch to use system certs | 15:46 |
| cjwatson | 18:01 <james_w> cjwatson: ah, that will do it then | 15:46 |
| cjwatson | skay: ^- | 15:46 |
| cjwatson | skay: use the packaged httplib2, or update its certs, or apply https://anonscm.debian.org/viewvc/python-modules/packages/python-httplib2/trunk/debian/patches/use_system_cacerts.patch?revision=28693&view=markup | 15:47 |
| cjwatson | skay: monkey-patching httplib2.CA_CERTS = "/etc/ssl/certs/ca-certificates.crt" might work too | 15:48 |
| cjwatson | skay: or in fact you can provide a ca_certs_locater module with a get() function that returns that path | 15:48 |
| cjwatson | skay: (you can see it in the context of that patch URL) | 15:48 |
| zyga | cjwatson: setting "merged at revision" from launchpad UI fails | 16:13 |
| cjwatson | zyga: oops id? | 16:16 |
| zyga | cjwatson: I don't get an oops, it just doesn't change | 16:17 |
| zyga | https://code.launchpad.net/~zyga/hwcert-tools/+git/hwcert-tools/+merge/261196 | 16:17 |
| cjwatson | zyga: ok, please file me a bug and I'll have a look | 16:17 |
| zyga | thanks | 16:17 |
| zyga | https://bugs.launchpad.net/launchpad/+bug/1462436 | 16:19 |
| ubot5 | Launchpad bug 1462436 in Launchpad itself "Unable to set "merged at revision" using launchpad UI for git merge requests" [Undecided,New] | 16:19 |
| cjwatson | zyga: did you set it to 45244162232911506a84693381705e12ae6124ac ? | 16:20 |
| zyga | cjwatson: yes | 16:20 |
| cjwatson | zyga: ok, it's in the db, the ui's just showing the wrong field | 16:20 |
| cjwatson | trivial fix | 16:20 |
| zyga | cjwatson: cool, thanks! | 16:20 |
| zyga | cjwatson: with anonymous login, reviewed_revid on a bzr merge request is '<email address hidden>' | 16:41 |
| zyga | cjwatson: is that expected, I didn't assume this is restricted information | 16:42 |
| zyga | cjwatson: https://code.launchpad.net/~zyga/plainbox/more/+merge/261249 | 16:42 |
| cjwatson | zyga: I don't see that. Screenshot please? | 16:44 |
| zyga | cjwatson: through the API | 16:44 |
| cjwatson | oh right | 16:44 |
| zyga | cjwatson: I can make a simple python snipped if you want | 16:45 |
| cjwatson | no need | 16:45 |
| cjwatson | but it's getting towards the end of the day and I can't stack this up in my memory, so another bug please :) | 16:45 |
| zyga | cjwatson: sure :-) | 16:45 |
| zyga | cjwatson: sorry for doing this on Friday evening :) | 16:46 |
| zyga | cjwatson: quick offtopic, how do I work with staging launchpad with 2fa, I cannot log in to change 2fa settings | 16:46 |
| cjwatson | zyga: https://help.ubuntu.com/community/SSO/FAQs/2FA#Why_doesn.27t_my_2F_login_work_on_staging.3F | 16:47 |
| zyga | ha, it's a FAQ :) | 16:47 |
| zyga | thanks | 16:47 |
| cjwatson | zyga: though for git-related stuff you want to use qastaging anyway, and that uses production SSO | 16:47 |
| zyga | cjwatson: oh, I didn't know, thanks | 16:47 |
| cjwatson | staging has no git backend | 16:47 |
| zyga | cjwatson: still, how do I sign in in the first place, 2fa is enabled but I don't have a staging-specific 2fa device | 16:48 |
| cjwatson | you need to make one | 16:48 |
| cjwatson | and ask IS for help I suppose | 16:48 |
| cjwatson | we don't admin SSO | 16:48 |
| zyga | cjwatson: ah, that explains it, thanks | 16:48 |
| zyga | I'll use qastaging | 16:48 |
| zyga | https://bugs.launchpad.net/launchpad/+bug/1462449 | 16:49 |
| ubot5 | Launchpad bug 1462449 in Launchpad itself "branch_merge_request.reviewed_revid is '<email address hidden>" if operated through anonymous API login" [Undecided,New] | 16:49 |
| cjwatson | ta | 16:50 |
| zyga | cjwatson: note, that is for _bzr_ not, git MR | 17:01 |
| zyga | cjwatson: you added the 'api git' tags | 17:01 |
| cjwatson | so I did, fixed | 17:02 |
| zyga | cjwatson: I'm about to EOD, it's not tarmac but I'd love if you could give some feedback on the git and bzr merge methods | 17:36 |
| zyga | cjwatson: specifically if the methods I used to derive various names are sane or not | 17:37 |
| zyga | cjwatson: https://git.launchpad.net/~zyga/+git/pmr/tree/process-merge-requests | 17:37 |
| zyga | cjwatson: tested on wily, though it looks like it could work all the way back to oldest supported LTS | 17:38 |
| cjwatson | zyga: haven't thought about it in general but its LP API interaction seems OK, with the exception of the getMergeProposals thing that we knew about | 17:40 |
| zyga | cjwatson: I was a little worried with the git remotes | 17:40 |
| zyga | cjwatson: basically with the path.split[-1] thing to get the branch name | 17:40 |
| cjwatson | why do you need to do that? git should accept fully-qualified ref paths | 17:41 |
| cjwatson | .split[-1] is definitely wrong since ref paths could be things like refs/heads/people/cjwatson/feature | 17:41 |
| cjwatson | but I think you can just drop the split | 17:42 |
| zyga | cjwatson: hmm, perhaps I don't know how to do that, I could only get it to work with 'git merge $remote/$branch' | 17:42 |
| zyga | cjwatson: oh, good point | 17:42 |
| * zyga uses / in path names all the time due to git-lp | 17:42 | |
| zyga | cjwatson: just the ref path cannot be used IMHO, as it can be identical | 17:42 |
| zyga | cjwatson: for both the target and source branch and something has to scope it (the remote) | 17:42 |
| cjwatson | sure | 17:43 |
| cjwatson | you might actually be best off stripping refs/heads/ and using refs/remotes/{source,target}/stripped_path | 17:44 |
| cjwatson | possibly | 17:44 |
| zyga | cjwatson: ah, good idea | 17:44 |
| zyga | let me try that | 17:44 |
| cjwatson | we have a plan to expose MPs inside the refs/merge/ namespace or similar, which will simplify this | 17:44 |
| cjwatson | like github does with refs/pull/ | 17:44 |
| zyga | cjwatson: oh, cool, so all of that would be visible in the remote itself | 17:45 |
| zyga | cjwatson: I'll tweak this for a few more hours today to get it to comment and work (perhaps as a snap or charm) | 17:46 |
| zyga | cjwatson: and next week I'll focus on tarmac | 17:46 |
| zyga | cjwatson: who maintains tarmac today (who's going to review my patches), do you know that by any chance? | 17:46 |
| cjwatson | I expect you know as well as I do | 17:46 |
| zyga | cjwatson: we'll see next week :-) | 17:49 |
| zyga | cjwatson: thanks for all the help today, I'll see you on Monday | 17:49 |
| cjwatson | sure, see you | 17:49 |
| zyga | cjwatson: who might be interested in a status update on the tarmac porting effort | 18:09 |
| zyga | cjwatson: I planned on sending a mail to checkbox-devel and CCing you | 18:09 |
| zyga | cjwatson: but perhaps there's another forum I should target | 18:09 |
| zyga | cjwatson: well, anyway, I need a break, feel free to FWD the mail to a different location | 18:15 |
| cjwatson | zyga: launchpad-dev@lists.launchpad.net would be good | 22:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!