[00:03] <spm> wgrant: awesome. will do what I can.
[00:10] <james_w> lifeless: plus, hiccup with test discovery, discover on 'foo' that finds 'foo.test_foo' will load it as 'test_foo', so that becomes the root of the test id, and then that can't be run by subunit.run.
[00:10] <james_w> lifeless: I think that's a bug in discover, but I'd like your opinion.
[00:14] <spm> "<Fault 8002: 'error'>" <== this is not the error message you're looking for....
[00:15] <spm> wgrant: just set 'actinium' back to ok, see if that sorts itself; if it does, I'll do the rest
[00:15] <wgrant> spm: Great, thanks.
[00:16] <wgrant> Some of the others were out with 'No route to host', which suggests a network glitch of some kind, which could also have caused the 'error's, I guess.
[00:16] <wgrant> Although the fact that it was all i386 hints that it might have been a rogue recipe build -- I guess we'll see soon.
[00:17] <spm> heh
[00:18] <james_w> lifeless: ah, it works if you use "." rather than "foo" as the discovery root. I don't think that's ideal, but I can see that discover may want to act the way it does so that you can discover on a root of ../../../somewhere if you want. I'd be happy to chat about this tomorrow if you like.
[00:19] <spm> wgrant: nope. looks more serious. it's dropped straight back into "I'm broken" state.
[00:20] <wgrant> spm: Argh, anything more useful in the b-m log than good ol' fault 8002?
[00:21] <spm> wgrant: you want me to look in logs for meaning vs just making something up!!?!?! good lord man, it's too early on a monday morning for that level of competence!
[00:26] <spm> bleh. that seems... unusual.
[02:15] <lifeless> james_w: its a python limitation I suspect
[02:15] <lifeless> james_w: it can't tell, due to the flexability of importing, where in the python namespace '.' is; it may need a second parameter to say 'here is the root', which may not be built in.
[02:15] <lifeless> james_w: so I think discover can be improved
[08:20] <adeuring> good morning
[08:21] <wgrant> noodles775: Morning.
[08:23] <noodles775> Hi wgrant and adeuring
[08:23] <adeuring> hi noodles775!
[08:23] <wgrant> noodles775: Are you going to have time to arrange a CP of the log parser branch?
[08:24] <noodles775> wgrant: We need to QA it first, but yes, it should happen soon. I'm currently organising the CP for the builders timeout (edge is now working with the fix).
[08:24] <wgrant> noodles775: Yep, I noticed edge was looking good.
[08:25] <wgrant> (well, apart from the i386 builders, but that's hopefully unrelated)
[08:27] <noodles775> wgrant: yeah, has there been any discussion there? I just tried enabling actinium, but it went straight back to Fault 8002. I'll check the logs.
[08:29] <spm> noodles775: https://pastebin.canonical.com/33033/
[08:29] <spm> I tried exactly the same earlier today
[08:29] <wgrant> Yeah, I was wondering what was in the logs.
[08:30] <wgrant> Given that it's only i386, I'm suspicious that a recipe build may have snuck through.
[08:30] <noodles775> Last mention of actinium seems fine: 2010-06-07 07:44:58+0100 [-] Processing successful build amd64 build of kwin-effect-bereflected 0.1~lucid~ppa1 in ubuntu lucid RELEASE from builder protactin
[08:30] <noodles775> quite recent.
[08:30] <wgrant> protactin != actinium?
[08:30] <wgrant> Hm.
[08:30] <spm> heh, that caught me out as well :-)
[08:31] <noodles775> right, I just search backwards...
[08:31] <wgrant> protactin doesn't exist.
[08:31] <noodles775> and cut the line while copying...
[08:31] <wgrant> Ah.
[08:32] <wgrant> So what about actinium?
[08:32] <wgrant> And who could possibly have thought that having those two names was a good idea? :P
[08:32] <noodles775> heh
[08:34] <noodles775> wgrant: just the traceback that spm posted... ah, I'll post it on the public one.
[08:35] <noodles775> http://pastebin.ubuntu.com/445954/
[08:36] <wgrant> Oh, useful...
[08:36] <wgrant> I guess that firing the rest trigger will fix them, but it might be nice to grab logs first if possible...
[08:36] <wgrant> s/rest/reset/
[08:36] <kb9vqf> I'm looking at setting up a local copy of Launchpad for a project I'm working on, but am having trouble getting Launchpad to accept a different OpenID URL than the default
[08:37] <wgrant> Ohhhhhhh, rescueIfLost.
[08:37] <wgrant> So it was a network glitch.
[08:37] <kb9vqf> How can I set a custom OpenID URL?  Something in launchpad-lazr.conf?  Is there any documentation for that file?
[08:38] <wgrant> spm, noodles775: So, we have a whole lot of builders that need resetting. Is that easy enough?
[08:39] <noodles775> Is that something you can do spm? lamont normally does it afaik.
[08:39] <spm> noodles775: no unf, only lamont or one of the gsa's. and it's a NZ holiday, so paul hasn't been around.
[08:39] <wgrant> (Basically, the builders dropped of the network for a while. The master noticed, and unassigned their builds. They came back, and the master noticed they were doing something they shouldn't be doing. The master tried to abort the builds. Aborting them is known to be... um.... buggy).
[08:39] <spm> ha
[08:40] <wgrant> Just the slaves need to be reset -- the thing that's done before every build.
[09:18] <bigjools> morning all
[09:21] <wgrant> Evening bigjools.
[13:29] <maxb> jelmer: Hi, about that fretsonfire vcs-import. Should we be complaining that the import of the upstream fretsonfire project was requested into the LP fretsonfire-severedfifth namespace instead of the LP fretsonfire namespace?
[13:36] <jelmer> maxb: yeah, we probably should
[13:37] <jelmer> maxb: I don't think we're able to change the project of a branch though
[13:37] <jelmer> maxb: also, this wouldn't be a problem if URLs didn't have to be unique..
[13:37] <maxb> Well, even if not that, it's a minor waste of resources to be importing the same branch twice
[13:41] <maxb> I guess we have the option of deleting the branch and requesting a replacement import of our own
[13:43] <wgrant> jelmer, maxb: You can change the product through the API.
[13:58] <jelmer> wgrant: not when you don't have permission to do so I hope?
[14:01] <wgrant> jelmer: Heh, no.
[14:04] <mwhudson> ~vcs-imports has edit on all import branches though
[14:05] <wgrant> bigjools: Ugh, that log parser issue is in the apachelog contrib module.
[14:06] <bigjools> yeah noodles775 just noticed that too
[14:06] <wgrant> It looks likt it might not be a real issue.
[14:06] <wgrant> Since it's trying to parse from somewhere other than the start of the line.
[14:07] <wgrant> So... either the exisitng offsets in the DB confused it, or something put bad offsets there.
[14:07] <wgrant> You've not changed the log file content at all?>
[14:08] <noodles775> But those lines are passed in by our code (specifically: next_line = fd.next())... so it could be a bad offset... that's a good point.
[14:08] <wgrant> If two have the same first line, the world will end like this.
[14:09] <bigjools> it should be smarter about offsets and seek to the nearest \n
[14:09] <wgrant> Well, it should probably actually complain if there isn't a \n right there.
[14:09] <wgrant> Since we want to know if something has gone wrong.
[14:49] <mars> gary_poster, here is an in-depth summary of the issue and outstanding questions for bug 587886
[14:49] <mup> Bug #587886: ec2 test mail reports SUCCESS when the suite fails <build-infrastructure> <Launchpad Foundations:In Progress by mars> <https://launchpad.net/bugs/587886>
[14:49] <mars> gary_poster, https://bugs.edge.launchpad.net/launchpad-foundations/+bug/587886/comments/3
[14:49] <mup> Bug #587886: ec2 test mail reports SUCCESS when the suite fails <build-infrastructure> <Launchpad Foundations:In Progress by mars> <https://launchpad.net/bugs/587886>
[14:49] <gary_poster> reading, thanks
[14:52] <gary_poster> mars, looks like shakeout from the subunit integration
[14:52] <mars> yep
[14:53] <mars> like I said, we need to address the root cause here after the fix goes through.  Otherwise changing the testrunner is always going to be risky and painful.
[14:54] <gary_poster> mars..isn't the root cause the fact that we have inter-process communication, which is by its nature more fragile for this sort of thing?
[14:54] <gary_poster> (and I don't see fixing that particular root cause)
[14:54] <mars> gary_poster, yes, but the testrunner claims to have error handling mechanisms in place.  Also, it has no concept of a child layer timeout.
[14:55] <mars> so its current mechanism is broken, and it is missing at least one possible safeguard.
[14:55] <adeuring> can somebody give me a clue about this test failure: http://paste.ubuntu.com/446120/ ? it occurs for this branch: lp:~adeuring/launchpad/expectations-bug-556499-model
[14:57] <mars> leonardr or gary_poster, ^ haven't we seen adeuring's error before?
[14:57] <leonardr> checking
[14:58] <leonardr> it looks like an error occured when generating the json representation of an object (which is stuffed into the HTML for use in ajax)
[14:58] <mars> adeuring, yes, check this: https://dev.launchpad.net/Debugging#Getting past "LocationError: 'json'" in TAL template tracebacks
[14:58] <adeuring> mars: thanks, will lok
[14:58] <leonardr> yeah, you need to find the underlying error
[14:59] <adeuring> leonardr: the main change in this branch is the adition of a new property that is exposed to the webservice
[14:59] <adeuring> though it is defined via get/set methods
[14:59] <leonardr> i'll take a look at the branch
[15:00] <adeuring> leonardr: but... the error occurs also for r9391 of the branch
[15:02] <gary_poster> mars, I don't see how a timeout could be coded reasonably for running arbitrary code that has no guarantee of generating anything on stdout or stderr in any particular amount of time.  If you do, cool, show me when you write it, cause I'll want to see what you have in mind (no need to explain now).
[15:02] <gary_poster> On the other topic, an you point me to the "error handling mechanisms" claims?  If the subprocess is running arbitrary code (which it does), and it does not return an error code it seems to me like you're going to have trouble.  The subprocess wrapper code (the code running the arbitrary code) is the place where you have to code very defensively to make sure it catches just about everything.
[15:02] <gary_poster> Is that what you mean you need to improve?
[15:04] <gary_poster> mars: or do you just mean your last point?"Why is the parent testrunner process not failing the suite when it knows that the child process died due to a testrunner error? (I.e. the parent it got a 'Could not communicate with subprocess' flag)"
[15:05] <mars> gary_poster, I think the code on either side of the subprocess gap needs to be examined to see why this exception did not cross the IPC channel
[15:05] <mars> gary_poster, the latter, what you just quoted
[15:05] <gary_poster> gotcha mars, thank you.
[15:06] <mars> gary_poster, if it knows "my subprocess just died, uh oh", then why the heck didn't the suite error out?
[15:06] <gary_poster> mars: ack, agree
[15:06] <leonardr> adeuring: i don't know. can you find the underlying exception? i hope it will make everything clear
[15:07] <adeuring> leonardr: yeah, I think mars gave me the right clue
[15:08] <gary_poster> noodles775, bigjools: bug 590766 sounds like a high priority.  is it?  noodles775, are you going to take it since it appears to be a continuation of your work for bug 588288, or are you tossing this over?
[15:08] <mup> Bug #590766: Apache log parser crashes out on the PPA logs <Launchpad Foundations:New> <https://launchpad.net/bugs/590766>
[15:08] <mup> Bug #588288: log parser should not read entire file into memory <qa-needstesting> <Launchpad Foundations:Fix Committed by michael.nelson> <https://launchpad.net/bugs/588288>
[15:08] <bigjools> gary_poster: I think it's happened because the offset it's using is out of sync with the file
[15:09] <gary_poster> ah
[15:09] <bigjools> gary_poster: and I'd like to toss it over if that's ok :)
[15:09] <bigjools> the code should probably look for the nearest \n to the offset
[15:09] <gary_poster> bigjools: and it's high priority?
[15:09] <bigjools> gary_poster: fairly yes
[15:09] <gary_poster> ok
[15:10] <bigjools> thanks
[15:10] <gary_poster> bigjools: sure.  do you have an easy way to dupe, perchance?  Otherwise I'll try to figure out a way to dupe with the clues you just gave.
[15:11] <bigjools> gary_poster: it's reproducible on dogfood
[15:11] <bigjools> but I suspect that's because the offset that's stored is out of whack for some reason
[15:11] <bigjools> I'm happy to help test on DF for you
[15:12] <bigjools> or probe for any more info you need
[15:12] <gary_poster> bigjools: ok, thanks, yeah.  I'll probably write up a hack patch soon for you to try to see if we are on the right track before I pursue a full proper branch.
[15:13] <bigjools> cool
[15:13] <noodles775> Thanks gary_poster !
[15:13] <gary_poster> :-) np
[15:15] <wgrant> bigjools: I don't think being more robust and looking for a \n nearby is at all the right solution.
[15:15] <wgrant> It should never happen.
[15:15] <bigjools> do expand ...
[15:16] <wgrant> Unless we have a bug, or somebody mangles the log files.
[15:16] <bigjools> never != will never
[15:16] <bigjools> and you hit on the right thing with your latter point
[15:16] <wgrant> Yes, and when it does happen we have a problem, so we probably want to know that it exists.
[15:16] <bigjools> it should not make the parser bail out permanently
[15:16] <wgrant> Why would somebody be mangling log files?
[15:16] <bigjools> PEBKAC
[15:16] <gary_poster> I agree I'd like to know what the root cause is
[15:16] <bigjools> never underestimate human fuckups
[15:17] <wgrant> It only kills the rest of that file, right?
[15:17] <bigjools> in my case I suspect it's because the dogfood database was restored from production
[15:19] <gary_poster> Vaguely, I'd prefer to reread the file if we get out of sync, but I don't understand what is going on in this code well enough yet--the diff doesn't give me enough context.
[15:20] <wgrant> We can't safely reread it.
[15:20] <wgrant> We may have already put stuff into the DB from previous runs.
[15:21] <gary_poster> I figured we would, but I had hoped we would have enough information around to know what we had already read.  That's obviously uninformed hope; perhaps it can't work.
[15:21] <wgrant> We have the information: the offset.
[15:21] <gary_poster> Which is broken.
[15:21] <wgrant> But the problem here is the case where that information is wrong.
[15:21] <wgrant> Right.
[15:22] <gary_poster> So the offset is too fragile.  I thought we might have a datetime of the last read line somewhere.  If not, we could store it.
[15:44] <gary_poster> bigjools: could you email me the specific file that is broken?  I'd like to experiment with it.
[15:44] <bigjools> I can
[15:44] <gary_poster> thank you
[15:45] <bigjools> gary_poster: ummm it's 1.7G
[15:45] <gary_poster> bigjools: ... :-/ devpad, and I
[15:45] <gary_poster> '
[15:45] <bigjools> I can copy it to.... devpad!
[15:45] <gary_poster> I will tell you when I have it?
[15:46]  * bigjools needs 2 more arms
[15:47] <gary_poster> He would look funny then.
[16:08] <nigelb> Is there plan for LP to have a "press foo to forward to debian" thingy?
[16:10] <james_w> leonardr: you might be interested in https://edge.launchpad.net/soupmatchers see http://bazaar.launchpad.net/~soupmatchers-dev/soupmatchers/trunk/annotate/head:/README
[16:58] <jml> nigelb, it's definitely within scope, but there aren't concrete plans to implement it right now.
[17:09] <henninge> Can somebody tell me where we import the sortable tables from that we use in Launchpad?
[17:09] <henninge> Are they LAZR-JS?
[17:21] <mars> gary_poster or sidnei, Zope question: if I want to add a test to zope.testing for a specific corner case, do I have to use a doctest to do it?
[17:22] <mars> gary_poster, sidnei, I would normally use a unit test for corner cases and test to increase code coverage.  The test in question is to ensure a bug is not present.
[17:22] <sidnei> mars, no, you don't need to use a doctest. in fact, if you're willing to convert all doctests to unittests you would be very welcome :)
[17:25] <mars> sidnei, alright, where in zope.testing would this unit test go?  "testrunner-ex" doesn't sound right
[17:25] <mars> sidnei, oops, have to go, lunch is served, back in 1hr
[17:31] <nigelb> jml: I'm trying to write something that links with reportbug
[17:31] <nigelb> bug anyway, hooking with debian bts should be easier than most, since its easy to opena  new bug.
[17:32] <nigelb> but its the searching that might be a bit challenging
[17:32] <ScottK> reportbug has searching code and it's in Python ....
[17:35] <nigelb> ScottK: oh, reportbug is python? if only I knew, I wouldn't be pulling my hair out last weekend
[17:36] <ScottK> ;-)
[17:39] <nigelb> ScottK: in that case its only trivial for me to add the querying LP part to reportbug as such as a new feature!
[17:39] <nigelb> I shuold try doing that this weekend
[19:00] <mars> sidnei, back
[19:03] <sidnei> mars, so tests are registered in tests.py. i see they are pretty much all doctests. but that shouldn't prevent you from writing a unittest
[19:03] <sidnei> mars, testrunner-ex contains sample tests used by the doctests to trigger failure conditions and edge cases apparenlty
[19:05] <mars> sidnei, yes, it looks that way
[19:06] <mars> sidnei, ok, I see the subunit tests block near the end of tests.py.  Looks like that is the place to put unit tests.
[19:07] <sidnei> yeah
[19:08] <mars> sidnei, should I create a new subdirectory just for unit tests? 'unit', or 'tests' or something?
[19:09] <mars> sidnei, I am a bit hobbled here by my ignorance of zope project conventions
[19:10] <sidnei> mars, uhm. instead of tests.py it should really be a tests directory there, and maybe a test_doctests.py inside. i think no-one bothered to fix that.
[19:10] <sidnei> mars, maybe just add the test to tests.py
[19:13] <mars> I'm not sure that is a good idea.  That file is large enough already.
[19:14] <mars> Adding an unknown number of xUnit tests to it would just pollute the module.
[19:15] <mars> sidnei, I could create a tests/ directory and put test_subunit.py inside it
[19:15] <mars> it would be a partial refactoring
[19:15] <sidnei> that sounds good too
[19:17] <mars> ok
[19:18] <mars> sidnei, ah, won't work: a 'tests' package directory would raise a name conflict with the existing 'tests' module
[19:19] <sidnei> yeah, so i thought.
[19:19] <mars> testtestrunner :P
[19:19] <sidnei> mars, best way would be to move tests.py to tests/test_doctest.py as i suggested.
[19:20] <mars> sidnei, and what about testrunner-ex and friends?
[19:20] <sidnei> mars, as i said, that's sample code used by the doctests
[20:06] <mars> leonardr, ping, just did a rf-get and build, am getting an AssertionError from the apidoc/index.html build step.  Known issue?
[20:14] <leonardr> mars, i don't know about it. pastebin?
[20:14] <jml> mars, btw, can I look at your patch for zope.testing when it's done?
[20:15] <mars> jml, sure.  may be a bit, I have to craft a reproduction of the error
[20:16] <jml> mars, that's ok. I'm on vacation so not in any kind of rush :)
[20:16] <jml> (yes I suck at vacation)
[20:16] <mars> lol
[20:21] <mars> leonardr, here is the output of 'make clean && make' on a fresh branch of devel: http://pastebin.ubuntu.com/446264/
[20:22] <leonardr> mars: hypothesis: someone landed a web service branch recently that broke this
[20:22] <leonardr> i don't know why they were able to land it, since apidoc.txt should have failed
[20:22] <leonardr> but that's the most likely explanation
[20:22] <mars> leonardr, fake success mail from ec2?
[20:22] <leonardr> "web service branch" = "branch that messes with or publishes something new on the web service"
[20:22] <leonardr> yeah, i guess
[20:23] <mars> leonardr, do you know how to fix it?
[20:23] <mars> I don't :)
[20:24] <leonardr> i know how to fix it on a high level, ie. 1) find the branch that caused the problem, 2) run the test, 3) fix the failure
[20:25] <leonardr> but i have no idea what the actual problem is--it could be anything anywhere in the web service
[20:26] <leonardr> mars: i'd start looking at rev 10953, adiroiban's POTemplate change
[20:29] <mars> leonardr, we'll find out in 27 minutes :)
[20:29] <mars> if buildbot is accurate
[20:41] <leonardr> mars, i was able to make revision 10952
[20:50] <mars> I don't trust the buildbot estimates any more.  Refreshing the page removed 2 minutes from the estimate since I last spoke of it, 20 minutes ago.
[21:19] <bryceh> https://bugs.edge.launchpad.net/ubuntu is oopsing for bdmurray and I, is this a known issue?
[21:21] <mars> bryceh, I was having similar problems with my branch listings page OOPSing earlier today.  There was mention of increased database loads due to some OAuth code.  gary_poster, could they be related?
[21:22] <gary_poster> mars, no what stub was talking about was systemic, not specific to today or this week or this month.
[21:22] <mars> gary_poster, ok
[21:22] <bryceh> the error I see is:  Module lp.bugs.model.bugtarget, line 211, in getBugCounts
[21:22] <bryceh> ', '.join(select_columns), ' AND '.join(conditions)))
[21:22] <bryceh> QueryCanceledError('canceling statement due to statement timeout\n',)
[21:22] <bryceh> (https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1619ED1527)
[21:22] <leonardr> mars, binary search has revealed it's got to be either 10958 or 10959
[21:23] <mars> leonardr, ah, have to love the binary bug search :)
[21:24] <bdmurray> well it couldn't be 10959 ;-)
[21:25] <mars> hehe
[21:30] <maxb> jelmer: Did you follow up about that fretsonfire import or did jonobacon apparently delete it himself for another reason?
[21:30] <leonardr> mars, bdmurray, it's 10959
[21:31] <jelmer> maxb: I haven't followed up
[21:31] <bdmurray> leonardr: can you provide some guidance for fixing it?
[21:31] <maxb> ok, I'll write to him since he's deleted the old import and requested a new one
[21:32] <jelmer> maxb: you can also msg him on irc, he's 'jono' on this network
[21:33] <leonardr> bdmurray, first step is to find the underlying problem
[21:34] <mars> leonardr, gary_poster, r10958 built fine for me.
[21:35] <lifeless> my gyess
[21:35] <lifeless> he couldn't find the edit-details button to fix it
[21:41] <leonardr> bdmurray
[21:41] <leonardr> this should be easy to fix
[21:41] <leonardr> you define a new argument to searchTasks, which is a reference(schema=Interface)
[21:41] <leonardr> you did what other, similar arguments did
[21:41] <leonardr> but what you didn't see is that that value doesn't stay Interface forever
[21:41] <leonardr> it only starts out as Interface to avoid a circular import
[21:42] <leonardr> take a look at lib/canonical/launchpad/interfaces/_schema_circular_imports.py
[21:42] <leonardr> you'll see # IHasBugs
[21:42] <leonardr> and then a number of calls to patch_plain_parameter_type()
[21:42] <kb9vqf> How can I set a custom OpenID URL?  Something in launchpad-lazr.conf?  Is there any documentation for that file?
[21:42] <leonardr> each of those replaces the 'Interface' in one Reference(schema=Interface)
[21:43] <leonardr> you need to add a call to patch_plain_parameter_type(IHasBugs, 'structural_subscriber', ???)
[21:44] <leonardr> the question is, what goes in that ???? What type of object is structural_subscriber, really?
[21:44] <leonardr> it looks like it's an IPerson
[21:44] <leonardr> so you would add patch_plain_parameter_type(IHasBugs, 'structural_subscriber', IPerson)
[21:45] <bdmurray> leonardr: right, it is.  and then would I just resubmit it to pqm?
[21:45] <leonardr> yes
[21:45] <leonardr> make sure that 'make' works after you make your change
[21:45] <gary_poster> leonardr, bdmurray: awesome, thank you
[21:45] <bdmurray> leonardr: yes, of course.
[21:45] <leonardr> gary, np
[21:46] <bdmurray> leonardr: thanks for the help
[21:46] <leonardr> sure
[22:07] <gary_poster> bryceh: did you make a bug for that?  If not, I will.
[22:07] <gary_poster> bryceh: (the timeout on https://bugs.launchpad.net/ubuntu and https://bugs.edge.launchpad.net/ubuntu)
[22:12] <bryceh> gary_poster, nope I didn't
[22:12] <gary_poster> bryceh: on it
[22:34] <maxb> Does anyone know why https://code.edge.launchpad.net/~chanwit/groovy/ck1 would not be showing a 'Branch metadata' section?
[22:35] <mars> maxb, thumper might
[22:38] <thumper> maxb: what do you mean?
[22:45] <Lonniebiz> Some questions:  Does launch pad solve the same problems that bugzilla does?
[22:46] <Lonniebiz> Can you install it on you own Ubuntu server, and make it work the same way launchpad.net works?
[22:46] <Lonniebiz> Can a software development company use Launch Pad for project management?
[22:46] <lifeless> yes
[22:47] <lifeless> sorry, in order
[22:47] <lifeless> no (solves more than)
[22:47] <lifeless> yes you can install it yourself, if you have the time and willpower to admin it (its not .... lightweight); you *must* rebrand it if you do that.
[22:48] <lifeless> Yes, you can use launchpad for some project management tasks, either hosted (launchpad.net, speak to bac for commercial subscription info), or on your own one (see my immediately previous answer)
[22:48] <Lonniebiz> My company is looking for a Software Project Manangement solution.
[22:48] <Lonniebiz> Been looking at Jira, but thought about how much I liked how Ubuntu allows you to submit bugs and stuff.
[22:49] <Lonniebiz> We develop software that is commercial, but need something to track us through the Software Development Life Cycle.
[22:50] <lifeless> sure
[22:50] <lifeless> launchpad.net can host such things
[22:50] <Lonniebiz> Think installing LaunchPad on our Ubuntu server would be too involved a solution. I'm a big Ubuntu fan myself....
[22:51] <maxb> thumper: Normally a branch page shows a 'Branch metadata' section showing its format, and if its stacked
[22:51] <maxb> But it's missing on that one branch
[22:51] <Lonniebiz> I've read this: https://dev.launchpad.net/Getting
[22:52] <Lonniebiz> After I complete those steps, will it be as simply as navigating to an internal ip such as http://localhost/LaunchPad   ?
[22:52] <thumper> maxb: the branch hasn't been scanned since we added the metadata, so nothing to show
[22:52] <maxb> oh, I see
[22:52] <Lonniebiz> then just add a project through the web interface?  Is it that simple or much much more involved.
[22:52] <maxb> It is MUCH MUCH more involved
[22:52] <maxb> For a start, you *must* rebrand it
[22:53] <maxb> And also learn lots about how the many components fit together, and how to run it in production, which isn't documented anywhere public
[22:54] <Lonniebiz> Yeah, but at first, we'd be just using it internally; If we were to let customers see it, we'd surely take the step of rebranding it.
[22:54] <maxb> To use it internally _legally_ you'd have to rebrand it first
[22:54] <Lonniebiz> For now, we're just looking at it more as a development tool than a customer feedback tool.
[22:54] <maxb> so says the licence
[22:54] <Lonniebiz> oh, I see.
[22:54] <maxb> (This annoys me too)
[22:55] <gary_poster> Lonniebiz: FWIW, https://answers.edge.launchpad.net/launchpad/+faq/208
[22:55] <Lonniebiz> Well, that doesn't seem hard, just change the logo right, and replace any word "launchpad" with "CompanyA", right?
[22:55] <maxb> and design replacements for all of the many icons....
[22:56] <gary_poster> (Again FWIW, I also think you are significantly underestimating the setup involved, as maxb suggested.)
[22:56] <Lonniebiz> that could be laborious...
[23:40] <rockstar> wgrant, ping