[00:01] <Kinnison> then look at bzrlib/smart/medium.py
[00:01] <Kinnison> and tell me how on earth bzr_access could ever work
[00:02]  * Kinnison pouts prettily at jelmer
[00:05] <Odd_Bloke> Kinnison: Presumably if you're using bzr:// and not bzr+ssh://, IIR this problem correctly.
[00:09] <Kinnison> bzr_access is explicitly for bzr+ssh though
[00:09] <Odd_Bloke> Then I don't recall this problem correctly. :p
[00:09] <Odd_Bloke> Sorry. :(
[00:13] <Kinnison> :-(
[00:13] <Kinnison> bzr:// uses a tcp connection
[00:13] <Kinnison> which is fine if you can trust the network between you and the server
[00:14] <Kinnison> sftp:// is slow, lacks remote hooks, but works for untrusted networks at the expense of needing a unix user per person who can access trees
[00:14] <Kinnison> bzr+ssh with bzr_access had promise, but has turned out to be useless
[00:14]  * Kinnison sighs
[05:41] <ubotu> New bug: #182469 in bzr "Bazaar has encountered an internal error: exceptions.MemoryError: " [Undecided,New] https://launchpad.net/bugs/182469
[06:51] <ubotu> New bug: #182477 in bzr "bzr crarshing when trying to commit to the APT repository" [Undecided,New] https://launchpad.net/bugs/182477
[20:10] <MWinther> Eeey... How do I enable bzr support in emacs?
[20:12] <Verterok-laptop> MWinther: I don't use emacs, did you look: https://launchpad.net/vc-bzr ?
[20:15] <MWinther> Verterok: Oh, thanks... I missed the instructions in the comments.
[20:16] <Verterok-laptop> np, glad to help ::D
[20:25] <Lo-lan-do> Hi all.  I'd just like a confirmation: private branches can be rebased, but as soon as they're made public they should only merge and pull, right?
[20:28] <dato> yeah
[20:30] <Lo-lan-do> Out of curiosity, what happens if I rebase a branch that someone else has already branched?
[20:31] <jelmer> Lo-lan-do: yes; other than for bzr-svn (which can only track lhs history) there shouldn't be much reason to use rebase
[20:31] <jelmer> s/which/because it/
[20:32] <jelmer> Lo-lan-do: Next time they pull they will get a branches diverged error
[20:32] <jelmer> Lo-lan-do: and if they merge afterwards, the rebased revisions end up twice in "bzr log"
[20:32] <Lo-lan-do> Oh.  Right, I'll refrain then :-)
[20:32] <dato> one use case is for right before pushing
[20:33] <dato> if you notice you're diverged, you rebase and push
[20:38] <Lo-lan-do> I see.
[20:39] <Lo-lan-do> Say, is the LCA merge algorithm the default in 1.1?
[20:40] <Lo-lan-do> I've read it's the bee's knees, so if it's really better I guess I should replace --weave with it in my scripts?
[20:42]  * rjek wonders idly if there's a bzr-cvs.
[20:42] <rjek> I suppose it's more of a faff due to the lack of changesets.
[20:42] <Lo-lan-do> rjek: The website says there isn't
[20:42] <Lo-lan-do> (I wondered the same thing yesterday)
[20:43] <rjek> I just want to import another project's source tree into mine.  It'd be nice to have history, but it's not essential.
[20:43] <Lo-lan-do> I'd suggest cvs2svn then bzr-svn
[20:43] <thumper> rjek: it is possible to import CVS to bzr using launchpad
[20:43] <thumper> rjek: if it is open source
[20:43] <rjek> thumper: It is - it's on sf's CVS server.
[20:44] <rjek> I only want to make a handful of changes to the source stored in CVS for my own purposes, it's more about reproducability than version control tbh.
[20:44] <thumper> rjek: luanchpad uses cscvs to import cvs to bzr
[20:44] <rjek> Does cscvs have advantages over cvs2svn?
[20:45] <thumper> rjek: I don't really know that much about it
[20:45] <thumper> rjek: except cscvs goes from cvs -> bzr
[20:45] <thumper> rjek: rather than cvs -> svn
[20:45] <rjek> Well, yes - there's an advantage in removing one of the steps, clearly.
[20:45] <thumper> I'd be curious to see how cvs-svn, then bzr-svn works
[20:45] <rjek> But I know bzr-svn does a good job.
[20:46] <rjek> So if cvs2svn does a good job, you'd hope the output would be high-quality.
[20:46] <thumper> rjek: one of the things that cscvs does is it tracks CVS changes
[20:46] <thumper> rjek: rather than a one-off conversion
[20:46] <rjek> That might be more useful, tbh.
[20:46] <rjek> (ie, that *is* an advantage I would be interested in.)
[20:54] <rjek> thumper: What's involved in getting Launchpad to track a CVS repository for me?
[20:55] <thumper> rjek: https://help.launchpad.net/VcsImports
[20:55] <rjek> Ta
[21:10]  * rjek mutters at Launchpad.
[21:10] <rjek> Apparently, optional fields are compulsory.
[21:18] <thumper> rjek: instead of muttering, file a bug :)
[21:20] <rjek> I wish to use Launchpad for the minimum amount of time I can get away with :)
[21:20] <thumper> rjek: why?
[21:21] <thumper> rjek: best to move this conversation to #launchpad
[21:21] <rjek> I generally find it hateful.
[21:31] <dlee> I'm realizing I'm sort of swimming upstream here... trying to find a nice way to at least convert, if not actively track, cvs to bzr; but we have about 40 projects in cvs on a FreeBSD system with people using Windows CVS clients to check in and manage Windows projects.  The projects contain mostly Windows text but also some binaries.
[21:32] <rjek> I'm told cscvs is the way Launchpad does it.  I'm also told Tailor, once set up, can nicely do incremental imports.
[21:32] <dlee> I believe bzr *always* checks in/out exactly what you send in:  Check in text from windows, check out CRLF no matter where you are.  But cvsps-import gets LF only from CVS in all cases I've tried, so cvsps-import can't currently manage the conversion because all checkouts would be LF-only even under Windows...
[21:33] <dlee> Does anyone know if cscvs (which I hadn't heard of until now) could help with this at all?
[21:34] <lifeless> dlee: so the limiting factor here is we haven'timplemented line ending translations
[21:34] <dlee> rjek:  I've used Tailor to some good effect with CVS (it *will* do CRLF properly it seems), but in my experience, it fails to notice CVS tags, so they don't show up on the Bzr side.
[21:35] <lifeless> dlee: the 'right way' to convert your repository is to convert it in binary form and then use line ending translation to get the text files to be checked out as text files on windows
[21:35] <dlee> lifeless:  Could be thought of that way.  Could also be said that the limiting factor is Windows insists on an annoying EOL translation. :P~~~
[21:35] <lifeless> well, older macs have different EOL to unix and windows
[21:35] <lifeless> so its a general problem
[21:36] <dlee> But anyway... I'd be fine with putting CRLF in Bazaar so everything on the Bzr side checks in/out with no translation... unless (I) someone knows a reason against that, or (II) I can't find a solution before Bzr implements such translation
[21:37] <lifeless> I think you will have to hack up a solution - editing cvsps for example
[21:37] <dlee> lifeless: point.
[21:37] <dlee> lifeless:  I tried hacking cvsps-import but not cvsps itself.
[21:38] <dlee> lifeless:  Isn't it true though that, if I check in text on Windows, it becomes CRLF inside the Bazaar branch?
[21:40] <dlee> My reason for thinking it would be best to get things in as CRLF and then not need translation is, mostly, that I thought that is what will automatically happen for new projects we do anyway.
[21:41] <lifeless> currently bzr just stores the bits untranslated
[21:41] <lifeless> so if your editor makes CRLF, you get CRLF
[21:41] <lifeless> I meant hacking cvsps-import actually ;)
[21:43] <dlee> Right... so in my mind at least, adding CRLF translation won't really help us here unless it happens before we kick off the whole CVS-to-Bazaar conversion, because currently, all projects either will by default, or must for consistency be made to, be stored as CRLF internally in Bazaar.
[21:45] <dlee> My knowledge of Python remains limited, but my last experiment there was to try using universal_newlines.  I suspect subprocess.popen.communicate() (if that's the right object hierarchy) of quietly converting CRLF to LF.  Cygwin could also be doing it for pipes though it doesn't for output redirection I guess.
[21:46] <lifeless> well
[21:46] <lifeless> cvs will ahve everything stored in LF at the moment
[21:46] <lifeless> there used to be flags for this in the cygwin environment
[21:46] <dlee> I suppose the next shot I'd have is to pass all cvs/co output through an output-to-file, read-from-file sequence, and see if that preserves line endings.  But I have a better idea that I don't know how to do:
[21:47] <dlee> (I do have MSDOS endings set in Cygwin, yet all this still happens)
[21:47] <dlee> Better idea, if it can be done:  Add a cvsps-import flag that makes it convert to CRLF on CVS files that do not have -kb set.  Sound?
[21:48] <dlee> I like this better because it's OS-independent, and I could mass-convert all 40 projects on the same fbsd system where the CVS repos are. :)
[21:48] <lifeless> -kb isn't a historical setting IIRC
[21:48] <lifeless> if it is then sure
[21:48] <lifeless> hmm, actually paging it in - it is
[21:49] <dlee> Sorry... if you're doing serious work, don't swap on my account. :-)  But the help is sure appreciated.
[21:49] <lifeless> I think thats a reasonable short term strategy
[21:50] <lifeless> the downside is that when bzr gets this natively all your text files will see a full-file diff
[21:52] <dlee> If/when bzr includes LF translation, won't we need a way to convert existing branches to an internal standard too?  The best I can imagine is svn-like properties, where you flag a file as one ending type or another to make Bzr (I) standardize it internally and (II) spit it out according to the given type.  Not sure whose project endings are though...
[21:54] <dlee> Scenario:  Under Windows, I check in text.txt and word.doc.  They are both stored without translation--text.txt as CRLF and word.doc as what it is.  If I check out on Unix, I get the same--CRLF and doc.  Then native ending support comes in...
[21:54] <dlee> If what you're saying is true, I'd see a full file diff on those then too, even though I hacked nothing.  And I think it's inevitible, unless we deal with the branch conversion as a sort of upgrade-type thing.
[21:57] <dlee> those == text.txt
[22:03] <dlee> Hmm...I guess internal conversion is optional as long as flagging a file as specifically CR, CRLF, or LF forces (I) output (co etc.) translation and (II) input-time translation to ending type detected in existing branch copy.  I imagine it'll be done though as input-time translation to specified type, and *maybe* output-time also.
[22:04] <lifeless> we have  wiki page about it
[22:04] <lifeless> bzr line ending something or other - google FTW
[22:08] <dlee> lifeless: looking...
[22:08] <igc> morning
[22:16] <dlee> lifeless:  Not finding it...but I'll table all this until I do so you don't have to say a lot of stuff I should already know.
[22:19] <lifeless> http://bazaar-vcs.org/LineEndings
[22:19] <mtaylor> is there a good internal API doc anywhere for bzr?
[22:19] <mtaylor> or is poking through the code the best way to get a handle on things?
[22:19] <lifeless> there are api docs
[22:19] <lifeless> on the web
[22:20] <lifeless> http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.html
[22:20] <lifeless> though I think thats an old copy, google isn't finding the newer one for me
[22:21] <mtaylor> lifeless: and that's just generated from pydoc stuff, right?
[22:21] <lifeless> I use 'pydoc foo' a lot
[22:21] <mtaylor> so the same info as in the docstrings
[22:21] <lifeless> yes, though it is richer than pydoc cause it hyperlinks
[22:22] <mtaylor> well right... but it doesn't have an overview of like "a bundle contains a ... " or whatever
[22:22] <lifeless> mtaylor: there is also doc/developers/
[22:23] <mtaylor> lifeless: hm. maybe I'll look in tere
[22:23] <mtaylor> I'm working on adding bzr support to reviewboard
[22:23] <mtaylor> and I'm getting tired of reading source
[22:23] <mtaylor> :)
[22:23] <lifeless> e.g.
[22:23] <lifeless> http://doc.bazaar-vcs.org/latest/developers/bundles.html
[22:24] <lifeless> http://doc.bazaar-vcs.org/latest/developers/bundle-format4.html is probably what you are working with
[22:24] <mtaylor> lifeless: ah... yes, this looks like more what I'm looking for
[22:26] <mtaylor> lifeless: so, while I'm bugging you - if I have a branch and a bundle - the bundle contains a list of file ids and a list of revisions that go with the file ids
[22:26] <mtaylor> lifeless: so I should be able to get a path of the file for a revision based on revision id and file id
[22:26] <lifeless> have you looked at the bundle buggy code? it has to do everything you are doing
[22:26] <mtaylor> lifeless: yeah - I was just about to start walking throught that
[22:27] <lifeless> bundles are not yet directly usable aas branches; they have to be installed somewhere, then you can get a revision tree of the revision the bundle introduced (or a delta, for cherrypick bundles)
[22:27] <mtaylor> I guess my question is... the bundle buggy code seems to merge_directive.install_revisions(branch)
[22:27] <mtaylor> ah
[22:28] <mtaylor> ok, that makes it much clearer
[22:28] <mtaylor> I was trying to think of a bundle as usable like a branch
[22:28] <mtaylor> ok
[22:28] <mtaylor> sweet. thanks!
[22:29] <mtaylor> lifeless: so if I get a Branch, and then install the revisions of the bundle into the branch, I haven't actually applied that bundle yet, right?
[22:31] <mtaylor> abentley: hey - I added some patches to a local bundlebuggy to support multiple branches - are you interested in them ?
[22:32] <abentley> Interested?  Sure.  What do they do?
[22:33] <mtaylor> abentley: so that I can configure a local repository containing more than one branch
[22:33] <mtaylor> and then bb can match a merge directive to the branch it belongs with
[22:33] <mtaylor> so you can manage more than one tree with one bb
[22:33] <mtaylor> should I send them to you directly? or to the bzr.dev bundlebuggy?
[22:34] <abentley> Directly to me, please.
[22:34] <mtaylor> ok
[22:35] <lifeless> abentley: oh hey!
[22:35] <abentley> lifeless: Hi.
[22:35] <lifeless> abentley: I was looking for you a few minutes back; I've just mailed about BreadthFirstSearcher and fetch
[22:35] <lifeless> abentley: how do you feel about me modifying the searcher to not return ghosts (including the start revisions if they are absent)
[22:35] <abentley> I don't see anything yet...
[22:36] <lifeless> literally just sent
[22:36] <abentley> lifeless: well, my gut says that's the wrong place to be filtering out ghosts.
[22:37] <abentley> I see it now.
[22:37] <lifeless> I've had a poke around, and couldn't see any use case for it. ParentProvider needs to return ghosts; I don't think breadth first searching does,.
[22:37] <lifeless> because breadthfirst searching is already hiding ancestry and topological order details
[22:37] <lifeless> it could for instance return (next_revs, next_ghosts) if you like
[22:38] <lifeless> that would be an api break I guess, so next_with_ghosts() or something for api transition
[22:41] <abentley> lifeless: I think we should be including ghosts in our APIs except where it's clear that they must not be present.  Otherwise, we are likely to get bugs related to hiding ghosts, and never know it.
[22:42] <abentley> Bug due to using ghosts when they should be ignored will be much more visible.
[22:42] <lifeless> this is one
[22:42] <abentley> And it's pretty visible, right?
[22:43] <lifeless> I agree with your point; however bfs is discarding data
[22:43] <lifeless> it knows what rev ids are ghosts
[22:43] <lifeless> it needs to propogate that information
[22:44] <mtaylor> abentley: sent
[22:44] <lifeless> or else we end up doing double-queries
[22:44] <abentley> lifeless: Propogating that info is completely reasonable.
[22:44] <lifeless> What do you think of the changed return value I suggest ?
[22:44] <lifeless> (or new on a new method)
[22:44] <abentley> mtaylor: got it.
[22:45] <abentley> lifeless: That would be fine on a new method, but I think the default method should just return revision_ids, ghost or not.
[22:46] <lifeless> I'd like to deprecate next() I think if I add a new method unless there is a good reason for having two query interfaces
[22:46] <abentley> Well, I'd like to include ghosts by default.
[22:47] <lifeless> they will be included
[22:47] <abentley> Won't they be split into a different group?
[22:47] <lifeless> yes
[22:47] <abentley> I think that ghosts should be not split into a separate group by default.
[22:47] <lifeless> I think that once we have identified the ghosts we should keep the separate
[22:48] <abentley> I think that operations should only be paying attention to whether a revision-id is a ghost if this data is relevant to the operation.
[22:48] <lifeless> because otherwise we are forcing roundtrips on other parts of the code; or making other parts of the code be filtering when they should not
[22:49] <abentley> Your proposed API would encourage people to do next()[0] even when ghosts should be included, because 95% of the time there aren't any ghosts.
[22:49] <lifeless> I think you are creating a source of performance / correctness bugs for users of that interface
[22:49] <abentley> I have not proposed anything that would damage performance.
[22:49] <lifeless> I explained above how it hurts performance
[22:49] <abentley> Your explanation suggests a misunderstanding of what I'm saying.
[22:50] <lifeless> anyhow, I'll do as you desire because my need will be met by the new method
[22:50] <abentley> If you want an API that splits out ghosts, fine.
[22:50] <abentley> But don't deprecate the old one.
[22:50] <abentley> Because it's worse for people to ignore ghosts when they should not than to pay attention to ghosts when they should not.
[22:52] <lifeless> I understand your motivation and agree in principal; on this particular API I think you are wrong.
[22:52] <lifeless> anyhow, -> doing the new method now.
[22:53] <lifeless> in particular returning the start revision ids for a search when they are absent from the repository is really hard to work with
[22:53] <lifeless> and thats just the special case of ghosts
[22:53] <lifeless> abentley: so I have a separate request; I want to modify next() to return StopIteration if the start revisions are all ghosts
[22:54] <lifeless> abentley: I don't have to, but please think about that
[22:54] <abentley> Why?
[22:55] <lifeless> because I spent the greater part of an hour while writing the pack fetch logic to handle that case; its sufficiently confusing as an api that there is a 5 line paragraph explaining code that uses it
[22:55] <abentley> But now you'll have an API that splits out all ghosts.
[22:55] <abentley> So callers that don't want ghosts won't get any.
[22:56] <lifeless> yes, and I'll use that; I'm thinking of users of next, if people that want to use it do so
[22:57] <abentley> That seems like an inconsistency in the API.
[22:57] <poolie> hello
[22:57] <abentley> If you ask for 5 ghosts and 1 non-ghost, you get all of them listed, but if you ask for 6 ghosts only, you get nothing?
[22:58] <lifeless> you're right I guess, I'll just write the more usable api I need and leave it at that. It feels wrong to have an api that discards information which is relevant to its callers is all
[22:59] <abentley> Btw, one client that wants to keep references to ghosts is Graph.heads
[22:59] <abentley> poolie: Hi.
[22:59] <poolie> hello
[22:59] <poolie> welcome
[23:00] <abentley> Thanks.
[23:02] <lifeless> abentley: it does?
[23:02] <abentley> Sure.  We can't assume a revision isn't a head if we don't know its derivation.
[23:03] <lifeless> we can't assume it is either; I would expect us to signal that to the caller
[23:05] <lifeless> hmm, this means that we'll generate inconsistent last-changed revisions for baz imports, just in reverse order to how we used to do it
[23:05] <abentley> If the revision itself is a ghost, but is not reachable from candidate heads, it must be a head.
[23:07] <abentley> We may wind up with some false heads if some descendant is a ghost.  I don't think we can avoid that.  But we can know whether the ghost revision itself is a head.
[23:09] <lifeless> the if the revision is /not/ a ghost, but is not reached, and we encounted ghosts, we cannot tell if it is a head or not, unless it reached the other heads
[23:09] <lifeless> if the revision is a ghost, it is not a head if it is reachable from some other head
[23:09] <lifeless> so yes we have to consider ghosts in heads(), but we need to know within heads() which are ghosts and which aren't to know whether to say 'head', or 'indeterminate'
[23:10] <abentley> lifeless: agreed.
[23:10] <lifeless> we can avoid ending up with false heads if our api is allowed to signal that it could not determine the answer. Which any ghost handling api must be able to do
[23:11] <lifeless> this is ok, it just means that we're not finished with heads()
[23:11] <abentley> Which is pretty reasonable since I implemented heads by accident :-)
[23:13] <abentley> mtaylor: these key lengths you're proposing don't seem to have any basis in specs.
[23:14] <abentley> for example, bug ids are URLs, and I don't think there's any length limit on URLs.
[23:15] <abentley> Even IE can do 2048-char URLs.
[23:16] <Peng_> Apache can limit URLs. I once got a 400 Bad Request error or something for a 13,000 char URL.
[23:18] <lifeless> squid limits to 4K at the moment, we're working on raising that
[23:18] <abentley> Peng_: Sure.  But does the spec say anything?
[23:18] <lifeless> its not limited
[23:18] <mtaylor> abentley: yes... that's one of the things I wanted to talk to you about... is there a place I can find what those lengths should look look?
[23:18] <mtaylor> look like, rather?
[23:19] <abentley> Well, URLs have no length limit.
[23:19] <abentley> I don't think email address do either, but I haven't checked as carefully.
[23:19] <mtaylor> ah, I suppose if I read the next line in your response. :)
[23:20] <mtaylor> ok. well then it might be a good idea to remove the lenght limit and introduce an artificial primary key there then
[23:20] <ubotu> New bug: #182715 in bzr "Graph.heads() gives false heads sometimes" [Undecided,New] https://launchpad.net/bugs/182715
[23:20] <mtaylor> as using a blob as a primary key is usually a really inefficient thing
[23:21] <abentley> mtaylor: That's why I've been slow responding to your first patch.
[23:21] <mtaylor> oh, did I send one already?
[23:21]  * mtaylor has a dead brain this week
[23:21] <mtaylor> I'll see if I can rework that
[23:21] <abentley> mtaylor: if the column is indexed, it shouldn't matter, should it?
[23:21] <mtaylor> no, it shouldn't
[23:22] <mtaylor> it's just that normally seconary indexes will contain a copy of the primary key so it knows how to point to the right row
[23:22] <mtaylor> so with a really big primary key, you wind up copying that data too much
[23:23] <abentley> So with variable-length keys, do you still pay a penalty when the keys are small?
[23:25] <mtaylor> not necessarily - that's sort of db engine specific
[23:26] <mtaylor> but in this case, elixir is making that column a blob
[23:26] <mtaylor> and most dbs have really bizarre implemenations of blobs at best
[23:26] <mtaylor> and in this case, mysql doesn't allow a blob as a primary key unless you specify a prefix length on the primary key
[23:27] <rjek> branch-format: Unable to handle http code 401: Unauthorised
[23:27] <rjek> Tsk.
[23:28] <abentley> Well, I'm in favour of using artificial keys-- makes for cleaner URLs.  But I can't say I'm looking forward to adding migration code.
[23:29] <mtaylor> hehe
[23:29] <mtaylor> no
[23:29] <mtaylor> I was justing thinking that myself
[23:30] <mtaylor> I'll see if I can get it working and then send you a new patch
[23:31] <abentley> Also, renaming dev.cfg is okay, but I would prefer that it continue to specify SQLite.
[23:34] <abentley> Probably I should roll config.ini into the TG config system.
[23:34] <abentley> That way we can stick all the local configuration in there.
[23:34] <abentley> including databases and web paths.
[23:36] <abentley> Also, I don't think "tree" is the right term for branches.
[23:38] <abentley> Also, erroring if the target_tree is not going to work on bzr.dev-- *lots* of people don't set target_tree correctly.
[23:38] <abentley> Also, please don't comment-out code.  We have a VCS, so just delete it.
[23:39] <abentley> We can always get it back if we want.
[23:42] <abentley> Also, you've got '/buggy' in a lot of places where it shouldn't be.
[23:43] <abentley> So I think the idea is an improvement, but there's some work needed on the implementation.
[23:44]  * abentley heads out for groceries
[23:58] <lifeless> abentley: ok that patch is sent in


[01:11] <sergio_br22> every week I get some broken package in xenial :/
[01:11] <sergio_br22> stuff is really moving fast
[01:11] <sergio_br22> i just fixed a package last week, and it's broken again
[12:37] <Odd_Bloke> We have a script that generates a summary of merge proposals that we're interested in, and we want to get a list of all the merge proposals that have a review requested from our team.  However, team.getRequestedReviews excludes MPs that someone in the team opened (as documented at https://launchpad.net/+apidoc/devel.html#team-getRequestedReviews), making this difficult.
[12:37] <Odd_Bloke> I've had a poke around in a debugger, but I didn't see a good way of getting around this; is it possible to get what we want from the team object?
[12:38] <Odd_Bloke> (If not, we could presumably iterate over things submitted by members of the team to gather the list, but I didn't want to resort to that if I'm missing an easier way of doing it)
[12:38] <wgrant> Odd_Bloke: Unfortunately there's no review requested of the team once someone claims it.
[12:38] <wgrant> It is completely transferred.
[12:39] <wgrant> Oh.
[12:39] <Odd_Bloke> wgrant: That's fine; but it doesn't even return unclaimed reviews.
[12:39] <wgrant> I miread.
[12:39] <Odd_Bloke> :)
[12:43] <wgrant> Odd_Bloke: It doesn't exclude MPs that someone in the team opened. That bit of the docstring just means that it only returns MPs that have a direct review requested of the team or person on which you invoke the method; it doesn't include reviews requested of teams that they participate in, so it doesn't return the full set of reviews that they can do.
[12:43] <wgrant> That doesn't seem like it would be a problem for you. What's the exact issue you're seeing?
[12:51] <Odd_Bloke> wgrant: Ah, OK; let me try to get a minimal test case for you (after lunch ^_^).
[12:51] <wgrant> Odd_Bloke: I must regrettably sleep imminently, but someone else might be around then.
[12:55] <Saviq> hey guys, it started happening yesterday - s390x builds for unity8 get stuck each build https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-010/+build/9031715
[12:55] <Saviq> we've been cancelling them, but I thought it might be interesting for you
[12:56] <wgrant> Ah, is that why all the s390x builders keep dropping out...
[12:56]  * wgrant pokes.
[13:04] <wgrant> Saviq: Looks like an sbuild change, only hitting s390x because the buildds are xenial due to the new port. Keep cancelling the builds for now, but we're investigating a fix.
[13:08] <Saviq> wgrant, ack, tx
[13:35] <Odd_Bloke> wgrant: cjwatson: We've seen our arm64 builds get stuck at https://launchpad.net/~cloudware/+livefs/ubuntu/xenial/cpc/+build/52672 a couple of times now; any ideas what's going on?  (The last one which I cancelled did not end up with a build log)
[13:35] <Odd_Bloke> (That last one being https://launchpad.net/~cloudware/+livefs/ubuntu/xenial/cpc/+build/52586)
[13:37] <cjwatson> Odd_Bloke: Possibly the same as the s390x issue above.
[13:37] <cjwatson> I bet it depends on the apt in the chroot.
[13:39] <Odd_Bloke> Our s390x builds are passing (and hit that same codepath).
[13:39] <Odd_Bloke> (Which isn't to say it isn't the same issue manifesting itself differently, of course :p)
[13:40] <cjwatson> Well, wait, livefs builds can't be the same thing.
[13:40] <cjwatson> Odd_Bloke: I can't see this build, though.  What does it look like from your end?
[13:41] <Odd_Bloke> cjwatson: It's "Currently building" with http://paste.ubuntu.com/15107531/ as Buildlog.
[13:41] <cjwatson> Um, not sure
[13:41] <Odd_Bloke> cjwatson: Which is what the last build looked like before I cancelled it (which then didn't get a build log attached to it).
[13:41] <cjwatson> wgrant: ^- could that be the out-of-loop-devices thing?
[13:50] <wgrant> Doesn't really look like it, but I suppose it's possible...
[13:50] <wgrant> I cancelled one just like that this morning.
[13:51] <wgrant> Could also just be a boring nbd hang.
[14:39] <cjwatson> Saviq: fixes on their way
[15:13] <Saviq> cjwatson, there you go https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-010/+build/9032689
[15:14] <cjwatson> Saviq: thanks, just awaiting proposed-migration of sbuild now
[15:15] <cjwatson> at least for the s390x case.  this does affect some other architectures too, but the exact circumstances that trigger it are build-dependent
[16:08] <Odd_Bloke> cjwatson: Has anything changed for the arm64 builders that might have caused us to start seeing this?  (We've never seen it before yesterday, and it's now happening most runs)
[16:18] <cjwatson> Odd_Bloke: We're gradually moving things into scalingstack, but you seem to have had successful runs on scalingstack builders before.
[16:18] <cjwatson> Odd_Bloke: Which builder is this on?
[16:19] <cjwatson> Odd_Bloke: bos01-arm64-009, right?
[16:19] <Odd_Bloke> cjwatson: I can't see the builder which the failures happened on; our current build (which hasn't reached the potential hang point yet) is on -004.
[16:24] <cjwatson> Odd_Bloke: You've definitely had a mix before today.  I'm sorting out some other upgrades right now, but as soon as I get the chance let me try resetting the bos01-arm64-{001..010} guests and seeing if that helps.
[16:25] <Odd_Bloke> cjwatson: Thanks. <3
[16:32] <Odd_Bloke> (So it looks like it hangs when we try to use a loop device for not-the-first-time; don't have the full build log so I don't know if I missed one in between refreshes, but it might be the second time)
[17:10] <cjwatson> Saviq: s390x is all sorted now.  as I say the same thing will affect other architectures in some situations - I've filed a ticket for the upgrade
[17:11] <Saviq> cjwatson, thanks
[22:12] <qengho> Hi hi. I'm stuck by the bzr-git bug that pukes when a Git commit in a foreign import is GPG signed. https://bugs.launchpad.net/bzr-git/+bug/1084403
[22:13] <qengho> Given first-class-ish Git branches on LP, can the importer import straight to a git branch, instead of trying to bzr-ize it?
[22:21] <wgrant> qengho: Direct git->git imports are not currently supported, but I was actually going to start investigating that today.
[22:22] <wgrant> It's easy to mirror manually with a cronjob in the interim.
[23:38] <qengho> I rebooted, didn't see reply. Is there a way to import a Git repo to Launchpad, not Bzr-izing it along the way?
[23:41] <wgrant> 09:21:54      wgrant | qengho: Direct git->git imports are not currently supported, but I was actually going to start investigating that today.
[23:41] <wgrant> 09:22:05      wgrant | It's easy to mirror manually with a cronjob in the interim.
[23:42] <qengho> wgrant: right. Thanks.


[00:01] <GeorgeJ> I'm running Ubuntu 12.10. I've installed deluged and deluge-web. The problem is: deluged comes with an init script in /etc/init.d, which, as long as I can tell tells upstart when the service starts, here's the file: http://paste.ubuntu.com/1497703/. The problem is, I wrote an upstart job for deluge-web as such: http://paste.ubuntu.com/1497681/. However, when I do sudo service deluged start, it does not also start deluged-web.
[00:02] <GeorgeJ> What could I be doing wrong? sudo service deluge-web start works just fine.
[00:24] <xnox> don't use start-stop-daemon
[00:25] <xnox> setuid/setguid commands are available as upstart stanzas, see upstart cookbook
[00:25] <xnox> i don't know if umask is needed
[00:29] <xnox> GeorgeJ: increase upstart verbosity (see cookbook) and then fully stop everything, start deluged and inspect what events are emitted. Maybe deluged fails to start? or is already running (aka -web missed the event already)
[00:30] <GeorgeJ> xnox: I stopped both services(and checked to make sure). And then just started deluged, to no avail.
[00:30] <GeorgeJ> I'll check how to increase verbosity.
[00:44] <GeorgeJ> xnox: I've added --verbose, should the log not be /var/log/syslog?
[00:45] <xnox> dmesg or syslog, can't remember. And it's with initctl call not "--verbose" =/ how did you increase verbosity?
[00:46] <xnox> http://upstart.ubuntu.com/cookbook/#initctl-log-priority set to debug level
[00:46] <xnox> $ sudo initctl log-priority debug
[00:46] <GeorgeJ> I've added --verbose to the linux line in grub.
[00:49] <xnox> oh... extreme =)
[00:50] <GeorgeJ> I've stopped and started ufw(which has an upstart job in /etc/init), but got no events in /var/log/kern.log /var/log/syslog and /var/log/dmesg :(
[00:50] <GeorgeJ> Even even done sudo initctl log-priority debug
[00:52] <xnox> GeorgeJ: I got them in $ dmesg
[00:52]  * xnox ponders why they are there and not elsewhere.
[00:56] <GeorgeJ> xnox: Yes, it seems that `dmesg` indeed show the events.  I don't like to remove files that were installed by packages.
[01:00] <xnox> but then you have clashing names....
[01:00] <xnox> GeorgeJ: and it's config files under /etc/ you are safe to modify/remove them. If you want audit, install etckeeper that does version control the whole /etc.
[01:02] <GeorgeJ> xnox: Cool!
[01:03] <GeorgeJ> Well, the installed init script is at /etc/init.d/deluged and it starts deluged just fine.
[01:03]  * xnox thought you are rewriting it to be an upstart job?! no?!
[01:03] <GeorgeJ> I want to start another binary called, deluge-web, so I've added http://paste.ubuntu.com/1497681/ at /etc/init/deluge-web/conf
[01:03] <xnox> ah.. I see.
[01:03] <GeorgeJ> Oh no, I'm adding one.
[01:05] <xnox> I have no clue if sysv scripts emit events that upstart jobs can see.
[01:07] <GeorgeJ> Well, there's no reason I'd assume so either, but the init script(http://paste.ubuntu.com/1497703/) contains start-stop-daemon, is that not the script telling upstart that the daemon started?
[01:07] <xnox> GeorgeJ: you can cheat and in `deluge-web` pre-start stanza do `service deluge start`.
[01:08] <xnox> GeorgeJ: no.
[01:08] <GeorgeJ> Aha! Then that's completely understandable.
[01:09] <GeorgeJ> Nah, I just start deluge-web independently, it shouldn't really matter in this case. I'll just bug the package maintainer to remove the init scripts and add the proper upstart jobs!
[01:09] <xnox> initscripts are big pile of crap, there is an upstart-sysv bridge that can manage and run them in a similar fashion to upstart jobs, but I don't know which events get emitted, if any.
[01:10] <xnox> GeorgeJ: yeap, file a bug on launchpad requesting an upstart job against that package.
[01:11] <GeorgeJ> xnox: Hmm, is there a template, or an existing such bug request I could use to make it easier? I've never really filed a bug before. Or, should I just describe my problem?
[01:13] <xnox> GeorgeJ: `ubuntu-bug deluge` follow promts and type "please provide an upstart job" you may want to say that you have other upstart jobs that depend on that one.
[01:15] <xnox> Good night!
[01:15] <GeorgeJ> xnox: Thank you very much! Good night!
[17:13] <Aeyoun> Hi. I have a problem with deb packaging. Every file in debian/* is copied over to the build-area *except* for the upstart file so it fails to be detected by dh_installinit and is not included in the package. Hoping there is some knowledge overlapp here so I can get some help.
[17:14] <Aeyoun> I have studied other deb packages and cannot see that any of them are doing anything different from what I am doing.
[17:35] <SpamapS> Aeyoun: the file should be named packagename.upstart or packagename.jobname.upstart
[17:36] <Aeyoun> SpamapS, I have tried naming it upstart, packagename.upstart, and packagename.jobname.upstart. all fail. (All are valid, though. The dh_installinit util looks for all of them.)