[01:47] <vvesley> o/
[01:47] <vvesley> Karma seria oque ?
[03:43] <Iowan> After creating a team for Ubuntu, I'm told it doesn't follow (current) naming convention - how can I change it's name... and contact information for the owner (the ubuntu.com email address isn't working
[03:55] <Iowan> Found it - easier than expected - right on the Change Details link.
[04:29] <ripps> lol, those chromium/firefox builds are really killing the ppa builder
[04:29] <timClicks> is it possible to merge two branches within launchpad?
[04:35] <beuno> timClicks, no, you need to merge them locally and push
[04:58] <Some_Person> Is my build *seriously* not going to start for 2 flippin' days?
[04:59] <Some_Person> By then, I'll have uploaded a new version
[05:00] <persia> Some_Person: The queue was mostly empty 24 hours ago, then everyone got excited.
[05:00] <Some_Person> https://launchpad.net/~stownsend42/+archive/supertux-svn/+build/1465634
[05:01] <wgrant> Lots of the PPA builders have been temporarily stolen.
[05:01] <wgrant> They will return.
[05:01] <Some_Person> stolen?
[05:01] <wgrant> To perform other duties.
[05:45] <Hobbsee> wgrant: seeing as it's more appropriate for here, do you know if the entire right panel for a bug is supposed to be at the bottom, starting below the "What next?" section?
[05:47] <persia> Hobbsee: Just make your browser wider.
[05:47] <persia> Err, narrower
[05:47] <Hobbsee> persia: it's already maxed on a 16:9 widescreen?
[05:47] <persia> For me, the right side pops up at about 600 horizontal pixels
[05:47] <wgrant> Hobbsee: That's fixed on edge.
[05:47]  * persia forgets the bug number
[05:47] <wgrant> Supposedly.
[05:48]  * persia tests edge
[05:48] <Hobbsee> oh, there we go
[05:48] <Hobbsee> ah yes, it's fixed on edge.  cool
[05:48] <persia> OOh!  It is fixed.
[05:48] <persia> Strange that I didn't see bugmail about it.
[05:49] <persia> Right.  Bug #493518 appears to be Fix Committed
[05:50] <wgrant> It was fixed very early on.
[05:50] <persia> About two weeks after it started.  I'm just surprised not to see a branch linked or a status change.
[05:50] <persia> I'm usually fairly impressed with the detailed bug mail from LP devs.
[09:54] <seb128> hi
[09:55] <seb128> launchpad edge is not able to display a package buglist without timeouting
[09:55] <seb128> known issue?
[09:56] <jpds> seb128: Yep.
[09:56] <RAOF> It's been happening for at least 24 hours.  I believe it was known yesterday.
[09:56] <persia> There's been reports of lots of timeouts on edge.  Try production.
[09:56] <seb128> I know about production thanks
[09:56] <seb128> I was asking if the issue is known before doing that in my corne :-=
[09:57] <jpds> bug #511546
[09:57] <seb128> corner ;-)
[09:57] <seb128> jpds, thanks
[09:57] <seb128> bryyce, ^
[12:35] <ahasenack> guys, I can't change a bug's project from landscape to smart, smart is not found
[12:35] <ahasenack> but bugs.launchpad.net/smart exists and is happy
[12:36] <ahasenack> weirdly, the first hit when I type "smart" in the overlay search box is, among 13 pages, a project called "Alternator"
[12:36] <ahasenack> if I use the full name, it's still not the first hit, but it is listed
[12:36] <ahasenack> just a FYI
[12:38] <persia> ahasenack: There's a couple bugs on the search interface (I forget the numbers), but I believe the goal is to do better when the user types the name correctly.
[12:38] <ahasenack> persia: you mean the long name
[12:38] <ahasenack> persia: "smart" is the correct name
[12:38] <persia> No, I mean the short name.
[12:39] <persia> Or maybe the long name too.
[12:39] <ahasenack> persia: I was just able to find it when using the long name
[12:39]  * persia isn't quite sure what thoughts lurk in the minds of LP devs.
[12:39] <persia> Right.  I've had that issue too.  I believe the plan is to do better when the user types a short name correctly, and maybe a long name too, so that the properly entered one comes up first.
[12:40] <persia> But this isn't what you initially asked :)  You need to migrate a bug between projects, and it isn't working.
[14:25] <rdb> Hm, my package in soyuz doesn't build because of a download error to developer.download.nvidia.com.
[14:25] <rdb> is there no internet connection while building the package?
[14:25] <bigjools> rdb: no, that is not allowed
[14:25] <noodles775> rdb,.. what he said.
[14:25] <rdb> But its a Build-Depends.
[14:25] <rdb> Build-Depends nvidia-cg-toolkit.
[14:25] <bigjools> there's a bug about that
[14:25] <bigjools> that dependency, I mean
[14:25] <rdb> Ouch.
[14:27] <rdb> Does this mean that someday, when the bug is fixed, my package will build?
[14:28] <bigjools> https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-cg-toolkit/+bug/284750
[14:28] <bigjools> well, read the bug :)
[14:29] <rdb> Given that the bug has already been 'fixed', how long will it take for this fix to propagate to the repo's?
[14:29] <rdb> I mean, I expected to be releasing a new version of my 3D game engine today
[14:29] <rdb> but apparently I'll have to do it without ubuntu support
[14:30] <bigjools> I think you're better off asking in an ubuntu channel, I don't know the answer to your questions
[14:30] <rdb> k, thanks.
[14:31] <bigjools> it looks like someone already made a PPA package of that, FWIW
[14:31] <rdb> Uh, if i mark that ppa as dependency for now, will that fix it for the short term?
[14:32] <bigjools> you could try, yep
[14:32] <bigjools> or copy his package to your PPA, if you don't want to pull all his other packages as potential dependencies
[14:32] <jcastro> that ppa looks old
[14:33] <bigjools> hey jorge.  yeah, the package is from October
[14:36] <jcastro> rdb: it's in the development release of ubuntu already, so someone just needs to backport it, info about that here: https://help.ubuntu.com/community/UbuntuBackports
[14:41] <rdb> hm, its a bit ugly to have the competitor 3d engine as ppa dependency :p
[15:01] <smoser> hello, i'm looking for a way to take a shorthand launchpad ppa reference (ppa:user/ppa) and from that, get : source and binary lines for sources.list, and the signing key
[15:02] <noodles775> smoser: are you aware that software sources does exactly that for you (in Karmic)?
[15:03] <smoser> no. i was not. /me goes to read
[15:03] <bigjools> there's a command line to add the repo as well
[15:03] <bigjools> add-apt-repository
[15:04] <bigjools> it knows about ppa:user
[15:19] <smoser> bigjools, noodles775 i dont see where add-apt-repository obtains a key
[15:20] <smoser> it seems like it has to already exist in %s/%s.key
[15:20] <smoser> erre.. /usr/share/app-install/channels/
[15:20] <bigjools> when I've used it before, it goes to a keyserver and downloads it
[15:21] <smoser> hm... maybe i'm missing it. i was just walking source
[15:21] <smoser> gah. it does. thanks for insisting
[15:21] <bigjools> :)
[15:26] <smoser> hm... well, walking further, it seems that I could fairly easily implement the same logic, the key was getting: 'https://launchpad.net/api/beta/~smoser/+archive/ppa'
[15:26] <smoser> the problem is that the code says:
[15:26] <smoser> # FIXME: this needs to go - elmo says the keyserver will not handle
[15:26] <smoser> #        the load
[15:27] <smoser> the other thing yucky is that the url includes 'beta'. so i'm wondering if there is a better/cleaner/more supported way to do this ?
[15:27] <smoser> anyone?
[15:27] <smoser> right now i think i go the 'apt-add-repository' route, but i'd prefer to remove the dependency.
[15:28] <bigjools> smoser: the "beta" is there because the API is still in beta
[15:28] <smoser> right
[15:28] <smoser> i'm looking to build this into something that would go into lucid
[15:28] <smoser> and woudl prefer to not depend on something that is not finalized, without an indication that it is expected to be solid.
[15:30] <bigjools> you mean the api?
[15:31] <smoser> well, yeah. if nothing else, i'm assuming that that url is not permenant
[15:32] <smoser> with 'beta' in it. and if i hard code it, i'll later have to service that.
[15:39] <bigjools> that URL should be hidden from you if you're using launchpadlib
[15:40] <bigjools> http://blog.launchpad.net/general/anonymous-access-to-the-launchpad-web-service-api
[15:40] <bigjools> smoser: ^
[15:40] <smoser> yeah.
[15:41] <smoser> i'd lke to avoid that dependency too if possible,... for now i think i the best idea is just to 'add-apt-repository <input>'
[15:41] <smoser> thanks for your help. (note, add-apt-repository does not use liblaunchpad)
[15:42] <bigjools> yeah
[15:42] <bigjools> np
[16:48] <menesis> PPA i386 builders are clogged again, > 1 day in queue
[16:52] <bigjools> menesis: what's your definition of clogged?
[16:52] <bigjools> note that there's fewer than normal PPA builders right now
[16:53] <maxb> I think > 1 day in queue is the definition of clogged being used here
[16:54] <menesis> they have more work to do than they can handle in acceptable time
[16:54] <maxb> Let's clarify it as "User experience is degraded compared to usual"
[16:54] <bigjools> when the missing builders come back that figure will drop
[16:55] <maxb> Are they likely to reappear in 1 day or in 7?
[16:58] <bigjools> they'd coming back any moment
[16:58] <bigjools> they're*
[17:23] <MTecknology> I'm trying to build a package with pbuilder before uploading to my PPA; I'm getting this error - any ideas what's wrong?  http://dpaste.com/150292/
[17:25] <maxb> xsltproc: Command not found
[17:26] <MTecknology> maxb: So I just missed a dependency?
[17:27] <maxb> yes
[17:27] <MTecknology> thanks
[17:35] <MTecknology> maxb: I'm hoping I don't hit too many of these errors during build; thanks for the help :)
[17:38] <MTecknology> maxb: any ideas about this one? http://dpaste.com/150297/
[17:38] <maxb> How about doing what it tells you to do on line 20?
[17:44] <MTecknology> maxb: I guess ./configure .... --with-fop in debian/rules is wrong..
[17:47] <persia> If you haven't already looked, the existing packaging of the bitlbee source may be a good guideline.
[17:50] <MTecknology> persia: ya.. that could help.. They're very different but I suppose it could help me figure everything out - thanks
[17:51] <persia> Just figured, as you appeared to be packaging bitlbee 1.2.4, which is in karmic and lucid :)
[17:51] <persia> Even if you change the format, the answers to all the puzzlers can probably be figured out from there.
[17:52] <MTecknology> persia: there's a separate bzr branch they have that lets you use libpurple and through that you can connect to facebook chat
[17:53] <maxb> This should not impact the docs buildsystem much, surely
[17:56] <persia> Generally my experience is that patches can be applied without changing the build system.
[18:29] <drubin> Is there a list of fields that launchpad's openid implementation supports?
[18:53] <jcastro> deryck: I purposely put my plenary on +patches on thursday just in case. :)
[18:56] <deryck> jcastro, cool :-)
[18:56] <deryck> jcastro, sorry we missed this release.
[18:56] <deryck> or will miss rather
[18:57] <jcastro> deryck: no worries
[18:57] <jcastro> something to demo during the sprint will be good enough!
[18:57] <deryck> excellent
[18:57] <deryck> jcastro, not this week, but next, right?
[18:57] <jcastro> right
[18:58] <deryck> jcastro, cool.  we may even have more landed by then too
[19:18] <drubin> Is it possible to get email passed back as part of the openid?
[19:35] <qense> Is Loggerhead having Internal Server problems?
[19:35] <qense> http://bazaar.launchpad.net/~mbudde/lernid/modular-lernid keeps complaining about it
[19:42] <cody-somerville> I have a launchpadlib script that runs every five minutes. 1-5 times a day, I get ValueError: No JSON object could be decoded. Any ideas what might be causing this?
[20:03] <abentley> drubin: It's definitely possible.  I believe some of our internal sites do that.
[20:04] <MTecknology> How can I figure out what package profides xft?
[20:05] <drubin> abentley: because I can't work out why passing email as a required field brings back "not under trust_root "
[20:06] <drubin> maybe my domain needs to be registered some where? not that I know where/what that is :/
[20:07] <drubin> abentley: "internal" which ones would that be maybe I can look up or look around those projects
[20:07] <abentley> MTecknology: You can use http://packages.ubuntu.com/.  If it's already installed, you can use "dpkg-query -S" to find out why.
[20:13] <abentley> drubin: I'm not an openID expert.  AFAICT, a "trust_root" failure would be due to a mismatch between the "return_to" field and the
[20:13] <abentley> "trust_root" field supplied by the relying party.
[20:21] <abentley> cody-somerville: In the general sense, I would expect it's an internal server error that's not being recognized as one.  Possibly it's returning the empty string.  I don't know why there are so many internal server errors.
[20:26] <drubin> abentley: Ah ye that was it, but it doesn't have any thing todo with the not getting email back :)
[20:27] <abentley> drubin: At least that's a bit clearer.  Your relying party will have to specifically request the email.  Are you doing that?
[20:29] <drubin> abentley: yes, I found this http://sourceforge.net/tracker/index.php?func=detail&aid=2847751&group_id=66150&atid=513503 it says that you need to  which seems to say I need to request something
[20:30] <abentley> qense: I've asked someone to have a look at that.
[20:30] <qense> abentley: thanks
[20:36] <thumper> abentley: morning
[20:36] <thumper> abentley: chr this week?
[20:36] <abentley> thumper: Morning.  Yes, I am.
[20:36] <abentley> qense: So far, it looks like only that branch is affected.
[20:37] <qense> abentley: weird, I'm wondering what mbudde did to it to make it behave that badly
[20:42] <abentley> qense: It's not a branch.  It's just a shared repository.
[20:44] <qense> ok
[20:59] <abentley> drubin: For third parties, we support only SREG by default, but you can ask Gary Poster to have our server configured to permit email addresses to be sent to your RP.
[21:01] <blueyed> Me and others have cpu/bandwidth to share for sure and I'd like to spend some of my boinc shares to Launchpad. Please make this easy for others to hel you building packages.
[21:01] <blueyed> It's fucking bad to have to wait for 2 hours for a tiny package (munin) to get built.
[21:01] <maxb> blueyed: How would you manage trust in a distributed buildd network?
[21:02] <blueyed> Please either throw more hardware at LP.net and its services or make it easier for people to donate cpu/bandwidth.
[21:02] <drubin> abentley: Thanks for that, I will contact Gary Poster. I am busy developing something for our loco but currently it is still sitting on localhost :)
[21:02] <blueyed> maxb: I don't know, and I don't care. There must be something.
[21:03] <blueyed> maxb: when it's not possible, then please install more hardware in the local environment.
[21:03] <drubin> abentley: Been trying to google for RP but googleing for 2 letter words isn't very helpful what does RP stand for/
[21:03] <abentley> drubin: Relying Party
[21:04] <maxb> blueyed: Well, I agree the long build times suck sometimes, but personally I'm greatful that Canonical provide the service at all
[21:04] <blueyed> It's really embarrasing.. so much wait and downtime. Ridiculous..
[21:05] <maxb> For free....?
[21:05] <maxb> If you don't like it, you could always build your packages yourself and serve them from your own servers
[21:05] <mneptok> blueyed: please watch the language, despite your frustration.
[21:06] <blueyed> maxb: often it would be better they would not provide it at all: then people would just build it locally: faster for them, and others woud have to add an external repo instead. (which involves adding another apt key etc)
[21:06] <blueyed> mneptok: ok.
[21:06] <mneptok> blueyed: thanks
[21:06] <blueyed> mneptok: what's your plan?
[21:06] <drubin> abentley: thanks again
[21:06] <maxb> blueyed: I don't understand your logic (and just ftr, I'm not affiliated with Canonical)
[21:07] <blueyed> maxb: my logic is: instead of adding backports of packages to my ppa, I'll keep them local (build instantly).
[21:07] <blueyed> maxb: others will not benefit from this, until I provide a public repo.
[21:08] <blueyed> (which takes less time than waiting for a build to complete).
[21:08] <maxb> I think you're hugely overreacting to pronounce the entire service useless just because occasionally Canonical borrow all the builders for other uses
[21:09] <blueyed> PPA is meant for the public, but it's shortness of resources makes this ridiculous.
[21:09] <blueyed> maxb: it's not just this.. also LP.net itself could be faster with more hardware. that's the point.
[21:10] <blueyed> either increase performance by profiling/software or add more cpu/ram. easy.
[21:12] <blueyed> I've been frustrated for so long with Ubuntu/LP.net feedback/performance/... - have given up almost.. now coming back some more, and it's still the same mess..
[21:12] <maxb> blueyed: It seems to me you are saying "Canonical, you are evil for not spending more money providing free services to me."  I
[21:13] <maxb> I don't see how any useful conversation can proceed from that
[21:13] <exarkun> I'm looking at https://bugs.launchpad.net/pyopenssl/+bug/454737
[21:14] <exarkun> There used to be a file attached to it
[21:14] <exarkun> If I follow the "See full activity log" link, then I can see that someone removed that attachment (annoying)
[21:14] <exarkun> That person also attached a new file, though
[21:15] <exarkun> However, I've looked at the bug page pretty hard, and I can't see any indication of that attachment
[21:15] <exarkun> What gives?
[21:15] <blueyed> maxb: I'm offering resources (CPU+mem+bandwidth). And there should just be a concept to add trust into this.
[21:15] <blueyed> maxb: apart from this, yes. why not double the resources?!
[21:16] <blueyed> it's not that much expensive, even myself, although financially quite broke, could provide this.
[21:16] <blueyed> ask people to donate, if necessary.
[21:16] <blueyed> that's the point.
[21:17] <beuno> blueyed, it's not a matter of throwing more hardware at it
[21:17] <exarkun> Oh, no, no new file was attached after all.  Blech.
[21:17] <exarkun> How do I stop people from deleting attachments from bugs?
[21:17] <beuno> and, trust me, servers with 128gb of ram don't dome cheap
[21:17] <blueyed> beuno: why not? and why do you need 128gb of ram?!
[21:18] <beuno> blueyed, because of a million reasons, it's not an application that can scale easily horizontally
[21:18] <blueyed> beuno: my idea is to build a cluster of several 2gb machines.. After all, Google is doing well with clusters of far less capable machines.
[21:18] <beuno> yes
[21:18] <blueyed> beuno: too bad.
[21:18] <beuno> google solves a different problem
[21:19] <beuno> if you want to help tackle performance
[21:19] <beuno> jump into the code
[21:19] <beuno> help optimize it
[21:19] <blueyed> pff
[21:19] <beuno> hardware isn't the problem here
[21:19] <maxb> Is build dispatch really so bad that it's the limiting factor on builder numbers?!
[21:19] <blueyed> I've tried once dive into it to provide a simple "select all" box for the advanced search statuses, but have given up upon it.
[21:20] <blueyed> beuno: it should be.
[21:20] <beuno> maxb, I don't know about builders. Those may be easier to scale.
[21:39] <wgrant> maxb: It is close to being a limiting factor yes.
[21:39] <wgrant> But throwing more builders at the problem would still fix things.
[21:39] <maxb> that is somewhat scary
[21:40] <wgrant> Some stuff is still synchronous for various evil reasons, but it's not that bad yet.
[21:40] <abentley> qense: I've filed this issue as bug #512517
[21:40] <wgrant> (and there is work in progress to fix the couple of things that can still block it)
[21:40] <qense> abentley: thanks! I'll follow that bug.
[21:41] <maxb> I didn't even know it was possible to get a shared repository on codehosting
[21:43] <abentley> maxb: Not a useful one, generally.  But for reasons I've yet to investigate, many of our branches are co-located with shared repositories.  So an aborted push attempt could leave a shared repository.
[21:44] <qense> you could ask mbudde how he pushed the branch
[21:44] <abentley> maxb: e.g. http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev is both a branch and a shared repository.
[21:45] <maxb> Does the sharedness of it matter at all, given it can't have child branches anyway?
[21:46] <abentley> maxb: It's not that it can't have child branches, it's that it *shouldn't*.  You can have a child branch named "backup.bzr" or ".bzr.backup", or ".bzr/*".  This is not recommended, and probably won't be mirrored properly.
[21:47] <abentley> maxb: Realistically, it doesn't matter, which is why I haven't investigated.
[22:54] <timClicks> hi there, can someone direct me to how to tell launchpad to import bugs from an external bug tracker?
[22:54] <timClicks> https://help.launchpad.net/Bugs/MultiProjectBugs#Bugs in external trackers
[22:54] <timClicks> seems to tell me its possible, but not how to do it precisely
[23:10] <thumper> timClicks: to actually import the bugs, or just to track them in an external tracker?
[23:11] <timClicks> thumper: import them, ideally
[23:11] <thumper> timClicks: from where?
[23:11] <timClicks> thumper: http://trac.sahanapy.org
[23:11] <thumper> timClicks: is the project looking to move the bug tracking to Launchpad, or just a mirror of the bugs?
[23:12] <timClicks> thumper: mirror them, at this stage
[23:12] <thumper> timClicks: ok, which TZ are you in?
[23:12] <timClicks> there's still a heated discussion about which system to use
[23:12] <timClicks> NZL (+12 UTC_
[23:12] <thumper> timClicks: because most of the bugs team work europe time
[23:12] <thumper> ha
[23:12] <timClicks> ah, sure
[23:12] <thumper> where in nz?
[23:12] <timClicks> wtgn, was just in LCA2010
[23:12] <thumper> ah, me too
[23:13] <thumper> as in I was also at LCA
[23:13] <timClicks> heh, right
[23:13] <thumper> but I'm in dunners
[23:13] <timClicks> i'll add a Q in the launchpad answers tracker
[23:13] <thumper> timClicks: that might be best
[23:13] <timClicks> i much prefer the lp bug tracker, because we can forward upstream
[23:13] <timClicks> & it's ajaxy
[23:13] <thumper> well, getting there
[23:14] <timClicks> :)
[23:35] <Kamping_Kaiser> timClicks: ah, there it is.
[23:35] <Kamping_Kaiser> timClicks: i spent an hour trying to find sahanapy.org after your talk, and failed :/
[23:35] <timClicks> Kamping_Kaiser: ha
[23:35] <timClicks> I should have made that much more obvious
[23:36] <Kamping_Kaiser> managed to find the php stuff easy, python, no so much
[23:37]  * timClicks nods
[23:37] <timClicks> that was the politics
[23:37] <timClicks> there was a lot of contention about even being allowed to call the python work sahanapy
[23:37] <Kamping_Kaiser> mmmm
[23:37] <timClicks> even though I personally feel it's a much stronger product technically
[23:38] <timClicks> which is probably why it's being run live at http://haiti.sahanafoundation.org/
[23:39] <Kamping_Kaiser> how to branch isn't imediately obvious to e from sahanapy.org either.
[23:39] <timClicks> I want more emphasis on Launchpad
[23:39] <timClicks> but at the moment, we're hosting our own pootle server etc
[23:40] <Kamping_Kaiser> yup
[23:40] <timClicks> after seeing some of the advanced lp features at one of the miniconfs
[23:40] <timClicks> i'm quite sold
[23:40] <timClicks> i've made a request to create a sahana super-project
[23:40] <bdrung> thumper: audacity has already an vcs import: https://code.launchpad.net/~vcs-imports/audacity/trunk
[23:41] <timClicks> that way, https://launchpad.net/sahana will at least make sense
[23:41] <bdrung> thumper: should i really request a new one? what will happen to the old one? aren't the vcs import branches owned by VCS imports?
[23:42] <thumper> bdrung: you can have another pointing to the new location
[23:42] <thumper> bdrung: I can stop the old one
[23:42] <thumper> bdrung: and mark it abandoned
[23:42] <Kamping_Kaiser> timClicks: a link to there somewhere on sanahapy would be handy, if thats a canonical location for source
[23:42] <thumper> bdrung: new import branches are no longer owned by vcsimports by default
[23:42] <thumper> timClicks: what is sahana?
[23:43] <thumper> bdrung: I can also change the main branch link
[23:43] <crimsun> we use it for crisiscamps
[23:43] <timClicks> thumper: it's a "disaster management system" - we collect, aggregate & disseminate lots of info
[23:43] <timClicks> http://haiti.sahanafoundation.org is live
[23:43] <timClicks> we're using about 1/3 of the system's functionality at the moment
[23:44] <bdrung> thumper: https://code.launchpad.net/~bdrung/audacity/trunk
[23:44] <timClicks> live situation maps, 650+ agency list & contacts, field locations, hosptial locations & status, SMS messaging imports where agencies can make pledges
[23:45] <timClicks> we export everything in a very RESTful manner csv, xml, xls, json, gpx, georss, rss
[23:45] <timClicks> plus some domain specific formats
[23:45] <thumper> bdrung: import approved
[23:46] <thumper> bdrung: I'll delete the old one as it never worked
[23:46] <timClicks> like edxl-have (hospital info) & pfif (person finder)
[23:46] <bdrung> thumper: thanks and thanks for all the answers
[23:46] <timClicks> oh - and kml for google maps imports
[23:47] <timClicks> Kamping_Kaiser: launchpad code hosting is canonical for sahanapy
[23:47] <Kamping_Kaiser> timClicks: cheers
[23:47] <timClicks> Kamping_Kaiser: sahana php is still using CVS from sourceforge
[23:47] <thumper> ok
[23:47] <timClicks> Kamping_Kaiser: mobile apps use lp, I think
[23:48] <bdrung> thumper: can you can the default series?
[23:48] <Kamping_Kaiser> timClicks: i found the cvs... i shuddered ;)
[23:48] <thumper> bdrung: I can make that the primary branch, yes
[23:48] <thumper> bdrung: I'll wait until the import has succeeded
[23:48] <bdrung> thumper: thanks
[23:49] <timClicks> Kamping_Kaiser: ya, I know
[23:49] <thumper> timClicks: so the code at lp:sahana is what? a python binding?  the main code?
[23:50] <thumper> timClicks: a project can't be converted to a project group, but we can create one
[23:50] <timClicks> well, tbh it's a vcs import of the php
[23:50] <timClicks> it's a bit messed up, really
[23:50] <bdrung> thumper: can you have a look at bug https://bugs.launchpad.net/launchpad-code/+bug/508932 if you have time to?
[23:50] <timClicks> is it possible to create a project group 'sahana'
[23:51] <thumper> timClicks: not with a project called sahana
[23:51] <thumper> timClicks: projects and project groups share a namespace
[23:51] <thumper> timClicks: have you asked a question about a project group?
[23:51] <timClicks> thumper: yes
[23:51] <timClicks> ideally, I would like project-group 'sahana' and projects 'sahana-py' 'sahana-php' 'sahana-j2me'
[23:52] <timClicks> can we rename sahana > sahana-py
[23:52] <timClicks> and break the link w/ the vcs import?
[23:53] <thumper> timClicks: projects can be renamed, but only by admins, best done early in a projects life
[23:53] <thumper> timClicks: it might be worthwhile putting that in the LP question
[23:55] <thumper> bdrung: I think the gnome-colors problem is the code committed a symlink to a file that doesn't exist
[23:55] <thumper> bdrung: I know that jelmer was looking at that in bzr-svn
[23:55] <thumper> bdrung: and has some solution
[23:56] <timClicks> thumper: I have admin rights via a team to the sahana project
[23:56] <thumper> timClicks: ah, but not LP admin rights :)
[23:56] <thumper> spm: you around?
[23:56] <timClicks> ahh gotcha