[00:13] <lifeless> mmm
[00:13] <wgrant> Was this added as part of the inline comment stuff recently?
[00:13] <wgrant> I thought this used to work.
[00:13] <wgrant> And we recently started getting message page timeouts.
[00:14] <wgrant> They appeared from nowhere on top of the timeout reports a couple of weeks ago.
[00:19] <lifeless> mwhudson: whats up ?
[00:19] <Fudge> hi looking for help to contact launchpad to ask for intervention or guidance on how to prevent a ppa from being deleted
[00:24] <jelmer> Fudge: what is the problem exactly?
[00:24] <Fudge> jelmer  someone on vinux deleted our natty ppa
[00:25] <Fudge> i am not linked with launchpad but as i am a contributor to vinux ive come to ask, the owner hasnt asked and thinks it cant be  stopped and may have to get all our users to chagne the ppa to another
[00:25] <Fudge> change
[00:25] <Fudge> i thought it may be possible to ask for the deletion to be stopped and to find out who marked it for deletion
[00:26] <Fudge> or if i can no tbe told for tony the owner to be emailed in regards to it
[00:26] <jelmer> Fudge: As far as I know PPAs can't really be undeleted
[00:27] <Fudge> it has not been deleted yet, just marked for deletion
[00:27] <jelmer> Fudge: One of the Launchpad help contacts might be able to help further. If they don't show up here, I would recommend filing a question about this: https://answers.launchpad.net/launchpad
[00:27] <wgrant> There will be no help contacts for at least 12 hours, so that won't work.
[00:27] <wgrant> Fudge: Which PPA?
[00:27] <wgrant> Fudge: The files can be recovered for a few days after deletion, if required.
[00:27] <Fudge> vinux/natty-/ubuntu natty
[00:28] <wgrant> And we can sort of revive a PPA sort of.
[00:28] <Fudge> its still there currently
[00:28] <wgrant> But I really wouldn't trust a PPA if you have people deleting it randomly.
[00:28] <wgrant> Because anyone who can delete it can upload to it as well.
[00:28] <Fudge> its been raised with dev team to limit who can access that but no action has been taken yet
[00:28] <Fudge> clearly this will make it happen correctly, im told its  not an easy thing to do as a user is asked several times to confirm the action
[00:29] <wgrant> The dev team is unconcerned that all these people have root access on users' systems? That is a worry.
[00:29] <Fudge> hell yeah
[00:29] <Fudge> i think anyone who joins vinux project on launchpad gets access, no idea why owner set it up like that
[00:29] <Fudge> doesnt seem as if it would be default
[00:29] <wgrant> Do you have a link to the PPA page?
[00:29] <wgrant> I don't see a PPA named natty-
[00:30] <wgrant> There is natty-testing.
[00:30] <Fudge> maybe its already gone?
[00:30] <wgrant> No.
[00:30] <Fudge> im not very good with launchpad, havnt learned all about it yet, btw im visually impaired
[00:30] <wgrant> Well, it may already but gone, but I'd still be able to see it.
[00:30] <wgrant> And I can't see it, so the name is probably wrong. Hmm.
[00:30] <Fudge> may i show you my source url?
[00:30] <wgrant> Sure.
[00:31] <wgrant> That would tell me what I need to know.
[00:31] <Fudge> deb http://ppa.launchpad.net/vinux/natty-/ubuntu natty main
[00:31] <wgrant> Ah, there it is.
[00:31] <wgrant> Thanks.
[00:31] <Fudge> thank you
[00:31] <wgrant> I was looking in the wrong place.
[00:31] <Fudge> :) i do that a lot loL
[00:33] <wgrant> It's odd. If someone clicked the delete button, it should be gone from ppa.launchpad.net by now.
[00:33] <wgrant> I wonder if someone has just disabled it.
[00:33] <wgrant> I've asked a sysadmin to check what state it is in.
[00:33] <Fudge> thank you so much mate
[00:34] <Fudge> I emailed Tony who is in the UK the creator of the ppa to add me to the vinux team on launchpad so I can make enquries too as well as asked him what steps he has taken to prevent it from being deleted. but think he has done little
[00:35] <wgrant> Fudge: Good news, it's not actually deleted, just disabled. Anyone in ~vinux can go to https://launchpad.net/~vinux/natty-/+edit and check the 'Enabled' flag to bring it back.
[00:35] <Fudge> woohoo ill get someone onto it :D
[00:36] <Fudge> are you able to see who marked it disablexd
[00:36] <Fudge> disabled
[00:36] <wgrant> I can try to grep through our logs, but may not be able to tell for sure. I'll see what I can find.
[00:36] <Fudge> thanx
[00:38] <wgrant> Fudge: Do you have any idea when this might have happened?
[00:38] <Fudge> last couple of days I believe
[00:38] <Fudge> is that narrow enough field
[00:38] <Fudge> timeframe i mean
[00:38] <wgrant> Yep.
[00:49] <Fudge> out of luck wgrant ?
[01:09] <Fudge> wgrant  im a member as well now
[01:10] <wgrant> Fudge: I can't find any requests that could have disabled that PPA in the last three days, unfortunately.
[01:11] <Fudge> mm i guess its not as simple as grep vinux | grep disable lol
[01:11] <wgrant> It is pretty much that simple, but there are a *lot* of logs.
[01:11] <Fudge> I appreciate you trying
[01:12] <Fudge> when the main guy wakes we will look at who has access, is it possible to have members that can not make changes, such as only uplaod to testing ppa where it has to be tested and aprooved
[01:12] <Fudge> like some kind of flag system based per user
[01:14] <wgrant> Anybody in the team that owns a PPA can upload to or disable or delete the PPA. However, you can use the API's newComponentUploader method (see https://help.launchpad.net/API/) to allow other people or teams to upload to particular PPAs, in addition to the owner.
[01:14] <Fudge> ah gr88
[01:22] <mwhudson> lifeless: https://bugs.launchpad.net/launchpad/+bug/855951
[01:24] <wgrant> mwhudson: Ah, heh, this is your fault, sort of.
[01:24] <lifeless> s/sort of/entirely/ :P
[01:25] <wgrant> mwhudson: We had memcached disabled on BugTask:+index
[01:25] <mwhudson> wgrant: because of feature flags?
[01:25] <mwhudson> wgrant: aah
[01:25] <wgrant> mwhudson: But your flag changes broke the pageid and team scopes.
[01:25] <wgrant> Must check if that's deployable yet...
[01:25] <lifeless> I've commented to this effect
[01:25] <wgrant> It is deployable!
[01:25] <wgrant> But let's QA a bit more first.
[01:25] <wgrant> StevenK: ^^
[01:25] <mwhudson> wgrant: ah, i relanded my branch but didn't do anything to fix the pageid scope
[01:26] <wgrant> mwhudson: I didn't realise it was broken too until now :/
[01:26] <mwhudson> oh well, it might be easy to fix
[01:26] <StevenK> wgrant: Working on it, qas is timing out a lot
[01:27] <lifeless> mwhudson: pageid scope was broken too ? howso ?
[01:27] <mwhudson> lifeless: that's what wgrant just said
[01:27] <wgrant> lifeless: I don't know how, but it no longer works.
[01:27] <lifeless> I'm asking not asserting ;)
[01:27] <mwhudson> it's the same sort of thing though, reading things out of the request before they are set
[01:28] <lifeless> I assumed that the bust scope for team broke everything
[01:28] <mwhudson> no
[01:28] <lifeless> ok
[01:28] <lifeless> so this is critical then
[01:28] <wgrant> TeamScope was broken by the move away from LaunchBag.
[01:28] <lifeless> mwhudson: want to rollback your new landing
[01:28] <mwhudson> wgrant: no
[01:28] <wgrant> mwhudson: Oh?
[01:28] <mwhudson> wgrant: it was broken by trying to find the person during featurecontroller construction
[01:29] <wgrant> Well, yes.
[01:29] <mwhudson> rather than when the scope was checked
[01:29] <wgrant> Which was done when LaunchBag was removed.
[01:29] <mwhudson> wgrant: yes, but that's irrelevant
[01:29] <mwhudson> really
[01:30] <mwhudson> because the user is added to the launchbag when request.setPrincipal is called
[01:30] <mwhudson> s/when/at the same time as/
[01:31] <wgrant> Sure, but to remove LaunchBag you had to pass in the user from elsewhere, which meant working it out early.
[01:31] <mwhudson> wgrant: no
[01:32] <mwhudson> wgrant: i didn't want TeamScope to reference the request, that's why i read it early
[01:32] <mwhudson> (implicitly reference in this case, to be fair)
[01:32] <lifeless> mwhudson: -> -dev?
[01:32] <mwhudson> lifeless: yes
[02:12] <jo-erlend> if I delete my PPA and then recreate it later, will it be completely gone, or will it remember the package versions, etc?
[02:13] <mwhudson> you won't be able to recreate it with the same name, iiuc
[02:13] <jo-erlend> oh
[02:43] <jo-erlend> how do I mark a bug as fixed?
[02:44] <RAOF> Set the status to ?fix released?
[02:44] <jo-erlend> "how do I set a bugs status to fixed released"?
[02:46] <RAOF> Be logged in, click on the existing status, click on ?fix released? in the popup?
[02:46] <jo-erlend> ah, there you go. Thanks. :)
[02:46] <jo-erlend> actually... When should I set it fixed release and when do I set it fix committed?
[02:48] <jo-erlend> my fix has been merged into trunk of the project, but I don't think a new package have been created for it. Does that mean it's committed, but not released?
[02:58] <RAOF> That's a project-specific policy.
[03:00] <jo-erlend> oh, ok.
[03:07] <lifeless> jo-erlend: many folk work this way:
[03:07] <lifeless>  - if a developer should still know about it, it is not fix released (or any other 'hidden by default' status)
[03:12] <jo-erlend> which are hidden by default?
[03:13] <lifeless> fix released
[03:13] <lifeless> invalid
[03:13] <lifeless> wontfix
[03:13] <lifeless> opinion
[03:13] <lifeless> I *think* thats it
[03:13] <jo-erlend> oh, ok, great. Thanks :)
[03:14] <lifeless> the largest number of users of your bug tracker is your developers
[03:14] <lifeless> with second largest being users :)
[03:14] <lifeless> so its a balancing act, but usually its better to optimise for developer time
[03:15] <jo-erlend> yes, that sounds reasonable :)
[08:43] <chrisccoulson> hi, i'm trying to set the contact address for ~mozillateam on launchpad to ubuntu-mozillateam@lists.ubuntu.com, but launchpad tells me that is already associated with https://launchpad.net/~ubuntu-mozillateam, which only seems to exist as a consequence of a package upload in gutsy
[08:43] <chrisccoulson> is there any chance of rectifying that?
[08:47] <xrg_> Hello. What is the preferred setup for some automated bot pushing branches onto LP? with separate ssh keys? separate account?
[08:51] <maxb> chrisccoulson: We can merge the teams, but for some reason LP insists that you claim the ~ubuntu-mozillateam team before we can merge it
[08:56] <chrisccoulson> maxb, ok, just tried that. i'm waiting on an e-mail now though :)
[09:04] <lag> Does anyone know what's going on with LP's unloading ability
[09:04] <lag> It appears to be shot
[09:05] <wgrant> Unloading ability?
[09:06] <lag> I try to upload a tar.gz to "Download files for this release" milestone page
[09:07] <lag> It uploads, then when it gets to 99% it says, "There as been a problem, please try again"
[09:07] <lag> And now I'm trying to dput into my PPA
[09:07] <lag> I get this:
[09:07] <lag> Uploading to ppa (via ftp to ppa.launchpad.net):
[09:07] <lag>   Uploading linux-ux500_3.0.0-1000.0.dsc: done.
[09:07] <lag>   Uploading linux-ux500_3.0.0-1000.0.tar.gz: 98763k/98764k
[09:07] <lag> And it just hangs there with 1k to go
[09:07] <lag> This has happened multiple times

[09:09] <wgrant> lag: Have you tried uploading to your PPA with SFTP instead of FTP?
[09:09] <wgrant> It looks like some router between you and LP isn't playing nice with FTP.
[09:09] <wgrant> SFTP is a bit harder to mess with, so is more likely to be reliable.
[09:12] <lag> wgrant: How do I do that?
[09:13] <wgrant> lag: https://help.launchpad.net/Packaging/PPA/Uploading#Uploading_with_SFTP
[09:14] <bigjools> https://answers.launchpad.net/launchpad/+faq/1738
[09:14] <lag> Will that cover dput and the upload button on my milestone page?
[09:14] <bigjools> the FAQ explains it better
[09:15]  * lag looks
[09:15] <wgrant> lag: Release file uploads are via HTTP, and unrelated to FTP/SFTP.
[09:16] <wgrant> Perhaps something is timing your HTTP connection out?
[09:16] <lag> I don't know what - the uploader in the bottom right corner goes up to 99%
[09:21] <bigjools> it's a known problem with FTP, no idea other than to guess at dodgy router natting
[09:23] <lag> Yes, that's made things much worse :)
[09:23] <lag> When it asks for login, is that my LP name 'lag', or one of my email addresses (that I use for SSO)
[09:24] <wgrant> Your LP name.
[09:24] <lag>   linux-ux500_3.0.0-1000.0.tar.gz:

[09:24] <wgrant> Yeah, dput's SFTP implementation doesn't report progress information, unfortunately.
[09:25] <lag> Ah
[09:25] <lag> Thanks for the heads-up
[09:25]  * lag waits
[09:52] <xrg_> up : how to push branches from a build machines to LP? with restricted ssh keys?
[13:50] <RFleming> Greetings and Salutations!
[13:51] <RFleming> I need help deciding if LaunchPad is right for me.
[13:51] <RFleming> anyone available for a chat?
[13:54] <dobey> RFleming: do you have a definition of what exactly is "right" for you?
[13:56] <RFleming> dobey: I do.  I'm in private business, and need issue tracking on deploying a rather large app internally.  There are several contractors outside of our WAN who will need access to the issue tracking system.  We currently use bugzilla internally, but with me and a couple of other guys doing stuff with open source and familiar with launchpad... well we're wondering if it's possible to have a secure launchpad
[13:56] <RFleming> project for us to use externally.
[13:59] <dobey> ah ok. i don't think i can answer that then. i think you want to look at this: https://launchpad.net/+tour/join-launchpad
[14:00] <RFleming> dobey: that's perfect!
[14:00] <dobey> RFleming: particularly the box in the bottom left corner there :)
[14:00] <RFleming> I have no problem paying for it :)
[14:00] <RFleming> dobey: one other thing.
[14:01] <RFleming> internally, we're using CVS and Bugzilla.  How can I install LaunchPad internally?
[14:02] <dobey> launchpad is really only designed to be run on launchpad.net afaik, and while i believe it is possible to run a local instance for testing; i don't think it is a supported means of use for production
[14:03] <RFleming> ahh
[14:03] <dobey> i am not on the launchpad team, btw. i just use it very heavily :)
[14:03] <dholbach> hiya
[14:03] <dobey> hi dholbach
[14:04] <dholbach> are launchpadlib hacking tips collected somewhere? :)
[14:04] <dobey> i don't know if such a thing exists
[14:04] <dobey> there is lp:lptools though :)
[14:05] <dholbach> I just need the number of bugs of a team, but something like launchpad.people["ubuntu-security-sponsors"].searchTasks(status=['Opinion', 'Invalid', "Won't Fix", 'Expired', 'Fix Released']) seems to cause an internal error it seems
[14:05] <dholbach> right, I could take a look at lp:ltools
[14:05] <dholbach> http://blog.launchpad.net/api/three-tips-for-faster-launchpadlib-api-clients was the only thing I found so far
[14:05] <dobey> dholbach: ah, it's probably causing the db query to timeout, since the query is probably very very large :)
[14:06] <dholbach> I nicked "int(collection._wadl_resource.representation['total_size'])" from somewhere and thought that'd help
[14:06] <dobey> dholbach: if you split that up into separate queries for each status, it might work better; but some of them might still timeout
[14:06] <dholbach> but it might be the db query
[14:07] <dobey> dholbach: doing a query on the toplevel bugs object might also be more prudent
[14:07] <dholbach> dobey, what do you mean by toplevel bugs?
[14:08] <dobey> dholbach: https://launchpad.net/+apidoc/1.0.html#bugs but i guess it only has createBug() it seems :(
[14:08] <dholbach> ah ok
[14:10] <dobey> dholbach: you might want to refine the searchTasks() also; with your query i think you're getting every bug related to that team in any manner; not sure if that's what you want
[14:10] <dobey> dholbach: omit_duplicates=True might be useful, for example ;)
[14:11] <dholbach> I'll try omit_duplicates=True - thanks dobey
[14:15] <dholbach> doesn't work either, but at least I found out from https://dev.launchpad.net/Foundations/Webservice/Performance/CollectionLength that I can remove the 'total_size' code :)
[14:15] <dholbach> ok, I guess it means, I need to go back to screen scraping for now
[14:19] <ams_cs> I'm having lots of trouble with bzr integration in LP. Is there is known problem, or is it just me?
[14:58] <ScottSanbar> ams_cs: What kind of problems?
[15:00] <ams_cs> ScottSanbar: the diff on branch and merge pages never appears, and (presumably) this leads to branch merges going unnoticed and the branches have to be tidies manually
[15:01] <ams_cs> See here: 7 branches "have not been scanned yet" .... https://code.launchpad.net/gcc-linaro
[15:04] <ScottSanbar> ams_cs:  I see that.  What was the bzr command(s) you used that caused this?
[15:06] <ams_cs> ScottSanbar: nothing new or unusual - they're straight-forward "bzr push", sometimes with an explicit --stacked-on, perhaps, but probably not even that, in most cases
[15:06] <ams_cs> ScottSanbar: what is unusual, I'm told, is the size of the gcc repo
[15:06] <ams_cs> bzr does not cope well with it, although it's far better than it was
[15:08] <ScottSanbar> ams_cs: Ok.  Good luck.
[15:09] <ScottSanbar> ams_cs:  Do you have a hint as to how to go forward to fix the problem, other than manually doing stuff, yet?
[15:10] <ams_cs> ScottSanbar: I'd guess that a bzr operation is crashing or timeing out
[15:10] <ams_cs> but I have no access to the logs, or whatever to know
[15:11] <ScottSanbar> ams_cs: is there anyway to do the necessary automated merges, etc. locally then just push the final "pre-tidied" stuff up?
[15:12]  * ams_cs does not understand
[15:13] <ams_cs> The problem is, besides the missing diffs, that when I do "bzr merge; bzr commit; bzr push" it doesn't detect the merge and update the branch status
[15:13] <ams_cs> I have to go into the launchpad site, and manually alter the branch attributes
[15:14] <ScottSanbar> ams_cs:  can you replicate the launchpad repo on your local PC in a local bzr "repo" then do all your merging and commiting locally, then just simply push up the pre-merged, committed (ie, "tidy'ed") stuff up?
[15:15] <ams_cs> ScottSanbar: of course, that's what I just said ....
[15:15] <ams_cs> ScottSanbar: I don't expect the site to do my merges for me!
[15:16] <ams_cs> ScottSanbar: I just expect it to notice I've done it, as it always has done, and remove the branches from the active branches page
[15:17] <ScottSanbar> ams_cs:  Oh, I see how it works - so you make all your changes locally, then when you push them up, you expect bazaar to notice all the changes correctly and update the launchpad repo to reflect the changes you made on your local repo?
[15:17] <ams_cs> ScottSanbar: exactly so
[15:18] <ScottSanbar> ams_cs:  Ok, thanks for helping me learn.  So, you have and everyone else working on this project has a complete copy of the launchpad repo on their local PCs?
[15:18] <ams_cs> when it's working, it normally changes the merge proposal to state "Merged", and the branch status similarly
[15:19] <ams_cs> yes, that's how bzr works
[15:19] <ScottSanbar> ams_cs:  Ok, thanks again for the info.  So, if you are working on your local repo, and someone else has changed their repo and updated launchpad, how do you get their changes into your local repo?
[15:21] <ams_cs> bzr merge would be one way
[15:21] <ams_cs> or start again with bzr pull and reapply your patch
[15:22] <ams_cs> bzr doesn't have "rebase" :(
[15:22] <exarkun> there's a plugin
[15:22] <ScottSanbar> sounds like kind of a pain
[15:22] <exarkun> works pretty well
[15:23] <ScottSanbar> what's the plugin name?
[15:23] <ScottSanbar> exarkun
[15:23] <ams_cs> exarkun: yes, but it takes so long to run that it's actually quicker to do it manually, and once it trashed my repo
[15:23] <exarkun> "rewrite" I guess
[15:24] <exarkun> ams_cs: That sounds pretty different from 'bzr doesn't have "rebase"'.
[15:24] <ams_cs> exarkun: it has a plugin that I no longer trust or find useful
[15:25] <exarkun> ams_cs: That's unfortunate.  You should have said that in the first place though.
[15:25] <exarkun> Then I could have kept ignoring the conversation :)
[15:26] <ScottSanbar> ams_cs, exarkun: I can see where manually doing pulls could be a very good solution vs. an automated solution that might be non-transparent
[15:26] <ams_cs> exarkun: to be fair to the rewrite plugin, it probably wasn't written with a project the scale of gcc in mind. It has 10's of thousands of files, and 100,000+ revisions, and makes bzr creak
[15:27] <exarkun> ams_cs: I am all for software that always works correctly, or at least fails without destroying data.
[15:27] <ams_cs> ScottSanbar: yes, there are always conflicts in the ChangeLog
[15:27] <exarkun> "there's a lot of data" is a bad excuse for failure
[15:28] <ams_cs> exarkun: true. I don't know what bzr's excuse it for not scaling well. git works fast and well, but doesn't integrate with LP, more's the pity
[15:28] <exarkun> Fortunately I've been lucky, it seems, with my use of the rewrite plugin, and haven't had issues (and I've only used it with small projects).  I really am sad to hear that it has problems, particularly repository corrupting problems.
[15:28] <exarkun> But I am glad to learn about the issue, rather than continuing to be ignorant of it.  I'll think twice before I use rewrite in the future.
[15:29] <exarkun> And I look forward to the day when bzr doesn't corrupt itself so readily (I've had _plenty_ of that sort of problem with bzr in other contexts).
[15:29] <ScottSanbar> ams_cs, exarkun:  Thanks for taking the time to help me learn.
[15:32] <exarkun> Speaking of changelog conflicts, here's one solution to that problem, http://twistedmatrix.com/trac/browser/trunk/twisted/python/test/test_release.py#L1523 and http://twistedmatrix.com/trac/browser/trunk/twisted/python/_release.py#L605
[15:32] <exarkun> And an example of its use in practice, http://twistedmatrix.com/trac/browser/trunk/twisted/topfiles
[15:33] <exarkun> Another solution is that it's possible to write custom merge algorithms for bzr to use.  It probably wouldn't be too difficult to implement a changelog merge algorithm that could deal with the conflict that always arises.
[15:34] <ams_cs> that's a nice feature!
[16:02] <ScottSanbar> hello-debhelper recipe fails in launchpad: https://launchpadlibrarian.net/80630411/buildlog.txt.gz https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/hello-debhelper/natty
[16:09] <czajkowski> Aloha
[17:07] <chmrr> I'm one of the upstream maintainers of https://launchpad.net/rt/ -- https://launchpad.net/rt/+packages shows that request-tracker3.8 packages list rt/4.0 as upstream, instead of rt/3.8  What's the right way to fix this on launchpad, as I don't seem to have rights to change them myself?
[17:08] <chmrr> Nevermind, #ubuntu-devel managed to set things right.
[17:34] <dobey> exarkun: or better solution is to just not maintain a separate changelog file in vcs; vcs log messages should be high enough quality to be in a ChangeLog too. :)
[17:36] <exarkun> dobey: Perhaps.  But there are different audiences for the information.  Certainly a ChangeLog which duplicates the vcs history is a waste of effort.  A ChangeLog that is suitable for consumption by a slightly less technical audience can be valuable though.
[17:42] <dobey> exarkun: are most of your issues with "bzr corrupting itself so readily" with conflicts in such files? i haven't had any real issues with bzr in quite some time
[17:42] <exarkun> dobey: no, they're mostly with shared repositories
[17:43] <exarkun> concurrent "bzr pull" processes stepping on each other and producing a state that can't be recovered from automatically
[17:46] <dobey> ah
[17:54] <chmrr> Out of curiosity, how much work is left to be able to import non-HEAD branches from git?  I know https://bugs.launchpad.net/launchpad/+bug/380871 is relevant, but only looks to be the backend part
[19:04] <chrissbx> Hello. How do I access launchpad with git?
[19:04] <TheEvilPhoenix> chrissbx:  launchpad doesnt support git
[19:05] <TheEvilPhoenix> chrissbx:  they support bzr directly, but you can link to code in git, or request it be pulled into bzr
[19:05] <chrissbx> (How do I clone a repo at all? Can't find any url on https://code.launchpad.net/~jonls/redshift/trunk)
[19:05] <chrissbx> Well, I want to take a look at history etc.; I'm fine with converting it locally, what would be the way to go?
[19:07] <cnd> is there a way to get ddebs built and published in ppas?
[19:29] <chrissbx> Ok, so the answer is: git init --bare trunk.git && bzr fast-export --export-marks trunk.git/marks trunk/.bzr/ | (cd trunk.git/ && git fast-import --export-marks=marks )
[19:29] <chrissbx> (not sure about the marks file path, seems to have to be inside the git dir, but dunno why)
[19:30] <chrissbx> And the answer to the first question is: bzr branch https://code.launchpad.net/~jonls/redshift/trunk
[19:51] <doko> spam at https://bugs.launchpad.net/bugs/653196
[20:00] <maxb> hidden
[20:26] <RFleming> Greetings and salutations!
[20:26] <RFleming> Does anyone know how long staging.launchpad.net will be offline?
[23:11] <cnd> wgrant, I've been trying to find info on how to enable ddebs in ppa builds
[23:11] <cnd> based on bugs, it looks like you might know what's going on there?